Re: [PATCH 0/4] Track exported dma-buffers with memcg
On Wed, Jan 11, 2023 at 11:56:45PM +0100, Daniel Vetter wrote: > [...] > I think eventually, at least for other "account gpu stuff in cgroups" use > case we do want to actually charge the memory. > > The problem is a bit that with gpu allocations reclaim is essentially "we > pass the error to userspace and they get to sort the mess out". There are > some exceptions (some gpu drivers to have shrinkers) would we need to make > sure these shrinkers are tied into the cgroup stuff before we could enable > charging for them? > No, there is no requirement to have shrinkers or making such memory reclaimable before charging it. Though existing shrinkers and the possible future shrinkers would need to be converted into memcg aware shrinkers. Though there will be a need to update user expectations that if they use memcgs with hard limits, they may start seeing memcg OOMs after the charging of dmabuf. > Also note that at least from the gpu driver side this is all a huge > endeavour, so if we can split up the steps as much as possible (and get > something interim useable that doesn't break stuff ofc), that is > practically need to make headway here. This sounds reasonable to me.
Re: [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
Hi
Am 11.01.23 um 20:21 schrieb Aaron Plattner:
On 1/11/23 8:58 AM, Javier Martinez Canillas wrote:
Hello Daniel,
On 1/11/23 16:41, Daniel Vetter wrote:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
restore
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
symptoms
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
Maybe adding a Fixes: ee7a69aa38d8 tag here too ?
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the
backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ba565515480d..a1821d369bb1 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int
aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
Maybe mention in the commit message that you are doing this change,
something like:
"Instead of calling aperture_remove_conflicting_devices() to remove
the conflicting
devices, just call to aperture_detach_devices() to detach the device
that matches
the same PCI BAR / aperture range. Since the former is just a wrapper
of the latter
plus a sysfb_disable() call, and now that's done in this function but
only for the
primary devices"
Patch looks good to me:
Reviewed-by: Javier Martinez Canillas
Thanks Daniel and Javier!
I wasn't able to reproduce the original problem on my hybrid laptop
since it refuses to boot with the console on an external display, but I
was able to reproduce it by switching the configuration around: booting
with i915.modeset=0 and with an experimental version of nvidia-drm that
registers a framebuffer console. I verified that loading nvidia-drm
Thank you for testing.
One thing I'd like to note is that using DRM's fbdev emulation is the
correct way to support a console. Nvidia-drm's current approach of
utilizing efifb is fragile and requires workarounds from distributions
(at least here at SUSE). Steps towards fbdev emulation are much appreciated.
Best regards
Thomas
breaks the efi-firmware framebuffer on Intel on Arch's
linux-6.1.4-arch1-1 kernel and that applying this patch series fixes it. So
Tested-by: Aaron Plattner
FWIW, the bug ought to be reproducible with i915.modeset=0 + any other
drm driver that registers a framebuffer.
-- Aaron
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
Hi
Am 11.01.23 um 17:37 schrieb Daniel Vetter:
On Wed, Jan 11, 2023 at 05:20:00PM +0100, Thomas Zimmermann wrote:
Hi
Am 11.01.23 um 16:41 schrieb Daniel Vetter:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ba565515480d..a1821d369bb1 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
There's another sysfb_disable() in aperture_remove_conflicting_devices()
without the branch but with a long comment. I find this slightly confusing.
I'd rather add a branched sysfb_disable() plus the comment to
aperture_detach_devices(). And then add a 'primary' parameter to
aperture_detach_devices(). In aperture_remove_conflicting_devices() the
parameter would be unconditionally true.
Yeah I was on the fence, but should be easy to redo with all the prep work
out of the way. It does mean we call sysfb_disable once for every bar, but
that shouldn't matter in any reasonable case :-)
Or leave it as is. It's not so important. The idea of the current design
was that aperture_remove_conflicting_device() would be the general
implementation and aperture_remove_conflicting_pci_device() would be a
helper that only detects the correct PCI BAR. That never really worked
in practice.
Best regards
Thomas
-Daniel
Best regards
Thomas
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
}
if (!primary)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/2] drm/panel: boe-tv101wum-nl6: Reduce lcm_reset to send initial code time
Re: [PATCH 0/6] Enable KFD to use render node BO mappings
Am 12.01.23 um 02:31 schrieb Felix Kuehling: Rebased on latest amd-staging-drm-next. This is meant to be the final review of this series, assuming no more issues are found. This patch series enables KFD to interoperate more closely with DRM render nodes. ROCm user mode already uses DRM render nodes to create its GPU VM contexts and to CPU-map its GEM buffer objects. This patch series adds an API to let KFD export its BOs as DMABufs, so they can be imported into the DRM render nodes. This enables more flexible virtual memory mappings using DRM_IOCTL_AMDGPU_GEM_VA. Patches 1 and 2 deal with the exporting and importing of DMABufs. The remaining patches let KFD validate and update GPUVM mappings managed through render nodes. The user mode side of this patch series can be seen in libhsakmt and KFDTest where we improve integration with libdrm (initializing amdgpu_device instances) to enable DMABuf imports into the render nodes representing KFD GPU VM contexts. KFDTest is modified to test evictions and validations of BOs mapped through amdgpu_bo_va_op: https://github.com/fxkamd/ROCT-Thunk-Interface/commits/fxkamd/dmabuf As a consequence, applications using Mesa and ROCm in the same process on the same GPU will now share a single render node FD and GPUVM address space. The DMABuf export API will also be used later for upstream IPC and RDMA implementations. Nice, I don't have time to check everything in detail but at least from a high level skimming over this I can't see anything obvious wrong. Feel free to add an Acked-by: Christian König to the series. Christian. Felix Kuehling (6): drm/amdgpu: Generalize KFD dmabuf import drm/amdkfd: Implement DMA buf fd export from KFD drm/amdkfd: Improve amdgpu_vm_handle_moved drm/amdgpu: Attach eviction fence on alloc drm/amdgpu: update mappings not managed by KFD drm/amdgpu: Do bo_va ref counting for KFD BOs drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 + .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 196 -- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 55 + include/uapi/linux/kfd_ioctl.h| 14 +- 8 files changed, 219 insertions(+), 77 deletions(-)
Re: [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes
Hi, > > > I think we need to do a bit of refactoring/documenting here first. > > [Kasireddy, Vivek] Just for reference, here is Dave's commit that added this > > property for qxl: > > commit 4695b03970df378dcb93fe3e7158381f1e980fa2 > > Author: Dave Airlie > > Date: Fri Oct 11 11:05:00 2013 +1000 > > > > qxl: add a connector property to denote hotplug should rescan modes. > > > > So GNOME userspace has an issue with when it rescans for modes on > > hotplug > > events, if the monitor has no EDID it assumes that nothing has changed > > on > > EDID as with real hw we'd never have new modes without a new EDID, and > > they > > kind off rely on the behaviour now, however with virtual GPUs we would > > like to rescan the modes and get a new preferred mode on hotplug events > > to handle dynamic guest resizing (where you resize the host window and > > the > > guest resizes with it). > > Ok this is just terrible. Because _anything_ without an EDID is impacted, > and we're certainly not going to sprinkle this property all over gpu > drivers just so Gnome takes the right path. Oh, and (newer) virtio-gpu actually has EDIDs ... take care, Gerd
Re: [PATCH 1/1] drm/ttm: Fix of rework on ttm_resource to use size_t type commit
Am 11.01.23 um 23:45 schrieb Kevin Brace:
From: Kevin Brace
Commit e3c92eb4a84fb0f00442e6b5cabf4f11b0eaaf41 (drm/ttm: rework on
ttm_resource to use size_t type) reworked ttm_resource{} to use size_t
type size instead of unsigned long type num_pages. In that commit,
when ttm_move_memcpy() is being called from ttm_bo_move_memcpy(),
the code was changed to specify the page size from ttm->num_pages
instead of the original code's dst_mem->num_pages. Since the commit
is about reworking ttm_resource{} to use size_t type size instead of
unsigned long type num_pages, the commit should have specified page
size converted version of dst_mem->size. Use PFN_UP macro to convert
dst_mem->size to page size.
Zack already came up with the same patch, please review that one instead.
Thanks,
Christian.
Signed-off-by: Kevin Brace
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ba3aa0a0fc43..da5493f789df 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -173,7 +173,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
- ttm_move_memcpy(clear, ttm->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, PFN_UP(dst_mem->size), dst_iter,
src_iter);
if (!src_iter->ops->maps_tt)
ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
Re: [PATCH] drm/ttm: Fix a regression causing kernel oops'es
Am 11.01.23 um 18:50 schrieb Zack Rusin:
From: Zack Rusin
The branch is explicitly taken if ttm == NULL which means that to avoid
a null pointer reference the ttm object can not be used inside. Switch
back to dst_mem to avoid kernel oops'es.
This fixes kernel oops'es with any buffer objects which don't have ttm_tt,
e.g. with vram based screen objects on vmwgfx.
Signed-off-by: Zack Rusin
Fixes: e3c92eb4a84f ("drm/ttm: rework on ttm_resource to use size_t type")
Cc: Somalapuram Amaranath
Cc: Christian König
Reviewed-by: Christian König
Should I push it to drm-misc-fixes?
Thanks,
Christian.
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fee7c20775c0..12017ec24d9f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -183,7 +183,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
- ttm_move_memcpy(clear, ttm->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, PFN_UP(dst_mem->size), dst_iter,
src_iter);
if (!src_iter->ops->maps_tt)
ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
RE: [PATCH] drm/amd/display: fix possible buffer overflow relating to secure display
[AMD Official Use Only - General]
Reviewed-by: Alan Liu
Thanks,
Alan
-Original Message-
From: Mahfooz, Hamza
Sent: Thursday, January 12, 2023 2:17 AM
To: amd-...@lists.freedesktop.org
Cc: Mahfooz, Hamza ; Wentland, Harry
; Li, Sun peng (Leo) ; Siqueira,
Rodrigo ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; David Airlie ; Daniel Vetter
; Lin, Wayne ; Pillai, Aurabindo
; Li, Roman ; Wu, Hersen
; Zuo, Jerry ; Liu, HaoPing (Alan)
; Dhillon, Jasdeep ; Liu, Aaron
; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
Subject: [PATCH] drm/amd/display: fix possible buffer overflow relating to
secure display
It is possible that adev->dm.dc->caps.max_links is greater than
AMDGPU_MAX_CRTCS. So, to not potentially access unallocated memory use
adev->mode_info.num_crtc to do the bounds check instead of
adev->dm.dc->caps.max_links.
Fixes: 278b2b5ba2f2 ("drm/amd/display: Implement multiple secure display")
Fixes: 65a2fbe75cd5 ("drm/amd/display: Fix when disabling secure_display")
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 8 +---
2 files changed, 6 insertions(+), 4 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 b4d60eedbcbf..86a268cc4b21 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1742,7 +1742,7 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev)
#if defined(CONFIG_DRM_AMD_SECURE_DISPLAY)
if (adev->dm.secure_display_ctxs) {
- for (i = 0; i < adev->dm.dc->caps.max_links; i++) {
+ for (i = 0; i < adev->mode_info.num_crtc; i++) {
if (adev->dm.secure_display_ctxs[i].crtc) {
flush_work(>dm.secure_display_ctxs[i].notify_ta_work);
flush_work(>dm.secure_display_ctxs[i].forward_roi_work);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 8841c447d0e2..8873ecada27c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -223,7 +223,7 @@ int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc
*crtc, #if defined(CONFIG_DRM_AMD_SECURE_DISPLAY)
/* Disable secure_display if it was enabled */
if (!enable) {
- for (i = 0; i < adev->dm.dc->caps.max_links; i++) {
+ for (i = 0; i < adev->mode_info.num_crtc; i++) {
if (adev->dm.secure_display_ctxs[i].crtc ==
crtc) {
/* stop ROI update on this crtc */
flush_work(>dm.secure_display_ctxs[i].notify_ta_work);
@@ -544,12 +544,14 @@ amdgpu_dm_crtc_secure_display_create_contexts(struct
amdgpu_device *adev)
struct secure_display_context *secure_display_ctxs = NULL;
int i;
- secure_display_ctxs = kcalloc(AMDGPU_MAX_CRTCS, sizeof(struct
secure_display_context), GFP_KERNEL);
+ secure_display_ctxs = kcalloc(adev->mode_info.num_crtc,
+ sizeof(struct secure_display_context),
+ GFP_KERNEL);
if (!secure_display_ctxs)
return NULL;
- for (i = 0; i < adev->dm.dc->caps.max_links; i++) {
+ for (i = 0; i < adev->mode_info.num_crtc; i++) {
INIT_WORK(_display_ctxs[i].forward_roi_work,
amdgpu_dm_forward_crc_window);
INIT_WORK(_display_ctxs[i].notify_ta_work,
amdgpu_dm_crtc_notify_ta_to_read);
secure_display_ctxs[i].crtc = >mode_info.crtcs[i]->base;
--
2.38.1
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
On 12/01/2023 07:48, Pin-yen Lin wrote:
On Thu, Jan 12, 2023 at 1:24 PM Dmitry Baryshkov
wrote:
On 12/01/2023 07:19, Pin-yen Lin wrote:
Hi Dmitry,
Thanks for the review.
On Thu, Jan 12, 2023 at 12:40 PM Dmitry Baryshkov
wrote:
On 12/01/2023 06:20, Pin-yen Lin wrote:
Add helpers to register and unregister Type-C "switches" for bridges
capable of switching their output between two downstream devices.
The helper registers USB Type-C mode switches when the "mode-switch"
and the "data-lanes" properties are available in Device Tree.
Signed-off-by: Pin-yen Lin
Tested-by: Chen-Yu Tsai
Reviewed-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
- Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
- Print out the node name when errors on parsing DT
- Use dev_dbg instead of dev_warn when no Type-C switch nodes available
- Made the return path of drm_dp_register_mode_switch clearer
Changes in v8:
- Fixed the build issue when CONFIG_TYPEC=m
- Fixed some style issues
Changes in v7:
- Extracted the common codes to a helper function
- New in v7
drivers/gpu/drm/display/drm_dp_helper.c | 134
include/drm/display/drm_dp_helper.h | 17 +++
2 files changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..a2ec40a621cb 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -30,11 +30,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel *panel,
struct drm_dp_aux *aux)
EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
#endif
+
+#if IS_REACHABLE(CONFIG_TYPEC)
+static int drm_dp_register_mode_switch(struct device *dev, struct device_node
*node,
+struct drm_dp_typec_switch_desc
*switch_desc,
+void *data, typec_mux_set_fn_t mux_set)
+{
+ struct drm_dp_typec_port_data *port_data;
+ struct typec_mux_desc mux_desc = {};
+ char name[32];
+ u32 dp_lanes[2];
+ int ret, num_lanes, port_num = -1;
+
+ num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
2 looks incorrect. IIRC DP altmode can support up to 4 lanes.
This function is implemented for 4-lane DP bridges to switch its
outputs between 2 downstreams. So, I assume that there will only be at
most 2 lanes for each downstream. I don't think a 4-lane downstream
makes sense for mode switches unless we want to support bridges with
more than 4 lanes.
Yes. However by using 4 here you'd make the helper generic and cover
both your case and the generic case. We don't need this for the msm case
(since the mux is handled by the PHY). But if not for the PHY, I'd have
used such helper (with max_lanes = 4).
I wonder if simply using 4 here really makes it more generic here.
This function assumes the mapping between "data-lanes" and the port
number (e.g., 0/1 --> port 0) and hard-coded the way to parse the
property.
Is it better to use "reg" instead of "data-lanes" to determine the
port number? The drivers can still read the DT node to get the
"data-lanes" property if they want to do some fancy stuffs around
that.
Yes, I admit, this sounds more logical.
+ if (num_lanes <= 0) {
+ dev_err(dev, "Error on getting data lanes count from %s: %d\n",
+ node->name, num_lanes);
+ return num_lanes;
+ }
+
+ ret = of_property_read_u32_array(node, "data-lanes", dp_lanes, num_lanes);
+ if (ret) {
+ dev_err(dev, "Failed to read the data-lanes variable from %s:
%d\n",
+ node->name, ret);
+ return ret;
+ }
+
+ port_num = dp_lanes[0] / 2;
+
+ port_data = _desc->typec_ports[port_num];
+ port_data->data = data;
+ mux_desc.fwnode = >fwnode;
+ mux_desc.drvdata = port_data;
+ snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
+ mux_desc.name = name;
+ mux_desc.set = mux_set;
+
+ port_data->typec_mux = typec_mux_register(dev, _desc);
+ if (IS_ERR(port_data->typec_mux)) {
+ ret = PTR_ERR(port_data->typec_mux);
+ dev_err(dev, "Mode switch register for port %d failed: %d\n",
+ port_num, ret);
+
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_dp_register_typec_switches() - register Type-C switches
+ * @dev: Device that registers Type-C switches
+ * @port: Device node for the switch
+ * @switch_desc: A Type-C switch descriptor
+ * @data: Private data for the switches
+ * @mux_set: Callback function for typec_mux_set
+ *
+ * This function registers USB Type-C switches for DP bridges that can switch
+ * the output signal between their
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
On Thu, Jan 12, 2023 at 1:24 PM Dmitry Baryshkov
wrote:
>
> On 12/01/2023 07:19, Pin-yen Lin wrote:
> > Hi Dmitry,
> >
> > Thanks for the review.
> >
> > On Thu, Jan 12, 2023 at 12:40 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On 12/01/2023 06:20, Pin-yen Lin wrote:
> >>> Add helpers to register and unregister Type-C "switches" for bridges
> >>> capable of switching their output between two downstream devices.
> >>>
> >>> The helper registers USB Type-C mode switches when the "mode-switch"
> >>> and the "data-lanes" properties are available in Device Tree.
> >>>
> >>> Signed-off-by: Pin-yen Lin
> >>> Tested-by: Chen-Yu Tsai
> >>> Reviewed-by: Chen-Yu Tsai
> >>> Reviewed-by: AngeloGioacchino Del Regno
> >>>
> >>>
> >>> ---
> >>>
> >>> Changes in v10:
> >>> - Collected Reviewed-by and Tested-by tags
> >>> - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
> >>> - Print out the node name when errors on parsing DT
> >>> - Use dev_dbg instead of dev_warn when no Type-C switch nodes available
> >>> - Made the return path of drm_dp_register_mode_switch clearer
> >>>
> >>> Changes in v8:
> >>> - Fixed the build issue when CONFIG_TYPEC=m
> >>> - Fixed some style issues
> >>>
> >>> Changes in v7:
> >>> - Extracted the common codes to a helper function
> >>> - New in v7
> >>>
> >>>drivers/gpu/drm/display/drm_dp_helper.c | 134
> >>>include/drm/display/drm_dp_helper.h | 17 +++
> >>>2 files changed, 151 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> >>> b/drivers/gpu/drm/display/drm_dp_helper.c
> >>> index 16565a0a5da6..a2ec40a621cb 100644
> >>> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> >>> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> >>> @@ -30,11 +30,13 @@
> >>>#include
> >>>#include
> >>>#include
> >>> +#include
> >>>#include
> >>>
> >>>#include
> >>>#include
> >>>#include
> >>> +#include
> >>>#include
> >>>#include
> >>>#include
> >>> @@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel
> >>> *panel, struct drm_dp_aux *aux)
> >>>EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
> >>>
> >>>#endif
> >>> +
> >>> +#if IS_REACHABLE(CONFIG_TYPEC)
> >>> +static int drm_dp_register_mode_switch(struct device *dev, struct
> >>> device_node *node,
> >>> +struct drm_dp_typec_switch_desc
> >>> *switch_desc,
> >>> +void *data, typec_mux_set_fn_t
> >>> mux_set)
> >>> +{
> >>> + struct drm_dp_typec_port_data *port_data;
> >>> + struct typec_mux_desc mux_desc = {};
> >>> + char name[32];
> >>> + u32 dp_lanes[2];
> >>> + int ret, num_lanes, port_num = -1;
> >>> +
> >>> + num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
> >>
> >> 2 looks incorrect. IIRC DP altmode can support up to 4 lanes.
> >
> > This function is implemented for 4-lane DP bridges to switch its
> > outputs between 2 downstreams. So, I assume that there will only be at
> > most 2 lanes for each downstream. I don't think a 4-lane downstream
> > makes sense for mode switches unless we want to support bridges with
> > more than 4 lanes.
>
> Yes. However by using 4 here you'd make the helper generic and cover
> both your case and the generic case. We don't need this for the msm case
> (since the mux is handled by the PHY). But if not for the PHY, I'd have
> used such helper (with max_lanes = 4).
>
I wonder if simply using 4 here really makes it more generic here.
This function assumes the mapping between "data-lanes" and the port
number (e.g., 0/1 --> port 0) and hard-coded the way to parse the
property.
Is it better to use "reg" instead of "data-lanes" to determine the
port number? The drivers can still read the DT node to get the
"data-lanes" property if they want to do some fancy stuffs around
that.
> >>
> >>> + if (num_lanes <= 0) {
> >>> + dev_err(dev, "Error on getting data lanes count from %s:
> >>> %d\n",
> >>> + node->name, num_lanes);
> >>> + return num_lanes;
> >>> + }
> >>> +
> >>> + ret = of_property_read_u32_array(node, "data-lanes", dp_lanes,
> >>> num_lanes);
> >>> + if (ret) {
> >>> + dev_err(dev, "Failed to read the data-lanes variable from
> >>> %s: %d\n",
> >>> + node->name, ret);
> >>> + return ret;
> >>> + }
> >>> +
> >>> + port_num = dp_lanes[0] / 2;
> >>> +
> >>> + port_data = _desc->typec_ports[port_num];
> >>> + port_data->data = data;
> >>> + mux_desc.fwnode = >fwnode;
> >>> + mux_desc.drvdata = port_data;
> >>> + snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
> >>> + mux_desc.name = name;
> >>> + mux_desc.set = mux_set;
> >>> +
> >>> + port_data->typec_mux = typec_mux_register(dev, _desc);
> >>> + if (IS_ERR(port_data->typec_mux)) {
> >>> + ret = PTR_ERR(port_data->typec_mux);
> >>> +
[PATCH] drm/msm/dpu: merge two CRTC debugfs dirs
For each CRTC we are creating two different debugfs directories one
using crtc index (created automatically for the CRC files) and another
one using CRTC name/object ID (for state and status files).
This can be confusing, so move our custom files to crtc->debugfs_entry,
effetively merging two debugfs dirs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7f0f467dbabd..659fdfec5346 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1380,16 +1380,12 @@ DEFINE_SHOW_ATTRIBUTE(dpu_crtc_debugfs_state);
static int _dpu_crtc_init_debugfs(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
- struct dentry *debugfs_root;
-
- debugfs_root = debugfs_create_dir(dpu_crtc->name,
- crtc->dev->primary->debugfs_root);
debugfs_create_file("status", 0400,
- debugfs_root,
+ crtc->debugfs_entry,
dpu_crtc, &_dpu_debugfs_status_fops);
debugfs_create_file("state", 0600,
- debugfs_root,
+ crtc->debugfs_entry,
_crtc->base,
_crtc_debugfs_state_fops);
--
2.39.0
Re: [PATCH v10 4/9] dt-bindings: display: bridge: anx7625: Add mode-switch support
On Thu, 12 Jan 2023 at 07:26, Pin-yen Lin wrote:
>
> Hi Dmitry,
>
> Thanks for the review.
>
> On Thu, Jan 12, 2023 at 12:43 PM Dmitry Baryshkov
> wrote:
> >
> > On 12/01/2023 06:20, Pin-yen Lin wrote:
> > > Analogix 7625 can be used in systems to switch the DP traffic between
> > > two downstreams, which can be USB Type-C DisplayPort alternate mode
> > > lane or regular DisplayPort output ports.
> > >
> > > Update the binding to accommodate this usage by introducing a
> > > data-lanes and a mode-switch property on endpoints.
> > >
> > > Also include the link to the product brief in the bindings.
> > >
> > > Signed-off-by: Pin-yen Lin
> > > Reviewed-by: Krzysztof Kozlowski
> > > Reviewed-by: Chen-Yu Tsai
> > > Tested-by: Chen-Yu Tsai
> > > Reviewed-by: AngeloGioacchino Del Regno
> > >
> > >
> > > ---
> > >
> > > Changes in v10:
> > > - Collected Reviewed-by and Tested-by tags
> > >
> > > Changes in v9:
> > > - Collected Reviewed-by tag
> > >
> > > Changes in v8:
> > > - Updated anx7625 bindings for data-lane property
> > > - Fixed the subject prefix
> > >
> > > Changes in v7:
> > > - Fixed issues reported by dt_binding_check
> > > - Updated the schema and the example dts for data-lanes.
> > > - Changed to generic naming for the example dts node.
> > >
> > > Changes in v6:
> > > - Remove switches node and use endpoints and data-lanes property to
> > >describe the connections.
> > >
> > > .../display/bridge/analogix,anx7625.yaml | 99 ++-
> > > 1 file changed, 96 insertions(+), 3 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index 4590186c4a0b..b49a350c40e3 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -12,7 +12,8 @@ maintainers:
> > >
> > > description: |
> > > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > > - designed for portable devices.
> > > + designed for portable devices. Product brief is available at
> > > +
> > > https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
> > >
> > > properties:
> > > compatible:
> > > @@ -112,10 +113,48 @@ properties:
> > > data-lanes: true
> > >
> > > port@1:
> > > -$ref: /schemas/graph.yaml#/properties/port
> > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > description:
> > > Video port for panel or connector.
> > >
> > > +patternProperties:
> > > + "^endpoint@[01]$":
> > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> > > +unevaluatedProperties: false
> > > +
> > > +properties:
> > > + reg:
> > > +maxItems: 1
> >
> > Please remove duplicates to the graph.yaml. You have several of them here.
>
> I'll fix this in v11.
> >
> > > +
> > > + remote-endpoint: true
> > > +
> > > + data-lanes:
> > > +oneOf:
> > > + - items:
> > > + - enum: [0, 1, 2, 3]
> > > +
> > > + - items:
> > > + - const: 0
> > > + - const: 1
> > > +
> > > + - items:
> > > + - const: 2
> > > + - const: 3
> > > +
> > > + - items:
> > > + - const: 0
> > > + - const: 1
> > > + - const: 2
> > > + - const: 3
> > > +
> > > + mode-switch:
> > > +type: boolean
> > > +description: Register this node as a Type-C mode switch
> > > or not.
> > > +
> > > +required:
> > > + - reg
> > > + - remote-endpoint
> > > +
> > > required:
> > > - port@0
> > > - port@1
> > > @@ -164,8 +203,12 @@ examples:
> > > };
> > >
> > > mipi2dp_bridge_out: port@1 {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +
> > > reg = <1>;
> > > -anx7625_out: endpoint {
> > > +anx7625_out: endpoint@0 {
> >
> > But why? It's perfectly fine from the graph perspective to omit the
> > index if there is jus a single endpoint.
>
> This is because "reg" property is added as a required property. Do you
> suggest making "reg" property optional and only add it when there are
> multiple ports?
Yes. I think it makes sense.
> >
> > > +reg = <0>;
> > > remote-endpoint = <_in>;
> > > };
> > > };
> > > @@ -186,3 +229,53 @@ examples:
> > > };
> > > };
> > >
Re: [PATCH v10 4/9] dt-bindings: display: bridge: anx7625: Add mode-switch support
Hi Dmitry,
Thanks for the review.
On Thu, Jan 12, 2023 at 12:43 PM Dmitry Baryshkov
wrote:
>
> On 12/01/2023 06:20, Pin-yen Lin wrote:
> > Analogix 7625 can be used in systems to switch the DP traffic between
> > two downstreams, which can be USB Type-C DisplayPort alternate mode
> > lane or regular DisplayPort output ports.
> >
> > Update the binding to accommodate this usage by introducing a
> > data-lanes and a mode-switch property on endpoints.
> >
> > Also include the link to the product brief in the bindings.
> >
> > Signed-off-by: Pin-yen Lin
> > Reviewed-by: Krzysztof Kozlowski
> > Reviewed-by: Chen-Yu Tsai
> > Tested-by: Chen-Yu Tsai
> > Reviewed-by: AngeloGioacchino Del Regno
> >
> >
> > ---
> >
> > Changes in v10:
> > - Collected Reviewed-by and Tested-by tags
> >
> > Changes in v9:
> > - Collected Reviewed-by tag
> >
> > Changes in v8:
> > - Updated anx7625 bindings for data-lane property
> > - Fixed the subject prefix
> >
> > Changes in v7:
> > - Fixed issues reported by dt_binding_check
> > - Updated the schema and the example dts for data-lanes.
> > - Changed to generic naming for the example dts node.
> >
> > Changes in v6:
> > - Remove switches node and use endpoints and data-lanes property to
> >describe the connections.
> >
> > .../display/bridge/analogix,anx7625.yaml | 99 ++-
> > 1 file changed, 96 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > index 4590186c4a0b..b49a350c40e3 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > @@ -12,7 +12,8 @@ maintainers:
> >
> > description: |
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > - designed for portable devices.
> > + designed for portable devices. Product brief is available at
> > +
> > https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
> >
> > properties:
> > compatible:
> > @@ -112,10 +113,48 @@ properties:
> > data-lanes: true
> >
> > port@1:
> > -$ref: /schemas/graph.yaml#/properties/port
> > +$ref: /schemas/graph.yaml#/$defs/port-base
> > description:
> > Video port for panel or connector.
> >
> > +patternProperties:
> > + "^endpoint@[01]$":
> > +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> > +unevaluatedProperties: false
> > +
> > +properties:
> > + reg:
> > +maxItems: 1
>
> Please remove duplicates to the graph.yaml. You have several of them here.
I'll fix this in v11.
>
> > +
> > + remote-endpoint: true
> > +
> > + data-lanes:
> > +oneOf:
> > + - items:
> > + - enum: [0, 1, 2, 3]
> > +
> > + - items:
> > + - const: 0
> > + - const: 1
> > +
> > + - items:
> > + - const: 2
> > + - const: 3
> > +
> > + - items:
> > + - const: 0
> > + - const: 1
> > + - const: 2
> > + - const: 3
> > +
> > + mode-switch:
> > +type: boolean
> > +description: Register this node as a Type-C mode switch or
> > not.
> > +
> > +required:
> > + - reg
> > + - remote-endpoint
> > +
> > required:
> > - port@0
> > - port@1
> > @@ -164,8 +203,12 @@ examples:
> > };
> >
> > mipi2dp_bridge_out: port@1 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > reg = <1>;
> > -anx7625_out: endpoint {
> > +anx7625_out: endpoint@0 {
>
> But why? It's perfectly fine from the graph perspective to omit the
> index if there is jus a single endpoint.
This is because "reg" property is added as a required property. Do you
suggest making "reg" property optional and only add it when there are
multiple ports?
>
> > +reg = <0>;
> > remote-endpoint = <_in>;
> > };
> > };
> > @@ -186,3 +229,53 @@ examples:
> > };
> > };
> > };
> > + - |
> > +i2c3 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +encoder@58 {
> > +compatible = "analogix,anx7625";
> > +reg = <0x58>;
> > +pinctrl-names = "default";
> > +pinctrl-0 = <_dp_pins>;
> > +enable-gpios = < 176 GPIO_ACTIVE_HIGH>;
> > +reset-gpios = <
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
On 12/01/2023 07:19, Pin-yen Lin wrote:
Hi Dmitry,
Thanks for the review.
On Thu, Jan 12, 2023 at 12:40 PM Dmitry Baryshkov
wrote:
On 12/01/2023 06:20, Pin-yen Lin wrote:
Add helpers to register and unregister Type-C "switches" for bridges
capable of switching their output between two downstream devices.
The helper registers USB Type-C mode switches when the "mode-switch"
and the "data-lanes" properties are available in Device Tree.
Signed-off-by: Pin-yen Lin
Tested-by: Chen-Yu Tsai
Reviewed-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
- Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
- Print out the node name when errors on parsing DT
- Use dev_dbg instead of dev_warn when no Type-C switch nodes available
- Made the return path of drm_dp_register_mode_switch clearer
Changes in v8:
- Fixed the build issue when CONFIG_TYPEC=m
- Fixed some style issues
Changes in v7:
- Extracted the common codes to a helper function
- New in v7
drivers/gpu/drm/display/drm_dp_helper.c | 134
include/drm/display/drm_dp_helper.h | 17 +++
2 files changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..a2ec40a621cb 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -30,11 +30,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel *panel,
struct drm_dp_aux *aux)
EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
#endif
+
+#if IS_REACHABLE(CONFIG_TYPEC)
+static int drm_dp_register_mode_switch(struct device *dev, struct device_node
*node,
+struct drm_dp_typec_switch_desc
*switch_desc,
+void *data, typec_mux_set_fn_t mux_set)
+{
+ struct drm_dp_typec_port_data *port_data;
+ struct typec_mux_desc mux_desc = {};
+ char name[32];
+ u32 dp_lanes[2];
+ int ret, num_lanes, port_num = -1;
+
+ num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
2 looks incorrect. IIRC DP altmode can support up to 4 lanes.
This function is implemented for 4-lane DP bridges to switch its
outputs between 2 downstreams. So, I assume that there will only be at
most 2 lanes for each downstream. I don't think a 4-lane downstream
makes sense for mode switches unless we want to support bridges with
more than 4 lanes.
Yes. However by using 4 here you'd make the helper generic and cover
both your case and the generic case. We don't need this for the msm case
(since the mux is handled by the PHY). But if not for the PHY, I'd have
used such helper (with max_lanes = 4).
+ if (num_lanes <= 0) {
+ dev_err(dev, "Error on getting data lanes count from %s: %d\n",
+ node->name, num_lanes);
+ return num_lanes;
+ }
+
+ ret = of_property_read_u32_array(node, "data-lanes", dp_lanes, num_lanes);
+ if (ret) {
+ dev_err(dev, "Failed to read the data-lanes variable from %s:
%d\n",
+ node->name, ret);
+ return ret;
+ }
+
+ port_num = dp_lanes[0] / 2;
+
+ port_data = _desc->typec_ports[port_num];
+ port_data->data = data;
+ mux_desc.fwnode = >fwnode;
+ mux_desc.drvdata = port_data;
+ snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
+ mux_desc.name = name;
+ mux_desc.set = mux_set;
+
+ port_data->typec_mux = typec_mux_register(dev, _desc);
+ if (IS_ERR(port_data->typec_mux)) {
+ ret = PTR_ERR(port_data->typec_mux);
+ dev_err(dev, "Mode switch register for port %d failed: %d\n",
+ port_num, ret);
+
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_dp_register_typec_switches() - register Type-C switches
+ * @dev: Device that registers Type-C switches
+ * @port: Device node for the switch
+ * @switch_desc: A Type-C switch descriptor
+ * @data: Private data for the switches
+ * @mux_set: Callback function for typec_mux_set
+ *
+ * This function registers USB Type-C switches for DP bridges that can switch
+ * the output signal between their output pins.
+ *
+ * Currently only mode switches are implemented, and the function assumes the
+ * given @port device node has endpoints with "mode-switch" property.
+ * Register the endpoint as port 0 if the "data-lanes" property falls in 0/1,
+ * and register it as port 1 if "data-lanes" falls in 2/3.
+ */
+int drm_dp_register_typec_switches(struct device *dev, struct device_node
*port,
+struct drm_dp_typec_switch_desc *switch_desc,
+void *data, typec_mux_set_fn_t mux_set)
+{
+ struct device_node
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
Hi Dmitry,
Thanks for the review.
On Thu, Jan 12, 2023 at 12:40 PM Dmitry Baryshkov
wrote:
>
> On 12/01/2023 06:20, Pin-yen Lin wrote:
> > Add helpers to register and unregister Type-C "switches" for bridges
> > capable of switching their output between two downstream devices.
> >
> > The helper registers USB Type-C mode switches when the "mode-switch"
> > and the "data-lanes" properties are available in Device Tree.
> >
> > Signed-off-by: Pin-yen Lin
> > Tested-by: Chen-Yu Tsai
> > Reviewed-by: Chen-Yu Tsai
> > Reviewed-by: AngeloGioacchino Del Regno
> >
> >
> > ---
> >
> > Changes in v10:
> > - Collected Reviewed-by and Tested-by tags
> > - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
> > - Print out the node name when errors on parsing DT
> > - Use dev_dbg instead of dev_warn when no Type-C switch nodes available
> > - Made the return path of drm_dp_register_mode_switch clearer
> >
> > Changes in v8:
> > - Fixed the build issue when CONFIG_TYPEC=m
> > - Fixed some style issues
> >
> > Changes in v7:
> > - Extracted the common codes to a helper function
> > - New in v7
> >
> > drivers/gpu/drm/display/drm_dp_helper.c | 134
> > include/drm/display/drm_dp_helper.h | 17 +++
> > 2 files changed, 151 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > b/drivers/gpu/drm/display/drm_dp_helper.c
> > index 16565a0a5da6..a2ec40a621cb 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -30,11 +30,13 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel
> > *panel, struct drm_dp_aux *aux)
> > EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
> >
> > #endif
> > +
> > +#if IS_REACHABLE(CONFIG_TYPEC)
> > +static int drm_dp_register_mode_switch(struct device *dev, struct
> > device_node *node,
> > +struct drm_dp_typec_switch_desc
> > *switch_desc,
> > +void *data, typec_mux_set_fn_t mux_set)
> > +{
> > + struct drm_dp_typec_port_data *port_data;
> > + struct typec_mux_desc mux_desc = {};
> > + char name[32];
> > + u32 dp_lanes[2];
> > + int ret, num_lanes, port_num = -1;
> > +
> > + num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
>
> 2 looks incorrect. IIRC DP altmode can support up to 4 lanes.
This function is implemented for 4-lane DP bridges to switch its
outputs between 2 downstreams. So, I assume that there will only be at
most 2 lanes for each downstream. I don't think a 4-lane downstream
makes sense for mode switches unless we want to support bridges with
more than 4 lanes.
>
> > + if (num_lanes <= 0) {
> > + dev_err(dev, "Error on getting data lanes count from %s:
> > %d\n",
> > + node->name, num_lanes);
> > + return num_lanes;
> > + }
> > +
> > + ret = of_property_read_u32_array(node, "data-lanes", dp_lanes,
> > num_lanes);
> > + if (ret) {
> > + dev_err(dev, "Failed to read the data-lanes variable from %s:
> > %d\n",
> > + node->name, ret);
> > + return ret;
> > + }
> > +
> > + port_num = dp_lanes[0] / 2;
> > +
> > + port_data = _desc->typec_ports[port_num];
> > + port_data->data = data;
> > + mux_desc.fwnode = >fwnode;
> > + mux_desc.drvdata = port_data;
> > + snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
> > + mux_desc.name = name;
> > + mux_desc.set = mux_set;
> > +
> > + port_data->typec_mux = typec_mux_register(dev, _desc);
> > + if (IS_ERR(port_data->typec_mux)) {
> > + ret = PTR_ERR(port_data->typec_mux);
> > + dev_err(dev, "Mode switch register for port %d failed: %d\n",
> > + port_num, ret);
> > +
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * drm_dp_register_typec_switches() - register Type-C switches
> > + * @dev: Device that registers Type-C switches
> > + * @port: Device node for the switch
> > + * @switch_desc: A Type-C switch descriptor
> > + * @data: Private data for the switches
> > + * @mux_set: Callback function for typec_mux_set
> > + *
> > + * This function registers USB Type-C switches for DP bridges that can
> > switch
> > + * the output signal between their output pins.
> > + *
> > + * Currently only mode switches are implemented, and the function assumes
> > the
> > + * given @port device node has endpoints with "mode-switch" property.
> > + * Register the endpoint as port 0 if the "data-lanes" property falls in
> > 0/1,
> > + * and register it as port 1 if "data-lanes" falls in 2/3.
> > + */
> > +int drm_dp_register_typec_switches(struct device *dev, struct
Re: [PATCH v10 0/9] Register Type-C mode-switch in DP bridge endpoints
Hi Dmitry, On Thu, Jan 12, 2023 at 12:34 PM Dmitry Baryshkov wrote: > > On 12/01/2023 06:20, Pin-yen Lin wrote: > > > > This series introduces bindings for anx7625/it6505 to register Type-C > > mode-switch in their output endpoints, and use data-lanes property to > > describe the pin connections. > > Please cc everybody on all patches. Having received just a single patch > made me spend time on having to look them up on lore. Sorry about that. I'll prevent that in the future series. > > > > > The first two patch modifies fwnode_graph_devcon_matches and > > cros_typec_init_ports to enable the registration of the switches. > > > > Patch 4~6 introduce the bindings for anx7625 and the corresponding driver > > modifications. > > > > Patch 7~9 add similar bindings and driver changes for it6505. > > > > v9: > > https://lore.kernel.org/all/20230109084101.265664-1-treapk...@chromium.org/ > > v8: > > https://lore.kernel.org/all/20230107102231.23682-1-treapk...@chromium.org/ > > v7: > > https://lore.kernel.org/all/20230105132457.4125372-1-treapk...@chromium.org/ > > v6: > > https://lore.kernel.org/all/20221124102056.393220-1-treapk...@chromium.org/ > > v5: > > https://lore.kernel.org/linux-usb/20220622173605.1168416-1-pmal...@chromium.org/ > > > > Changes in v10: > > - Collected Reviewed-by and Tested-by tags > > - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks > > - Print out the node name when errors on parsing DT > > - Use dev_dbg instead of dev_warn when no Type-C switch nodes available > > - Made the return path of drm_dp_register_mode_switch clearer > > - Added a TODO for implementing orientation switch for anx7625 > > - Updated the commit message for the absence of orientation switch > > - Fixed typo in the commit message > > > > Changes in v9: > > - Collected Reviewed-by tag > > - Fixed subject prefix again > > - Changed the naming of the example node for it6505 > > > > Changes in v8: > > - Fixed the build issue when CONFIG_TYPEC=m > > - Fixed some style issues > > - Fixed the subject prefixes for the bindings patch > > - Fixed the bindings for data-lanes properties > > > > Changes in v7: > > - Fix the long comment lines > > - Extracted the common codes to a helper function > > - Fixed style issues in anx7625 driver > > - Removed DT property validation in anx7625 driver. > > - Fixed style issues in it6505 driver > > - Removed the redundant sleep in it6505 driver > > - Removed DT property validation in it6505 driver > > - Rebased to drm-misc-next > > - Fixed indentations in bindings patches > > - Added a new patch to fix indentations in Kconfig > > > > Changes in v6: > > - Changed it6505_typec_mux_set callback function to accommodate with > >the latest drm-misc patches > > - Changed the driver implementation to accommodate with the new binding > > - Dropped typec-switch binding and use endpoints and data-lanes properties > >to describe the pin connections > > - Added new patches (patch 1,2,4) to fix probing issues > > - Changed the bindings of it6505/anx7625 and modified the drivers > >accordingly > > - Merged it6505/anx7625 driver changes into a single patch > > > > Pin-yen Lin (7): > >drm/display: Add Type-C switch helpers > >dt-bindings: display: bridge: anx7625: Add mode-switch support > >drm/bridge: anx7625: Check for Type-C during panel registration > >drm/bridge: anx7625: Register Type C mode switches > >dt-bindings: display: bridge: it6505: Add mode-switch support > >drm/bridge: it6505: Fix Kconfig indentation > >drm/bridge: it6505: Register Type C mode switches > > > > Prashant Malani (2): > >device property: Add remote endpoint to devcon matcher > >platform/chrome: cros_ec_typec: Purge blocking switch devlinks > > > > .../display/bridge/analogix,anx7625.yaml | 99 - > > .../bindings/display/bridge/ite,it6505.yaml | 93 ++-- > > drivers/base/property.c | 15 ++ > > drivers/gpu/drm/bridge/Kconfig| 21 +-- > > drivers/gpu/drm/bridge/analogix/Kconfig | 1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 105 +- > > drivers/gpu/drm/bridge/analogix/anx7625.h | 13 ++ > > drivers/gpu/drm/bridge/ite-it6505.c | 119 +++- > > drivers/gpu/drm/display/drm_dp_helper.c | 134 ++ > > drivers/platform/chrome/cros_ec_typec.c | 10 ++ > > include/drm/display/drm_dp_helper.h | 17 +++ > > 11 files changed, 598 insertions(+), 29 deletions(-) > > > > -- > With best wishes > Dmitry > Thanks and regards, Pin-yen
Re: [PATCH v10 4/9] dt-bindings: display: bridge: anx7625: Add mode-switch support
On 12/01/2023 06:20, Pin-yen Lin wrote:
Analogix 7625 can be used in systems to switch the DP traffic between
two downstreams, which can be USB Type-C DisplayPort alternate mode
lane or regular DisplayPort output ports.
Update the binding to accommodate this usage by introducing a
data-lanes and a mode-switch property on endpoints.
Also include the link to the product brief in the bindings.
Signed-off-by: Pin-yen Lin
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
Changes in v9:
- Collected Reviewed-by tag
Changes in v8:
- Updated anx7625 bindings for data-lane property
- Fixed the subject prefix
Changes in v7:
- Fixed issues reported by dt_binding_check
- Updated the schema and the example dts for data-lanes.
- Changed to generic naming for the example dts node.
Changes in v6:
- Remove switches node and use endpoints and data-lanes property to
describe the connections.
.../display/bridge/analogix,anx7625.yaml | 99 ++-
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 4590186c4a0b..b49a350c40e3 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -12,7 +12,8 @@ maintainers:
description: |
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
- designed for portable devices.
+ designed for portable devices. Product brief is available at
+
https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
properties:
compatible:
@@ -112,10 +113,48 @@ properties:
data-lanes: true
port@1:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
Video port for panel or connector.
+patternProperties:
+ "^endpoint@[01]$":
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+ reg:
+maxItems: 1
Please remove duplicates to the graph.yaml. You have several of them here.
+
+ remote-endpoint: true
+
+ data-lanes:
+oneOf:
+ - items:
+ - enum: [0, 1, 2, 3]
+
+ - items:
+ - const: 0
+ - const: 1
+
+ - items:
+ - const: 2
+ - const: 3
+
+ - items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+
+ mode-switch:
+type: boolean
+description: Register this node as a Type-C mode switch or not.
+
+required:
+ - reg
+ - remote-endpoint
+
required:
- port@0
- port@1
@@ -164,8 +203,12 @@ examples:
};
mipi2dp_bridge_out: port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
reg = <1>;
-anx7625_out: endpoint {
+anx7625_out: endpoint@0 {
But why? It's perfectly fine from the graph perspective to omit the
index if there is jus a single endpoint.
+reg = <0>;
remote-endpoint = <_in>;
};
};
@@ -186,3 +229,53 @@ examples:
};
};
};
+ - |
+i2c3 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+pinctrl-names = "default";
+pinctrl-0 = <_dp_pins>;
+enable-gpios = < 176 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 177 GPIO_ACTIVE_HIGH>;
+vdd10-supply = <_dpbrdg>;
+vdd18-supply = <_dpbrdg_dx>;
+vdd33-supply = <_dpbrdg_dx>;
+analogix,audio-enable;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+anx7625_dp_in: endpoint {
+bus-type = <7>;
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+reg = <1>;
+anx_typec0: endpoint@0 {
+reg = <0>;
+mode-switch;
+
Re: [PATCH v10 3/9] drm/display: Add Type-C switch helpers
On 12/01/2023 06:20, Pin-yen Lin wrote:
Add helpers to register and unregister Type-C "switches" for bridges
capable of switching their output between two downstream devices.
The helper registers USB Type-C mode switches when the "mode-switch"
and the "data-lanes" properties are available in Device Tree.
Signed-off-by: Pin-yen Lin
Tested-by: Chen-Yu Tsai
Reviewed-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
- Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
- Print out the node name when errors on parsing DT
- Use dev_dbg instead of dev_warn when no Type-C switch nodes available
- Made the return path of drm_dp_register_mode_switch clearer
Changes in v8:
- Fixed the build issue when CONFIG_TYPEC=m
- Fixed some style issues
Changes in v7:
- Extracted the common codes to a helper function
- New in v7
drivers/gpu/drm/display/drm_dp_helper.c | 134
include/drm/display/drm_dp_helper.h | 17 +++
2 files changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..a2ec40a621cb 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -30,11 +30,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel *panel,
struct drm_dp_aux *aux)
EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
#endif
+
+#if IS_REACHABLE(CONFIG_TYPEC)
+static int drm_dp_register_mode_switch(struct device *dev, struct device_node
*node,
+ struct drm_dp_typec_switch_desc
*switch_desc,
+ void *data, typec_mux_set_fn_t mux_set)
+{
+ struct drm_dp_typec_port_data *port_data;
+ struct typec_mux_desc mux_desc = {};
+ char name[32];
+ u32 dp_lanes[2];
+ int ret, num_lanes, port_num = -1;
+
+ num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
2 looks incorrect. IIRC DP altmode can support up to 4 lanes.
+ if (num_lanes <= 0) {
+ dev_err(dev, "Error on getting data lanes count from %s: %d\n",
+ node->name, num_lanes);
+ return num_lanes;
+ }
+
+ ret = of_property_read_u32_array(node, "data-lanes", dp_lanes,
num_lanes);
+ if (ret) {
+ dev_err(dev, "Failed to read the data-lanes variable from %s:
%d\n",
+ node->name, ret);
+ return ret;
+ }
+
+ port_num = dp_lanes[0] / 2;
+
+ port_data = _desc->typec_ports[port_num];
+ port_data->data = data;
+ mux_desc.fwnode = >fwnode;
+ mux_desc.drvdata = port_data;
+ snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
+ mux_desc.name = name;
+ mux_desc.set = mux_set;
+
+ port_data->typec_mux = typec_mux_register(dev, _desc);
+ if (IS_ERR(port_data->typec_mux)) {
+ ret = PTR_ERR(port_data->typec_mux);
+ dev_err(dev, "Mode switch register for port %d failed: %d\n",
+ port_num, ret);
+
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_dp_register_typec_switches() - register Type-C switches
+ * @dev: Device that registers Type-C switches
+ * @port: Device node for the switch
+ * @switch_desc: A Type-C switch descriptor
+ * @data: Private data for the switches
+ * @mux_set: Callback function for typec_mux_set
+ *
+ * This function registers USB Type-C switches for DP bridges that can switch
+ * the output signal between their output pins.
+ *
+ * Currently only mode switches are implemented, and the function assumes the
+ * given @port device node has endpoints with "mode-switch" property.
+ * Register the endpoint as port 0 if the "data-lanes" property falls in 0/1,
+ * and register it as port 1 if "data-lanes" falls in 2/3.
+ */
+int drm_dp_register_typec_switches(struct device *dev, struct device_node
*port,
+ struct drm_dp_typec_switch_desc *switch_desc,
+ void *data, typec_mux_set_fn_t mux_set)
+{
+ struct device_node *sw;
+ int ret;
+
+ for_each_child_of_node(port, sw) {
+ if (of_property_read_bool(sw, "mode-switch"))
+ switch_desc->num_typec_switches++;
+ }
+
+ if (!switch_desc->num_typec_switches) {
+ dev_dbg(dev, "No Type-C switches node found\n");
+ return 0;
+ }
+
+ switch_desc->typec_ports = devm_kcalloc(
+ dev, switch_desc->num_typec_switches,
+ sizeof(struct drm_dp_typec_port_data), GFP_KERNEL);
+
+ if (!switch_desc->typec_ports)
+ return -ENOMEM;
+
+ /* Register
Re: [PATCH v10 0/9] Register Type-C mode-switch in DP bridge endpoints
On 12/01/2023 06:20, Pin-yen Lin wrote: This series introduces bindings for anx7625/it6505 to register Type-C mode-switch in their output endpoints, and use data-lanes property to describe the pin connections. Please cc everybody on all patches. Having received just a single patch made me spend time on having to look them up on lore. The first two patch modifies fwnode_graph_devcon_matches and cros_typec_init_ports to enable the registration of the switches. Patch 4~6 introduce the bindings for anx7625 and the corresponding driver modifications. Patch 7~9 add similar bindings and driver changes for it6505. v9: https://lore.kernel.org/all/20230109084101.265664-1-treapk...@chromium.org/ v8: https://lore.kernel.org/all/20230107102231.23682-1-treapk...@chromium.org/ v7: https://lore.kernel.org/all/20230105132457.4125372-1-treapk...@chromium.org/ v6: https://lore.kernel.org/all/20221124102056.393220-1-treapk...@chromium.org/ v5: https://lore.kernel.org/linux-usb/20220622173605.1168416-1-pmal...@chromium.org/ Changes in v10: - Collected Reviewed-by and Tested-by tags - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks - Print out the node name when errors on parsing DT - Use dev_dbg instead of dev_warn when no Type-C switch nodes available - Made the return path of drm_dp_register_mode_switch clearer - Added a TODO for implementing orientation switch for anx7625 - Updated the commit message for the absence of orientation switch - Fixed typo in the commit message Changes in v9: - Collected Reviewed-by tag - Fixed subject prefix again - Changed the naming of the example node for it6505 Changes in v8: - Fixed the build issue when CONFIG_TYPEC=m - Fixed some style issues - Fixed the subject prefixes for the bindings patch - Fixed the bindings for data-lanes properties Changes in v7: - Fix the long comment lines - Extracted the common codes to a helper function - Fixed style issues in anx7625 driver - Removed DT property validation in anx7625 driver. - Fixed style issues in it6505 driver - Removed the redundant sleep in it6505 driver - Removed DT property validation in it6505 driver - Rebased to drm-misc-next - Fixed indentations in bindings patches - Added a new patch to fix indentations in Kconfig Changes in v6: - Changed it6505_typec_mux_set callback function to accommodate with the latest drm-misc patches - Changed the driver implementation to accommodate with the new binding - Dropped typec-switch binding and use endpoints and data-lanes properties to describe the pin connections - Added new patches (patch 1,2,4) to fix probing issues - Changed the bindings of it6505/anx7625 and modified the drivers accordingly - Merged it6505/anx7625 driver changes into a single patch Pin-yen Lin (7): drm/display: Add Type-C switch helpers dt-bindings: display: bridge: anx7625: Add mode-switch support drm/bridge: anx7625: Check for Type-C during panel registration drm/bridge: anx7625: Register Type C mode switches dt-bindings: display: bridge: it6505: Add mode-switch support drm/bridge: it6505: Fix Kconfig indentation drm/bridge: it6505: Register Type C mode switches Prashant Malani (2): device property: Add remote endpoint to devcon matcher platform/chrome: cros_ec_typec: Purge blocking switch devlinks .../display/bridge/analogix,anx7625.yaml | 99 - .../bindings/display/bridge/ite,it6505.yaml | 93 ++-- drivers/base/property.c | 15 ++ drivers/gpu/drm/bridge/Kconfig| 21 +-- drivers/gpu/drm/bridge/analogix/Kconfig | 1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 105 +- drivers/gpu/drm/bridge/analogix/anx7625.h | 13 ++ drivers/gpu/drm/bridge/ite-it6505.c | 119 +++- drivers/gpu/drm/display/drm_dp_helper.c | 134 ++ drivers/platform/chrome/cros_ec_typec.c | 10 ++ include/drm/display/drm_dp_helper.h | 17 +++ 11 files changed, 598 insertions(+), 29 deletions(-) -- With best wishes Dmitry
[PATCH v10 9/9] drm/bridge: it6505: Register Type C mode switches
Register USB Type-C mode switches when the "mode-switch" property and
relevant port are available in Device Tree. Configure the "lane_swap"
state based on the entered alternate mode for a specific Type-C
connector, which ends up updating the lane swap registers of the it6505
chip.
Signed-off-by: Pin-yen Lin
---
(no changes since v7)
Changes in v7:
- Fixed style issues in it6505 driver
- Removed the redundant sleep in it6505 driver
- Removed DT property validation in it6505 driver
- Rebased to drm-misc-next
- Extracted common codes to another commit
Changes in v6:
- Changed it6505_typec_mux_set callback function to accommodate with
the latest drm-misc patches
- Changed the driver implementation to accommodate with the new binding
- Squashed to a single patch
drivers/gpu/drm/bridge/Kconfig | 1 +
drivers/gpu/drm/bridge/ite-it6505.c | 119 +++-
2 files changed, 116 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 737578dd57ed..33803f581562 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -87,6 +87,7 @@ config DRM_FSL_LDB
config DRM_ITE_IT6505
tristate "ITE IT6505 DisplayPort bridge"
depends on OF
+ depends on TYPEC || TYPEC=n
select DRM_DISPLAY_DP_HELPER
select DRM_DISPLAY_HDCP_HELPER
select DRM_DISPLAY_HELPER
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
index 9cda2df21b88..d9be09e889e2 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -28,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -455,6 +458,7 @@ struct it6505 {
struct delayed_work delayed_audio;
struct it6505_audio_data audio;
struct dentry *debugfs;
+ struct drm_dp_typec_switch_desc switch_desc;
/* it6505 driver hold option */
bool enable_drv_hold;
@@ -3346,12 +3350,105 @@ static void it6505_shutdown(struct i2c_client *client)
it6505_lane_off(it6505);
}
+static void it6505_typec_ports_update(struct it6505 *it6505)
+{
+ struct drm_dp_typec_switch_desc switch_desc = it6505->switch_desc;
+
+ /* Check if both ports available and do nothing to retain the current
one */
+ if (switch_desc.typec_ports[0].dp_connected &&
switch_desc.typec_ports[1].dp_connected)
+ return;
+
+ if (switch_desc.typec_ports[0].dp_connected)
+ it6505->lane_swap = false;
+ else if (switch_desc.typec_ports[1].dp_connected)
+ it6505->lane_swap = true;
+}
+
+static int it6505_typec_mux_set(struct typec_mux_dev *mux,
+ struct typec_mux_state *state)
+{
+ struct drm_dp_typec_port_data *port_data = typec_mux_get_drvdata(mux);
+ struct it6505 *it6505 = (struct it6505 *) port_data->data;
+ struct device *dev = >client->dev;
+ struct drm_dp_typec_switch_desc switch_desc = it6505->switch_desc;
+ bool old_dp_connected, new_dp_connected;
+
+ if (switch_desc.num_typec_switches == 1)
+ return 0;
+
+ mutex_lock(>extcon_lock);
+
+ old_dp_connected = switch_desc.typec_ports[0].dp_connected ||
+ switch_desc.typec_ports[1].dp_connected;
+
+ port_data->dp_connected = state->alt &&
+ state->alt->svid == USB_TYPEC_DP_SID &&
+ state->alt->mode == USB_TYPEC_DP_MODE;
+
+ dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
+ switch_desc.typec_ports[0].dp_connected,
switch_desc.typec_ports[1].dp_connected);
+
+ new_dp_connected = switch_desc.typec_ports[0].dp_connected ||
+ switch_desc.typec_ports[1].dp_connected;
+
+ if (it6505->enable_drv_hold) {
+ dev_dbg(dev, "enable driver hold\n");
+ goto unlock;
+ }
+
+ it6505_typec_ports_update(it6505);
+
+ if (!old_dp_connected && new_dp_connected) {
+ int ret = pm_runtime_get_sync(dev);
+
+ /*
+* pm_runtime_force_suspend() disables runtime PM when the
+* system enters suspend state. But on system resume, mux_set
+* can be triggered before pm_runtime_force_resume() re-enables
+* runtime PM. This makes the bridge stay powered off if the
+* downstream display is connected when the system is suspended.
+* Handling the error here to make sure the bridge is powered
+* on, and leave the PM runtime usage count incremented so
+* the future runtime PM calls is balanced.
+*/
+ if (ret < 0)
+ it6505_poweron(it6505);
+
+
[PATCH v10 8/9] drm/bridge: it6505: Fix Kconfig indentation
Replace the spaces with tab characters in the Kconfig file. Signed-off-by: Pin-yen Lin Reviewed-by: AngeloGioacchino Del Regno --- Changes in v10: - Collected Reviewed-by tag Changes in v7: - New in v7 drivers/gpu/drm/bridge/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 57946d80b02d..737578dd57ed 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -85,19 +85,19 @@ config DRM_FSL_LDB Support for i.MX8MP DPI-to-LVDS on-SoC encoder. config DRM_ITE_IT6505 -tristate "ITE IT6505 DisplayPort bridge" -depends on OF + tristate "ITE IT6505 DisplayPort bridge" + depends on OF select DRM_DISPLAY_DP_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HELPER -select DRM_DP_AUX_BUS -select DRM_KMS_HELPER -select DRM_DP_HELPER -select EXTCON -select CRYPTO -select CRYPTO_HASH -help - ITE IT6505 DisplayPort bridge chip driver. + select DRM_DP_AUX_BUS + select DRM_KMS_HELPER + select DRM_DP_HELPER + select EXTCON + select CRYPTO + select CRYPTO_HASH + help + ITE IT6505 DisplayPort bridge chip driver. config DRM_LONTIUM_LT8912B tristate "Lontium LT8912B DSI/HDMI bridge" -- 2.39.0.314.g84b9a713c41-goog
[PATCH v10 7/9] dt-bindings: display: bridge: it6505: Add mode-switch support
ITE IT6505 can be used in systems to switch the DP traffic between
two downstreams, which can be USB Type-C DisplayPort alternate mode
lane or regular DisplayPort output ports.
Update the binding to accommodate this usage by introducing a
data-lanes and a mode-switch property on endpoints.
Signed-off-by: Pin-yen Lin
---
(no changes since v9)
Changes in v9:
- Fixed subject prefix again
- Changed the naming of the example node for it6505
Changes in v8:
- Updated bindings for data-lanes property
- Fixed subject prefix
Changes in v7:
- Fixed issues reported by dt_binding_check.
- Updated the schema and the example dts for data-lanes.
- Changed to generic naming for the example dts node.
Changes in v6:
- Remove switches node and use endpoints and data-lanes property to
describe the connections.
.../bindings/display/bridge/ite,it6505.yaml | 93 ---
1 file changed, 82 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
index b16a9d9127dd..94182f131f86 100644
--- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
@@ -77,20 +77,43 @@ properties:
unevaluatedProperties: false
description: Video port for DP output
-properties:
- endpoint:
+patternProperties:
+ "^endpoint@[01]$":
$ref: /schemas/graph.yaml#/$defs/endpoint-base
unevaluatedProperties: false
properties:
+ reg:
+maxItems: 1
+
+ remote-endpoint: true
+
data-lanes:
-minItems: 1
-uniqueItems: true
-items:
- - enum: [ 0, 1 ]
- - const: 1
- - const: 2
- - const: 3
+oneOf:
+ - items:
+ - enum: [0, 1, 2, 3]
+
+ - items:
+ - const: 0
+ - const: 1
+
+ - items:
+ - const: 2
+ - const: 3
+
+ - items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+
+ mode-switch:
+type: boolean
+description: Register this node as a Type-C mode switch or not.
+
+required:
+ - reg
+ - remote-endpoint
required:
- port@0
@@ -102,7 +125,6 @@ required:
- pwr18-supply
- interrupts
- reset-gpios
- - extcon
- ports
additionalProperties: false
@@ -139,8 +161,11 @@ examples:
};
port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
reg = <1>;
-it6505_out: endpoint {
+it6505_out: endpoint@0 {
+reg = <0>;
remote-endpoint = <_in>;
data-lanes = <0 1>;
};
@@ -148,3 +173,49 @@ examples:
};
};
};
+ - |
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+dp-bridge@5c {
+compatible = "ite,it6505";
+interrupts = <8 IRQ_TYPE_LEVEL_LOW 8 0>;
+reg = <0x5c>;
+pinctrl-names = "default";
+pinctrl-0 = <_pins>;
+ovdd-supply = <_vsim2_reg>;
+pwr18-supply = <_dpbrdg_dx>;
+reset-gpios = < 177 0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+it6505_dpi_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+ite_typec0: endpoint@0 {
+reg = <0>;
+mode-switch;
+data-lanes = <0 1>;
+remote-endpoint = <_port0>;
+};
+ite_typec1: endpoint@1 {
+reg = <1>;
+mode-switch;
+data-lanes = <2 3>;
+remote-endpoint = <_port1>;
+};
+};
+};
+};
+};
--
2.39.0.314.g84b9a713c41-goog
[PATCH v10 6/9] drm/bridge: anx7625: Register Type C mode switches
Register USB Type-C mode switches when the "mode-switch" property and
relevant ports are available in Device Tree. Configure the crosspoint
switch based on the entered alternate mode for a specific Type-C
connector.
Crosspoint switch can also be used for switching the output signal for
different orientations of a single USB Type-C connector, but the
orientation switch is not implemented yet. A TODO is added for this.
Signed-off-by: Pin-yen Lin
Tested-by: Chen-Yu Tsai
---
Changes in v10:
- Added a TODO for implementing orientation switch for anx7625
- Updated the commit message for the absence of orientation switch
- Fixed typo in the commit message
- Collected Tested-by tag
Changes in v7:
- Fixed style issues in anx7625 driver
- Removed DT property validation in anx7625 driver.
- Extracted common codes to another commit.
Changes in v6:
- Squashed to a single patch
drivers/gpu/drm/bridge/analogix/Kconfig | 1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 92 +++
drivers/gpu/drm/bridge/analogix/anx7625.h | 13
3 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 173dada218ec..992b43ed1dd7 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -34,6 +34,7 @@ config DRM_ANALOGIX_ANX7625
tristate "Analogix Anx7625 MIPI to DP interface support"
depends on DRM
depends on OF
+ depends on TYPEC || TYPEC=n
select DRM_DISPLAY_DP_HELPER
select DRM_DISPLAY_HDCP_HELPER
select DRM_DISPLAY_HELPER
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 1cf242130b91..808dbf79d209 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -2572,6 +2574,90 @@ static void anx7625_runtime_disable(void *data)
pm_runtime_disable(data);
}
+static void anx7625_set_crosspoint_switch(struct anx7625_data *ctx,
+ enum typec_orientation orientation)
+{
+ if (orientation == TYPEC_ORIENTATION_NORMAL) {
+ anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
+ SW_SEL1_SSRX_RX1 | SW_SEL1_DPTX0_RX2);
+ anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
+ SW_SEL2_SSTX_TX1 | SW_SEL2_DPTX1_TX2);
+ } else if (orientation == TYPEC_ORIENTATION_REVERSE) {
+ anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_0,
+ SW_SEL1_SSRX_RX2 | SW_SEL1_DPTX0_RX1);
+ anx7625_reg_write(ctx, ctx->i2c.tcpc_client, TCPC_SWITCH_1,
+ SW_SEL2_SSTX_TX2 | SW_SEL2_DPTX1_TX1);
+ }
+}
+
+static void anx7625_typec_two_ports_update(struct anx7625_data *ctx)
+{
+ struct drm_dp_typec_switch_desc switch_desc = ctx->switch_desc;
+ /* Check if both ports available and do nothing to retain the current
one */
+ if (switch_desc.typec_ports[0].dp_connected &&
switch_desc.typec_ports[1].dp_connected)
+ return;
+
+ if (switch_desc.typec_ports[0].dp_connected)
+ anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_NORMAL);
+ else if (switch_desc.typec_ports[1].dp_connected)
+ anx7625_set_crosspoint_switch(ctx, TYPEC_ORIENTATION_REVERSE);
+}
+
+static int anx7625_typec_mux_set(struct typec_mux_dev *mux,
+struct typec_mux_state *state)
+{
+ struct drm_dp_typec_port_data *port_data = typec_mux_get_drvdata(mux);
+ struct anx7625_data *ctx = (struct anx7625_data *) port_data->data;
+ struct device *dev = >client->dev;
+ struct drm_dp_typec_switch_desc switch_desc = ctx->switch_desc;
+ bool new_dp_connected, old_dp_connected;
+
+ if (switch_desc.num_typec_switches == 1)
+ return 0;
+
+ old_dp_connected = switch_desc.typec_ports[0].dp_connected ||
+ switch_desc.typec_ports[1].dp_connected;
+
+ port_data->dp_connected = state->alt &&
+ state->alt->svid == USB_TYPEC_DP_SID &&
+ state->alt->mode == USB_TYPEC_DP_MODE;
+
+ dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n",
+ switch_desc.typec_ports[0].dp_connected,
switch_desc.typec_ports[1].dp_connected);
+
+ new_dp_connected = switch_desc.typec_ports[0].dp_connected ||
+ switch_desc.typec_ports[1].dp_connected;
+
+ /* dp on, power on first */
+ if (!old_dp_connected && new_dp_connected)
+ pm_runtime_get_sync(dev);
+
+ anx7625_typec_two_ports_update(ctx);
+
+ /* dp off, power off last */
+ if (old_dp_connected &&
[PATCH v10 5/9] drm/bridge: anx7625: Check for Type-C during panel registration
The output port endpoints can be connected to USB-C connectors.
Running drm_of_find_panel_or_bridge() with such endpoints leads to
a continuous return value of -EPROBE_DEFER, even though there is
no panel present.
To avoid this, check for the existence of a "mode-switch" property in
the port endpoint, and skip panel registration completely if so.
Signed-off-by: Pin-yen Lin
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
Changes in v6:
- New in v6
drivers/gpu/drm/bridge/analogix/anx7625.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b375887e655d..1cf242130b91 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1649,7 +1649,7 @@ static int anx7625_get_swing_setting(struct device *dev,
static int anx7625_parse_dt(struct device *dev,
struct anx7625_platform_data *pdata)
{
- struct device_node *np = dev->of_node, *ep0;
+ struct device_node *np = dev->of_node, *ep0, *sw;
int bus_type, mipi_lanes;
anx7625_get_swing_setting(dev, pdata);
@@ -1688,6 +1688,17 @@ static int anx7625_parse_dt(struct device *dev,
if (of_property_read_bool(np, "analogix,audio-enable"))
pdata->audio_en = 1;
+ /*
+* Don't bother finding a panel if a Type-C `mode-switch` property is
+* present in one of the endpoints.
+*/
+ for_each_endpoint_of_node(np, sw) {
+ if (of_property_read_bool(sw, "mode-switch")) {
+ of_node_put(sw);
+ return 0;
+ }
+ }
+
pdata->panel_bridge = devm_drm_of_get_bridge(dev, np, 1, 0);
if (IS_ERR(pdata->panel_bridge)) {
if (PTR_ERR(pdata->panel_bridge) == -ENODEV) {
--
2.39.0.314.g84b9a713c41-goog
[PATCH v10 4/9] dt-bindings: display: bridge: anx7625: Add mode-switch support
Analogix 7625 can be used in systems to switch the DP traffic between
two downstreams, which can be USB Type-C DisplayPort alternate mode
lane or regular DisplayPort output ports.
Update the binding to accommodate this usage by introducing a
data-lanes and a mode-switch property on endpoints.
Also include the link to the product brief in the bindings.
Signed-off-by: Pin-yen Lin
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
Changes in v9:
- Collected Reviewed-by tag
Changes in v8:
- Updated anx7625 bindings for data-lane property
- Fixed the subject prefix
Changes in v7:
- Fixed issues reported by dt_binding_check
- Updated the schema and the example dts for data-lanes.
- Changed to generic naming for the example dts node.
Changes in v6:
- Remove switches node and use endpoints and data-lanes property to
describe the connections.
.../display/bridge/analogix,anx7625.yaml | 99 ++-
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 4590186c4a0b..b49a350c40e3 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -12,7 +12,8 @@ maintainers:
description: |
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
- designed for portable devices.
+ designed for portable devices. Product brief is available at
+
https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
properties:
compatible:
@@ -112,10 +113,48 @@ properties:
data-lanes: true
port@1:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
description:
Video port for panel or connector.
+patternProperties:
+ "^endpoint@[01]$":
+$ref: /schemas/graph.yaml#/$defs/endpoint-base
+unevaluatedProperties: false
+
+properties:
+ reg:
+maxItems: 1
+
+ remote-endpoint: true
+
+ data-lanes:
+oneOf:
+ - items:
+ - enum: [0, 1, 2, 3]
+
+ - items:
+ - const: 0
+ - const: 1
+
+ - items:
+ - const: 2
+ - const: 3
+
+ - items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+
+ mode-switch:
+type: boolean
+description: Register this node as a Type-C mode switch or not.
+
+required:
+ - reg
+ - remote-endpoint
+
required:
- port@0
- port@1
@@ -164,8 +203,12 @@ examples:
};
mipi2dp_bridge_out: port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
reg = <1>;
-anx7625_out: endpoint {
+anx7625_out: endpoint@0 {
+reg = <0>;
remote-endpoint = <_in>;
};
};
@@ -186,3 +229,53 @@ examples:
};
};
};
+ - |
+i2c3 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+pinctrl-names = "default";
+pinctrl-0 = <_dp_pins>;
+enable-gpios = < 176 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 177 GPIO_ACTIVE_HIGH>;
+vdd10-supply = <_dpbrdg>;
+vdd18-supply = <_dpbrdg_dx>;
+vdd33-supply = <_dpbrdg_dx>;
+analogix,audio-enable;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+anx7625_dp_in: endpoint {
+bus-type = <7>;
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+reg = <1>;
+anx_typec0: endpoint@0 {
+reg = <0>;
+mode-switch;
+data-lanes = <0 1>;
+remote-endpoint = <_port0>;
+};
+anx_typec1: endpoint@1 {
+reg = <1>;
+mode-switch;
+data-lanes = <2
[PATCH v10 3/9] drm/display: Add Type-C switch helpers
Add helpers to register and unregister Type-C "switches" for bridges
capable of switching their output between two downstream devices.
The helper registers USB Type-C mode switches when the "mode-switch"
and the "data-lanes" properties are available in Device Tree.
Signed-off-by: Pin-yen Lin
Tested-by: Chen-Yu Tsai
Reviewed-by: Chen-Yu Tsai
Reviewed-by: AngeloGioacchino Del Regno
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
- Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks
- Print out the node name when errors on parsing DT
- Use dev_dbg instead of dev_warn when no Type-C switch nodes available
- Made the return path of drm_dp_register_mode_switch clearer
Changes in v8:
- Fixed the build issue when CONFIG_TYPEC=m
- Fixed some style issues
Changes in v7:
- Extracted the common codes to a helper function
- New in v7
drivers/gpu/drm/display/drm_dp_helper.c | 134
include/drm/display/drm_dp_helper.h | 17 +++
2 files changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..a2ec40a621cb 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -30,11 +30,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -3891,3 +3893,135 @@ int drm_panel_dp_aux_backlight(struct drm_panel *panel,
struct drm_dp_aux *aux)
EXPORT_SYMBOL(drm_panel_dp_aux_backlight);
#endif
+
+#if IS_REACHABLE(CONFIG_TYPEC)
+static int drm_dp_register_mode_switch(struct device *dev, struct device_node
*node,
+ struct drm_dp_typec_switch_desc
*switch_desc,
+ void *data, typec_mux_set_fn_t mux_set)
+{
+ struct drm_dp_typec_port_data *port_data;
+ struct typec_mux_desc mux_desc = {};
+ char name[32];
+ u32 dp_lanes[2];
+ int ret, num_lanes, port_num = -1;
+
+ num_lanes = drm_of_get_data_lanes_count(node, 0, 2);
+ if (num_lanes <= 0) {
+ dev_err(dev, "Error on getting data lanes count from %s: %d\n",
+ node->name, num_lanes);
+ return num_lanes;
+ }
+
+ ret = of_property_read_u32_array(node, "data-lanes", dp_lanes,
num_lanes);
+ if (ret) {
+ dev_err(dev, "Failed to read the data-lanes variable from %s:
%d\n",
+ node->name, ret);
+ return ret;
+ }
+
+ port_num = dp_lanes[0] / 2;
+
+ port_data = _desc->typec_ports[port_num];
+ port_data->data = data;
+ mux_desc.fwnode = >fwnode;
+ mux_desc.drvdata = port_data;
+ snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
+ mux_desc.name = name;
+ mux_desc.set = mux_set;
+
+ port_data->typec_mux = typec_mux_register(dev, _desc);
+ if (IS_ERR(port_data->typec_mux)) {
+ ret = PTR_ERR(port_data->typec_mux);
+ dev_err(dev, "Mode switch register for port %d failed: %d\n",
+ port_num, ret);
+
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * drm_dp_register_typec_switches() - register Type-C switches
+ * @dev: Device that registers Type-C switches
+ * @port: Device node for the switch
+ * @switch_desc: A Type-C switch descriptor
+ * @data: Private data for the switches
+ * @mux_set: Callback function for typec_mux_set
+ *
+ * This function registers USB Type-C switches for DP bridges that can switch
+ * the output signal between their output pins.
+ *
+ * Currently only mode switches are implemented, and the function assumes the
+ * given @port device node has endpoints with "mode-switch" property.
+ * Register the endpoint as port 0 if the "data-lanes" property falls in 0/1,
+ * and register it as port 1 if "data-lanes" falls in 2/3.
+ */
+int drm_dp_register_typec_switches(struct device *dev, struct device_node
*port,
+ struct drm_dp_typec_switch_desc *switch_desc,
+ void *data, typec_mux_set_fn_t mux_set)
+{
+ struct device_node *sw;
+ int ret;
+
+ for_each_child_of_node(port, sw) {
+ if (of_property_read_bool(sw, "mode-switch"))
+ switch_desc->num_typec_switches++;
+ }
+
+ if (!switch_desc->num_typec_switches) {
+ dev_dbg(dev, "No Type-C switches node found\n");
+ return 0;
+ }
+
+ switch_desc->typec_ports = devm_kcalloc(
+ dev, switch_desc->num_typec_switches,
+ sizeof(struct drm_dp_typec_port_data), GFP_KERNEL);
+
+ if (!switch_desc->typec_ports)
+ return -ENOMEM;
+
+ /* Register switches for each connector. */
+ for_each_child_of_node(port, sw) {
+ if (!of_property_read_bool(sw,
[PATCH v10 2/9] platform/chrome: cros_ec_typec: Purge blocking switch devlinks
From: Prashant Malani
When using OF graph, the fw_devlink code will create links between the
individual port driver (cros-ec-typec here) and the parent device for
a Type-C switch (like mode-switch). Since the mode-switch will in turn
have the usb-c-connector (i.e the child of the port driver) as a
supplier, fw_devlink will not be able to resolve the cyclic dependency
correctly.
As a result, the mode-switch driver probe() never runs, so mode-switches
are never registered. Because of that, the port driver probe constantly
fails with -EPROBE_DEFER, because the Type-C connector class requires all
switch devices to be registered prior to port registration.
To break this deadlock and allow the mode-switch registration to occur,
purge all the usb-c-connector nodes' absent suppliers. This eliminates
the connector as a supplier for a switch and allows it to be probed.
Signed-off-by: Prashant Malani
Signed-off-by: Pin-yen Lin
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
Changes in v7:
- Fix the long comment lines
Changes in v6:
- New in v6
drivers/platform/chrome/cros_ec_typec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 2a7ff14dc37e..302474a647cc 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -382,6 +382,16 @@ static int cros_typec_init_ports(struct cros_typec_data
*typec)
return -EINVAL;
}
+ /*
+* OF graph may have set up some device links with switches,
+* since connectors have their own compatible. Purge these
+* to avoid a deadlock in switch probe (the switch mistakenly
+* assumes the connector is a supplier).
+*/
+ if (dev_of_node(dev))
+ device_for_each_child_node(dev, fwnode)
+ fw_devlink_purge_absent_suppliers(fwnode);
+
/* DT uses "reg" to specify port number. */
port_prop = dev->of_node ? "reg" : "port-number";
device_for_each_child_node(dev, fwnode) {
--
2.39.0.314.g84b9a713c41-goog
[PATCH v10 1/9] device property: Add remote endpoint to devcon matcher
From: Prashant Malani
When searching the device graph for device matches, check the
remote-endpoint itself for a match.
Some drivers register devices for individual endpoints. This allows
the matcher code to evaluate those for a match too, instead
of only looking at the remote parent devices. This is required when a
device supports two mode switches in its endpoints, so we can't simply
register the mode switch with the parent node.
Signed-off-by: Prashant Malani
Signed-off-by: Pin-yen Lin
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
---
Changes in v10:
- Collected Reviewed-by and Tested-by tags
Changes in v6:
- New in v6
drivers/base/property.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 2a5a37fcd998..48877af4e444 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1223,6 +1223,21 @@ static unsigned int fwnode_graph_devcon_matches(struct
fwnode_handle *fwnode,
break;
}
+ /*
+* Some drivers may register devices for endpoints. Check
+* the remote-endpoints for matches in addition to the remote
+* port parent.
+*/
+ node = fwnode_graph_get_remote_endpoint(ep);
+ if (fwnode_device_is_available(node)) {
+ ret = match(node, con_id, data);
+ if (ret) {
+ if (matches)
+ matches[count] = ret;
+ count++;
+ }
+ }
+
node = fwnode_graph_get_remote_port_parent(ep);
if (!fwnode_device_is_available(node)) {
fwnode_handle_put(node);
--
2.39.0.314.g84b9a713c41-goog
[PATCH v10 0/9] Register Type-C mode-switch in DP bridge endpoints
This series introduces bindings for anx7625/it6505 to register Type-C mode-switch in their output endpoints, and use data-lanes property to describe the pin connections. The first two patch modifies fwnode_graph_devcon_matches and cros_typec_init_ports to enable the registration of the switches. Patch 4~6 introduce the bindings for anx7625 and the corresponding driver modifications. Patch 7~9 add similar bindings and driver changes for it6505. v9: https://lore.kernel.org/all/20230109084101.265664-1-treapk...@chromium.org/ v8: https://lore.kernel.org/all/20230107102231.23682-1-treapk...@chromium.org/ v7: https://lore.kernel.org/all/20230105132457.4125372-1-treapk...@chromium.org/ v6: https://lore.kernel.org/all/20221124102056.393220-1-treapk...@chromium.org/ v5: https://lore.kernel.org/linux-usb/20220622173605.1168416-1-pmal...@chromium.org/ Changes in v10: - Collected Reviewed-by and Tested-by tags - Replaced "void *" with "typec_mux_set_fn_t" for mux_set callbacks - Print out the node name when errors on parsing DT - Use dev_dbg instead of dev_warn when no Type-C switch nodes available - Made the return path of drm_dp_register_mode_switch clearer - Added a TODO for implementing orientation switch for anx7625 - Updated the commit message for the absence of orientation switch - Fixed typo in the commit message Changes in v9: - Collected Reviewed-by tag - Fixed subject prefix again - Changed the naming of the example node for it6505 Changes in v8: - Fixed the build issue when CONFIG_TYPEC=m - Fixed some style issues - Fixed the subject prefixes for the bindings patch - Fixed the bindings for data-lanes properties Changes in v7: - Fix the long comment lines - Extracted the common codes to a helper function - Fixed style issues in anx7625 driver - Removed DT property validation in anx7625 driver. - Fixed style issues in it6505 driver - Removed the redundant sleep in it6505 driver - Removed DT property validation in it6505 driver - Rebased to drm-misc-next - Fixed indentations in bindings patches - Added a new patch to fix indentations in Kconfig Changes in v6: - Changed it6505_typec_mux_set callback function to accommodate with the latest drm-misc patches - Changed the driver implementation to accommodate with the new binding - Dropped typec-switch binding and use endpoints and data-lanes properties to describe the pin connections - Added new patches (patch 1,2,4) to fix probing issues - Changed the bindings of it6505/anx7625 and modified the drivers accordingly - Merged it6505/anx7625 driver changes into a single patch Pin-yen Lin (7): drm/display: Add Type-C switch helpers dt-bindings: display: bridge: anx7625: Add mode-switch support drm/bridge: anx7625: Check for Type-C during panel registration drm/bridge: anx7625: Register Type C mode switches dt-bindings: display: bridge: it6505: Add mode-switch support drm/bridge: it6505: Fix Kconfig indentation drm/bridge: it6505: Register Type C mode switches Prashant Malani (2): device property: Add remote endpoint to devcon matcher platform/chrome: cros_ec_typec: Purge blocking switch devlinks .../display/bridge/analogix,anx7625.yaml | 99 - .../bindings/display/bridge/ite,it6505.yaml | 93 ++-- drivers/base/property.c | 15 ++ drivers/gpu/drm/bridge/Kconfig| 21 +-- drivers/gpu/drm/bridge/analogix/Kconfig | 1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 105 +- drivers/gpu/drm/bridge/analogix/anx7625.h | 13 ++ drivers/gpu/drm/bridge/ite-it6505.c | 119 +++- drivers/gpu/drm/display/drm_dp_helper.c | 134 ++ drivers/platform/chrome/cros_ec_typec.c | 10 ++ include/drm/display/drm_dp_helper.h | 17 +++ 11 files changed, 598 insertions(+), 29 deletions(-) -- 2.39.0.314.g84b9a713c41-goog
Re: [PATCH v3 1/2] drm/msm/dsi: add a helper method to compute the dsi byte clk
On 12/01/2023 02:15, Abhinav Kumar wrote: Re-arrange the dsi_calc_pclk method to two helpers, one to compute the DSI byte clk and the other to compute the pclk. This makes the separation of the two clean and also allows clients to compute and use the dsi byte clk separately. changes in v2: - move the assignments to definition lines Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/msm/dsi/dsi.h | 2 ++ drivers/gpu/drm/msm/dsi/dsi_host.c | 21 ++--- 2 files changed, 16 insertions(+), 7 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()
On 12/01/2023 02:16, Abhinav Kumar wrote: Currently there is no protection against a user trying to set an unsupported mode on DSI. Implement a check based on the opp table whether the byte clock for the mode can be supported by validating whether an opp table entry exists. For devices which have not added opp table support yet, skip this check otherwise it will break bootup on those devices. changes in v3: - make the comment shorter - handle all errors except ENODEV Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15 Reported-by: Rob Clark Signed-off-by: Abhinav Kumar --- Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] drm/msm/dpu: Remove some unused variables
On 12/01/2023 05:38, Jiapeng Chong wrote: Variables 'sc8280xp_regdma' and 'sm8350_regdma' are defined in the dpu_hw_catalog.c file, but not used elsewhere, so remove these unused variables. drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:2029:37: warning: unused variable 'sc8280xp_regdma'. drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:2053:37: warning: unused variable 'sm8350_regdma'. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3722 Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 16 1 file changed, 16 deletions(-) NAK, the patch should change catalog entries to use correct regdma entries instead of deleting them. -- With best wishes Dmitry
[PATCH] drm/msm/dpu: Remove some unused variables
Variables 'sc8280xp_regdma' and 'sm8350_regdma' are defined in the
dpu_hw_catalog.c file, but not used elsewhere, so remove these unused
variables.
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:2029:37: warning: unused
variable 'sc8280xp_regdma'.
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:2053:37: warning: unused
variable 'sm8350_regdma'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3722
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0f3da480b066..79bbef93948f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -2026,14 +2026,6 @@ static const struct dpu_vbif_cfg sdm845_vbif[] = {
},
};
-static const struct dpu_reg_dma_cfg sc8280xp_regdma = {
- .base = 0x0,
- .version = 0x0002,
- .trigger_sel_off = 0x119c,
- .xin_id = 7,
- .clk_ctrl = DPU_CLK_CTRL_REG_DMA,
-};
-
static const struct dpu_reg_dma_cfg sdm845_regdma = {
.base = 0x0, .version = 0x1, .trigger_sel_off = 0x119c
};
@@ -2050,14 +2042,6 @@ static const struct dpu_reg_dma_cfg sm8250_regdma = {
.clk_ctrl = DPU_CLK_CTRL_REG_DMA,
};
-static const struct dpu_reg_dma_cfg sm8350_regdma = {
- .base = 0x400,
- .version = 0x0002,
- .trigger_sel_off = 0x119c,
- .xin_id = 7,
- .clk_ctrl = DPU_CLK_CTRL_REG_DMA,
-};
-
static const struct dpu_reg_dma_cfg sm8450_regdma = {
.base = 0x0,
.version = 0x0002,
--
2.20.1.7.g153144c
[pull] amdgpu, amdkfd drm-fixes-6.2
Hi Dave, Daniel, Fixes for 6.2. The following changes since commit 93235bfd5a9c3329df31d1a4d7a93d138b3138c2: Merge tag 'amd-drm-fixes-6.2-2023-01-04' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-01-05 12:13:51 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.2-2023-01-11 for you to fetch changes up to a6941f89d7c6a6ba49316bbd7da2fb2f719119a7: drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU (2023-01-10 18:11:08 -0500) amd-drm-fixes-6.2-2023-01-11: amdgpu: - SMU13 fan speed fix - SMU13 fix power cap handling - SMU13 BACO fix - Fix a possible segfault in bo validation error case - Delay removal of firmware framebuffer - Fix error when unloading amdkfd: - SVM fix when clearing vram - GC11 fix for multi-GPU Eric Huang (2): drm/amdkfd: Add sync after creating vram bo drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU Evan Quan (2): drm/amd/pm: correct the reference clock for fan speed(rpm) calculation drm/amd/pm: add the missing mapping for PPT feature on SMU13.0.0 and 13.0.7 Guchun Chen (1): drm/amd/pm/smu13: BACO is supported when it's in BACO state Luben Tuikov (1): drm/amdgpu: Fix potential NULL dereference Mario Limonciello (1): drm/amd: Delay removal of the firmware framebuffer YiPeng Chai (1): drm/amdgpu: Fixed bug on error when unloading amdgpu drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 8 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 5 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 9 + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 8 ++-- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 1 + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 1 + 10 files changed, 31 insertions(+), 13 deletions(-)
[PATCH] drm/amd/display: Remove useless else if
The assignment of the else and if branches is the same, so the if else here is redundant, so we remove it. ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1951:2-4: WARNING: possible condition with no effect (if == else). Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3719 Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 + 1 file changed, 1 insertion(+), 4 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 4300ce98ce8d..aa3024e58d12 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1948,10 +1948,7 @@ static int dm_dmub_sw_init(struct amdgpu_device *adev) dmub_asic = DMUB_ASIC_DCN21; break; case IP_VERSION(3, 0, 0): - if (adev->ip_versions[GC_HWIP][0] == IP_VERSION(10, 3, 0)) - dmub_asic = DMUB_ASIC_DCN30; - else - dmub_asic = DMUB_ASIC_DCN30; + dmub_asic = DMUB_ASIC_DCN30; break; case IP_VERSION(3, 0, 1): dmub_asic = DMUB_ASIC_DCN301; -- 2.20.1.7.g153144c
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/pxp: Use drm_dbg if arb session failed due to fw version
On 12/21/2022 9:49 AM, Alan Previn wrote:
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually get a -ENODEV for the protected context
creation which is the correct behavior and we don't create unnecessary
drm_error's in our dmesg (for what is unsupported platforms).
LGTM. Is there a link to where these pxp status codes are documented?
Reviewed-by: Vinay Belgaumkar
Changes from prio revs:
v2 : - remove unnecessary newline. (Jani)
v1 : - print incorrect version from input packet, not output.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index c2f23394f9b8..aaa8187a0afb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -17,6 +17,7 @@
*/
enum pxp_status {
PXP_STATUS_SUCCESS = 0x0,
+ PXP_STATUS_ERROR_API_VERSION = 0x1002,
PXP_STATUS_OP_NOT_PERMITTED = 0x4013
};
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d50354bfb993..73aa8015f828 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -298,6 +298,10 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
if (ret)
drm_err(>drm, "Failed to send tee msg ret=[%d]\n", ret);
+ else if (msg_out.header.status == PXP_STATUS_ERROR_API_VERSION)
+ drm_dbg(>drm, "PXP firmware version unsupported, requested:
"
+ "CMD-ID-[0x%08x] on API-Ver-[0x%08x]\n",
+ msg_in.header.command_id, msg_in.header.api_version);
else if (msg_out.header.status != 0x0)
drm_warn(>drm, "PXP firmware failed arb session init request
ret=[0x%08x]\n",
msg_out.header.status);
base-commit: cc44a1e87ea6b788868878295119398966f98a81
[PATCH v2 12/14] drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
warns:
clang-16: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Similar to commit 84edc2eff827 ("selftest/fpu: avoid clang warning"),
just add this flag to GCC builds. Commit 0f0727d971f6 ("drm/amd/display:
readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP
routines") added '-msse2' to prevent clang from emitting software
floating point routines.
Signed-off-by: Nathan Chancellor
Acked-by: Alex Deucher
---
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/dc/dml/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 0ecea87cf48f..9d0f79dff2e3 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -26,7 +26,8 @@
# subcomponents.
ifdef CONFIG_X86
-dml_ccflags := -mhard-float -msse
+dml_ccflags-$(CONFIG_CC_IS_GCC) := -mhard-float
+dml_ccflags := $(dml_ccflags-y) -msse
endif
ifdef CONFIG_PPC64
--
2.39.0
[PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS
Hi all,
Clang can emit a few different warnings when it encounters a flag that it
recognizes but does not support internally. These warnings are elevated to
errors within {as,cc}-option via -Werror to catch unsupported flags that should
not be added to KBUILD_{A,C}FLAGS; see commit c3f0d0bc5b01 ("kbuild, LLVMLinux:
Add -Werror to cc-option to support clang").
If an unsupported flag is unconditionally to KBUILD_{A,C}FLAGS, all subsequent
{as,cc}-option will always fail, preventing supported and even potentially
necessary flags from getting adding to the tool flags.
One would expect these warnings to be visible in the kernel build logs since
they are added to KBUILD_{A,C}FLAGS but unfortunately, these warnings are
hidden with clang's -Qunused-arguments flag, which is added to KBUILD_CPPFLAGS
and used for both compiling and assembling files.
Patches 1-4 address the internal inconsistencies of invoking the assembler
within kbuild by using KBUILD_AFLAGS consistently and using '-x
assembler-with-cpp' over '-x assembler'. This matches how assembly files are
built across the kernel and helps avoid problems in situations where macro
definitions or warning flags are present in KBUILD_AFLAGS, which cause
instances of -Wunused-command-line-argument when the preprocessor is not called
to consume them. There were a couple of places in architecture code where this
change would break things so those are fixed first.
Patches 5-12 clean up warnings that will show up when -Qunused-argument is
dropped. I hope none of these are controversial.
Patch 13 turns two warnings into errors so that the presence of unused flags
cannot be easily ignored.
Patch 14 drops -Qunused-argument. This is done last so that it can be easily
reverted if need be.
This series has seen my personal test framework, which tests several different
configurations and architectures, with LLVM tip of tree (16.0.0). I have done
defconfig, allmodconfig, and allnoconfig builds for arm, arm64, i386, mips,
powerpc, riscv, s390, and x86_64 with GCC 12.2.0 as well but I am hoping the
rest of the test infrastructure will catch any lurking problems.
I would like this series to stay together so that there is no opportunity for
breakage so please consider giving acks so that this can be carried via the
kbuild tree (and many thanks to the people who have already provided such
tags).
---
Changes in v2:
- Pick up tags where provided (thank you everyone!)
- Patch 6 and 9: Clarify that '-s' is a compiler flag that is only relevant to
the linking phase and remove all mention of the assembler's '-s' flag, as the
assembler is never directly invoked (Nick, Segher)
- Patch 7: Move '-z noexecstack' into new ldflags-y variable (Nick)
- Patch 8: Reword commit message to explain the problem in a clearer manner
(Nick)
- Link to v1:
https://lore.kernel.org/r/20221228-drop-qunused-arguments-v1-0-658cbc8fc...@kernel.org
---
Nathan Chancellor (12):
MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT
MIPS: Prefer cc-option for additions to cflags
powerpc: Remove linker flag from KBUILD_AFLAGS
powerpc/vdso: Remove unused '-s' flag from ASFLAGS
powerpc/vdso: Improve linker flags
powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with
clang
s390/vdso: Drop unused '-s' flag from KBUILD_AFLAGS_64
s390/vdso: Drop '-shared' from KBUILD_CFLAGS_64
s390/purgatory: Remove unused '-MD' and unnecessary '-c' flags
drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang
kbuild: Turn a couple more of clang's unused option warnings into errors
kbuild: Stop using '-Qunused-arguments' with clang
Nick Desaulniers (2):
x86/boot/compressed: prefer cc-option for CFLAGS additions
kbuild: Update assembler calls to use proper flags and language target
Makefile| 1 -
arch/mips/Makefile | 13 ++---
arch/mips/include/asm/asmmacro-32.h | 4 +--
arch/mips/include/asm/asmmacro.h| 42 ++---
arch/mips/include/asm/fpregdef.h| 14 --
arch/mips/include/asm/mipsregs.h| 20 +++---
arch/mips/kernel/genex.S| 2 +-
arch/mips/kernel/r2300_fpu.S| 4 +--
arch/mips/kernel/r4k_fpu.S | 12 -
arch/mips/kvm/fpu.S | 6 ++---
arch/mips/loongson2ef/Platform | 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/kernel/vdso/Makefile | 25 +++--
arch/s390/kernel/vdso64/Makefile| 4 +--
arch/s390/purgatory/Makefile| 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dml/Makefile | 3 ++-
scripts/Kconfig.include | 2 +-
scripts/Makefile.clang | 2 ++
scripts/Makefile.compiler | 8
[PATCH 4/4] drm/i915/guc: Add a debug print on GuC triggered reset
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 99d09e3394597..0be7c27a436dd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4665,6 +4665,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
+ drm_dbg(_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting =
%d, banned = %d\n",
+ ce->guc_id.id, test_bit(CONTEXT_EXITING, >flags),
+ test_bit(CONTEXT_BANNED, >flags));
+
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
--
2.39.0
[PATCH 3/4] drm/i915/guc: Look for a guilty context when an engine reset fails
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..99d09e3394597 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4754,11 +4754,24 @@ static void reset_fail_worker_func(struct work_struct
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(>submission_state.lock, flags);
- if (likely(reset_fail_mask))
+ if (likely(reset_fail_mask)) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* GuC is toast at this point - it dead loops after sending the
failed
+* reset notification. So need to manually determine the guilty
context.
+* Note that it should be safe/reliable to do this here because
the GuC
+* is toast and will not be scheduling behind the KMD's back.
+*/
+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
+ intel_guc_find_hung_context(engine);
+
intel_gt_handle_error(gt, reset_fail_mask,
I915_ERROR_CAPTURE,
- "GuC failed to reset engine mask=0x%x\n",
+ "GuC failed to reset engine mask=0x%x",
reset_fail_mask);
+ }
}
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
--
2.39.0
[PATCH 2/4] drm/i915: Allow error capture of a pending request
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that this might be better than nothing.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index bd2cf7d235df0..2e338a9667a4b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1628,11 +1628,9 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (rq && !i915_request_started(rq)) {
- drm_info(>gt->i915->drm, "Got hung context on
%s with no active request!\n",
-engine->name);
- rq = NULL;
- }
+ if (rq && !i915_request_started(rq))
+ drm_info(>gt->i915->drm, "Confused - active
request not yet started: %lld:%lld, ce = 0x%04X/%s!\n",
+rq->fence.context, rq->fence.seqno,
ce->guc_id.id, engine->name);
} else {
/*
* Getting here with GuC enabled means it is a forced error
capture
--
2.39.0
[PATCH 1/4] drm/i915: Allow error capture without a request
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.
In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.
So update the error capture code to always record engine information
if an engine is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.
v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null
pointer.
Signed-off-by: John Harrison
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_gpu_error.c | 61 +++
1 file changed, 43 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64e..bd2cf7d235df0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct
intel_engine_coredump *ee)
}
static bool record_context(struct i915_gem_context_coredump *e,
- const struct i915_request *rq)
+ struct intel_context *ce)
{
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
rcu_read_lock();
- ctx = rcu_dereference(rq->context->gem_context);
+ ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
- e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
- e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+ e->total_runtime = intel_context_get_total_runtime_ns(ce);
+ e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
simulated = i915_gem_context_no_error_capture(ctx);
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs
*engine, gfp_t gfp, u32 dump_
return ee;
}
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+ struct intel_context *ce,
+ gfp_t gfp)
+{
+ struct intel_engine_capture_vma *vma = NULL;
+
+ ee->simulated |= record_context(>context, ce);
+ if (ee->simulated)
+ return NULL;
+
+ /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+ vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+ vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+ return vma;
+}
+
struct intel_engine_capture_vma *
intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
struct i915_request *rq,
gfp_t gfp)
{
- struct intel_engine_capture_vma *vma = NULL;
+ struct intel_engine_capture_vma *vma;
- ee->simulated |= record_context(>context, rq);
- if (ee->simulated)
+ vma = engine_coredump_add_context(ee, rq->context, gfp);
+ if (!vma)
return NULL;
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct
intel_engine_coredump *ee,
*/
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
- vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
- vma = capture_vma(vma, rq->context->state, "HW context", gfp);
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1608,8 +1628,11 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (!rq || !i915_request_started(rq))
- goto no_request_capture;
+ if (rq && !i915_request_started(rq)) {
+ drm_info(>gt->i915->drm, "Got hung context on
%s with no active request!\n",
+engine->name);
+ rq = NULL;
+ }
} else {
[PATCH 0/4] Allow error capture without a request / on reset failure
From: John Harrison It is technically possible to get a hung context without a valid request. In such a situation, try to provide as much information in the error capture as possible rather than just aborting and capturing nothing. Similarly, in the case of an engine reset failure the GuC is not able to report the guilty context. So try a manual search instead of reporting nothing. Signed-off-by: John Harrison John Harrison (4): drm/i915: Allow error capture without a request drm/i915: Allow error capture of a pending request drm/i915/guc: Look for a guilty context when an engine reset fails drm/i915/guc: Add a debug print on GuC triggered reset .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 59 +-- 2 files changed, 60 insertions(+), 20 deletions(-) -- 2.39.0
Re: [PATCH 4/5] drm/vmwgfx: Remove redundant framebuffer format check
On Mon, 2023-01-09 at 07:58 -0300, Maíra Canal wrote:
> Now that framebuffer_check() verifies that the format is properly
> supported, there is no need to check it again on vmwgfx's inside
> helpers.
>
> Therefore, remove the redundant framebuffer format check from the
> vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
> functions, letting framebuffer_check() perform the framebuffer
> validation.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 257f090071f1..05b8d8f912bf 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1317,15 +1317,6 @@ static int vmw_kms_new_framebuffer_surface(struct
> vmw_private *dev_priv,
> * Sanity checks.
> */
>
> - if (!drm_any_plane_has_format(_priv->drm,
> - mode_cmd->pixel_format,
> - mode_cmd->modifier[0])) {
> - drm_dbg(_priv->drm,
> - "unsupported pixel format %p4cc / modifier 0x%llx\n",
> - _cmd->pixel_format, mode_cmd->modifier[0]);
> - return -EINVAL;
> - }
> -
> /* Surface must be marked as a scanout. */
> if (unlikely(!surface->metadata.scanout))
> return -EINVAL;
> @@ -1648,15 +1639,6 @@ static int vmw_kms_new_framebuffer_bo(struct
> vmw_private
> *dev_priv,
> return -EINVAL;
> }
>
> - if (!drm_any_plane_has_format(_priv->drm,
> - mode_cmd->pixel_format,
> - mode_cmd->modifier[0])) {
> - drm_dbg(_priv->drm,
> - "unsupported pixel format %p4cc / modifier 0x%llx\n",
> - _cmd->pixel_format, mode_cmd->modifier[0]);
> - return -EINVAL;
> - }
> -
> vfbd = kzalloc(sizeof(*vfbd), GFP_KERNEL);
> if (!vfbd) {
> ret = -ENOMEM;
That's a nice cleanup. Thanks.
Reviewed-by: Zack Rusin
RE: [PATCH v11 0/3] drm: exynos: dsi: Restore the bridge chain
Hi Jagan Teki, Sorry for late. > -Original Message- > From: Jagan Teki > Sent: Saturday, January 7, 2023 2:56 AM > To: Marek Szyprowski ; Inki Dae > ; Seung-Woo Kim ; Kyungmin Park > ; Neil Armstrong ; Robert > Foss ; Andrzej Hajda ; Sam > Ravnborg > Cc: Marek Vasut ; linux-samsung-...@vger.kernel.org; dri- > de...@lists.freedesktop.org; linux-amarula amar...@amarulasolutions.com> > Subject: Re: [PATCH v11 0/3] drm: exynos: dsi: Restore the bridge chain > > On Mon, Dec 12, 2022 at 11:59 PM Jagan Teki > wrote: > > > > Split the Exynos DSI bridge chain update patches from Samsung DSIM > > bridge driver for easy to apply. > > > > Changes for v11: > > - enable bridge.pre_enable_prev_first > > Changes for v10: > > - collect Marek.V Review tag > > Any update on this? > Added Thierry Reding who is a maintainer of DRM panel drivers. I will pick this patch series - including panel and bride patches - up. Thierry and Andrzej, please let me know if any problem. Thanks, Inki Dae > Jagan.
[PATCH 1/2] drm/i915/guc: Improve clean up of busyness stats worker
From: John Harrison
The stats worker thread management was mis-matched between
enable/disable call sites. Fix those up. Also, abstract the cancel
code into a helper function rather than replicating in multiple places.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22 ---
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..982364777d0c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1435,19 +1435,25 @@ static void guc_init_engine_stats(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
+ int ret;
mod_delayed_work(system_highpri_wq, >timestamp.work,
guc->timestamp.ping_delay);
- with_intel_runtime_pm(>i915->runtime_pm, wakeref) {
- int ret = guc_action_enable_usage_stats(guc);
+ with_intel_runtime_pm(>i915->runtime_pm, wakeref)
+ ret = guc_action_enable_usage_stats(guc);
- if (ret)
- drm_err(>i915->drm,
- "Failed to enable usage stats: %d!\n", ret);
+ if (ret) {
+ cancel_delayed_work_sync(>timestamp.work);
+ drm_err(>i915->drm, "Failed to enable usage stats: %d!\n",
ret);
}
}
+static void guc_park_engine_stats(struct intel_guc *guc)
+{
+ cancel_delayed_work_sync(>timestamp.work);
+}
+
void intel_guc_busyness_park(struct intel_gt *gt)
{
struct intel_guc *guc = >uc.guc;
@@ -1460,7 +1466,7 @@ void intel_guc_busyness_park(struct intel_gt *gt)
* and causes an unclaimed register access warning. Cancel the worker
* synchronously here.
*/
- cancel_delayed_work_sync(>timestamp.work);
+ guc_park_engine_stats(guc);
/*
* Before parking, we should sample engine busyness stats if we need to.
@@ -4409,11 +4415,11 @@ void intel_guc_submission_enable(struct intel_guc *guc)
guc_init_global_schedule_policy(guc);
}
+/* Note: By the time we're here, GuC may have already been reset */
void intel_guc_submission_disable(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
-
- /* Note: By the time we're here, GuC may have already been reset */
+ guc_park_engine_stats(guc);
/* Disable and route to host */
if (GRAPHICS_VER(gt->i915) >= 12)
--
2.39.0
[PATCH 2/2] drm/i915/guc: Fix missing return code checks in submission init
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kernel context. However, there was no return code checking on any of
the kernel context registration paths. So the driver kept going and
tried to use the kernel context for the record defaults process.
This would not cause any actual problems. The invalid requests would
be rejected by GuC and ultimately the start up sequence would
correctly wedge due to the context creation failure. But fixing the
issue correctly rather ignoring it means we won't get CI complaining
when the fast request patch lands and enables the extra error checking.
So fix it by checking for errors and aborting as appropriate when
creating kernel contexts. While at it, clean up some other submission
init related failure cleanup paths. Also, rename guc_init_lrc_mapping
to guc_init_submission as the former name hasn't been valid in a long
time.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 91 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +-
3 files changed, 75 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 982364777d0c6..dd856fd92945b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1431,7 +1431,7 @@ static int guc_action_enable_usage_stats(struct intel_guc
*guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
-static void guc_init_engine_stats(struct intel_guc *guc)
+static int guc_init_engine_stats(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
@@ -1447,6 +1447,8 @@ static void guc_init_engine_stats(struct intel_guc *guc)
cancel_delayed_work_sync(>timestamp.work);
drm_err(>i915->drm, "Failed to enable usage stats: %d!\n",
ret);
}
+
+ return ret;
}
static void guc_park_engine_stats(struct intel_guc *guc)
@@ -4108,9 +4110,11 @@ static void guc_set_default_submission(struct
intel_engine_cs *engine)
engine->submit_request = guc_submit_request;
}
-static inline void guc_kernel_context_pin(struct intel_guc *guc,
- struct intel_context *ce)
+static inline int guc_kernel_context_pin(struct intel_guc *guc,
+struct intel_context *ce)
{
+ int ret;
+
/*
* Note: we purposefully do not check the returns below because
* the registration can only fail if a reset is just starting.
@@ -4118,16 +4122,24 @@ static inline void guc_kernel_context_pin(struct
intel_guc *guc,
* isn't happening and even it did this code would be run again.
*/
- if (context_guc_id_invalid(ce))
- pin_guc_id(guc, ce);
+ if (context_guc_id_invalid(ce)) {
+ int ret = pin_guc_id(guc, ce);
+
+ if (ret < 0)
+ return ret;
+ }
if (!test_bit(CONTEXT_GUC_INIT, >flags))
guc_context_init(ce);
- try_context_registration(ce, true);
+ ret = try_context_registration(ce, true);
+ if (ret)
+ unpin_guc_id(guc, ce);
+
+ return ret;
}
-static inline void guc_init_lrc_mapping(struct intel_guc *guc)
+static inline int guc_init_submission(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct intel_engine_cs *engine;
@@ -4154,9 +4166,17 @@ static inline void guc_init_lrc_mapping(struct intel_guc
*guc)
struct intel_context *ce;
list_for_each_entry(ce, >pinned_contexts_list,
- pinned_contexts_link)
- guc_kernel_context_pin(guc, ce);
+ pinned_contexts_link) {
+ int ret = guc_kernel_context_pin(guc, ce);
+
+ if (ret) {
+ /* No point in trying to clean up as i915 will
wedge on failure */
+ return ret;
+ }
+ }
}
+
+ return 0;
}
static void guc_release(struct intel_engine_cs *engine)
@@ -4400,30 +4420,57 @@ static int guc_init_global_schedule_policy(struct
intel_guc *guc)
return ret;
}
-void intel_guc_submission_enable(struct intel_guc *guc)
+static void guc_route_semaphores(struct intel_guc *guc, bool to_guc)
{
struct intel_gt *gt = guc_to_gt(guc);
+ u32 val;
- /* Enable and route to GuC */
- if (GRAPHICS_VER(gt->i915) >= 12)
-
[PATCH 0/2] Clean up some GuC related failure paths
From: John Harrison Improve failure code handling during GuC intialisation. Signed-off-by: John Harrison John Harrison (2): drm/i915/guc: Improve clean up of busyness stats worker drm/i915/guc: Fix missing return code checks in submission init .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 113 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +- 3 files changed, 89 insertions(+), 33 deletions(-) -- 2.39.0
[PATCH 5/6] drm/amdgpu: update mappings not managed by KFD
When restoring after an eviction, use amdgpu_vm_handle_moved to update
BO VA mappings in KFD VMs that are not managed through the KFD API. This
should allow using the render node API to create more flexible memory
mappings in KFD VMs.
v2: Sync with pd fence after all page table updates
v3: Update comments, remove TODOs that are no longer applicable
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 28 +++
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 79213f476493..df08e84f01d7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2728,12 +2728,6 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
if (ret)
goto validate_map_fail;
- ret = process_sync_pds_resv(process_info, _obj);
- if (ret) {
- pr_debug("Memory eviction: Failed to sync to PD BO moving
fence. Try again\n");
- goto validate_map_fail;
- }
-
/* Validate BOs and map them to GPUVM (update VM page tables). */
list_for_each_entry(mem, _info->kfd_bo_list,
validate_list.head) {
@@ -2781,6 +2775,19 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
if (failed_size)
pr_debug("0x%lx/0x%lx in system\n", failed_size, total_size);
+ /* Update mappings not managed by KFD */
+ list_for_each_entry(peer_vm, _info->vm_list_head,
+ vm_list_node) {
+ struct amdgpu_device *adev = amdgpu_ttm_adev(
+ peer_vm->root.bo->tbo.bdev);
+
+ ret = amdgpu_vm_handle_moved(adev, peer_vm, );
+ if (ret) {
+ pr_debug("Memory eviction: handle moved failed. Try
again\n");
+ goto validate_map_fail;
+ }
+ }
+
/* Update page directories */
ret = process_update_pds(process_info, _obj);
if (ret) {
@@ -2788,6 +2795,15 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
goto validate_map_fail;
}
+ /* Sync with fences on all the page tables. They implicitly depend on
any
+* move fences from amdgpu_vm_handle_moved above.
+*/
+ ret = process_sync_pds_resv(process_info, _obj);
+ if (ret) {
+ pr_debug("Memory eviction: Failed to sync to PD BO moving
fence. Try again\n");
+ goto validate_map_fail;
+ }
+
/* Wait for validate and PT updates to finish */
amdgpu_sync_wait(_obj, false);
--
2.34.1
[PATCH 6/6] drm/amdgpu: Do bo_va ref counting for KFD BOs
This is needed to correctly handle BOs imported into the GEM API, which
would otherwise get added twice to the same VM.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 28 +++
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index df08e84f01d7..8b5ba2e04a79 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -370,9 +370,17 @@ static int amdgpu_amdkfd_bo_validate_and_fence(struct
amdgpu_bo *bo,
return ret;
ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
- if (!ret)
- dma_resv_add_fence(bo->tbo.base.resv, fence,
- DMA_RESV_USAGE_BOOKKEEP);
+ if (ret)
+ goto unreserve_out;
+
+ ret = dma_resv_reserve_fences(bo->tbo.base.resv, 1);
+ if (ret)
+ goto unreserve_out;
+
+ dma_resv_add_fence(bo->tbo.base.resv, fence,
+ DMA_RESV_USAGE_BOOKKEEP);
+
+unreserve_out:
amdgpu_bo_unreserve(bo);
return ret;
@@ -785,6 +793,7 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
uint64_t va = mem->va;
struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
struct amdgpu_bo *bo[2] = {NULL, NULL};
+ struct amdgpu_bo_va *bo_va;
bool same_hive = false;
int i, ret;
@@ -871,7 +880,12 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
pr_debug("Unable to reserve BO during memory attach");
goto unwind;
}
- attachment[i]->bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+ bo_va = amdgpu_vm_bo_find(vm, bo[i]);
+ if (!bo_va)
+ bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+ else
+ ++bo_va->ref_count;
+ attachment[i]->bo_va = bo_va;
amdgpu_bo_unreserve(bo[i]);
if (unlikely(!attachment[i]->bo_va)) {
ret = -ENOMEM;
@@ -895,7 +909,8 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
continue;
if (attachment[i]->bo_va) {
amdgpu_bo_reserve(bo[i], true);
- amdgpu_vm_bo_del(adev, attachment[i]->bo_va);
+ if (--attachment[i]->bo_va->ref_count == 0)
+ amdgpu_vm_bo_del(adev, attachment[i]->bo_va);
amdgpu_bo_unreserve(bo[i]);
list_del([i]->list);
}
@@ -912,7 +927,8 @@ static void kfd_mem_detach(struct kfd_mem_attachment
*attachment)
pr_debug("\t remove VA 0x%llx in entry %p\n",
attachment->va, attachment);
- amdgpu_vm_bo_del(attachment->adev, attachment->bo_va);
+ if (--attachment->bo_va->ref_count == 0)
+ amdgpu_vm_bo_del(attachment->adev, attachment->bo_va);
drm_gem_object_put(>tbo.base);
list_del(>list);
kfree(attachment);
--
2.34.1
[PATCH 3/6] drm/amdkfd: Improve amdgpu_vm_handle_moved
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 18 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++-
4 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 275da612cd87..a80d2557edb2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1121,6 +1121,10 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
return r;
}
+ /* TODO: Is this loop still needed, or could this be handled by
+* amdgpu_vm_handle_moved, now that it can handle all BOs that are
+* reserved under p->ticket?
+*/
amdgpu_bo_list_for_each_entry(e, p->bo_list) {
/* ignore duplicates */
bo = ttm_to_amdgpu_bo(e->tv.bo);
@@ -1140,7 +1144,7 @@ static int amdgpu_cs_vm_handling(struct amdgpu_cs_parser
*p)
return r;
}
- r = amdgpu_vm_handle_moved(adev, vm);
+ r = amdgpu_vm_handle_moved(adev, vm, >ticket);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 271e30e34d93..23a213e4ab2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -404,7 +404,7 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment
*attach)
r = amdgpu_vm_clear_freed(adev, vm, NULL);
if (!r)
- r = amdgpu_vm_handle_moved(adev, vm);
+ r = amdgpu_vm_handle_moved(adev, vm, ticket);
if (r && r != -EBUSY)
DRM_ERROR("Failed to invalidate VM page tables (%d))\n",
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index dc379dc22c77..75dae2850e75 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1286,11 +1286,12 @@ int amdgpu_vm_clear_freed(struct amdgpu_device *adev,
* PTs have to be reserved!
*/
int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
- struct amdgpu_vm *vm)
+ struct amdgpu_vm *vm,
+ struct ww_acquire_ctx *ticket)
{
struct amdgpu_bo_va *bo_va;
struct dma_resv *resv;
- bool clear;
+ bool clear, unlock;
int r;
spin_lock(>status_lock);
@@ -1313,17 +1314,24 @@ int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
spin_unlock(>status_lock);
/* Try to reserve the BO to avoid clearing its ptes */
- if (!amdgpu_vm_debug && dma_resv_trylock(resv))
+ if (!amdgpu_vm_debug && dma_resv_trylock(resv)) {
clear = false;
+ unlock = true;
+ /* The caller is already holding the reservation lock */
+ } else if (ticket && dma_resv_locking_ctx(resv) == ticket) {
+ clear = false;
+ unlock = false;
/* Somebody else is using the BO right now */
- else
+ } else {
clear = true;
+ unlock = false;
+ }
r = amdgpu_vm_bo_update(adev, bo_va, clear);
if (r)
return r;
- if (!clear)
+ if (unlock)
dma_resv_unlock(resv);
spin_lock(>status_lock);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 094bb4807303..03a3314e5b43 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -400,7 +400,8 @@ int amdgpu_vm_clear_freed(struct amdgpu_device *adev,
struct amdgpu_vm *vm,
struct dma_fence **fence);
int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
- struct amdgpu_vm *vm);
+ struct amdgpu_vm *vm,
+ struct ww_acquire_ctx *ticket);
void amdgpu_vm_bo_base_init(struct amdgpu_vm_bo_base *base,
struct amdgpu_vm *vm, struct amdgpu_bo *bo);
int amdgpu_vm_update_range(struct amdgpu_device *adev, struct amdgpu_vm *vm,
--
2.34.1
[PATCH 4/6] drm/amdgpu: Attach eviction fence on alloc
Instead of attaching the eviction fence when a KFD BO is first mapped,
attach it when it is allocated or imported. This in preparation to allow
KFD BOs to be mapped using the render node API.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 63 ++-
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 5645103beed0..79213f476493 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -360,6 +360,24 @@ static int amdgpu_amdkfd_bo_validate(struct amdgpu_bo *bo,
uint32_t domain,
return ret;
}
+static int amdgpu_amdkfd_bo_validate_and_fence(struct amdgpu_bo *bo,
+ uint32_t domain,
+ struct dma_fence *fence)
+{
+ int ret = amdgpu_bo_reserve(bo, false);
+
+ if (ret)
+ return ret;
+
+ ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
+ if (!ret)
+ dma_resv_add_fence(bo->tbo.base.resv, fence,
+ DMA_RESV_USAGE_BOOKKEEP);
+ amdgpu_bo_unreserve(bo);
+
+ return ret;
+}
+
static int amdgpu_amdkfd_validate_vm_bo(void *_unused, struct amdgpu_bo *bo)
{
return amdgpu_amdkfd_bo_validate(bo, bo->allowed_domains, false);
@@ -1720,6 +1738,11 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
}
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
+ } else {
+ ret = amdgpu_amdkfd_bo_validate_and_fence(bo, domain,
+ >process_info->eviction_fence->base);
+ if (ret)
+ goto err_validate_bo;
}
if (offset)
@@ -1729,6 +1752,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
allocate_init_user_pages_failed:
err_pin_bo:
+err_validate_bo:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
drm_vma_node_revoke(>vma_node, drm_priv);
err_node_allow:
@@ -1804,10 +1828,6 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
if (unlikely(ret))
return ret;
- /* The eviction fence should be removed by the last unmap.
-* TODO: Log an error condition if the bo still has the eviction fence
-* attached
-*/
amdgpu_amdkfd_remove_eviction_fence(mem->bo,
process_info->eviction_fence);
pr_debug("Release VA 0x%llx - 0x%llx\n", mem->va,
@@ -1931,19 +1951,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
if (unlikely(ret))
goto out_unreserve;
- if (mem->mapped_to_gpu_memory == 0 &&
- !amdgpu_ttm_tt_get_usermm(bo->tbo.ttm)) {
- /* Validate BO only once. The eviction fence gets added to BO
-* the first time it is mapped. Validate will wait for all
-* background evictions to complete.
-*/
- ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
- if (ret) {
- pr_debug("Validate failed\n");
- goto out_unreserve;
- }
- }
-
list_for_each_entry(entry, >attachments, list) {
if (entry->bo_va->base.vm != avm || entry->is_mapped)
continue;
@@ -1970,10 +1977,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
mem->mapped_to_gpu_memory);
}
- if (!amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) && !bo->tbo.pin_count)
- dma_resv_add_fence(bo->tbo.base.resv,
- >process_info->eviction_fence->base,
- DMA_RESV_USAGE_BOOKKEEP);
ret = unreserve_bo_and_vms(, false, false);
goto out;
@@ -1990,7 +1993,6 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
struct amdgpu_device *adev, struct kgd_mem *mem, void *drm_priv)
{
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
- struct amdkfd_process_info *process_info = avm->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
struct kfd_mem_attachment *entry;
struct bo_vm_reservation_context ctx;
@@ -2031,15 +2033,6 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
mem->mapped_to_gpu_memory);
}
- /* If BO is unmapped from all VMs, unfence it. It can be evicted if
-* required.
-*/
- if (mem->mapped_to_gpu_memory == 0 &&
- !amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm) &&
- !mem->bo->tbo.pin_count)
- amdgpu_amdkfd_remove_eviction_fence(mem->bo,
- process_info->eviction_fence);
-
unreserve_out:
unreserve_bo_and_vms(, false,
[PATCH 2/6] drm/amdkfd: Implement DMA buf fd export from KFD
Exports a DMA buf fd of a given KFD buffer handle. This is intended for
being able to import KFD BOs into GEM contexts to leverage the
amdgpu_bo_va API for more flexible virtual address mappings. It will
also be used for the new upstreamable RDMA solution coming to UCX and
RCCL.
The corresponding user mode change (Thunk API and kfdtest) is here:
https://github.com/fxkamd/ROCT-Thunk-Interface/commits/fxkamd/dmabuf
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 45 +++
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 55 +++
include/uapi/linux/kfd_ioctl.h| 14 -
4 files changed, 104 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 333780491867..01ba3589b60a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -308,6 +308,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device
*adev,
uint64_t va, void *drm_priv,
struct kgd_mem **mem, uint64_t *size,
uint64_t *mmap_offset);
+int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
+ struct dma_buf **dmabuf);
int amdgpu_amdkfd_get_tile_config(struct amdgpu_device *adev,
struct tile_config *config);
void amdgpu_amdkfd_ras_poison_consumption_handler(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index e13c3493b786..5645103beed0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -710,6 +710,21 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
}
}
+static int kfd_mem_export_dmabuf(struct kgd_mem *mem)
+{
+ if (!mem->dmabuf) {
+ struct dma_buf *ret = amdgpu_gem_prime_export(
+ >bo->tbo.base,
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DRM_RDWR : 0);
+ if (IS_ERR(ret))
+ return PTR_ERR(ret);
+ mem->dmabuf = ret;
+ }
+
+ return 0;
+}
+
static int
kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct kgd_mem *mem,
struct amdgpu_bo **bo)
@@ -717,16 +732,9 @@ kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct
kgd_mem *mem,
struct drm_gem_object *gobj;
int ret;
- if (!mem->dmabuf) {
- mem->dmabuf = amdgpu_gem_prime_export(>bo->tbo.base,
- mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
- DRM_RDWR : 0);
- if (IS_ERR(mem->dmabuf)) {
- ret = PTR_ERR(mem->dmabuf);
- mem->dmabuf = NULL;
- return ret;
- }
- }
+ ret = kfd_mem_export_dmabuf(mem);
+ if (ret)
+ return ret;
gobj = amdgpu_gem_prime_import(adev_to_drm(adev), mem->dmabuf);
if (IS_ERR(gobj))
@@ -2267,6 +2275,23 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
return ret;
}
+int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
+ struct dma_buf **dma_buf)
+{
+ int ret;
+
+ mutex_lock(>lock);
+ ret = kfd_mem_export_dmabuf(mem);
+ if (ret)
+ goto out;
+
+ get_dma_buf(mem->dmabuf);
+ *dma_buf = mem->dmabuf;
+out:
+ mutex_unlock(>lock);
+ return ret;
+}
+
/* Evict a userptr BO by stopping the queues if necessary
*
* Runs in MMU notifier, may be in RECLAIM_FS context. This means it
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index f79b8e964140..bcf2263927d6 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1572,6 +1572,58 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
return r;
}
+static int kfd_ioctl_export_dmabuf(struct file *filep,
+ struct kfd_process *p, void *data)
+{
+ struct kfd_ioctl_export_dmabuf_args *args = data;
+ struct kfd_process_device *pdd;
+ struct dma_buf *dmabuf;
+ struct kfd_dev *dev;
+ void *mem;
+ int ret = 0;
+
+ dev = kfd_device_by_id(GET_GPU_ID(args->handle));
+ if (!dev)
+ return -EINVAL;
+
+ mutex_lock(>mutex);
+
+ pdd = kfd_get_process_device_data(dev, p);
+ if (!pdd) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
+ mem = kfd_process_device_translate_handle(pdd,
+
[PATCH 0/6] Enable KFD to use render node BO mappings
Rebased on latest amd-staging-drm-next. This is meant to be the final review of this series, assuming no more issues are found. This patch series enables KFD to interoperate more closely with DRM render nodes. ROCm user mode already uses DRM render nodes to create its GPU VM contexts and to CPU-map its GEM buffer objects. This patch series adds an API to let KFD export its BOs as DMABufs, so they can be imported into the DRM render nodes. This enables more flexible virtual memory mappings using DRM_IOCTL_AMDGPU_GEM_VA. Patches 1 and 2 deal with the exporting and importing of DMABufs. The remaining patches let KFD validate and update GPUVM mappings managed through render nodes. The user mode side of this patch series can be seen in libhsakmt and KFDTest where we improve integration with libdrm (initializing amdgpu_device instances) to enable DMABuf imports into the render nodes representing KFD GPU VM contexts. KFDTest is modified to test evictions and validations of BOs mapped through amdgpu_bo_va_op: https://github.com/fxkamd/ROCT-Thunk-Interface/commits/fxkamd/dmabuf As a consequence, applications using Mesa and ROCm in the same process on the same GPU will now share a single render node FD and GPUVM address space. The DMABuf export API will also be used later for upstream IPC and RDMA implementations. Felix Kuehling (6): drm/amdgpu: Generalize KFD dmabuf import drm/amdkfd: Implement DMA buf fd export from KFD drm/amdkfd: Improve amdgpu_vm_handle_moved drm/amdgpu: Attach eviction fence on alloc drm/amdgpu: update mappings not managed by KFD drm/amdgpu: Do bo_va ref counting for KFD BOs drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 + .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 196 -- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 55 + include/uapi/linux/kfd_ioctl.h| 14 +- 8 files changed, 219 insertions(+), 77 deletions(-) -- 2.34.1
[PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 38 ++-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 6f236ded5f12..e13c3493b786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2209,30 +2209,27 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
struct amdgpu_bo *bo;
int ret;
- if (dma_buf->ops != _dmabuf_ops)
- /* Can't handle non-graphics buffers */
- return -EINVAL;
-
- obj = dma_buf->priv;
- if (drm_to_adev(obj->dev) != adev)
- /* Can't handle buffers from other devices */
- return -EINVAL;
+ obj = amdgpu_gem_prime_import(adev_to_drm(adev), dma_buf);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
- AMDGPU_GEM_DOMAIN_GTT)))
+ AMDGPU_GEM_DOMAIN_GTT))) {
/* Only VRAM and GTT BOs are supported */
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_put_obj;
+ }
*mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
- if (!*mem)
- return -ENOMEM;
+ if (!*mem) {
+ ret = -ENOMEM;
+ goto err_put_obj;
+ }
ret = drm_vma_node_allow(>vma_node, drm_priv);
- if (ret) {
- kfree(*mem);
- return ret;
- }
+ if (ret)
+ goto err_free_mem;
if (size)
*size = amdgpu_bo_size(bo);
@@ -2249,7 +2246,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
| KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE
| KFD_IOC_ALLOC_MEM_FLAGS_EXECUTABLE;
- drm_gem_object_get(>tbo.base);
+ get_dma_buf(dma_buf);
+ (*mem)->dmabuf = dma_buf;
(*mem)->bo = bo;
(*mem)->va = va;
(*mem)->domain = (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM) ?
@@ -2261,6 +2259,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct
amdgpu_device *adev,
(*mem)->is_imported = true;
return 0;
+
+err_free_mem:
+ kfree(*mem);
+err_put_obj:
+ drm_gem_object_put(obj);
+ return ret;
}
/* Evict a userptr BO by stopping the queues if necessary
--
2.34.1
Re: [PATCH 0/4] Track exported dma-buffers with memcg
On Wed, Jan 11, 2023 at 2:56 PM Daniel Vetter wrote: > > On Mon, Jan 09, 2023 at 04:18:12PM -0800, Shakeel Butt wrote: > > Hi T.J., > > > > On Mon, Jan 9, 2023 at 1:38 PM T.J. Mercier wrote: > > > > > > Based on discussions at LPC, this series adds a memory.stat counter for > > > exported dmabufs. This counter allows us to continue tracking > > > system-wide total exported buffer sizes which there is no longer any > > > way to get without DMABUF_SYSFS_STATS, and adds a new capability to > > > track per-cgroup exported buffer sizes. The total (root counter) is > > > helpful for accounting in-kernel dmabuf use (by comparing with the sum > > > of child nodes or with the sum of sizes of mapped buffers or FD > > > references in procfs) in addition to helping identify driver memory > > > leaks when in-kernel use continually increases over time. With > > > per-application cgroups, the per-cgroup counter allows us to quickly > > > see how much dma-buf memory an application has caused to be allocated. > > > This avoids the need to read through all of procfs which can be a > > > lengthy process, and causes the charge to "stick" to the allocating > > > process/cgroup as long as the buffer is alive, regardless of how the > > > buffer is shared (unless the charge is transferred). > > > > > > The first patch adds the counter to memcg. The next two patches allow > > > the charge for a buffer to be transferred across cgroups which is > > > necessary because of the way most dmabufs are allocated from a central > > > process on Android. The fourth patch adds a SELinux hook to binder in > > > order to control who is allowed to transfer buffer charges. > > > > > > [1] > > > https://lore.kernel.org/all/20220617085702.4298-1-christian.koe...@amd.com/ > > > > > > > I am a bit confused by the term "charge" used in this patch series. > > From the patches, it seems like only a memcg stat is added and nothing > > is charged to the memcg. > > > > This leads me to the question: Why add this stat in memcg if the > > underlying memory is not charged to the memcg and if we don't really > > want to limit the usage? > > > > I see two ways forward: > > > > 1. Instead of memcg, use bpf-rstat [1] infra to implement the > > per-cgroup stat for dmabuf. (You may need an additional hook for the > > stat transfer). > > > > 2. Charge the actual memory to the memcg. Since the size of dmabuf is > > immutable across its lifetime, you will not need to do accounting at > > page level and instead use something similar to the network memory > > accounting interface/mechanism (or even more simple). However you > > would need to handle the reclaim, OOM and charge context and failure > > cases. However if you are not looking to limit the usage of dmabuf > > then this option is an overkill. > > I think eventually, at least for other "account gpu stuff in cgroups" use > case we do want to actually charge the memory. > Yes, I've been looking at this today. > The problem is a bit that with gpu allocations reclaim is essentially "we > pass the error to userspace and they get to sort the mess out". There are > some exceptions (some gpu drivers to have shrinkers) would we need to make > sure these shrinkers are tied into the cgroup stuff before we could enable > charging for them? > I'm also not sure that we can depend on the dmabuf being backed at export time 100% of the time? (They are for dmabuf heaps.) If not, that'd make calling the existing memcg folio based functions a bit difficult. > Also note that at least from the gpu driver side this is all a huge > endeavour, so if we can split up the steps as much as possible (and get > something interim useable that doesn't break stuff ofc), that is > practically need to make headway here. TJ has been trying out various > approaches for quite some time now already :-/ > -Daniel > > > Please let me know if I misunderstood something. > > > > [1] https://lore.kernel.org/all/20220824233117.1312810-1-hao...@google.com/ > > > > thanks, > > Shakeel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
[PATCH v4 5/6] drm/i915/pxp: Trigger the global teardown for before suspending
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a suspended state and GuC had been reset.
Internal specifications actually required the driver to ensure
that all active sessions be properly cleaned up in such cases where
the system is suspended and the GuC potentially unable to respond.
This patch adds the global teardown code in i915's suspend_prepare
code path.
Signed-off-by: Alan Previn
Reviewed-by: Juston Li
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 +---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 9 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++
5 files changed, 64 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index cfc9af8b3d21..f3d9e7989eb7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -270,6 +270,55 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
}
+static int __pxp_global_teardown_locked(struct intel_pxp *pxp, bool
terminate_for_cleanup)
+{
+ if (terminate_for_cleanup) {
+ if (!pxp->arb_is_valid)
+ return 0;
+ /*
+* To ensure synchronous and coherent session teardown
completion
+* in response to suspend or shutdown triggers, don't use a
worker.
+*/
+ intel_pxp_mark_termination_in_progress(pxp);
+ intel_pxp_terminate(pxp, false);
+ } else {
+ if (pxp->arb_is_valid)
+ return 0;
+ /*
+* If we are not in final termination, and the arb-session is
currently
+* inactive, we are doing a reset and restart due to some
runtime event.
+* Use the worker that was designed for this.
+*/
+ pxp_queue_termination(pxp);
+ }
+
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(250)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+void intel_pxp_end(struct intel_pxp *pxp)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ intel_wakeref_t wakeref;
+
+ if (!intel_pxp_is_enabled(pxp))
+ return;
+
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ mutex_lock(>arb_mutex);
+
+ if (__pxp_global_teardown_locked(pxp, true))
+ drm_dbg(>drm, "PXP end timed out\n");
+
+ mutex_unlock(>arb_mutex);
+
+ intel_pxp_fini_hw(pxp);
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+}
+
/*
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
@@ -286,16 +335,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
mutex_lock(>arb_mutex);
- if (pxp->arb_is_valid)
- goto unlock;
-
- pxp_queue_termination(pxp);
-
- if (!wait_for_completion_timeout(>termination,
- msecs_to_jiffies(250))) {
- ret = -ETIMEDOUT;
+ ret = __pxp_global_teardown_locked(pxp, false);
+ if (ret)
goto unlock;
- }
/* make sure the compiler doesn't optimize the double access */
barrier();
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 9658d3005222..3ded0890cd27 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_start(struct intel_pxp *pxp);
+void intel_pxp_end(struct intel_pxp *pxp);
int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 892d39cc61c1..e427464aa131 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -16,7 +16,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
- pxp->arb_is_valid = false;
+ intel_pxp_end(pxp);
intel_pxp_invalidate(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 74ed7e16e481..d8278c4002e3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -115,11 +115,14 @@ static int
[PATCH v4 6/6] drm/i915/pxp: Pxp hw init should be in resume_complete
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no additional GEM IOCTLs will come after that could
restart the session).
However, if other devices or drivers fail their suspend_prepare, the
system will not go into suspend and i915 will be expected to resume
operation. In this case, we need to re-initialize the PXP hardware
and this really should be done within the pm_resume_complete callback
which is the correct opposing function in the resume sequence to
match pm_suspend_prepare of the suspend sequence.
Because this callback is the last thing at the end of resuming
we expect little to no impact to the rest of the i915 resume sequence
with this change.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 1 +
drivers/gpu/drm/i915/i915_driver.c | 20 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +++---
4 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..fd1a23621222 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -77,6 +77,7 @@ void intel_gt_pm_fini(struct intel_gt *gt);
void intel_gt_suspend_prepare(struct intel_gt *gt);
void intel_gt_suspend_late(struct intel_gt *gt);
+
int intel_gt_resume(struct intel_gt *gt);
void intel_gt_runtime_suspend(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c1e427ba57ae..c3e7c40daaeb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1170,6 +1170,13 @@ static bool suspend_to_idle(struct drm_i915_private
*dev_priv)
return false;
}
+static void i915_drm_complete(struct drm_device *dev)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+
+ intel_pxp_resume_complete(i915->pxp);
+}
+
static int i915_drm_prepare(struct drm_device *dev)
{
struct drm_i915_private *i915 = to_i915(dev);
@@ -1370,8 +1377,6 @@ static int i915_drm_resume(struct drm_device *dev)
i915_gem_resume(dev_priv);
- intel_pxp_resume(dev_priv->pxp);
-
intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
intel_hpd_init(dev_priv);
@@ -1484,6 +1489,16 @@ int i915_driver_resume_switcheroo(struct
drm_i915_private *i915)
return i915_drm_resume(>drm);
}
+static void i915_pm_complete(struct device *kdev)
+{
+ struct drm_i915_private *i915 = kdev_to_i915(kdev);
+
+ if (!i915)
+ dev_err(kdev, "DRM not initialized, aborting suspend.\n");
+
+ i915_drm_complete(>drm);
+}
+
static int i915_pm_prepare(struct device *kdev)
{
struct drm_i915_private *i915 = kdev_to_i915(kdev);
@@ -1779,6 +1794,7 @@ const struct dev_pm_ops i915_pm_ops = {
* PMSG_RESUME]
*/
.prepare = i915_pm_prepare,
+ .complete = i915_pm_complete,
.suspend = i915_pm_suspend,
.suspend_late = i915_pm_suspend_late,
.resume_early = i915_pm_resume_early,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index e427464aa131..4f836b317424 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -34,7 +34,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
}
}
-void intel_pxp_resume(struct intel_pxp *pxp)
+void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
if (!intel_pxp_is_enabled(pxp))
return;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
index 586be769104f..06b46f535b42 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
@@ -11,7 +11,7 @@ struct intel_pxp;
#ifdef CONFIG_DRM_I915_PXP
void intel_pxp_suspend_prepare(struct intel_pxp *pxp);
void intel_pxp_suspend(struct intel_pxp *pxp);
-void intel_pxp_resume(struct intel_pxp *pxp);
+void intel_pxp_resume_complete(struct intel_pxp *pxp);
void intel_pxp_runtime_suspend(struct intel_pxp *pxp);
#else
static inline void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
@@ -22,7 +22,7 @@ static inline void intel_pxp_suspend(struct intel_pxp *pxp)
{
}
-static inline void intel_pxp_resume(struct intel_pxp *pxp)
+static inline void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
}
@@ -32,6 +32,6 @@ static inline void intel_pxp_runtime_suspend(struct intel_pxp
*pxp)
#endif
static inline void intel_pxp_runtime_resume(struct intel_pxp *pxp)
{
- intel_pxp_resume(pxp);
+ intel_pxp_resume_complete(pxp);
}
#endif /* __INTEL_PXP_PM_H__ */
--
2.39.0
[PATCH v4 4/6] drm/i915/pxp: Invalidate all PXP fw sessions during teardown
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the entity that needs
ensure the sessions' state across both iGT and security firmware
are at a known clean point when performing a full global teardown.
Architecturally speaking, i915 should inspect all active sessions
and submit the invalidate-stream-key PXP command to the security
firmware for each of them. However, for the upstream i915 driver
we only support the arbitration session that can be created
so that will be the only session we will cleanup.
Signed-off-by: Alan Previn
Reviewed-by: Juston Li
---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
.../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15
.../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 35 +++
5 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 04440fada711..9658d3005222 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -24,6 +24,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
+void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_start(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
index 739f9072fa5f..26f7d9f01bf3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
@@ -12,6 +12,9 @@
/* PXP-Opcode for Init Session */
#define PXP42_CMDID_INIT_SESSION 0x1e
+/* PXP-Opcode for Invalidate Stream Key */
+#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
+
/* PXP-Input-Packet: Init Session (Arb-Session) */
struct pxp42_create_arb_in {
struct pxp_cmd_header header;
@@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Invalidate Stream Key */
+struct pxp42_inv_stream_key_in {
+ struct pxp_cmd_header header;
+ u32 rsvd[3];
+} __packed;
+
+/* PXP-Output-Packet: Invalidate Stream Key */
+struct pxp42_inv_stream_key_out {
+ struct pxp_cmd_header header;
+ u32 rsvd;
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index c2f23394f9b8..69e34ec49e78 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -27,6 +27,9 @@ struct pxp_cmd_header {
union {
u32 status; /* out */
u32 stream_id; /* in */
+#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
+#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
+#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
};
/* Length of the message (excluding the header) */
u32 buffer_len;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index ae413580b81a..74ed7e16e481 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -110,6 +110,8 @@ static int pxp_terminate_arb_session_and_global(struct
intel_pxp *pxp)
intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
+ intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
+
return ret;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index bef6d7f8ac55..9e247f38f3bd 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -311,3 +311,38 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
return ret;
}
+
+void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 session_id)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ struct pxp42_inv_stream_key_in msg_in = {0};
+ struct pxp42_inv_stream_key_out msg_out = {0};
+ int ret, trials = 0;
+
+try_again:
+ memset(_in, 0, sizeof(msg_in));
+ memset(_out, 0, sizeof(msg_out));
+ msg_in.header.api_version = PXP_APIVER(4, 2);
+ msg_in.header.command_id = PXP42_CMDID_INVALIDATE_STREAM_KEY;
+ msg_in.header.buffer_len = sizeof(msg_in) - sizeof(msg_in.header);
+
+ msg_in.header.stream_id = FIELD_PREP(PXP_CMDHDR_EXTDATA_SESSION_VALID,
1);
+ msg_in.header.stream_id |= FIELD_PREP(PXP_CMDHDR_EXTDATA_APP_TYPE, 0);
+
[PATCH v4 3/6] mei: clean pending read with vtag on bus
From: Alexander Usyskin
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/misc/mei/client.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 9ddb854b8155..5c19097266fe 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1343,7 +1343,9 @@ static void mei_cl_reset_read_by_vtag(const struct mei_cl
*cl, u8 vtag)
struct mei_cl_vtag *vtag_l;
list_for_each_entry(vtag_l, >vtag_map, list) {
- if (vtag_l->vtag == vtag) {
+ /* The client on bus has one fixed vtag map */
+ if ((cl->cldev && mei_cldev_enabled(cl->cldev)) ||
+ vtag_l->vtag == vtag) {
vtag_l->pending_read = false;
break;
}
--
2.39.0
[PATCH v4 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
From: Alexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier
to ensure proper ordering of power flows.
V2: condition on absence of heci_pxp to filter out DG
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d50354bfb993..bef6d7f8ac55 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct device
*i915_kdev,
intel_wakeref_t wakeref;
int ret = 0;
+ if (!HAS_HECI_PXP(i915) &&
+ drm_WARN_ON(>drm, !device_link_add(i915_kdev, tee_kdev,
DL_FLAG_STATELESS)))
+ return -ENOMEM;
+
mutex_lock(>tee_mutex);
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
@@ -169,6 +173,9 @@ static void i915_pxp_tee_component_unbind(struct device
*i915_kdev,
mutex_lock(>tee_mutex);
pxp->pxp_component = NULL;
mutex_unlock(>tee_mutex);
+
+ if (!HAS_HECI_PXP(i915))
+ device_link_remove(i915_kdev, tee_kdev);
}
static const struct component_ops i915_pxp_tee_component_ops = {
--
2.39.0
[PATCH v4 1/6] mei: mei-me: resume device in prepare
From: Alexander Usyskin
Asynchronous runtime resume is not possible while the system
is suspending.
The power management subsystem resumes the device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in their prepare callbacks.
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/misc/mei/pci-me.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 704cd0caa172..4280759739f0 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -340,6 +340,12 @@ static void mei_me_remove(struct pci_dev *pdev)
}
#ifdef CONFIG_PM_SLEEP
+static int mei_me_pci_prepare(struct device *device)
+{
+ pm_runtime_resume(device);
+ return 0;
+}
+
static int mei_me_pci_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
@@ -396,7 +402,17 @@ static int mei_me_pci_resume(struct device *device)
return 0;
}
-#endif /* CONFIG_PM_SLEEP */
+
+static void mei_me_pci_complete(struct device *device)
+{
+ pm_runtime_suspend(device);
+}
+#else /* CONFIG_PM_SLEEP */
+
+#define mei_me_pci_prepare NULL
+#define mei_me_pci_suspend NULL
+
+#endif /* !CONFIG_PM_SLEEP */
#ifdef CONFIG_PM
static int mei_me_pm_runtime_idle(struct device *device)
@@ -499,6 +515,8 @@ static inline void mei_me_unset_pm_domain(struct mei_device
*dev)
}
static const struct dev_pm_ops mei_me_pm_ops = {
+ .prepare = mei_me_pci_prepare,
+ .complete = mei_me_pci_complete,
SET_SYSTEM_SLEEP_PM_OPS(mei_me_pci_suspend,
mei_me_pci_resume)
SET_RUNTIME_PM_OPS(
--
2.39.0
[PATCH v4 0/6] drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
A customer issue was recently discovered and in the process a gap in i915's PXP interaction with HW+FW architecure was also realized. This series adds those missing pieces. This fix includes changes where i915 calls into the mei component interface in order to submit requests to the security firmware during the i915's suspend_prepare flow. This change did expose a blocking issue in the mei component side that was discovered while testing in rev1. The issue being the mei-pxp component driver not being able to runtime-resume while being within the suspend_prepare callstack. Thus, we have now included the mei patches (from Alexander) that fixes that issue by adding a device-link based on the interface type to ensure mei side runtime resume during the i915's suspend_prepare call. That said, as per request from Alexander, we seek Greg's and Tomas' review for the mei patches (Patch 1, 2 and 3). Patch 2, although is a change in the i915 code, is the mei component device link change. The individual patches explain more details. Patch 7 can be ignored as it won't be merged and is only meant to ensure the CI run's the PXP subtests with PXP support enabled in KConfig. Changes from prior revs: v1: - Dont need to teardown non-arbitration sessions (Juston). - Fix builds when PXP is enabled in config (Alan/CI-build). - Fix the broken pm-suspend-resume symmetry when we do this pxp-session-teardown during i915s pm_suspend_prepare by ensuring the init is done during i915s pm_resume_complete. v2: - Rebase on latest drm-tip after PXP subsytem was promoted to global. - Remove "INTEL_PXP_MAX_HWDRM_SESSIONS" unneeded (Juston Li). - Added mei patches that are dependencies for this series to successfully pass testing when PXP config is enabled. v3: - Added fix for mei patch when CONFIG_PM_SLEEP is off (reported by kernel test robot ). Alan Previn (3): drm/i915/pxp: Invalidate all PXP fw sessions during teardown drm/i915/pxp: Trigger the global teardown for before suspending drm/i915/pxp: Pxp hw init should be in resume_complete Alexander Usyskin (3): mei: mei-me: resume device in prepare drm/i915/pxp: add device link between i915 and mei_pxp mei: clean pending read with vtag on bus drivers/gpu/drm/i915/gt/intel_gt_pm.h | 1 + drivers/gpu/drm/i915/i915_driver.c| 20 ++- drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 --- drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 + .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15 + .../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 + drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +- drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 +++- drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 42 + drivers/misc/mei/client.c | 4 +- drivers/misc/mei/pci-me.c | 20 ++- 13 files changed, 172 insertions(+), 21 deletions(-) base-commit: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 -- 2.39.0
[PATCH v3 2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()
Currently there is no protection against a user trying to set
an unsupported mode on DSI. Implement a check based on the opp
table whether the byte clock for the mode can be supported by
validating whether an opp table entry exists.
For devices which have not added opp table support yet, skip
this check otherwise it will break bootup on those devices.
changes in v3:
- make the comment shorter
- handle all errors except ENODEV
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15
Reported-by: Rob Clark
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..b20fddb534a7 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -450,6 +450,25 @@ static enum drm_mode_status
dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge,
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct mipi_dsi_host *host = msm_dsi->host;
+ struct platform_device *pdev = msm_dsi->pdev;
+ struct dev_pm_opp *opp;
+ unsigned long byte_clk_rate;
+
+ byte_clk_rate = dsi_byte_clk_get_rate(host, IS_BONDED_DSI(), mode);
+
+ /*
+* fail all errors except -ENODEV as that could mean that opp
+* table is not yet implemented
+*/
+ opp = dev_pm_opp_find_freq_ceil(>dev, _clk_rate);
+ if (IS_ERR(opp)) {
+ if (PTR_ERR(opp) == -ERANGE)
+ return MODE_CLOCK_RANGE;
+ else if (PTR_ERR(opp) != -ENODEV)
+ return MODE_ERROR;
+ } else {
+ dev_pm_opp_put(opp);
+ }
return msm_dsi_host_check_dsc(host, mode);
}
--
2.39.0
[PATCH v3 1/2] drm/msm/dsi: add a helper method to compute the dsi byte clk
Re-arrange the dsi_calc_pclk method to two helpers, one to
compute the DSI byte clk and the other to compute the pclk.
This makes the separation of the two clean and also allows
clients to compute and use the dsi byte clk separately.
changes in v2:
- move the assignments to definition lines
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 21 ++---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 2a96b4fe7839..1a551cc0e889 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -118,6 +118,8 @@ int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host *host, bool
is_bonded_dsi,
+ const struct drm_display_mode *mode);
int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c3cd96de7f7d..c145fd359ed5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -570,9 +570,8 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
-static unsigned long dsi_get_pclk_rate(struct msm_dsi_host *msm_host, bool
is_bonded_dsi)
+static unsigned long dsi_get_pclk_rate(const struct drm_display_mode *mode,
bool is_bonded_dsi)
{
- struct drm_display_mode *mode = msm_host->mode;
unsigned long pclk_rate;
pclk_rate = mode->clock * 1000;
@@ -589,11 +588,13 @@ static unsigned long dsi_get_pclk_rate(struct
msm_dsi_host *msm_host, bool is_bo
return pclk_rate;
}
-static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host *host, bool
is_bonded_dsi,
+ const struct drm_display_mode *mode)
{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
- unsigned long pclk_rate = dsi_get_pclk_rate(msm_host, is_bonded_dsi);
+ unsigned long pclk_rate = dsi_get_pclk_rate(mode, is_bonded_dsi);
u64 pclk_bpp = (u64)pclk_rate * bpp;
if (lanes == 0) {
@@ -607,8 +608,14 @@ static void dsi_calc_pclk(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
else
do_div(pclk_bpp, (8 * lanes));
- msm_host->pixel_clk_rate = pclk_rate;
- msm_host->byte_clk_rate = pclk_bpp;
+ return pclk_bpp;
+}
+
+static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+{
+ msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
is_bonded_dsi);
+ msm_host->byte_clk_rate = dsi_byte_clk_get_rate(_host->base,
is_bonded_dsi,
+ msm_host->mode);
DBG("pclk=%lu, bclk=%lu", msm_host->pixel_clk_rate,
msm_host->byte_clk_rate);
@@ -636,7 +643,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
dsi_calc_pclk(msm_host, is_bonded_dsi);
- pclk_bpp = (u64)dsi_get_pclk_rate(msm_host, is_bonded_dsi) * bpp;
+ pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, is_bonded_dsi) * bpp;
do_div(pclk_bpp, 8);
msm_host->src_clk_rate = pclk_bpp;
--
2.39.0
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917 --- Comment #8 from kolAflash (kolafl...@kolahilft.de) --- (In reply to Alex Deucher from comment #7) > do you still have the problem with: > CONFIG_DRM_FBDEV_EMULATION=n > in your .config? The problem unfortunately still exists with CONFIG_DRM_FBDEV_EMULATION=n (and I get a black screen on the virtual console) > Does reverting a6250bdb6c4677ee77d699b338e077b900f94c0c fix it? No. That also doesn't help. I'm sorry. Anything else I can try? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression
On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote: > Hi everyone, > > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-* > > Regression is due to a chicken-egg problem loading modules; on > `modprobe i915`, drm is loaded 1st, and drm.debug is set. When > drm_debug_enabled() tested __drm_debug at runtime, that just worked. > > But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a > post-load enablement of drm_dbg/dyndbg callsites (static-keys), via > dyndbg's callback on __drm_debug. Since all drm-drivers need drm.ko, > it is loaded 1st, then drm.debug=X is applied, then drivers load, but > too late for drm_dbgs to be enabled. > > STATUS > > For all-loadable drm,i915,amdgpu configs, it almost works, but > propagating drm.debug to dependent modules doesnt actually apply, > though the motions are there. This is not the problem I want to chase > here. > > The more basic trouble is: > > For builtin drm + helpers, things are broken pretty early; at the > beginning of dynamic_debug_init(). As the ddebug_sanity() commit-msg > describes in some detail, the records added by _USE fail to reference > the struct ddebug_class_map created and exported by _DEFINE, but get > separate addresses to "other" data that segv's when used as the > expected pointer. FWIW, the pointer val starts with "revi". So I honestly have no idea here, linker stuff is way beyond where I have clue. So what's the way forward here? The DEFINE/USE split does like the right thing to do at least from the "how it's used in drivers" pov. But if we're just running circles not quite getting there I dunno :-/ -Daniel > > OVERVIEW > > DECLARE_DYNDBG_CLASSMAP is broken: it is one-size-fits-all-poorly. > It muddles the distinction between a (single) definition, and multiple > references. Something exported should suffice. > > The core of this patchset splits it into: > > DYNDBG_CLASSMAP_DEFINEused once per subsystem to define each classmap > DYNDBG_CLASSMAP_USE declare dependence on a DEFINEd classmap > > This makes the weird coordinated-changes-by-identical-classmaps > "feature" unnecessary; the DEFINE can export the var, and USE refers > to the exported var. > > So this patchset adds another section: __dyndbg_class_refs. > > It is like __dyndbg_classes; it is scanned under ddebug_add_module(), > and attached to each module's ddebug_table. Once attached, it can be > used like classes to validate and apply class FOO >control queries. > > It also maps the class user -> definer explicitly, so that when the > module is loaded, the section scan can find the kernel-param that is > wired to dyndbg's kparam-callback, and apply its state-var, forex: > __drm_debug to the just loaded helper/driver module. > > Theres plenty to address Im sure. > > Jim Cromie (17): > test-dyndbg: fixup CLASSMAP usage error > test-dyndbg: show that DEBUG enables prdbgs at compiletime > dyndbg: fix readback value on LEVEL_NAMES interfaces > dyndbg: replace classmap list with a vector > dyndbg: make ddebug_apply_class_bitmap more selective > dyndbg: dynamic_debug_init - use pointer inequality, not strcmp > dyndbg: drop NUM_TYPE_ARRAY > dyndbg: reduce verbose/debug clutter > dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with > DYNDBG_CLASSMAP(_DEFINE|_USE) > dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE) > dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args > dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements > drm_print: fix stale macro-name in comment > dyndbg: unwrap __ddebug_add_module inner function NOTYET > dyndbg: ddebug_sanity() > dyndbg: mess-w-dep-class > dyndbg: miss-on HACK > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 14 +- > drivers/gpu/drm/display/drm_dp_helper.c | 14 +- > drivers/gpu/drm/drm_crtc_helper.c | 14 +- > drivers/gpu/drm/drm_print.c | 22 +-- > drivers/gpu/drm/i915/i915_params.c | 14 +- > drivers/gpu/drm/nouveau/nouveau_drm.c | 14 +- > include/asm-generic/vmlinux.lds.h | 3 + > include/drm/drm_print.h | 6 +- > include/linux/dynamic_debug.h | 57 -- > include/linux/map.h | 54 ++ > kernel/module/main.c| 2 + > lib/dynamic_debug.c | 240 +++- > lib/test_dynamic_debug.c| 47 ++--- > 13 files changed, 344 insertions(+), 157 deletions(-) > create mode 100644 include/linux/map.h > > -- > 2.38.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()
On 1/11/2023 2:56 PM, Dmitry Baryshkov wrote:
On 12/01/2023 00:52, Abhinav Kumar wrote:
Currently there is no protection against a user trying to set
an unsupported mode on DSI. Implement a check based on the opp
table whether the byte clock for the mode can be supported by
validating whether an opp table entry exists.
For devices which have not added opp table support yet, skip
this check otherwise it will break bootup on those devices.
changes in v2:
- drop dev_pm_opp_get_opp_table() usage
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15
Reported-by: Rob Clark
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..c4c24dabfd6f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -450,6 +450,31 @@ static enum drm_mode_status
dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge,
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct mipi_dsi_host *host = msm_dsi->host;
+ struct platform_device *pdev = msm_dsi->pdev;
+ struct dev_pm_opp *opp;
+ unsigned long byte_clk_rate;
+
+ byte_clk_rate = dsi_byte_clk_get_rate(host, IS_BONDED_DSI(), mode);
+
+ /*
+ * If dev_pm_opp_find_freq_ceil() returns -EINVAL, its a bad
+ * pointer being passed, so treat as an error and return MODE_ERROR
+ *
+ * If dev_pm_opp_find_freq_ceil() returns -ERANGE, no clock
+ * was found matching the byte_clk, so return MODE_CLOCK_RANGE
+ *
+ * If dev_pm_opp_find_freq_ceil() returns -ENODEV, don't treat
+ * it as an error as it could mean opp table is not implemented
+ */
I'd say, too lengthy and verbose.
hmmm just wanted to document the basis of the policy, I can make it
shorter.
+ opp = dev_pm_opp_find_freq_ceil(>dev, _clk_rate);
+ if (IS_ERR(opp)) {
+ if (PTR_ERR(opp) == -EINVAL)
+ return MODE_ERROR;
+ else if (PTR_ERR(opp) == -ERANGE)
+ return MODE_CLOCK_RANGE;
I think the logic should be quite opposite. Ignore -ENODEV, handle
-ERANGE and return MODE_ERROR for all other errors. In your code you are
ignoring not only -ENODEV, but all other possible errors which can be
added in future.
Atm, those were the only ones handled but you are right.
this is better.
if (IS_ERR(opp)) {
if (PTR_ERR(opp) == -ERANGE)
return MODE_CLOCK_RANGE;
else
return MODE_ERROR;
} else {
dev_pm_opp_put(opp);
}
+ } else {
+ dev_pm_opp_put(opp);
+ }
return msm_dsi_host_check_dsc(host, mode);
}
Re: [RFC PATCH 13/17] drm_print: fix stale macro-name in comment
On Mon, Dec 05, 2022 at 05:34:20PM -0700, Jim Cromie wrote:
> Cited commit uses stale macro name, fix this, and explain better.
>
> When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
> onto BITs in drm.debug. This still uses enum drm_debug_category, but
> it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
> This requires that the macro args: DRM_UT_* list must be kept in sync
> and in order.
>
> Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3
> drivers.")
> Signed-off-by: Jim Cromie
Should I land this already?
-Daniel
> ---
> . emphasize ABI non-change despite enum val change - Jani Nikula
> . reorder to back of patchset to follow API name changes.
> ---
> include/drm/drm_print.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 6a27e8f26770..7695ba31b3a4 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const
> char *prefix)
> *
> */
> enum drm_debug_category {
> - /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
> + /*
> + * Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
> + * the enum-values define BIT()s in drm.debug, so are ABI.
> + */
> /**
>* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost
wrote:
> On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> > On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> > tvrtko.ursu...@linux.intel.com> wrote:
> >
> > >
> > > On 10/01/2023 14:08, Jason Ekstrand wrote:
> > > > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > > > tvrtko.ursu...@linux.intel.com>>
> > >
> > > > wrote:
> > > >
> > > >
> > > >
> > > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > > >
> > > > [snip]
> > > >
> > > > > >>> AFAICT it proposes to have 1:1 between *userspace*
> > > created
> > > > > contexts (per
> > > > > >>> context _and_ engine) and drm_sched. I am not sure
> > > avoiding
> > > > > invasive changes
> > > > > >>> to the shared code is in the spirit of the overall
> idea
> > > > and instead
> > > > > >>> opportunity should be used to look at way to
> > > > refactor/improve
> > > > > drm_sched.
> > > > >
> > > > >
> > > > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > > > all or
> > > > > really needs to drive a re-factor. (More on that later.)
> > > > There's only
> > > > > one real issue which is that it fires off potentially a lot of
> > > > kthreads.
> > > > > Even that's not that bad given that kthreads are pretty light
> and
> > > > you're
> > > > > not likely to have more kthreads than userspace threads which
> are
> > > > much
> > > > > heavier. Not ideal, but not the end of the world either.
> > > > Definitely
> > > > > something we can/should optimize but if we went through with
> Xe
> > > > without
> > > > > this patch, it would probably be mostly ok.
> > > > >
> > > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > > >>
> > > > > >> I'm not really prepared to make large changes to DRM
> > > > scheduler
> > > > > at the
> > > > > >> moment for Xe as they are not really required nor does
> > > Boris
> > > > > seem they
> > > > > >> will be required for his work either. I am interested
> to
> > > see
> > > > > what Boris
> > > > > >> comes up with.
> > > > > >>
> > > > > >>> Even on the low level, the idea to replace drm_sched
> > > threads
> > > > > with workers
> > > > > >>> has a few problems.
> > > > > >>>
> > > > > >>> To start with, the pattern of:
> > > > > >>>
> > > > > >>>while (not_stopped) {
> > > > > >>> keep picking jobs
> > > > > >>>}
> > > > > >>>
> > > > > >>> Feels fundamentally in disagreement with workers
> (while
> > > > > obviously fits
> > > > > >>> perfectly with the current kthread design).
> > > > > >>
> > > > > >> The while loop breaks and worker exists if no jobs are
> > > ready.
> > > > >
> > > > >
> > > > > I'm not very familiar with workqueues. What are you saying
> would
> > > fit
> > > > > better? One scheduling job per work item rather than one big
> work
> > > > item
> > > > > which handles all available jobs?
> > > >
> > > > Yes and no, it indeed IMO does not fit to have a work item which
> is
> > > > potentially unbound in runtime. But it is a bit moot conceptual
> > > > mismatch
> > > > because it is a worst case / theoretical, and I think due more
> > > > fundamental concerns.
> > > >
> > > > If we have to go back to the low level side of things, I've
> picked
> > > this
> > > > random spot to consolidate what I have already mentioned and
> perhaps
> > > > expand.
> > > >
> > > > To start with, let me pull out some thoughts from workqueue.rst:
> > > >
> > > > """
> > > > Generally, work items are not expected to hog a CPU and consume
> many
> > > > cycles. That means maintaining just enough concurrency to prevent
> > > work
> > > > processing from stalling should be optimal.
> > > > """
> > > >
> > > > For unbound queues:
> > > > """
> > > > The responsibility of regulating concurrency level is on the
> users.
> > > > """
> > > >
> > > > Given the unbound queues will be spawned on demand to service all
> > > > queued
> > > > work items (more interesting when mixing up with the
> > > > system_unbound_wq),
> > > > in the proposed design the number of instantiated worker threads
> does
> > > > not correspond to the number of user threads (as you have
> elsewhere
> > > > stated), but pessimistically to the number of active user
> contexts.
> > > >
> > > >
> > > > Those are pretty much the same in practice. Rather, user threads is
> > > > typically an upper bound on the number of contexts. Yes, a single
> user
> > > > thread could have a bunch of contexts but basically nothing
Re: [PATCH v2 2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()
On 12/01/2023 00:52, Abhinav Kumar wrote:
Currently there is no protection against a user trying to set
an unsupported mode on DSI. Implement a check based on the opp
table whether the byte clock for the mode can be supported by
validating whether an opp table entry exists.
For devices which have not added opp table support yet, skip
this check otherwise it will break bootup on those devices.
changes in v2:
- drop dev_pm_opp_get_opp_table() usage
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15
Reported-by: Rob Clark
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..c4c24dabfd6f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -450,6 +450,31 @@ static enum drm_mode_status
dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge,
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct mipi_dsi_host *host = msm_dsi->host;
+ struct platform_device *pdev = msm_dsi->pdev;
+ struct dev_pm_opp *opp;
+ unsigned long byte_clk_rate;
+
+ byte_clk_rate = dsi_byte_clk_get_rate(host, IS_BONDED_DSI(), mode);
+
+ /*
+* If dev_pm_opp_find_freq_ceil() returns -EINVAL, its a bad
+* pointer being passed, so treat as an error and return MODE_ERROR
+*
+* If dev_pm_opp_find_freq_ceil() returns -ERANGE, no clock
+* was found matching the byte_clk, so return MODE_CLOCK_RANGE
+*
+* If dev_pm_opp_find_freq_ceil() returns -ENODEV, don't treat
+* it as an error as it could mean opp table is not implemented
+*/
I'd say, too lengthy and verbose.
+ opp = dev_pm_opp_find_freq_ceil(>dev, _clk_rate);
+ if (IS_ERR(opp)) {
+ if (PTR_ERR(opp) == -EINVAL)
+ return MODE_ERROR;
+ else if (PTR_ERR(opp) == -ERANGE)
+ return MODE_CLOCK_RANGE;
I think the logic should be quite opposite. Ignore -ENODEV, handle
-ERANGE and return MODE_ERROR for all other errors. In your code you are
ignoring not only -ENODEV, but all other possible errors which can be
added in future.
+ } else {
+ dev_pm_opp_put(opp);
+ }
return msm_dsi_host_check_dsc(host, mode);
}
--
With best wishes
Dmitry
Re: [PATCH 0/4] Track exported dma-buffers with memcg
On Mon, Jan 09, 2023 at 04:18:12PM -0800, Shakeel Butt wrote: > Hi T.J., > > On Mon, Jan 9, 2023 at 1:38 PM T.J. Mercier wrote: > > > > Based on discussions at LPC, this series adds a memory.stat counter for > > exported dmabufs. This counter allows us to continue tracking > > system-wide total exported buffer sizes which there is no longer any > > way to get without DMABUF_SYSFS_STATS, and adds a new capability to > > track per-cgroup exported buffer sizes. The total (root counter) is > > helpful for accounting in-kernel dmabuf use (by comparing with the sum > > of child nodes or with the sum of sizes of mapped buffers or FD > > references in procfs) in addition to helping identify driver memory > > leaks when in-kernel use continually increases over time. With > > per-application cgroups, the per-cgroup counter allows us to quickly > > see how much dma-buf memory an application has caused to be allocated. > > This avoids the need to read through all of procfs which can be a > > lengthy process, and causes the charge to "stick" to the allocating > > process/cgroup as long as the buffer is alive, regardless of how the > > buffer is shared (unless the charge is transferred). > > > > The first patch adds the counter to memcg. The next two patches allow > > the charge for a buffer to be transferred across cgroups which is > > necessary because of the way most dmabufs are allocated from a central > > process on Android. The fourth patch adds a SELinux hook to binder in > > order to control who is allowed to transfer buffer charges. > > > > [1] > > https://lore.kernel.org/all/20220617085702.4298-1-christian.koe...@amd.com/ > > > > I am a bit confused by the term "charge" used in this patch series. > From the patches, it seems like only a memcg stat is added and nothing > is charged to the memcg. > > This leads me to the question: Why add this stat in memcg if the > underlying memory is not charged to the memcg and if we don't really > want to limit the usage? > > I see two ways forward: > > 1. Instead of memcg, use bpf-rstat [1] infra to implement the > per-cgroup stat for dmabuf. (You may need an additional hook for the > stat transfer). > > 2. Charge the actual memory to the memcg. Since the size of dmabuf is > immutable across its lifetime, you will not need to do accounting at > page level and instead use something similar to the network memory > accounting interface/mechanism (or even more simple). However you > would need to handle the reclaim, OOM and charge context and failure > cases. However if you are not looking to limit the usage of dmabuf > then this option is an overkill. I think eventually, at least for other "account gpu stuff in cgroups" use case we do want to actually charge the memory. The problem is a bit that with gpu allocations reclaim is essentially "we pass the error to userspace and they get to sort the mess out". There are some exceptions (some gpu drivers to have shrinkers) would we need to make sure these shrinkers are tied into the cgroup stuff before we could enable charging for them? Also note that at least from the gpu driver side this is all a huge endeavour, so if we can split up the steps as much as possible (and get something interim useable that doesn't break stuff ofc), that is practically need to make headway here. TJ has been trying out various approaches for quite some time now already :-/ -Daniel > Please let me know if I misunderstood something. > > [1] https://lore.kernel.org/all/20220824233117.1312810-1-hao...@google.com/ > > thanks, > Shakeel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2 2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()
Currently there is no protection against a user trying to set
an unsupported mode on DSI. Implement a check based on the opp
table whether the byte clock for the mode can be supported by
validating whether an opp table entry exists.
For devices which have not added opp table support yet, skip
this check otherwise it will break bootup on those devices.
changes in v2:
- drop dev_pm_opp_get_opp_table() usage
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15
Reported-by: Rob Clark
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..c4c24dabfd6f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -450,6 +450,31 @@ static enum drm_mode_status
dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge,
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct mipi_dsi_host *host = msm_dsi->host;
+ struct platform_device *pdev = msm_dsi->pdev;
+ struct dev_pm_opp *opp;
+ unsigned long byte_clk_rate;
+
+ byte_clk_rate = dsi_byte_clk_get_rate(host, IS_BONDED_DSI(), mode);
+
+ /*
+* If dev_pm_opp_find_freq_ceil() returns -EINVAL, its a bad
+* pointer being passed, so treat as an error and return MODE_ERROR
+*
+* If dev_pm_opp_find_freq_ceil() returns -ERANGE, no clock
+* was found matching the byte_clk, so return MODE_CLOCK_RANGE
+*
+* If dev_pm_opp_find_freq_ceil() returns -ENODEV, don't treat
+* it as an error as it could mean opp table is not implemented
+*/
+ opp = dev_pm_opp_find_freq_ceil(>dev, _clk_rate);
+ if (IS_ERR(opp)) {
+ if (PTR_ERR(opp) == -EINVAL)
+ return MODE_ERROR;
+ else if (PTR_ERR(opp) == -ERANGE)
+ return MODE_CLOCK_RANGE;
+ } else {
+ dev_pm_opp_put(opp);
+ }
return msm_dsi_host_check_dsc(host, mode);
}
--
2.39.0
[PATCH v2 1/2] drm/msm/dsi: add a helper method to compute the dsi byte clk
Re-arrange the dsi_calc_pclk method to two helpers, one to
compute the DSI byte clk and the other to compute the pclk.
This makes the separation of the two clean and also allows
clients to compute and use the dsi byte clk separately.
changes in v2:
- move the assignments to definition lines
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 21 ++---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 2a96b4fe7839..1a551cc0e889 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -118,6 +118,8 @@ int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host *host, bool
is_bonded_dsi,
+ const struct drm_display_mode *mode);
int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c3cd96de7f7d..c145fd359ed5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -570,9 +570,8 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
-static unsigned long dsi_get_pclk_rate(struct msm_dsi_host *msm_host, bool
is_bonded_dsi)
+static unsigned long dsi_get_pclk_rate(const struct drm_display_mode *mode,
bool is_bonded_dsi)
{
- struct drm_display_mode *mode = msm_host->mode;
unsigned long pclk_rate;
pclk_rate = mode->clock * 1000;
@@ -589,11 +588,13 @@ static unsigned long dsi_get_pclk_rate(struct
msm_dsi_host *msm_host, bool is_bo
return pclk_rate;
}
-static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host *host, bool
is_bonded_dsi,
+ const struct drm_display_mode *mode)
{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
- unsigned long pclk_rate = dsi_get_pclk_rate(msm_host, is_bonded_dsi);
+ unsigned long pclk_rate = dsi_get_pclk_rate(mode, is_bonded_dsi);
u64 pclk_bpp = (u64)pclk_rate * bpp;
if (lanes == 0) {
@@ -607,8 +608,14 @@ static void dsi_calc_pclk(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
else
do_div(pclk_bpp, (8 * lanes));
- msm_host->pixel_clk_rate = pclk_rate;
- msm_host->byte_clk_rate = pclk_bpp;
+ return pclk_bpp;
+}
+
+static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+{
+ msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
is_bonded_dsi);
+ msm_host->byte_clk_rate = dsi_byte_clk_get_rate(_host->base,
is_bonded_dsi,
+ msm_host->mode);
DBG("pclk=%lu, bclk=%lu", msm_host->pixel_clk_rate,
msm_host->byte_clk_rate);
@@ -636,7 +643,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
dsi_calc_pclk(msm_host, is_bonded_dsi);
- pclk_bpp = (u64)dsi_get_pclk_rate(msm_host, is_bonded_dsi) * bpp;
+ pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, is_bonded_dsi) * bpp;
do_div(pclk_bpp, 8);
msm_host->src_clk_rate = pclk_bpp;
--
2.39.0
[PATCH 1/1] drm/ttm: Fix of rework on ttm_resource to use size_t type commit
From: Kevin Brace
Commit e3c92eb4a84fb0f00442e6b5cabf4f11b0eaaf41 (drm/ttm: rework on
ttm_resource to use size_t type) reworked ttm_resource{} to use size_t
type size instead of unsigned long type num_pages. In that commit,
when ttm_move_memcpy() is being called from ttm_bo_move_memcpy(),
the code was changed to specify the page size from ttm->num_pages
instead of the original code's dst_mem->num_pages. Since the commit
is about reworking ttm_resource{} to use size_t type size instead of
unsigned long type num_pages, the commit should have specified page
size converted version of dst_mem->size. Use PFN_UP macro to convert
dst_mem->size to page size.
Signed-off-by: Kevin Brace
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ba3aa0a0fc43..da5493f789df 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -173,7 +173,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
- ttm_move_memcpy(clear, ttm->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, PFN_UP(dst_mem->size), dst_iter,
src_iter);
if (!src_iter->ops->maps_tt)
ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
--
2.38.2
Re: [PATCH 5/5] drm/plane: Unexport drm_any_plane_has_format()
On Mon, Jan 09, 2023 at 07:58:08AM -0300, Maíra Canal wrote: > As the format validation is being dealt with exclusively > inside framebuffer_check(), there is no need to export the > drm_any_plane_has_format() symbol. > > Therefore, unexport the drm_any_plane_has_format() symbol, reinforcing > that format validation is being dealt with by the DRM API. > > Signed-off-by: Maíra Canal Usually we also delete the kerneldoc at that point, since that's mainly for driver authors and they don't need this anymore. With that Also please move the function decl to the drm_crtc_internal.h since this is no longer used outside of drm core/helper code. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_plane.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 24e7998d1731..67c0ab60c7b6 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -837,7 +837,6 @@ bool drm_any_plane_has_format(struct drm_device *dev, > > return false; > } > -EXPORT_SYMBOL(drm_any_plane_has_format); > > /* > * __setplane_internal - setplane handler for internal callers > -- > 2.39.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/5] drm/framebuffer: Check for valid formats
On Mon, Jan 09, 2023 at 07:58:04AM -0300, Maíra Canal wrote:
> Currently, framebuffer_check() doesn't check if the pixel format is
> supported, which can lead to the acceptance of invalid pixel formats
> e.g. the acceptance of invalid modifiers. Therefore, add a check for
> valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
> calls with invalid formats.
>
> Moreover, note that this check is only valid for atomic drivers,
> because, for non-atomic drivers, checking drm_any_plane_has_format() is
> not possible since the format list for the primary plane is fake, and
> we'd therefore reject valid formats.
>
> Signed-off-by: Maíra Canal
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst| 9 -
> drivers/gpu/drm/drm_framebuffer.c | 8
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 1f8a5ebe188e..3a79c26c5cc7 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -276,11 +276,10 @@ Various hold-ups:
> - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom
> fb
>setup code can't be deleted.
>
> -- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
> - atomic drivers we could check for valid formats by calling
> - drm_plane_check_pixel_format() against all planes, and pass if any plane
> - supports the format. For non-atomic that's not possible since like the
> format
> - list for the primary plane is fake and we'd therefor reject valid formats.
> +- Need to switch to drm_gem_fb_create(), as now framebuffer_check() checks
> for
> + valid formats for atomic drivers.
> +
> +- Add an addfb format validation for non-atomic drivers.
>
> - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
>version of the varios drm_gem_fb_create functions. Maybe called
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index aff3746dedfb..605642bf3650 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -280,6 +280,14 @@ static int framebuffer_check(struct drm_device *dev,
> }
> }
>
> + /* Verify that the modifier is supported. */
> + if (drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
> 0x%llx\n",
> + >pixel_format, r->modifier[0]);
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
> --
> 2.39.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/2] drm: Add DRM-managed alloc_workqueue() and alloc_ordered_workqueue()
On Tue, Jan 10, 2023 at 11:24:47PM +0800, Jiasheng Jiang wrote:
> Add drmm_alloc_workqueue() and drmm_alloc_ordered_workqueue(), the helpers
> that provide managed workqueue cleanup. The workqueue will be destroyed
> with the final reference of the DRM device.
>
> Signed-off-by: Jiasheng Jiang
Yeah I think this looks nice.
Reviewed-by: Daniel Vetter
I'm assuming driver maintainers will pick this up, if not please holler.
Also the threading seems broken, it's not a patch series. The b4 tool or
git send-email (of all the patches of the entire series at once, not each
individually) should get this right.
Unfortunately I did't find the right link in the kernel docs, or at least
they're not as detailed as I hoped.
Also your previous submission had iirc a bunch more patches, do you plan
to include them all in the next patch set?
-Daniel
> ---
> drivers/gpu/drm/drm_managed.c | 66 +++
> include/drm/drm_managed.h | 8 +
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 4cf214de50c4..d3bd6247eec9 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -271,6 +271,13 @@ static void drmm_mutex_release(struct drm_device *dev,
> void *res)
> mutex_destroy(lock);
> }
>
> +static void drmm_destroy_workqueue(struct drm_device *dev, void *res)
> +{
> + struct workqueue_struct *wq = res;
> +
> + destroy_workqueue(wq);
> +}
> +
> /**
> * drmm_mutex_init - _device-managed mutex_init()
> * @dev: DRM device
> @@ -289,3 +296,62 @@ int drmm_mutex_init(struct drm_device *dev, struct mutex
> *lock)
> return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
> }
> EXPORT_SYMBOL(drmm_mutex_init);
> +
> +/**
> + * drmm_alloc_workqueue - _device-managed alloc_workqueue()
> + * @dev: DRM device
> + * @wq: workqueue to be allocated
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + *
> + * This is a _device-managed version of alloc_workqueue().
> + * The initialized lock is automatically destroyed on the final
> + * drm_dev_put().
> + */
> +int drmm_alloc_workqueue(struct drm_device *dev,
> + struct workqueue_struct *wq, const char *fmt,
> + unsigned int flags, int max_active, ...)
> +{
> + va_list args;
> +
> + va_start(args, max_active);
> + wq = alloc_workqueue(fmt, flags, max_active, args);
> + va_end(args);
> +
> + if (!wq)
> + return -ENOMEM;
> +
> + return drmm_add_action_or_reset(dev, drmm_destroy_workqueue, wq);
> +}
> +EXPORT_SYMBOL(drmm_alloc_workqueue);
> +
> +/**
> + * drmm_alloc_ordered_workqueue - _device-managed
> + * alloc_ordered_workqueue()
> + * @dev: DRM device
> + * @wq: workqueue to be allocated
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + *
> + * This is a _device-managed version of alloc_ordered_workqueue().
> + * The initialized lock is automatically destroyed on the final
> + * drm_dev_put().
> + */
> +int drmm_alloc_ordered_workqueue(struct drm_device *dev,
> + struct workqueue_struct *wq,
> + const char *fmt, unsigned int flags, ...)
> +{
> + va_list args;
> +
> + va_start(args, flags);
> + wq = alloc_ordered_workqueue(fmt, flags, args);
> + va_end(args);
> +
> + if (!wq)
> + return -ENOMEM;
> +
> + return drmm_add_action_or_reset(dev, drmm_destroy_workqueue, wq);
> +}
> +EXPORT_SYMBOL(drmm_alloc_ordered_workqueue);
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 359883942612..68cecc14e1af 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -107,4 +107,12 @@ void drmm_kfree(struct drm_device *dev, void *data);
>
> int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
>
> +int drmm_alloc_workqueue(struct drm_device *dev,
> + struct workqueue_struct *wq, const char *fmt,
> + unsigned int flags, int max_active, ...);
> +
> +int drmm_alloc_ordered_workqueue(struct drm_device *dev,
> + struct workqueue_struct *wq,
> + const char *fmt, unsigned int flags, ...);
> +
> #endif
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 0/1] DRM commit e3c92eb causes OpenChrome DRM to crash during boot
From: Kevin Brace Hi, I work on an out of the kernel tree DRM module for VIA Technologies Chrome integrated graphics (https://cgit.freedesktop.org/openchrome/drm-openchrome/), and DRM commit e3c92eb4a84fb0f00442e6b5cabf4f11b0eaaf41 (drm/ttm: rework on ttm_resource to use size_t type) definitely breaks my code. The bug is 100% reproducible. It took me about 2 1/2 weeks to track down the bad commit due to the general difficulty of debugging DRM code since it gets loaded by the OS way before sysklogd service is even up and running to record a crash. For this bug, bug check did not come on, so this made it very hard to track down the bad commit. After reversing many commits, I was able to see a difference in the behavior of the code if this particular commit was reversed. I am including a patch that I think correctly fixes the erroneous code, and OpenChrome DRM works correctly (i.e., OS now boots properly) if the patch is applied. Please be more careful tinkering with TTM in the future since it tends to be very fragile. -- Kevin Brace (1): drm/ttm: Fix of rework on ttm_resource to use size_t type commit drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.38.2
Re: [PATCH 2/2] drm/debugfs: add descriptions to struct parameters
On Mon, Jan 09, 2023 at 08:28:20AM -0300, Maíra Canal wrote:
> On 1/6/23 17:19, Daniel Vetter wrote:
> > On Thu, Jan 05, 2023 at 04:30:39PM -0300, Maíra Canal wrote:
> > > The structs drm_debugfs_info and drm_debugfs_entry don't have
> > > descriptions for their parameters, which is causing the following
> > > warnings:
> > >
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'name' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'show' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'driver_features' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:93: warning: Function parameter or member
> > > 'data' not described in 'drm_debugfs_info'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'dev' not described in 'drm_debugfs_entry'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'file' not described in 'drm_debugfs_entry'
> > > include/drm/drm_debugfs.h:105: warning: Function parameter or member
> > > 'list' not described in 'drm_debugfs_entry'
> > >
> > > Therefore, fix the warnings by adding descriptions to all struct
> > > parameters.
> > >
> > > Reported-by: Stephen Rothwell
> > > Signed-off-by: Maíra Canal
> > > ---
> > > include/drm/drm_debugfs.h | 18 ++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
> > > index 53b7297260a5..7616f457ce70 100644
> > > --- a/include/drm/drm_debugfs.h
> > > +++ b/include/drm/drm_debugfs.h
> > > @@ -86,9 +86,22 @@ struct drm_info_node {
> > >* core.
> > >*/
> > > struct drm_debugfs_info {
> > > + /** @name: File name */
> > > const char *name;
> > > +
> > > + /**
> > > + * @show:
> > > + *
> > > + * Show callback. _file->private will be set to the
> > > + * drm_debugfs_entry corresponding to the instance of this info
> > > + * on a given drm_device.
> >
> > So this is a bit late, but why don't we pass that drm_debugfs_entry as an
> > explicit parameter? Or maybe just the struct drm_device, because that and
> > the void *data is really all there is to pass along. Would give us more
> > type-safety, which really is the main reason for having drm-specific
> > debugfs functions.
>
> It seems like a better idea to pass the drm_debugfs_entry as an explicit
> parameter. I can work on it, but I guess it is a better idea to finish
> the conversion of all drm_debugfs_create_files() to drm_debugfs_add_files()
> and then perform the change in the show() signature.
So drm_debugfs_entry still feels like a bit too high level, do callers
really need that? They get the void * and I guess need the struct
drm_device *
This really starts to matter more when we also roll this out for
connector/crtc, then you can give them directly a pointer to that. And the
drm_debugfs_entry thing becomes an implementation detail entirely.
Or do I miss something?
Also yes we can do that later on, it shouldn't be too annyoing to roll
out.
-Daniel
>
> Best Regards,
> - Maíra Canal
>
> >
> > Either way, on the series: Reviewed-by: Daniel Vetter
> >
> >
> > > + */
> > > int (*show)(struct seq_file*, void*);
> > > +
> > > + /** @driver_features: Required driver features for this entry. */
> > > u32 driver_features;
> > > +
> > > + /** @data: Driver-private data, should not be device-specific. */
> > > void *data;
> > > };
> > > @@ -99,8 +112,13 @@ struct drm_debugfs_info {
> > >* drm_debugfs_info on a drm_device.
> > >*/
> > > struct drm_debugfs_entry {
> > > + /** @dev: drm_device for this node. */
> > > struct drm_device *dev;
> > > +
> > > + /** @file: Template for this node. */
> > > struct drm_debugfs_info file;
> > > +
> > > + /** @list: Linked list of all device nodes. */
> > > struct list_head list;
> > > };
> > > --
> > > 2.39.0
> > >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917 --- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) --- do you still have the problem with: CONFIG_DRM_FBDEV_EMULATION=n in your .config? Does reverting a6250bdb6c4677ee77d699b338e077b900f94c0c fix it? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v5 1/4] dt-bindings: display/msm: convert MDP5 schema to YAML format
On 2023-01-12 00:31:33, Dmitry Baryshkov wrote: > On 12/01/2023 00:29, Marijn Suijten wrote: > > On 2023-01-10 06:40:27, Dmitry Baryshkov wrote: > >> On 09/01/2023 09:49, Marijn Suijten wrote: > >>> On 2023-01-09 07:01:49, Dmitry Baryshkov wrote: > > > +description: | > >>> > >>> Should multiline descriptions be treated as a oneline string with `>`? > >> > >> Ack, I'm fine with either of them, let's use the > > >> > >>> > + Contains the list of output ports from DPU device. These ports > + connect to interfaces that are external to the DPU hardware, > + such as DSI, DP etc. MDP5 devices support up to 4 ports:: > >>> > >>> How do these double colons render? Is this intentional? > >> > >> double colons is an escape for a single colon if I remember correcly. > > > > I thought no escaping was necessary here, especially since this is > > already a value - it is a multiline string. > > I was mostly following examples, grep :: through the dt-bindings. Saw that, maybe these "freeform" description strings are intended to be RST to support more elaborate rendering if/when that happens? > >> BTW: how to render the DT schema? > > > > I'm not sure if there's currently any rendering tool to view these docs > > in a "friendly" manner, e.g. an html page, or whether they're only used > > as specifications for DT validation. > > Probably there will be one at some point. It might make good addition to > devicetree.org. Would be super cool to have some "interactive" / properly rendered/colored docs up there for DT :) - Marijn
Re: [PATCH] drm/msm/dpu: sort entries in the HW catalog
On 2023-01-09 20:30:01, Dmitry Baryshkov wrote: > The usual problem is that there are two dimensions: with each > generations there are new (and removed) features, but on the other hand > within each generation there are units that are feature-rich and the > ones that are feature-deprived. qcm2290, sm6115, etc. Yes, in that case (as we currently already do) have to duplicate an existing struct and give one of the two a new feature bit. > Thus SDM comes before SC and SM > platforms and QCM is kept as the last one. There are no functional > changes in this patch. > > Signed-off-by: Dmitry Baryshkov > --- > > Yes, I hate such mass-moves too. However the entries in this file are > slowly becoming uncontrollable. Let's enforce some order now (while it's > late already, but not _that_ late). > >>> > >>> I agree that something should happen, contributing to this file is > >>> unnecessarily tough. > >> > >> In the IRC conversation Rob suggested playing with includes, but I > >> don't see a good way to implement that. > > > > That would be nice; especially if we accept struct duplication (instead > > of recursively including "earlier" versions where needed, as mentioned > > in IRC that'll spiral out of control). With that one can easily diff > > two include files and understand the differences between SoCs and/or DPU > > hardware revisions (or notice whether a certain configuration might be > > missing/extraneous). > > Let's see what kind of binary growth does it bring. In the end it well > might be that the compiler is smart enough. Curious as well, it might overlap identical structs (identical byte sequence) similar to string interning? - Marijn
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> tvrtko.ursu...@linux.intel.com> wrote:
>
> >
> > On 10/01/2023 14:08, Jason Ekstrand wrote:
> > > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > > mailto:tvrtko.ursu...@linux.intel.com>>
> >
> > > wrote:
> > >
> > >
> > >
> > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > >
> > > [snip]
> > >
> > > > >>> AFAICT it proposes to have 1:1 between *userspace*
> > created
> > > > contexts (per
> > > > >>> context _and_ engine) and drm_sched. I am not sure
> > avoiding
> > > > invasive changes
> > > > >>> to the shared code is in the spirit of the overall idea
> > > and instead
> > > > >>> opportunity should be used to look at way to
> > > refactor/improve
> > > > drm_sched.
> > > >
> > > >
> > > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > > all or
> > > > really needs to drive a re-factor. (More on that later.)
> > > There's only
> > > > one real issue which is that it fires off potentially a lot of
> > > kthreads.
> > > > Even that's not that bad given that kthreads are pretty light and
> > > you're
> > > > not likely to have more kthreads than userspace threads which are
> > > much
> > > > heavier. Not ideal, but not the end of the world either.
> > > Definitely
> > > > something we can/should optimize but if we went through with Xe
> > > without
> > > > this patch, it would probably be mostly ok.
> > > >
> > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > >>
> > > > >> I'm not really prepared to make large changes to DRM
> > > scheduler
> > > > at the
> > > > >> moment for Xe as they are not really required nor does
> > Boris
> > > > seem they
> > > > >> will be required for his work either. I am interested to
> > see
> > > > what Boris
> > > > >> comes up with.
> > > > >>
> > > > >>> Even on the low level, the idea to replace drm_sched
> > threads
> > > > with workers
> > > > >>> has a few problems.
> > > > >>>
> > > > >>> To start with, the pattern of:
> > > > >>>
> > > > >>>while (not_stopped) {
> > > > >>> keep picking jobs
> > > > >>>}
> > > > >>>
> > > > >>> Feels fundamentally in disagreement with workers (while
> > > > obviously fits
> > > > >>> perfectly with the current kthread design).
> > > > >>
> > > > >> The while loop breaks and worker exists if no jobs are
> > ready.
> > > >
> > > >
> > > > I'm not very familiar with workqueues. What are you saying would
> > fit
> > > > better? One scheduling job per work item rather than one big work
> > > item
> > > > which handles all available jobs?
> > >
> > > Yes and no, it indeed IMO does not fit to have a work item which is
> > > potentially unbound in runtime. But it is a bit moot conceptual
> > > mismatch
> > > because it is a worst case / theoretical, and I think due more
> > > fundamental concerns.
> > >
> > > If we have to go back to the low level side of things, I've picked
> > this
> > > random spot to consolidate what I have already mentioned and perhaps
> > > expand.
> > >
> > > To start with, let me pull out some thoughts from workqueue.rst:
> > >
> > > """
> > > Generally, work items are not expected to hog a CPU and consume many
> > > cycles. That means maintaining just enough concurrency to prevent
> > work
> > > processing from stalling should be optimal.
> > > """
> > >
> > > For unbound queues:
> > > """
> > > The responsibility of regulating concurrency level is on the users.
> > > """
> > >
> > > Given the unbound queues will be spawned on demand to service all
> > > queued
> > > work items (more interesting when mixing up with the
> > > system_unbound_wq),
> > > in the proposed design the number of instantiated worker threads does
> > > not correspond to the number of user threads (as you have elsewhere
> > > stated), but pessimistically to the number of active user contexts.
> > >
> > >
> > > Those are pretty much the same in practice. Rather, user threads is
> > > typically an upper bound on the number of contexts. Yes, a single user
> > > thread could have a bunch of contexts but basically nothing does that
> > > except IGT. In real-world usage, it's at most one context per user
> > thread.
> >
> > Typically is the key here. But I am not sure it is good enough. Consider
> > this example - Intel Flex 170:
> >
> > * Delivers up to 36 streams 1080p60 transcode throughput per card.
> > * When scaled to 10 cards in a
Re: [PATCH v5 1/4] dt-bindings: display/msm: convert MDP5 schema to YAML format
On 12/01/2023 00:29, Marijn Suijten wrote: On 2023-01-10 06:40:27, Dmitry Baryshkov wrote: On 09/01/2023 09:49, Marijn Suijten wrote: On 2023-01-09 07:01:49, Dmitry Baryshkov wrote: +description: | Should multiline descriptions be treated as a oneline string with `>`? Ack, I'm fine with either of them, let's use the > + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. MDP5 devices support up to 4 ports:: How do these double colons render? Is this intentional? double colons is an escape for a single colon if I remember correcly. I thought no escaping was necessary here, especially since this is already a value - it is a multiline string. I was mostly following examples, grep :: through the dt-bindings. BTW: how to render the DT schema? I'm not sure if there's currently any rendering tool to view these docs in a "friendly" manner, e.g. an html page, or whether they're only used as specifications for DT validation. Probably there will be one at some point. It might make good addition to devicetree.org. - Marijn -- With best wishes Dmitry
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Fri, Jan 06, 2023 at 04:33:04PM -0800, Abhinav Kumar wrote: > Hi Daniel > > Thanks for looking into this series. > > On 1/6/2023 1:49 PM, Dmitry Baryshkov wrote: > > On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote: > > > > > > On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote: > > > > On Fri, 6 Jan 2023 at 02:38, Jessica Zhang > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 1/5/2023 3:33 AM, Daniel Vetter wrote: > > > > > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote: > > > > > > > Introduce and add support for a solid_fill property. When the > > > > > > > solid_fill > > > > > > > property is set, and the framebuffer is set to NULL, memory fetch > > > > > > > will be > > > > > > > disabled. > > > > > > > > > > > > > > In addition, loosen the NULL FB checks within the atomic commit > > > > > > > callstack > > > > > > > to allow a NULL FB when the solid_fill property is set and add FB > > > > > > > checks > > > > > > > in methods where the FB was previously assumed to be non-NULL. > > > > > > > > > > > > > > Finally, have the DPU driver use drm_plane_state.solid_fill and > > > > > > > instead of > > > > > > > dpu_plane_state.color_fill, and add extra checks in the DPU > > > > > > > atomic commit > > > > > > > callstack to account for a NULL FB in cases where solid_fill is > > > > > > > set. > > > > > > > > > > > > > > Some drivers support hardware that have optimizations for solid > > > > > > > fill > > > > > > > planes. This series aims to expose these capabilities to > > > > > > > userspace as > > > > > > > some compositors have a solid fill flag (ex. SOLID_COLOR in the > > > > > > > Android > > > > > > > hardware composer HAL) that can be set by apps like the Android > > > > > > > Gears > > > > > > > app. > > > > > > > > > > > > > > Userspace can set the solid_fill property to a blob containing the > > > > > > > appropriate version number and solid fill color (in RGB323232 > > > > > > > format) and > > > > > > > setting the framebuffer to NULL. > > > > > > > > > > > > > > Note: Currently, there's only one version of the solid_fill blob > > > > > > > property. > > > > > > > However if other drivers want to support a similar feature, but > > > > > > > require > > > > > > > more than just the solid fill color, they can extend this feature > > > > > > > by > > > > > > > creating additional versions of the drm_solid_fill struct. > > > > > > > > > > > > > > Changes in V2: > > > > > > > - Dropped SOLID_FILL_FORMAT property (Simon) > > > > > > > - Switched to implementing solid_fill property as a blob (Simon, > > > > > > > Dmitry) > > > > > > > - Changed to checks for if solid_fill_blob is set (Dmitry) > > > > > > > - Abstracted (plane_state && !solid_fill_blob) checks to helper > > > > > > > method > > > > > > > (Dmitry) > > > > > > > - Removed DPU_PLANE_COLOR_FILL_FLAG > > > > > > > - Fixed whitespace and indentation issues (Dmitry) > > > > > > > > > > > > Now that this is a blob, I do wonder again whether it's not cleaner > > > > > > to set > > > > > > the blob as the FB pointer. Or create some kind other kind of > > > > > > special data > > > > > > source objects (because solid fill is by far not the only such > > > > > > thing). > > > > > > > > > > > > We'd still end up in special cases like when userspace that doesn't > > > > > > understand solid fill tries to read out such a framebuffer, but > > > > > > these > > > > > > cases already exist anyway for lack of priviledges. > > > > > > > > > > > > So I still think that feels like the more consistent way to > > > > > > integrate this > > > > > > feature. Which doesn't mean it has to happen like that, but the > > > > > > patches/cover letter should at least explain why we don't do it > > > > > > like this. > > > > > > > > > > Hi Daniel, > > > > > > > > > > IIRC we were facing some issues with this check [1] when trying to set > > > > > FB to a PROP_BLOB instead. Which is why we went with making it a > > > > > separate property instead. Will mention this in the cover letter. > > > > > > > > What kind of issues? Could you please describe them? > > > > > > We switched from bitmask to enum style for prop types, which means it's > > > not possible to express with the current uapi a property which accepts > > > both an object or a blob. > > > > > > Which yeah sucks a bit ... > > > > > > But! > > > > > > blob properties are kms objects (like framebuffers), so it should be > > > possible to stuff a blob into an object property as-is. Of course you need > > > to update the validation code to make sure we accept either an fb or a > > > blob for the internal representation. But that kind of split internally is > > > required no matter what I think. > > > > I checked your idea and notes from Jessica. So while we can pass blobs > > to property objects, the prop_fb_id is created as an object property > > with the type DRM_MODE_OBJECT_FB. Passing DRM_MODE_OBJECT_BLOB would >
Re: [PATCH v5 1/4] dt-bindings: display/msm: convert MDP5 schema to YAML format
On 2023-01-10 06:40:27, Dmitry Baryshkov wrote: > On 09/01/2023 09:49, Marijn Suijten wrote: > > On 2023-01-09 07:01:49, Dmitry Baryshkov wrote: > >> +description: | > > > > Should multiline descriptions be treated as a oneline string with `>`? > > Ack, I'm fine with either of them, let's use the > > > > > >> + Contains the list of output ports from DPU device. These ports > >> + connect to interfaces that are external to the DPU hardware, > >> + such as DSI, DP etc. MDP5 devices support up to 4 ports:: > > > > How do these double colons render? Is this intentional? > > double colons is an escape for a single colon if I remember correcly. I thought no escaping was necessary here, especially since this is already a value - it is a multiline string. > BTW: how to render the DT schema? I'm not sure if there's currently any rendering tool to view these docs in a "friendly" manner, e.g. an html page, or whether they're only used as specifications for DT validation. - Marijn
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917 --- Comment #6 from kolAflash (kolafl...@kolahilft.de) --- Created attachment 303585 --> https://bugzilla.kernel.org/attachment.cgi?id=303585=edit 6.1.4 dmesg after hibernation (In reply to Mario Limonciello (AMD) from comment #4) > [...] > Is it 100% failure rate on 6.0.y? Yes. > Since you mentioned that you couldn't effectively use 6.1.y because of the > MST issue, are you only finding it on 6.0.y when connected to a dock or > anything else unique? No. Happens with dock, with simple USB-C power (no dock) and on battery. > > Sadly I don't know how to provide helpful logs. After reboot there's > nothing > > helpful in /var/log/messages > > Can you check /var/lib/systemd/pstore? Perhaps there was a kernel crash > that got saved into NVRAM and restored by systemd on the next boot. Sadly that file doesn't exist. There are some files in /sys/fs/pstore/. But nothing from today. (In reply to Alex Deucher from comment #5) > Can you attach your dmesg output? I don't know how to get logs (including dmesg) when hibernation has failed. As said, after reboot there's nothing new in /var/log/messages Instead I attached dmesg after hibernation with v6.1.4. Is that helpful? Another thing: Is it important that my SWAP is a file /swap on an ext4 partition inside a LUKS partition? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [RFC PATCH 1/4] drm/msm/mdss: convert UBWC setup to use match data
On 2023-01-11 17:11:03, Dmitry Baryshkov wrote:
> On 11/01/2023 10:44, Marijn Suijten wrote:
> > On 2023-01-09 12:32:18, Abhinav Kumar wrote:
> >
> On 12/7/2022 4:08 PM, Dmitry Baryshkov wrote:
> >
> > +struct msm_mdss_data {
> > + u32 ubwc_version;
> > + u32 ubwc_swizzle;
> > + u32 ubwc_static;
> > + u32 highest_bank_bit;
> > + u32 macrotile_mode;
> > +};
> >
> > This magic struct could really use some documentation, otherwise users
> > will have no idea what fields to set (or omit) nor what values to use.
> > For example decoder 2.0 seems to only use ubwc_static as a sort of magic
> > "we don't know what the bits in UBWC_STATIC mean", whereas decoder 3.0
> > reconstructs this field entirely from the other parameters. Decoder 4.0
> > however does the same, but _also_ embeds this uwbc_static magic value
> > back into the register value?
>
> On the bright side these magic values correspond 1:1 to the vendor dtsi
> and to the part of DPU hw catalog. It would be nice to know the bit used
> by decoder 2.0, but I fear that we'd have to resort to wild guesses
> unless Qualcomm decides to disclose that information.
If downstream has these fields verbatim that makes it easier to
copy-paste, agreed.
> As for dec 4.0 and ubwc_static. I fear that it's just somebody (writing
> downstream DT parsing) reused the ubwc-static name for the bitfield
> which in reality has some sensible name.
Yes, ugh.
> > Also read on below about checking "compatibility" between this struct
> > and the decoder version, and why I feel this struct (versus mandatory
> > function arguments) makes this struct less robust.
> >
> > struct msm_mdss {
> > struct device *dev;
> > @@ -40,6 +48,7 @@ struct msm_mdss {
> > unsigned long enabled_mask;
> > struct irq_domain *domain;
> > } irq_controller;
> > + const struct msm_mdss_data *mdss_data;
> > struct icc_path *path[2];
> > u32 num_paths;
> > };
> > @@ -180,46 +189,40 @@ static int _msm_mdss_irq_domain_add(struct
> > msm_mdss *msm_mdss)
> > #define UBWC_3_0 0x3000
> > #define UBWC_4_0 0x4000
> > -static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss,
> > - u32 ubwc_static)
> > +static void msm_mdss_setup_ubwc_dec_20(struct msm_mdss *msm_mdss)
> > {
> > - writel_relaxed(ubwc_static, msm_mdss->mmio + UBWC_STATIC);
> > + const struct msm_mdss_data *data = msm_mdss->mdss_data;
> > +
> > + writel_relaxed(data->ubwc_static, msm_mdss->mmio + UBWC_STATIC);
> > }
> > -static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss,
> > - unsigned int ubwc_version,
> > - u32 ubwc_swizzle,
> > - u32 highest_bank_bit,
> > - u32 macrotile_mode)
> > +static void msm_mdss_setup_ubwc_dec_30(struct msm_mdss *msm_mdss)
> > {
> > - u32 value = (ubwc_swizzle & 0x1) |
> > - (highest_bank_bit & 0x3) << 4 |
> > - (macrotile_mode & 0x1) << 12;
> > + const struct msm_mdss_data *data = msm_mdss->mdss_data;
> > + u32 value = (data->ubwc_swizzle & 0x1) |
> > + (data->highest_bank_bit & 0x3) << 4 |
> > + (data->macrotile_mode & 0x1) << 12;
> > - if (ubwc_version == UBWC_3_0)
> > + if (data->ubwc_version == UBWC_3_0)
> > value |= BIT(10);
> > - if (ubwc_version == UBWC_1_0)
> > + if (data->ubwc_version == UBWC_1_0)
> > value |= BIT(8);
> > writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
> > }
> > -static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss,
> > - unsigned int ubwc_version,
> > - u32 ubwc_swizzle,
> > - u32 ubwc_static,
> > - u32 highest_bank_bit,
> > - u32 macrotile_mode)
> > +static void msm_mdss_setup_ubwc_dec_40(struct msm_mdss *msm_mdss)
> > {
> > - u32 value = (ubwc_swizzle & 0x7) |
> > - (ubwc_static & 0x1) << 3 |
> > - (highest_bank_bit & 0x7) << 4 |
> > - (macrotile_mode & 0x1) << 12;
> > + const struct msm_mdss_data *data = msm_mdss->mdss_data;
> > + u32 value = (data->ubwc_swizzle & 0x7) |
> > + (data->ubwc_static & 0x1) << 3 |
> > + (data->highest_bank_bit & 0x7) << 4 |
> > + (data->macrotile_mode & 0x1) << 12;
> > writel_relaxed(value, msm_mdss->mmio + UBWC_STATIC);
> > - if (ubwc_version == UBWC_3_0) {
> > + if (data->ubwc_version == UBWC_3_0) {
> > writel_relaxed(1, msm_mdss->mmio + UBWC_CTRL_2);
> > writel_relaxed(0, msm_mdss->mmio +
Re: [RFC 3/3] drm: Update file owner during use
On Tue, Jan 10, 2023 at 01:14:51PM +, Tvrtko Ursulin wrote: > > On 06/01/2023 18:00, Daniel Vetter wrote: > > On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote: > > > Am 06.01.23 um 11:53 schrieb Daniel Vetter: > > > > On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote: > > > > > Am 05.01.23 um 13:32 schrieb Daniel Vetter: > > > > > > [SNIP] > > > > > > > For the case of an master fd I actually don't see the reason why > > > > > > > we should > > > > > > > limit that? And fd can become master if it either was master > > > > > > > before or has > > > > > > > CAP_SYS_ADMIN. Why would we want an extra check for the pid/tgid > > > > > > > here? > > > > > > This is just info/debug printing, I don't see the connection to > > > > > > drm_auth/master stuff? Aside from the patch mixes up the master > > > > > > opener and > > > > > > the current user due to fd passing or something like that. > > > > > That's exactly why my comment meant as well. > > > > > > > > > > The connect is that the drm_auth/master code currently the pid/tgid as > > > > > indicator if the "owner" of the fd has changed and so if an access > > > > > should be > > > > > allowed or not. I find that approach a bit questionable. > > > > > > > > > > > Note that we cannot do that (I think at least, after pondering this > > > > > > some > > > > > > more) because it would break the logind master fd passing scheme - > > > > > > there > > > > > > the receiving compositor is explicitly _not_ allowed to acquire > > > > > > master > > > > > > rights on its own. So the master priviledges must not move with the > > > > > > fd or > > > > > > things can go wrong. > > > > > That could be the rational behind that, but why doesn't logind then > > > > > just > > > > > pass on a normal render node to the compositor? > > > > Because the compositor wants the kms node. We have 3 access levels in > > > > drm > > > > > > > > - render stuff > > > > - modeset stuff (needs a card* node and master rights for changing > > > > things) > > > > - set/drop master (needs root) > > > > > > > > logind wants to give the compositor modeset access, but not master > > > > drop/set access (because vt switching is controlled by logind). > > > > > > > > The pid check in drm_auth is for the use-case where you start your > > > > compositor on a root vt (or setuid-root), and then want to make sure > > > > that after cred dropping, set/drop master keeps working. Because in that > > > > case the vt switch dance is done by the compositor. > > > > > > > > Maybe we should document this stuff a bit better :-) > > > > > > Maybe add a friendly warning? E.g. like "Don't touch it, it works!" :) > > > > I think Tvrtko just volunteered for that :-) Maybe addition in the > > drm-uapi.rst section would be good that fills out the gaps we have. > > I can attempt to copy, paste and tidy what you wrote here, albeit with less > than full degree of authority. Assuming into the existing comment above > drm_master_check_perm? I'd put it into the DOC: section in drm_auth.c so it shows up in the drm-uapi.rst docs. Or do a new one if you want to split this out and then include it in the drm-uapi.rst. > But in terms of where my series is going next I would need some > clarification in the other sub-thread. Maybe I'm lost on what the leftover confusion is? This one seemed to be it? -Daniel > > Regards, > > Tvrtko > > > > So basically this is a valid use case where logind set/get the master > > > status > > > of a fd while the compositor uses the master functionality? > > > > Yup, and the compositor is _not_ allowed to call these. Despite that it's > > the exact sime struct file - it has to be the same struct file in both > > loging and compositor, otherwise logind cannot orchestratet the vt switch > > dance for the compositors. Which unlike non-logind vt switching has the > > nice property that if a compositor dies/goes rogue, logind can still force > > the switch. With vt-only switching you need the sysrq to reset the console > > to text and kill the foreground process for the same effect. > > -Daniel > > > > > > > > Christian. > > > > > > > -Daniel > > > > > > > > > Christian. > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Christian. > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Tvrtko > > > > > > > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > return 0; > > > > > > > > > > if (!capable(CAP_SYS_ADMIN)) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_debugfs.c > > > > > > > > > > b/drivers/gpu/drm/drm_debugfs.c > > > > > > > > > > index 42f657772025..9d4e3146a2b8 100644 > > > > > > > > > > --- a/drivers/gpu/drm/drm_debugfs.c > > > > > > > > > > +++ b/drivers/gpu/drm/drm_debugfs.c > > > > > > > > > > @@ -90,15 +90,17 @@ static int drm_clients_info(struct > > > > > > > > > > seq_file > > > > > > > >
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 10/01/2023 14:08, Jason Ekstrand wrote:
> > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > mailto:tvrtko.ursu...@linux.intel.com>>
>
> > wrote:
> >
> >
> >
> > On 09/01/2023 17:27, Jason Ekstrand wrote:
> >
> > [snip]
> >
> > > >>> AFAICT it proposes to have 1:1 between *userspace*
> created
> > > contexts (per
> > > >>> context _and_ engine) and drm_sched. I am not sure
> avoiding
> > > invasive changes
> > > >>> to the shared code is in the spirit of the overall idea
> > and instead
> > > >>> opportunity should be used to look at way to
> > refactor/improve
> > > drm_sched.
> > >
> > >
> > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > all or
> > > really needs to drive a re-factor. (More on that later.)
> > There's only
> > > one real issue which is that it fires off potentially a lot of
> > kthreads.
> > > Even that's not that bad given that kthreads are pretty light and
> > you're
> > > not likely to have more kthreads than userspace threads which are
> > much
> > > heavier. Not ideal, but not the end of the world either.
> > Definitely
> > > something we can/should optimize but if we went through with Xe
> > without
> > > this patch, it would probably be mostly ok.
> > >
> > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > >>
> > > >> I'm not really prepared to make large changes to DRM
> > scheduler
> > > at the
> > > >> moment for Xe as they are not really required nor does
> Boris
> > > seem they
> > > >> will be required for his work either. I am interested to
> see
> > > what Boris
> > > >> comes up with.
> > > >>
> > > >>> Even on the low level, the idea to replace drm_sched
> threads
> > > with workers
> > > >>> has a few problems.
> > > >>>
> > > >>> To start with, the pattern of:
> > > >>>
> > > >>>while (not_stopped) {
> > > >>> keep picking jobs
> > > >>>}
> > > >>>
> > > >>> Feels fundamentally in disagreement with workers (while
> > > obviously fits
> > > >>> perfectly with the current kthread design).
> > > >>
> > > >> The while loop breaks and worker exists if no jobs are
> ready.
> > >
> > >
> > > I'm not very familiar with workqueues. What are you saying would
> fit
> > > better? One scheduling job per work item rather than one big work
> > item
> > > which handles all available jobs?
> >
> > Yes and no, it indeed IMO does not fit to have a work item which is
> > potentially unbound in runtime. But it is a bit moot conceptual
> > mismatch
> > because it is a worst case / theoretical, and I think due more
> > fundamental concerns.
> >
> > If we have to go back to the low level side of things, I've picked
> this
> > random spot to consolidate what I have already mentioned and perhaps
> > expand.
> >
> > To start with, let me pull out some thoughts from workqueue.rst:
> >
> > """
> > Generally, work items are not expected to hog a CPU and consume many
> > cycles. That means maintaining just enough concurrency to prevent
> work
> > processing from stalling should be optimal.
> > """
> >
> > For unbound queues:
> > """
> > The responsibility of regulating concurrency level is on the users.
> > """
> >
> > Given the unbound queues will be spawned on demand to service all
> > queued
> > work items (more interesting when mixing up with the
> > system_unbound_wq),
> > in the proposed design the number of instantiated worker threads does
> > not correspond to the number of user threads (as you have elsewhere
> > stated), but pessimistically to the number of active user contexts.
> >
> >
> > Those are pretty much the same in practice. Rather, user threads is
> > typically an upper bound on the number of contexts. Yes, a single user
> > thread could have a bunch of contexts but basically nothing does that
> > except IGT. In real-world usage, it's at most one context per user
> thread.
>
> Typically is the key here. But I am not sure it is good enough. Consider
> this example - Intel Flex 170:
>
> * Delivers up to 36 streams 1080p60 transcode throughput per card.
> * When scaled to 10 cards in a 4U server configuration, it can support
> up to 360 streams of HEVC/HEVC 1080p60 transcode throughput.
>
I had a feeling it was going to be media
> One transcode stream from my experience typically is 3-4 GPU contexts
> (buffer travels from vcs -> rcs -> vcs, maybe vecs) used from a single
> CPU thread. 4
Re: [PATCH] drm/vc4: Check for valid formats
On Wed, Jan 11, 2023 at 11:32:43AM -0300, Maíra Canal wrote:
> On 1/11/23 10:28, Ville Syrjälä wrote:
> > On Mon, Jan 02, 2023 at 03:20:06PM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 02.01.23 um 14:57 schrieb Maíra Canal:
> > > > Currently, vc4 is not checking valid formats before creating a
> > > > framebuffer, which is triggering the IGT test
> > > > igt@kms_addfb_basic@addfb25-bad-modifier to fail, as vc4 accepts
> > > > to create a framebuffer with an invalid modifier. Therefore, check
> > > > for valid formats before creating framebuffers on vc4 and vc5 in
> > > > order to avoid creating framebuffers with invalid formats.
> > > >
> > > > Signed-off-by: Maíra Canal
> > > > ---
> > > >drivers/gpu/drm/vc4/vc4_kms.c | 23 ++-
> > > >1 file changed, 22 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c
> > > > b/drivers/gpu/drm/vc4/vc4_kms.c
> > > > index 53d9f30460cf..5d1afd66fcc1 100644
> > > > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > > > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > > > @@ -500,6 +500,27 @@ static struct drm_framebuffer
> > > > *vc4_fb_create(struct drm_device *dev,
> > > > mode_cmd = _cmd_local;
> > > > }
> > > >
> > > > + if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
> > > > + mode_cmd->modifier[0])) {
> > > > + drm_dbg_kms(dev, "Unsupported pixel format %p4cc /
> > > > modifier 0x%llx\n",
> > > > + _cmd->pixel_format,
> > > > mode_cmd->modifier[0]);
> > > > + return ERR_PTR(-EINVAL);
> > > > + }
> > >
> > > This might be a stupid question, but why doesn't drm_fbgem_fb_create()
> > > do this test already? It seems like a no-brainer and *not* testing for
> > > the plane formats should be the exception.
> >
> > That was the approach I tried originally but there were a bunch of
> > problems with various drivers it at the time. Dunno if all of those
> > got sorted out or not. IIRC the idea floating around for ancient
> > drivers was to skip the check based on plane->format_default. Looks
> > like we're already using that approach in the setcrtc ioctl.
> >
>
> I ended up following Thomas's idea to check drm_drv_uses_atomic_modesetting()
> in order to check the modifier only for atomic drivers. If you have any
> feedback
> on this idea, I would be glad to hear it. The current version of this patch
> is [1].
>
> [1]
> https://lore.kernel.org/dri-devel/20230109105807.18172-1-mca...@igalia.com/T/
Yeah for atomic drivers the format list better be accurate, so we should
be able to enforce this.
For legacy driver it's a bit a mess, but I'm toying with some ideas how we
could add at least some validation there too. It's just that the audit is
a total pain :-/
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes
On Tue, Jan 10, 2023 at 01:58:52AM +, Kasireddy, Vivek wrote: > Hi Daniel, > > > > > On Fri, Jan 06, 2023 at 09:56:40AM +0100, Gerd Hoffmann wrote: > > > On Thu, Nov 17, 2022 at 05:30:54PM -0800, Vivek Kasireddy wrote: > > > > Setting this property will allow the userspace to look for new modes or > > > > position info when a hotplug event occurs. > > > > > > This works just fine for modes today. > > > > > > I assume this is this need to have userspace also check for position > > > info updates added by patch #1)? > > > > What does this thing even do? Quick grep says qxl and vmwgfx also use > > this, but it's not documented anywhere, and it's also not done with any > > piece of common code. Which all looks really fishy. > [Kasireddy, Vivek] AFAIU, this property appears to be useful only for virtual > GPU drivers to share the Host output(s) layout with the Guest compositor. The > suggested_x/y properties are specifically used for this purpose but it looks > like > the hotplug_mode_update property also needs to be set in order to have Guest > compositors (Mutter cares but Weston does not) look at suggested_x/y. > > > > > I think we need to do a bit of refactoring/documenting here first. > [Kasireddy, Vivek] Just for reference, here is Dave's commit that added this > property for qxl: > commit 4695b03970df378dcb93fe3e7158381f1e980fa2 > Author: Dave Airlie > Date: Fri Oct 11 11:05:00 2013 +1000 > > qxl: add a connector property to denote hotplug should rescan modes. > > So GNOME userspace has an issue with when it rescans for modes on hotplug > events, if the monitor has no EDID it assumes that nothing has changed on > EDID as with real hw we'd never have new modes without a new EDID, and > they > kind off rely on the behaviour now, however with virtual GPUs we would > like to rescan the modes and get a new preferred mode on hotplug events > to handle dynamic guest resizing (where you resize the host window and the > guest resizes with it). Ok this is just terrible. Because _anything_ without an EDID is impacted, and we're certainly not going to sprinkle this property all over gpu drivers just so Gnome takes the right path. Can we fix gnome instead to be slightly less dense about this stuff? > This is a simple property we can make userspace watch for to trigger new > behaviour based on it, and can be used to replaced EDID hacks in virtual > drivers. > > Are you suggesting that this property needs to be part of drm_mode_config > just like suggested_x/y properties? I think this thing shouldn't exist :-) > > Also in principle, userspace needs to look at everything in the connector > > again when it gets a hotplug event. We do have hotplug events for specific > > properties nowadays, but those are fairly new. > [Kasireddy, Vivek] From what I understand, Mutter does probe all the > connector properties during hotplug but it still needs this property to be > set in > order to consider suggested_x/y values. And, it appears, some customers and > users have relied on this behavior from when these properties were first > introduced for virtual GPU drivers. Be more like Weston. Whatever it is mutter does, it doesn't make much sense to me. We can't remove this from existing gpu drivers because no regression guarantee, but we definitely shouldn't add it anywhere. Also can you please document that this is a "do not ever use this in any new driver" kind of property when you go about docementing these? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v1 2/2] drm/virtio: Add the hotplug_mode_update property for rescanning of modes
On Tue, Jan 10, 2023 at 10:28:39AM +0100, Gerd Hoffmann wrote: > On Fri, Jan 06, 2023 at 10:35:15AM +0100, Daniel Vetter wrote: > > On Fri, Jan 06, 2023 at 09:56:40AM +0100, Gerd Hoffmann wrote: > > > On Thu, Nov 17, 2022 at 05:30:54PM -0800, Vivek Kasireddy wrote: > > > > Setting this property will allow the userspace to look for new modes or > > > > position info when a hotplug event occurs. > > > > > > This works just fine for modes today. > > > > > > I assume this is this need to have userspace also check for position > > > info updates added by patch #1)? > > > > What does this thing even do? Quick grep says qxl and vmwgfx also use > > this, but it's not documented anywhere, and it's also not done with any > > piece of common code. Which all looks really fishy. > > It's again a virtualization-specific thing. On physical hardware you > typically have no idea which of your two monitors stands left and which > stands right. On virtual hardware the host knows how the two windows > for the two heads are arranged and can pass on that information to the > guest. suggested_x/y properties added by patch #1 do pass that > information to userspace so the display server can arrange things > correctly without manual invention. Yeah suggested_x/y I know about. Would still be good to fix the documentation situation for that. > I have no clue though why this hotplug_mode_update property exists in > the first place and why mutter checks it. IMHO mutter could just check > for suggested_x/y directly. This one is the complete wtf here. I have no idea why this exists. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [v11] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
On 2022-12-20 05:25:19, Kalyan Thota wrote:
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
>
> Representation: master_flush && (PCC_flush | IGC_flush .. etc )
>
> This change adds necessary support for the above design.
>
> Changes in v1:
> - Few nits (Doug, Dmitry)
> - Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
>
> Changes in v2:
> - Move the address offset to flush macro (Dmitry)
> - Separate ops for the sub block flush (Dmitry)
>
> Changes in v3:
> - Reuse the DPU_DSPP_xx enum instead of a new one (Dmitry)
>
> Changes in v4:
> - Use shorter version for unsigned int (Stephen)
>
> Changes in v5:
> - Spurious patch please ignore.
>
> Changes in v6:
> - Add SOB tag (Doug, Dmitry)
>
> Changes in v7:
> - Cache flush mask per dspp (Dmitry)
> - Few nits (Marijn)
>
> Changes in v8:
> - Few nits (Marijn)
>
> Changes in v9:
> - Use DSPP enum while accessing flush mask to make it readable (Dmitry)
> - Few nits (Dmitry)
>
> Changes in v10:
> - Fix white spaces in a separate patch (Dmitry)
>
> Changes in v11:
> - Define a macro for dspp flush selection (Marijn)
> - Few nits (Marijn)
Please CC the reviewer when you send updated versions of your patches,
so that they don't have to be alerted/requested by others to re-review
the latest version, and scour the lists for where that latest version
is.
Looks much more understandable with the macro, thanks!
I have a few more nits for you below, but beyond that you can have my:
Marijn Suijten
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 ++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 44
> --
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 5 ++-
> 5 files changed, 55 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 601d687..4170fbe 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc
> *crtc)
>
> /* stage config flush mask */
> ctl->ops.update_pending_flush_dspp(ctl,
> - mixer[i].hw_dspp->idx);
> + mixer[i].hw_dspp->idx, DPU_DSPP_PCC);
> }
> }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 27f029f..0eecb2f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -65,7 +65,10 @@
> (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
>
> #define CTL_SC7280_MASK \
> - (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
> BIT(DPU_CTL_VM_CFG))
> + (BIT(DPU_CTL_ACTIVE_CFG) | \
> + BIT(DPU_CTL_FETCH_ACTIVE) | \
> + BIT(DPU_CTL_VM_CFG) | \
> + BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
>
> #define MERGE_3D_SM8150_MASK (0)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index 38aa38a..0e70337 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -161,10 +161,12 @@ enum {
> * DSPP sub-blocks
> * @DPU_DSPP_PCC Panel color correction block
> * @DPU_DSPP_GC Gamma correction block
> + * @DPU_DSPP_IGC Inverse gamma correction block
> */
> enum {
> DPU_DSPP_PCC = 0x1,
> DPU_DSPP_GC,
> + DPU_DSPP_IGC,
> DPU_DSPP_MAX
> };
>
> @@ -191,6 +193,7 @@ enum {
> * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
> * @DPU_CTL_FETCH_ACTIVE:Active CTL for fetch HW (SSPPs)
> * @DPU_CTL_VM_CFG: CTL config to support multiple VMs
> + * @DPU_CTL_DSPP_BLOCK_FLUSH CTL config to support dspp sub-block flush
Missing colon?
> * @DPU_CTL_MAX
> */
> enum {
> @@ -198,6 +201,7 @@ enum {
> DPU_CTL_ACTIVE_CFG,
> DPU_CTL_FETCH_ACTIVE,
> DPU_CTL_VM_CFG,
> + DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
> DPU_CTL_MAX
> };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index a35ecb6..fb2a115 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -33,6 +33,7 @@
> #define CTL_INTF_FLUSH0x110
> #define CTL_INTF_MASTER 0x134
> #define CTL_FETCH_PIPE_ACTIVE 0x0FC
> +#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
Ordering-wise this should've sat before CTL_FETCH_PIPE_ACTIVE, which in
turn should have been in between CTL_INTF_ACTIVE and CTL_MERGE_3D_FLUSH
:/
>
> #define
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, 10 Jan 2023 at 09:46, Boris Brezillon wrote: > > Hi Daniel, > > On Mon, 9 Jan 2023 21:40:21 +0100 > Daniel Vetter wrote: > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > Hi Jason, > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > Jason Ekstrand wrote: > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > wrote: > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote: > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to have a > > > > > > > > > 1 to 1 > > > > > > > > > mapping between a drm_gpu_scheduler and drm_sched_entity. At > > > > > > > > > first > > > > > this > > > > > > > > > seems a bit odd but let us explain the reasoning below. > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple drm_sched_entity > > > > > > > > > is not > > > > > > > > > guaranteed to be the same completion even if targeting the > > > > > > > > > same > > > > > hardware > > > > > > > > > engine. This is because in XE we have a firmware scheduler, > > > > > > > > > the > > > > > GuC, > > > > > > > > > which allowed to reorder, timeslice, and preempt submissions. > > > > > > > > > If a > > > > > using > > > > > > > > > shared drm_gpu_scheduler across multiple drm_sched_entity, > > > > > > > > > the TDR > > > > > falls > > > > > > > > > apart as the TDR expects submission order == completion order. > > > > > Using a > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this > > > > > problem. > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the same sort > > > > > > > > of > > > > > > > > issues to support Arm's new Mali GPU which is relying on a > > > > > FW-assisted > > > > > > > > scheduling scheme (you give the FW N streams to execute, and it > > > > > > > > does > > > > > > > > the scheduling between those N command streams, the kernel > > > > > > > > driver > > > > > > > > does timeslice scheduling to update the command streams passed > > > > > > > > to the > > > > > > > > FW). I must admit I gave up on using drm_sched at some point, > > > > > > > > mostly > > > > > > > > because the integration with drm_sched was painful, but also > > > > > > > > because > > > > > I > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > timeslice-oriented scheduling model wasn't really future proof. > > > > > Giving > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler probably > > > > > might > > > > > > > > help for a few things (didn't think it through yet), but I feel > > > > > > > > it's > > > > > > > > coming short on other aspects we have to deal with on Arm GPUs. > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, and I > > > > > > > think I > > > > > > > have a better understanding of how you get away with using > > > > > > > drm_sched > > > > > > > while still controlling how scheduling is really done. Here > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you use the > > > > > > > drm_sched job queuing/dep/tracking mechanism. The whole run-queue > > > > > > > > > > You nailed it here, we use the DRM scheduler for queuing jobs, > > > > > dependency tracking and releasing jobs to be scheduled when > > > > > dependencies > > > > > are met, and lastly a tracking mechanism of inflights jobs that need > > > > > to > > > > > be cleaned up if an error occurs. It doesn't actually do any > > > > > scheduling > > > > > aside from the most basic level of not overflowing the submission ring > > > > > buffer. In this sense, a 1 to 1 relationship between entity and > > > > > scheduler fits quite well. > > > > > > > > > > > > > Yeah, I think there's an annoying difference between what > > > > AMD/NVIDIA/Intel > > > > want here and what you need for Arm thanks to the number of FW queues > > > > available. I don't remember the exact number of GuC queues but it's at > > > > least 1k. This puts it in an entirely different class from what you > > > > have on > > > > Mali. Roughly, there's about three categories here: > > > > > > > > 1. Hardware where the kernel is placing jobs on actual HW rings. This > > > > is > > > > old Mali, Intel Haswell and earlier, and probably a bunch of others. > > > > (Intel BDW+ with execlists is a weird case that doesn't fit in this > > > > categorization.) > > > > > > > > 2. Hardware (or firmware) with a very limited number of queues where > > > > you're going to have to juggle in the kernel in order to
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917 --- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) --- Can you attach your dmesg output? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917 --- Comment #4 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) --- > Perfect guess! OK.. so we need to find out why this works in 6.1.y and not in 6.0.y. There are some fairly severe bugs it fixed. Is it 100% failure rate on 6.0.y? Since you mentioned that you couldn't effectively use 6.1.y because of the MST issue, are you only finding it on 6.0.y when connected to a dock or anything else unique? > Sadly I don't know how to provide helpful logs. After reboot there's nothing > helpful in /var/log/messages Can you check /var/lib/systemd/pstore? Perhaps there was a kernel crash that got saved into NVRAM and restored by systemd on the next boot. > Just wanted to say THANK YOU for all your help in the last couple of month!!! :) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 3/9] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 35
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 26 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 29 +++-
4 files changed, 70 insertions(+), 23 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 8fac2660e16b..957fa11373fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -100,7 +100,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index be52bf92e847..809b49f59594 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,30 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static i915_reg_t get_kcr_reg(const struct intel_pxp *pxp)
+{
+ if (pxp->gsccs_priv)
+ return MTL_KCR_INIT;
+ return GEN12_KCR_INIT;
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ i915_reg_t reg = get_kcr_reg(pxp);
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, reg, val);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
+}
+
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
+{
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -323,14 +333,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..dd4131903d4e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR enable/disable control */
+#define GEN12_KCR_INIT _MMIO(0x320f0)
+#define MTL_KCR_INIT _MMIO(0x3860f0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define GEN12_KCR_SIP _MMIO(0x32260)
+#define MTL_KCR_SIP _MMIO(0x386260)
+
+/* PXP global terminate register for session termination */
+#define GEN12_KCR_GLOBAL_TERMINATE _MMIO(0x320f8)
+#define MTL_KCR_GLOBAL_TERMINATE _MMIO(0x3860f8)
+
+#endif /* __INTEL_PXP_REGS_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 080aa2209c5b..7bb06e67b155 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++
