Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, sorry for the delay. On 22-08-02, Adam Ford wrote: ... > > > I think that the most important one is the blanking calc. Can you try to > > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > > > if you can get a output still? Also something to try would be to disable > > > the internal timing generator by specifying > > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for > > I did some reading about the internal timing generator. It appears > that it's required when video formats use fractional bytes, and it's > preconfigured to run at 720p by default, but registers 28h through 37h > configure it for other video modes. I thought this timing generator can detect the sync timing automatically. Also I saw some mail discussions where this timing generator can trigger missbehaviours. Since we send the sync packages from the dsi-host to the ADV, I think it should be possible for the ADV to reconstruct the sync signals without the need of the internal timing generator. > Are you thinking the imx8mm DSI generator would do it better? You mean the porches we are sending? Regards, Marco
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Tue, Aug 2, 2022 at 8:51 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > > > Hi Adam, Fabio, > > > > > > On 22-08-01, Adam Ford wrote: > > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > > > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > > > > 1080p. I haven't yet been able to get other modes to work. > > > > > > > > > > Ok, good. On another thread, you mentioned that you were also trying > > > > > to get LVDS to work via SN65DSI83. > > > > > > > > > > Does LVDS work for you on this branch? > > > > > > > > I haven't tried with Marek's latest suggestion. In the other thread > > > > he mentioned a burst mode and setting the DSI speeds to higher > > > > frequencies, but the patch he had didn't look like it would apply > > > > cleanly, so I will need to dig into that a bit further. > > > > > > Can you provide me a link to this thread? > > > > Sure, > > > > https://www.spinics.net/lists/dri-devel/msg358301.html > > > > > > > > > Since my company doesn't really ship the LVDS displays with the kits, > > > > the HDMI is the default video, so I've been focusing on it. > > > > > > > > To answer Marco's question, I was able to revert "MLK-21958-13: > > > > drm/bridge: adv7511: Limit supported clocks" and still get a display > > > > at 1080p, but all the other resolutions I tried appear to come up > > > > blank. > > > > > > Cool so now you have the same state as we are. > > > > I have a couple patches applied to mine which mimic some of the stuff > > that NXP did. Since I have access to a programmer manual, i was able > > to confirm some of the 7535 specific stuff and the low-refresh rate > > changes in their kernel appear appropriate and I also created a second > > table of default settings for the 7535 and if the type is set > > properly, i'll use the newer table instead of the older one. If anyone > > wants any of these patches, I can certainly share them, but I am not > > certain they make any difference. > > > > There are a few other items in the programmer manual that I want to > > attempt to implement once I have a chance to further review the > > document. > > > > > > > > I think that the most important one is the blanking calc. Can you try to > > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > > > if you can get a output still? Also something to try would be to disable > > > the internal timing generator by specifying > > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for > > I did some reading about the internal timing generator. It appears > that it's required when video formats use fractional bytes, and it's > preconfigured to run at 720p by default, but registers 28h through 37h > configure it for other video modes. I think there may still be some issues with the DSIM since some of the clock frequencies are set in the device tree. >From what I can tell, the pixel rate is calculated based on the burst-clock-frequency and that generates a byte clock. For 89100, the byte clock is 111375000. Modetest timings for 1080p show: index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: nhsync, nvsync; type: driver When looking at modetest, there is a clock for 1080p which appears to be 148500. 111375000/148500 = 750. The rest of the entries in my table do not divide evenly. I don;t know if that explains the lack of display, but it's something to note. It seems to me that instead of fixing the samsung,burst-clock-frequency to 89100, we should make the desired PLL related to the desired pixel clock so it divides evenly. Looking at NXP's kernel, I also noticed that their esc_prescaler is based on the byte clock divided by 20MHz. With some small code changes to get the PLL based on the desired pixel clock instead of hard-coded, I was able to set samsung,burst-clock-frequency = <15>; samsung,esc-clock-frequency = <2000>; With these settings and the above mentioned code changes, 1080p still appears, however when attempting other modes, the display still fails to load. I also noticed that the phy ref clock is set to 27MHz instead of NXP's 12MHz. I attempted to play with that setting, but I couldn't get 1080p to work again, so I backed it out. Maybe I am headed in the wrong direction, but I'm going to examine the P/M/S calculation of the timing on NXP's kernel to see how the DSIM in this code compares. If someone who understands the interactions between these different components has suggestions, I'm willing to run some experiments. adam > > Are you thinking the imx8mm DSI generator would do it better? > > > > such frequencies you can check the hdmi clk-lane. I
Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Hi Thomas, I am honestly surprised of the e-mail back and forth regarding the mainlining of OpenChrome DRM, but let me state my position. Considering the age of the hardware I am dealing with (i.e., pre-OpenGL 2.x generation 3D engine), I do not anticipate being able to run OpenChrome on Wayland with acceleration. As a first step after mainlining, I am looking to add uAPI to pass 2D / 3D acceleration commands to the graphics engine, but frankly, I am going to focus on the 2D acceleration side first. Considering the age of the hardware, I do not think limiting the use to X.Org X Server is a bad choice. I do OpenChrome development on Gentoo Linux where 32-bit x86 ISA and X.Org X Server are still fully supported. Adding 3D acceleration will likely be done after 2D and video accelerations are mostly working. The proposed OpenChrome uAPI is essentially a cutdown version of the mostly 2D acceleration focused implementation (my opinion) being worked on and off since 2011. The limited addition of uAPI calls is merely a preparatory step for adding 2D acceleration in the near future (I have not started the work yet.). I assume you are aware that OpenChrome DDX is a user of DRM_VIA_GEM_CREATE, DRM_VIA_GEM_MAP, and DRM_VIA_GEM_UNMAP uAPIs. For those who still choose to use older generation hardware, I think X.Org X Server still has a lot of life left in it, and I plan to continue modernizing the graphics stack for what I call "underserved" (i.e., neglected) graphics hardware. Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com > Sent: Tuesday, August 02, 2022 at 4:38 AM > From: "Thomas Zimmermann" > To: "Kevin Brace" > Cc: dri-devel@lists.freedesktop.org > Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h > > Hi > > Am 02.08.22 um 05:45 schrieb Kevin Brace: > > Hi Thomas, > > > > I hope I am comprehending this right. > > Yes, I am adding 3 new uAPI calls, not 6 of them. > > Correspondingly, there are 3 new structs added. > > That's understood. > > > While I may drop one (unmap uAPI), I personally do not wish to drop the > > other two at this point. > > Instead, I may need to add setparam and / or getparam uAPI to pass PCI > > Device ID back to the userspace. > > This is mainly needed by Mesa, although there is no code for Mesa at this > > point. > > Exactly my point! There's no userspace for it. That's why Sam and me are > asking you to remove all kinds if uapi changes or ioctls from the > patchset until Mesa (or some other component) requires it. > > > I fear dropping the remaining two will require substantial redesign, and I > > will like to avoid this since the code is already working. > > No, it won't require a redesign. You'll have to remove the changes to > the uapi header and any new ioctls that are in the patchset. Userspace > programs; such as X11's modesetting driver, Weston or Gnome; will use > the kernel's dumb-buffer ioctls to create unaccelerated buffers. You > won't need any via-specific code in userspace. It's all there already > and fully driver independent. Mesa will do software rendering. For the > kernel's dumb buffers, please see [1]. > > > It is my plan to proceed to adding acceleration after the code is added to > > the mainline kernel tree, so I will like to do it the way it is set up now. > > You can still send the current uapi changes when you add 3d acceleration > to the kernel and Mesa. But once these interfaces have been added to > the kernel, they are nearly impossible to change or remove. That's why > we don't want to do this now. > > Best regards > Thomas > > [1] > https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#dumb-buffer-objects > > > > > Regards, > > > > Kevin Brace > > Brace Computer Laboratory blog > > https://bracecomputerlab.com > > > > > >> Sent: Monday, August 01, 2022 at 11:49 AM > >> From: "Thomas Zimmermann" > >> To: "Kevin Brace" > >> Cc: dri-devel@lists.freedesktop.org > >> Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h > >> > >> Hi Kevin > >> > >> Am 31.07.22 um 00:48 schrieb Kevin Brace: > >>> Hi Thomas, > >>> > >>> I cannot drop the older DRI1 based uAPI calls. > >>> This is because include/uapi/drm/via_drm.h needs to retain backward > >>> compatibility with the existing OpenChrome DDX's XvMC library (it gets > >>> compiled when OpenChrome DDX is built) and likely with the existing DDX > >>> Xv code as well. > >>> If I remove the DRI1 based uAPI calls, the XvMC library will not get > >>> compiled (compile error will occur since the XvMC library assumes the > >>> presence of DRI1 based uAPI), and I assume the same for the DDX Xv code > >>> (I cannot even reach here since the XvMC library is compiled first). > >>> Although the v3 patch does not contain it, v4 patch will utilize > >>> drm_invalid_op() for the discontinued (not deprecated since OpenChrome > >>> DRM does not support the older DRI1 based uAPI at all) DRI1 based uAPI. > >>> > >>>
Re: [PATCH 1/7] drm/i915/guc: Add a helper for log buffer size
On 8/2/2022 10:37, Teres Alexis, Alan Previn wrote:
Something minor in comments, so conditional R-B (please fix on the way in or
reply to correct me):
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:
From: Alan Previn
Add a helper to get GuC log buffer size.
Signed-off-by: Alan Previn
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 49 --
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 25b2d7ce6640d..492bbf419d4df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -15,6 +15,32 @@
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
+static u32 intel_guc_log_size(struct intel_guc_log *log)
+{
+ /*
+* GuC Log buffer Layout:
+*
+* NB: Ordering must follow "enum guc_log_buffer_type".
+*
+* +===+ 00B
+* | Debug state header |
+* +---+ 32B
Something we might have missed in prior updates but i think the bufer state is
now 36 bytes long no? (9 dwords).
Good catch. Yes, an extra word was added some while back.
John.
+* |Crash dump state header|
+* +---+ 64B
+* | Capture state header |
+* +---+ 96B
+* | |
+* +===+ PAGE_SIZE (4KB)
+* | Debug logs |
+* +===+ + DEBUG_SIZE
+* |Crash Dump logs|
+* +===+ + CRASH_SIZE
+* | Capture logs |
+* +===+ + CAPTURE_SIZE
+*/
+ return PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +
CAPTURE_BUFFER_SIZE;
+}
+
/**
* DOC: GuC firmware log
*
@@ -461,32 +487,11 @@ int intel_guc_log_create(struct intel_guc_log *log)
GEM_BUG_ON(log->vma);
- /*
-* GuC Log buffer Layout
-* (this ordering must follow "enum guc_log_buffer_type" definition)
-*
-* +===+ 00B
-* | Debug state header |
-* +---+ 32B
-* |Crash dump state header|
-* +---+ 64B
-* | Capture state header |
-* +---+ 96B
-* | |
-* +===+ PAGE_SIZE (4KB)
-* | Debug logs |
-* +===+ + DEBUG_SIZE
-* |Crash Dump logs|
-* +===+ + CRASH_SIZE
-* | Capture logs |
-* +===+ + CAPTURE_SIZE
-*/
if (intel_guc_capture_output_min_size_est(guc) > CAPTURE_BUFFER_SIZE)
DRM_WARN("GuC log buffer for state_capture maybe too small. %d <
%d\n",
CAPTURE_BUFFER_SIZE,
intel_guc_capture_output_min_size_est(guc));
- guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +
- CAPTURE_BUFFER_SIZE;
+ guc_log_size = intel_guc_log_size(log);
vma = intel_guc_allocate_vma(guc, guc_log_size);
if (IS_ERR(vma)) {
--
2.37.1
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Record CTB info in error logs
On 8/2/2022 11:27, Teres Alexis, Alan Previn wrote:
One minor NIT (though i hope it could be fixed otw in as it adds a bit of
ease-of-log-readibility).
That said, everything else looks good.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
From: John Harrison
When debugging GuC communication issues, it is useful to have the CTB
info available. So add the state and buffer contents to the error
capture log.
Also, add a sub-structure for the GuC specific error capture info as
it is now becoming numerous.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 59 +++
drivers/gpu/drm/i915/i915_gpu_error.h | 20 +++--
2 files changed, 67 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index addba75252343..543ba63f958ea 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -671,6 +671,18 @@ static void err_print_pciid(struct
drm_i915_error_state_buf *m,
pdev->subsystem_device);
}
+static void err_print_guc_ctb(struct drm_i915_error_state_buf *m,
+ const char *name,
+ const struct intel_ctb_coredump *ctb)
+{
+ if (!ctb->size)
+ return;
+
+ err_printf(m, "GuC %s CTB: raw: 0x%08X, 0x%08X/%08X, cached: 0x%08X/%08X,
desc = 0x%08X, buf = 0x%08X x 0x%08X\n",
+ name, ctb->raw_status, ctb->raw_head, ctb->raw_tail,
+ ctb->head, ctb->tail, ctb->desc_offset, ctb->cmds_offset,
ctb->size);
NIT: to make it more readible on first glance, would be nice to add more descriptive
text like "raw: Sts:0x%08X,
Hd:0x%08X,Tl:0x@08X..." also, the not sure why cmds_offset is presented with a "x
size" as opposed to just "desc-off =
foo1, cmd-off = foo2, size = foo3"?
The line is long enough as it is. I'd rather not make it even longer.
Same for ': x ' rather than ' _addr =
, _size = '. It's useful for readability to keep a
single CTB channel on a single line but not if that line is excessively
long.
John.
+}
+
static void err_print_uc(struct drm_i915_error_state_buf *m,
const struct intel_uc_coredump *error_uc)
{
@@ -678,8 +690,12 @@ static void err_print_uc(struct drm_i915_error_state_buf
*m,
intel_uc_fw_dump(_uc->guc_fw, );
intel_uc_fw_dump(_uc->huc_fw, );
- err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->timestamp);
- intel_gpu_error_print_vma(m, NULL, error_uc->guc_log);
+ err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->guc.timestamp);
+ intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_log);
+ err_printf(m, "GuC CTB fence: %d\n", error_uc->guc.last_fence);
+ err_print_guc_ctb(m, "Send", error_uc->guc.ctb + 0);
+ err_print_guc_ctb(m, "Recv", error_uc->guc.ctb + 1);
+ intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_ctb);
}
static void err_free_sgl(struct scatterlist *sgl)
@@ -854,7 +870,7 @@ static void __err_print_to_sgl(struct
drm_i915_error_state_buf *m,
if (error->gt) {
bool print_guc_capture = false;
- if (error->gt->uc && error->gt->uc->is_guc_capture)
+ if (error->gt->uc && error->gt->uc->guc.is_guc_capture)
print_guc_capture = true;
err_print_gt_display(m, error->gt);
@@ -1009,7 +1025,8 @@ static void cleanup_uc(struct intel_uc_coredump *uc)
{
kfree(uc->guc_fw.path);
kfree(uc->huc_fw.path);
- i915_vma_coredump_free(uc->guc_log);
+ i915_vma_coredump_free(uc->guc.vma_log);
+ i915_vma_coredump_free(uc->guc.vma_ctb);
kfree(uc);
}
@@ -1658,6 +1675,23 @@ gt_record_engines(struct intel_gt_coredump *gt,
}
}
+static void gt_record_guc_ctb(struct intel_ctb_coredump *saved,
+ const struct intel_guc_ct_buffer *ctb,
+ const void *blob_ptr, struct intel_guc *guc)
+{
+ if (!ctb || !ctb->desc)
+ return;
+
+ saved->raw_status = ctb->desc->status;
+ saved->raw_head = ctb->desc->head;
+ saved->raw_tail = ctb->desc->tail;
+ saved->head = ctb->head;
+ saved->tail = ctb->tail;
+ saved->size = ctb->size;
+ saved->desc_offset = ((void *)ctb->desc) - blob_ptr;
+ saved->cmds_offset = ((void *)ctb->cmds) - blob_ptr;
+}
+
static struct intel_uc_coredump *
gt_record_uc(struct intel_gt_coredump *gt,
struct i915_vma_compress *compress)
@@ -1684,9 +1718,16 @@ gt_record_uc(struct intel_gt_coredump *gt,
* log times to system times (in conjunction with the error->boottime
and
* gt->clock_frequency fields saved elsewhere).
*/
- error_uc->timestamp = intel_uncore_read(gt->_gt->uncore,
GUCPMTIMESTAMP);
- error_uc->guc_log = create_vma_coredump(gt->_gt,
Re: [Intel-gfx] [PATCH 5/7] drm/i915/guc: Use streaming loads to speed up dumping the guc log
On 8/2/2022 11:48, Teres Alexis, Alan Previn wrote:
One concern below. Else, nice, simple yet good optimization here. :)
In the interest of quicker progression, I will provide a conditional R-B if you
can either fix the issue raised below on
the way in or provide a reason why that's not an issue:
Not an issue, but code changes like that can't be 'fixed on the way in'.
Tweaking a commit message can potentially happen when merging patches
but not code changes. For that you have to repost for CI.
John.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
From: Chris Wilson
Use a temporary page and mempy_from_wc to reduce the time it takes to
dump the guc log to debugfs.
Signed-off-by: Chris Wilson
Signed-off-by: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 --
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 07d31ae32f765..4722d4b18ed19 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -750,8 +750,9 @@ int intel_guc_log_dump(struct intel_guc_log *log, struct
drm_printer *p,
struct intel_guc *guc = log_to_guc(log);
struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct drm_i915_gem_object *obj = NULL;
- u32 *map;
- int i = 0;
+ void *map;
+ u32 *page;
+ int i, j;
if (!intel_guc_is_supported(guc))
return -ENODEV;
@@ -764,23 +765,34 @@ int intel_guc_log_dump(struct intel_guc_log *log, struct
drm_printer *p,
if (!obj)
return 0;
+ page = (u32 *)__get_free_page(GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
Alan: although unlikely, its possible that user could trigger debugfs mid of a
gt reset - not sure if we need to use the
"uc->reset_in_progress" before calling this allocation and return a different
error in that case like EAGAIN or EBUSY or
ECONNRESET.
Doesn't matter.
The issue of thou shalt not allocate memory during a reset is only
relevant to code that can be called from within the reset path. As in,
you must not do something that could block the reset from completing.
This is only debugfs code. It is not called from within the reset path.
So if it gets blocked waiting for memory to be released, no-one cares.
John.
+
intel_guc_dump_time_info(guc, p);
map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(map)) {
DRM_DEBUG("Failed to pin object\n");
drm_puts(p, "(log data unaccessible)\n");
+ free_page((unsigned long)page);
return PTR_ERR(map);
}
- for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
- drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
- *(map + i), *(map + i + 1),
- *(map + i + 2), *(map + i + 3));
+ for (i = 0; i < obj->base.size; i += PAGE_SIZE) {
+ if (!i915_memcpy_from_wc(page, map + i, PAGE_SIZE))
+ memcpy(page, map + i, PAGE_SIZE);
+
+ for (j = 0; j < PAGE_SIZE / sizeof(u32); j += 4)
+ drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+ *(page + j + 0), *(page + j + 1),
+ *(page + j + 2), *(page + j + 3));
+ }
drm_puts(p, "\n");
i915_gem_object_unpin_map(obj);
+ free_page((unsigned long)page);
return 0;
}
--
2.37.1
[PATCH v3 5/6] drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const()
As of the commit 1de452a0edda ("regulator: core: Allow drivers to
define their init data as const") we no longer need to do copying of
regulator bulk data from initdata to something dynamic. Let's take
advantage of that.
In addition to saving some code, this also moves us to using
ARRAY_SIZE() to specify how many regulators we have which is less
error prone.
This gets rid of some layers of wrappers which makes it obvious that
we can get rid of an extra error print.
devm_regulator_bulk_get_const() prints errors for you so you don't
need an extra layer of printing.
In all cases here I have preserved the old settings without any
investigation about whether the loads being set are sensible. In the
cases of some of the PHYs if several PHYs in the same file used
exactly the same settings I had them point to the same data structure.
NOTE: Though I haven't done the math, this is likely an overall
savings in terms of "static const" data. We previously always
allocated space for 8 supplies. Each of these supplies took up 36
bytes of data (32 for name, 4 for an int).
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Do all the PHYs too.
- Get rid of error print after devm_regulator_bulk_get_const().
- Just directly call the bulk commands; get rid of the wrapper.
- Update commit message to point at the git hash of the regulator change.
Changes in v2:
- ("Take advantage of devm_regulator_bulk_get_const") new for v2.
drivers/gpu/drm/msm/dsi/dsi.h | 12 --
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +-
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 3 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 42 ++---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 37 +---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 5 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 20 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 32 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 14 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 28 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 12 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 32 ++--
12 files changed, 167 insertions(+), 242 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index bb6a5bd05cb1..d661510d570d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -30,20 +30,8 @@ enum msm_dsi_phy_usecase {
MSM_DSI_PHY_SLAVE,
};
-#define DSI_DEV_REGULATOR_MAX 8
#define DSI_BUS_CLK_MAX4
-/* Regulators for DSI devices */
-struct dsi_reg_entry {
- char name[32];
- int enable_load;
-};
-
-struct dsi_reg_config {
- int num;
- struct dsi_reg_entry regs[DSI_DEV_REGULATOR_MAX];
-};
-
struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 901d6fd53800..7e97c239ed48 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -9,16 +9,16 @@ static const char * const dsi_v2_bus_clk_names[] = {
"core_mmss", "iface", "bus",
};
+static const struct regulator_bulk_data apq8064_dsi_regulators[] = {
+ { .supply = "vdda", .init_load_uA = 10 }, /* 1.2 V */
+ { .supply = "avdd", .init_load_uA = 1 },/* 3.0 V */
+ { .supply = "vddio", .init_load_uA = 10 }, /* 1.8 V */
+};
+
static const struct msm_dsi_config apq8064_dsi_cfg = {
.io_offset = 0,
- .reg_cfg = {
- .num = 3,
- .regs = {
- {"vdda", 10}, /* 1.2 V */
- {"avdd", 1},/* 3.0 V */
- {"vddio", 10}, /* 1.8 V */
- },
- },
+ .regulator_data = apq8064_dsi_regulators,
+ .num_regulators = ARRAY_SIZE(apq8064_dsi_regulators),
.bus_clk_names = dsi_v2_bus_clk_names,
.num_bus_clks = ARRAY_SIZE(dsi_v2_bus_clk_names),
.io_start = { 0x470, 0x580 },
@@ -29,16 +29,16 @@ static const char * const dsi_6g_bus_clk_names[] = {
"mdp_core", "iface", "bus", "core_mmss",
};
+static const struct regulator_bulk_data msm8974_apq8084_regulators[] = {
+ { .supply = "vdd", .init_load_uA = 15 },/* 3.0 V */
+ { .supply = "vdda", .init_load_uA = 10 }, /* 1.2 V */
+ { .supply = "vddio", .init_load_uA = 10 }, /* 1.8 V */
+};
+
static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
- .reg_cfg = {
- .num = 3,
- .regs = {
- {"vdd", 15},/* 3.0 V */
- {"vdda", 10}, /* 1.2 V */
- {"vddio", 10}, /* 1.8 V */
- },
- },
+ .regulator_data = msm8974_apq8084_regulators,
+ .num_regulators = ARRAY_SIZE(msm8974_apq8084_regulators),
[PATCH v3 6/6] drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling
The dsi_phy_driver_probe() function has a "goto fail" for no
reason. Change it to just always return directly when it sees an
error. Make this simpler by leveraging dev_err_probe() which is
designed to make code like this shorter / simpler.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- ("Improve dsi_phy_driver_probe() probe error handling") new for v3.
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 74 ++-
1 file changed, 27 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 0a00f9b73fc5..57cd525de7a1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -621,12 +621,9 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
phy->pdev = pdev;
phy->id = dsi_phy_get_id(phy);
- if (phy->id < 0) {
- ret = phy->id;
- DRM_DEV_ERROR(dev, "%s: couldn't identify PHY index, %d\n",
- __func__, ret);
- goto fail;
- }
+ if (phy->id < 0)
+ return dev_err_probe(dev, phy->id,
+"Couldn't identify PHY index\n");
phy->regulator_ldo_mode = of_property_read_bool(dev->of_node,
"qcom,dsi-phy-regulator-ldo-mode");
@@ -634,88 +631,71 @@ static int dsi_phy_driver_probe(struct platform_device
*pdev)
phy->cphy_mode = (phy_type == PHY_TYPE_CPHY);
phy->base = msm_ioremap_size(pdev, "dsi_phy", >base_size);
- if (IS_ERR(phy->base)) {
- DRM_DEV_ERROR(dev, "%s: failed to map phy base\n", __func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->base))
+ return dev_err_probe(dev, PTR_ERR(phy->base),
+"Failed to map phy base\n");
phy->pll_base = msm_ioremap_size(pdev, "dsi_pll", >pll_size);
- if (IS_ERR(phy->pll_base)) {
- DRM_DEV_ERROR(>dev, "%s: failed to map pll base\n",
__func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->pll_base))
+ return dev_err_probe(dev, PTR_ERR(phy->pll_base),
+"Failed to map pll base\n");
if (phy->cfg->has_phy_lane) {
phy->lane_base = msm_ioremap_size(pdev, "dsi_phy_lane",
>lane_size);
- if (IS_ERR(phy->lane_base)) {
- DRM_DEV_ERROR(>dev, "%s: failed to map phy lane
base\n", __func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->lane_base))
+ return dev_err_probe(dev, PTR_ERR(phy->lane_base),
+"Failed to map phy lane base\n");
}
if (phy->cfg->has_phy_regulator) {
phy->reg_base = msm_ioremap_size(pdev, "dsi_phy_regulator",
>reg_size);
- if (IS_ERR(phy->reg_base)) {
- DRM_DEV_ERROR(>dev, "%s: failed to map phy
regulator base\n", __func__);
- ret = -ENOMEM;
- goto fail;
- }
+ if (IS_ERR(phy->reg_base))
+ return dev_err_probe(dev, PTR_ERR(phy->reg_base),
+"Failed to map phy regulator
base\n");
}
if (phy->cfg->ops.parse_dt_properties) {
ret = phy->cfg->ops.parse_dt_properties(phy);
if (ret)
- goto fail;
+ return ret;
}
ret = devm_regulator_bulk_get_const(dev, phy->cfg->num_regulators,
phy->cfg->regulator_data,
>supplies);
if (ret)
- goto fail;
+ return ret;
phy->ahb_clk = msm_clk_get(pdev, "iface");
- if (IS_ERR(phy->ahb_clk)) {
- DRM_DEV_ERROR(dev, "%s: Unable to get ahb clk\n", __func__);
- ret = PTR_ERR(phy->ahb_clk);
- goto fail;
- }
+ if (IS_ERR(phy->ahb_clk))
+ return dev_err_probe(dev, PTR_ERR(phy->ahb_clk),
+"Unable to get ahb clk\n");
/* PLL init will call into clk_register which requires
* register access, so we need to enable power and ahb clock.
*/
ret = dsi_phy_enable_resource(phy);
if (ret)
- goto fail;
+ return ret;
if (phy->cfg->ops.pll_init) {
ret = phy->cfg->ops.pll_init(phy);
- if (ret) {
- DRM_DEV_INFO(dev,
- "%s: pll init failed: %d, need separate pll clk
driver\n",
- __func__, ret);
- goto fail;
-
[PATCH v3 4/6] drm/msm/dsi: Use the new regulator bulk feature to specify the load
As of commit 6eabfc018e8d ("regulator: core: Allow specifying an
initial load w/ the bulk API") we can now specify the initial load in
the bulk data rather than having to manually call regulator_set_load()
on each regulator. Let's use it.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Update commit message to point at the git hash of the regulator change.
Changes in v2:
- ("Use the new regulator bulk feature to specify the load") new for v2.
drivers/gpu/drm/msm/dsi/dsi_host.c| 13 +++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 13 +++--
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 9df278d39559..a0a1b6d61d05 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -260,8 +260,10 @@ static int dsi_regulator_init(struct msm_dsi_host
*msm_host)
int num = msm_host->cfg_hnd->cfg->reg_cfg.num;
int i, ret;
- for (i = 0; i < num; i++)
+ for (i = 0; i < num; i++) {
s[i].supply = regs[i].name;
+ s[i].init_load_uA = regs[i].enable_load;
+ }
ret = devm_regulator_bulk_get(_host->pdev->dev, num, s);
if (ret < 0) {
@@ -270,15 +272,6 @@ static int dsi_regulator_init(struct msm_dsi_host
*msm_host)
return ret;
}
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
-regs[i].enable_load);
- if (ret < 0)
- return ret;
- }
- }
-
return 0;
}
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 7c105120d73e..efb6b1726cdb 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -515,8 +515,10 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
int num = phy->cfg->reg_cfg.num;
int i, ret;
- for (i = 0; i < num; i++)
+ for (i = 0; i < num; i++) {
s[i].supply = regs[i].name;
+ s[i].init_load_uA = regs[i].enable_load;
+ }
ret = devm_regulator_bulk_get(dev, num, s);
if (ret < 0) {
@@ -529,15 +531,6 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
return ret;
}
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
- regs[i].enable_load);
- if (ret < 0)
- return ret;
- }
- }
-
return 0;
}
--
2.37.1.455.g008518b4e5-goog
[PATCH v3 2/6] drm/msm/dsi: Fix number of regulators for SDM660
1 regulators is specified listed but the number 2 is specified. This
presumably means we try to get a regulator with no name. Fix it.
Fixes: 033f47f7f121 ("drm/msm/dsi: Add DSI configuration for SDM660")
Signed-off-by: Douglas Anderson
---
(no changes since v2)
Changes in v2:
- ("Fix number of regulators for SDM660") new for v2.
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 02000a7b7a18..72c018e26f47 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -148,7 +148,7 @@ static const char * const dsi_sdm660_bus_clk_names[] = {
static const struct msm_dsi_config sdm660_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
- .num = 2,
+ .num = 1,
.regs = {
{"vdda", 12560, 4 },/* 1.2 V */
},
--
2.37.1.455.g008518b4e5-goog
[PATCH v3 3/6] drm/msm/dsi: Don't set a load before disabling a regulator
As of commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually doing anything
useful. Let's remove it.
It should be noted that all of the loads set that were being specified
were pointless noise anyway. The only use for this number is to pick
between low power and high power modes of regulators. Regulators
appear to do this changeover at loads on the order of 1 uA. You
would need a lot of clients of the same rail for that 100 uA number to
count for anything.
Note that now that we get rid of the setting of the load at disable
time, we can just set the load once when we first get the regulator
and then forget it.
It should also be noted that the regulator functions
regulator_bulk_enable() and regulator_set_load() already print error
messages when they encounter problems so while moving things around we
get rid of some extra error prints.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Fix typo in commit message.
- Just directly call the bulk commands; get rid of the wrapper.
drivers/gpu/drm/msm/dsi/dsi.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 52 +++---
drivers/gpu/drm/msm/dsi/dsi_host.c| 71 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 52 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 4 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 6 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 4 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 6 +-
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 2 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 6 +-
10 files changed, 60 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 580a1e6358bf..bb6a5bd05cb1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -37,7 +37,6 @@ enum msm_dsi_phy_usecase {
struct dsi_reg_entry {
char name[32];
int enable_load;
- int disable_load;
};
struct dsi_reg_config {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 72c018e26f47..901d6fd53800 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -14,9 +14,9 @@ static const struct msm_dsi_config apq8064_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
- {"vdda", 10, 100}, /* 1.2 V */
- {"avdd", 1, 100}, /* 3.0 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"avdd", 1},/* 3.0 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_v2_bus_clk_names,
@@ -34,9 +34,9 @@ static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
.reg_cfg = {
.num = 3,
.regs = {
- {"vdd", 15, 100}, /* 3.0 V */
- {"vdda", 10, 100}, /* 1.2 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdd", 15},/* 3.0 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_6g_bus_clk_names,
@@ -54,8 +54,8 @@ static const struct msm_dsi_config msm8916_dsi_cfg = {
.reg_cfg = {
.num = 2,
.regs = {
- {"vdda", 10, 100}, /* 1.2 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_8916_bus_clk_names,
@@ -73,8 +73,8 @@ static const struct msm_dsi_config msm8976_dsi_cfg = {
.reg_cfg = {
.num = 2,
.regs = {
- {"vdda", 10, 100}, /* 1.2 V */
- {"vddio", 10, 100}, /* 1.8 V */
+ {"vdda", 10}, /* 1.2 V */
+ {"vddio", 10}, /* 1.8 V */
},
},
.bus_clk_names = dsi_8976_bus_clk_names,
@@ -88,12 +88,12 @@ static const struct msm_dsi_config msm8994_dsi_cfg = {
.reg_cfg = {
.num = 6,
.regs = {
- {"vdda", 10, 100}, /* 1.25 V */
- {"vddio", 10, 100}, /* 1.8 V */
- {"vcca", 1, 100}, /* 1.0 V */
- {"vdd", 10, 100}, /* 1.8 V */
- {"lab_reg", -1, -1},
- {"ibb_reg", -1, -1},
+
[PATCH v3 1/6] drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg
3 regulators are specified listed but the number 2 is specified. Fix
it.
Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 info in dsi_cfg")
Signed-off-by: Douglas Anderson
---
(no changes since v2)
Changes in v2:
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 2c23324a2296..02000a7b7a18 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -109,7 +109,7 @@ static const char * const dsi_8996_bus_clk_names[] = {
static const struct msm_dsi_config msm8996_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
- .num = 2,
+ .num = 3,
.regs = {
{"vdda", 18160, 1 },/* 1.25 V */
{"vcca", 17000, 32 }, /* 0.925 V */
--
2.37.1.455.g008518b4e5-goog
[PATCH v3 0/6] drm/msm/dsi regulator improvements
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads for DSI drivers.
As of v3 of this series, the regulator API improvements needed for the
later patches in the series are merged into mainline. Thus this series
only contains the DSI changes now.
I'd expect:
* The first two patches are bugfixes found while converting the DSI
driver over. Those could land any time.
* The third patch ("drm/msm/dsi: Don't set a load before disabling a
regulator") is a patch a sent the other day verbatim, included in
this series because it's highly related. It could land any
time.
* The next two patches use the new APIs. Since those APIs are now in
mainline those could also land any time.
* The last patch is just cleanup I noticed as I was touching the
function. It's not really related to regulators but it applies atop
these. In theory it could be rebased to land separately.
Changes in v3:
- ("Improve dsi_phy_driver_probe() probe error handling") new for v3.
- Do all the PHYs too.
- Fix typo in commit message.
- Get rid of error print after devm_regulator_bulk_get_const().
- Just directly call the bulk commands; get rid of the wrapper.
- Update commit message to point at the git hash of the regulator change.
Changes in v2:
- ("Fix number of regulators for SDM660") new for v2.
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
- ("Take advantage of devm_regulator_bulk_get_const") new for v2.
- ("Use the new regulator bulk feature to specify the load") new for v2.
Douglas Anderson (6):
drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg
drm/msm/dsi: Fix number of regulators for SDM660
drm/msm/dsi: Don't set a load before disabling a regulator
drm/msm/dsi: Use the new regulator bulk feature to specify the load
drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const()
drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling
drivers/gpu/drm/msm/dsi/dsi.h | 13 --
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 172 +-
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 3 +-
drivers/gpu/drm/msm/dsi/dsi_host.c| 96 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 160
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 5 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 20 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 32 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c| 14 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 28 +--
.../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 12 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 32 ++--
12 files changed, 197 insertions(+), 390 deletions(-)
--
2.37.1.455.g008518b4e5-goog
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gt: document TLB cache invalidation functions
On Fri, Jul 29, 2022 at 09:03:55AM +0200, Mauro Carvalho Chehab wrote:
Add a description for the TLB cache invalidation algorithm and for
the related kAPI functions.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 0/2] at:
https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/
Documentation/gpu/i915.rst | 7 ++
drivers/gpu/drm/i915/gt/intel_tlb.c | 25 +++
drivers/gpu/drm/i915/gt/intel_tlb.h | 101
3 files changed, 133 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..46911fdd79e8 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
+TLB cache invalidation
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
+
Workarounds
---
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index af8cae979489..4873b7ecc015 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
}
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
+ * @seqno: sequence number
+ *
+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
+ * full TLB cache invalidation.
+ *
+ * Note:
+ * The TLB cache invalidation logic depends on GEN-specific registers.
+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
+ */
void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
{
intel_wakeref_t wakeref;
@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
u32 seqno)
}
}
+/**
+ * intel_gt_init_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * TLB cache invalidation logic internally uses some resources that require
+ * initialization. Should be called before doing any TLB cache invalidation.
+ */
void intel_gt_init_tlb(struct intel_gt *gt)
{
mutex_init(>tlb.invalidate_lock);
seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
}
+/**
+ * intel_gt_fini_tlb - initialize TLB-specific vars
Free TLB-specific vars
+ * @gt: GT structure
+ *
+ * Frees any resources needed by TLB cache invalidation logic.
+ */
void intel_gt_fini_tlb(struct intel_gt *gt)
{
mutex_destroy(>tlb.invalidate_lock);
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h
b/drivers/gpu/drm/i915/gt/intel_tlb.h
index 46ce25bf5afe..dca70c33bd61 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
@@ -11,16 +11,117 @@
#include "intel_gt_types.h"
+/**
+ * DOC: TLB cache invalidation logic
+ *
+ * The way the current algorithm works is that a struct drm_i915_gem_object can
+ * be created on any order. At unbind/evict time, the object is warranted that
+ * it won't be used anymore. So, a sequence number provided by
+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen either
+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() - for
+ * VMA async VMA bind.
+ *
+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is
called,
+ * where it checks if the sequence number of the object was already invalidated
+ * or not. If not, it flushes the TLB and increments the sequence number::
+ *
+ * void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
+ * {
+ * ...
+ * with_intel_gt_pm_if_awake(gt, wakeref) {
+ * mutex_lock(>tlb.invalidate_lock);
+ * if (tlb_seqno_passed(gt, seqno))
+ * goto unlock;
+ *
+ * // Some code to do TLB invalidation
+ * ...
+ *
+ * write_seqcount_invalidate(>tlb.seqno); // increment seqno
+ * mutex_lock(>tlb.invalidate_lock);
+ * }
+ *
+ * So, let's say the current seqno is 2 and 3 new objects were created,
+ * on this order::
+ *
+ * obj1
+ * obj2
+ * obj3
+ *
+ * They can be unbind/evict on a different order. At unbind/evict time,
+ * the mm.tlb will be stamped with the sequence number, using the number
+ * from the last TLB flush, plus 1.
I am trying to get my head around the below function.
void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb)
{
WRITE_ONCE(tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
}
Though we pass obj->mm.tlb for 'tlb' while calling this function,
aren't we writing to local 'tlb' variable here instead of obj->mm.tlb?
+ *
+ * Different threads may be used on unbind/evict and/or unset pages.
+ * As the logic at void intel_gt_invalidate_tlb_full() is protected by a mutex,
May be we can skip
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Move TLB invalidation to its own file
On Fri, Jul 29, 2022 at 09:03:54AM +0200, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.
And looks like,
1. Rename intel_gt_invalidate_tlb() to intel_gt_invalidate_tlb_full()
2. Add intel_gt_init_tlb() and intel_gt_fini_tlb() abstracts.
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 0/2] at:
https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 168 +---
drivers/gpu/drm/i915/gt/intel_gt.h| 12 --
drivers/gpu/drm/i915/gt/intel_tlb.c | 183 ++
drivers/gpu/drm/i915/gt/intel_tlb.h | 29
drivers/gpu/drm/i915/i915_vma.c | 1 +
7 files changed, 219 insertions(+), 179 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..d3df9832d1f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,7 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+ gt/intel_tlb.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8357dbdcab5c..1cd76cc5d9f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,7 +7,7 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
+#include "gt/intel_tlb.h"
#include "i915_drv.h"
#include "i915_gem_object.h"
@@ -199,7 +199,7 @@ static void flush_tlb_invalidate(struct drm_i915_gem_object
*obj)
if (!obj->mm.tlb)
return;
- intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+ intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
obj->mm.tlb = 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f435e06125aa..18d82cd620bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -11,9 +11,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
-#include "i915_perf_oa_regs.h"
#include "intel_context.h"
-#include "intel_engine_pm.h"
#include "intel_engine_regs.h"
#include "intel_ggtt_gmch.h"
#include "intel_gt.h"
@@ -31,6 +29,7 @@
#include "intel_renderstate.h"
#include "intel_rps.h"
#include "intel_gt_sysfs.h"
+#include "intel_tlb.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
@@ -48,8 +47,7 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
- mutex_init(>tlb.invalidate_lock);
- seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
+ intel_gt_init_tlb(gt);
intel_gt_pm_init_early(gt);
intel_uc_init_early(>uc);
@@ -770,7 +768,7 @@ void intel_gt_driver_late_release_all(struct
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
- mutex_destroy(>tlb.invalidate_lock);
+ intel_gt_fini_tlb(gt);
intel_engines_free(gt);
}
}
@@ -881,163 +879,3 @@ void intel_gt_info_print(const struct intel_gt_info *info,
intel_sseu_dump(>sseu, p);
}
-
-struct reg_and_bit {
- i915_reg_t reg;
- u32 bit;
-};
-
-static struct reg_and_bit
-get_reg_and_bit(const struct intel_engine_cs *engine, const bool gen8,
- const i915_reg_t *regs, const unsigned int num)
-{
- const unsigned int class = engine->class;
- struct reg_and_bit rb = { };
-
- if (drm_WARN_ON_ONCE(>i915->drm,
-class >= num || !regs[class].reg))
- return rb;
-
- rb.reg = regs[class];
- if (gen8 && class == VIDEO_DECODE_CLASS)
- rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
- else
- rb.bit = engine->instance;
-
- rb.bit = BIT(rb.bit);
-
- return rb;
-}
-
-static void mmio_invalidate_full(struct intel_gt *gt)
-{
- static const i915_reg_t gen8_regs[] = {
- [RENDER_CLASS] = GEN8_RTCR,
- [VIDEO_DECODE_CLASS]= GEN8_M1TCR, /* , GEN8_M2TCR */
- [VIDEO_ENHANCEMENT_CLASS] = GEN8_VTCR,
- [COPY_ENGINE_CLASS] = GEN8_BTCR,
- };
- static const i915_reg_t gen12_regs[] = {
- [RENDER_CLASS]
Re: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if last connected port isn't connected
On Tue, 2022-07-05 at 08:45 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Wednesday, June 8, 2022 3:30 AM
> > To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Ville Syrjälä
> > ; Zuo, Jerry ; Jani
> > Nikula
> > ; Imre Deak ; Daniel Vetter
> > ; Sean Paul ; David Airlie
> > ; Daniel Vetter ; Thomas Zimmermann
> > ; Lakha, Bhawanpreet
> > ; open list
> > Subject: [RESEND RFC 15/18] drm/display/dp_mst: Skip releasing payloads if
> > last connected port isn't connected
> >
> > In the past, we've ran into strange issues regarding errors in response to
> > trying to destroy payloads after a port has been unplugged. We fixed this
> > back in:
> >
> > This is intended to replace the workaround that was added here:
> >
> > commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
> > ports in stale topology")
> >
> > which was intended fix to some of the payload leaks that were observed
> > before, where we would attempt to determine if the port was still
> > connected to the topology before updating payloads using
> > drm_dp_mst_port_downstream_of_branch. This wasn't a particularly good
> > solution, since one of the points of still having port and mstb validation
> > is to
> > avoid sending messages to newly disconnected branches wherever possible
> > - thus the required use of drm_dp_mst_port_downstream_of_branch
> > would indicate something may be wrong with said validation.
> >
> > It seems like it may have just been races and luck that made
> > drm_dp_mst_port_downstream_of_branch work however, as while I was
> > trying to figure out the true cause of this issue when removing the legacy
> > MST code - I discovered an important excerpt in section 2.14.2.3.3.6 of
> > the DP
> > 2.0
> > specs:
> >
> > "BAD_PARAM - This reply is transmitted when a Message Transaction
> > parameter is in error; for example, the next port number is invalid or /no
> > device is connected/ to the port associated with the port number."
> >
> > Sure enough - removing the calls to
> > drm_dp_mst_port_downstream_of_branch()
> > and instead checking the ->ddps field of the parent port to see whether we
> > should release a given payload or not seems to totally fix the issue. This
> > does
> > actually make sense to me, as it seems the implication is that given a
> > topology where an MSTB is removed, the payload for the MST parent's port
> > will be released automatically if that port is also marked as
> > disconnected.
> > However, if there's another parent in the chain after that which is
> > connected
> > - payloads must be released there with an ALLOCATE_PAYLOAD message.
> >
> > So, let's do that!
> >
> > Signed-off-by: Lyude Paul
> > Cc: Wayne Lin
> > Cc: Ville Syrjälä
> > Cc: Fangzhi Zuo
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 51 +++
> > 1 file changed, 17 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index dd314586bac3..70adb8db4335 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3137,7 +3137,7 @@ static struct drm_dp_mst_port
> > *drm_dp_get_last_connected_port_to_mstb(struct drm static struct
> > drm_dp_mst_branch * drm_dp_get_last_connected_port_and_mstb(struct
> > drm_dp_mst_topology_mgr *mgr,
> > struct drm_dp_mst_branch *mstb,
> > - int *port_num)
> > + struct drm_dp_mst_port
> > **last_port)
> > {
> > struct drm_dp_mst_branch *rmstb = NULL;
> > struct drm_dp_mst_port *found_port;
> > @@ -3153,7 +3153,8 @@
> > drm_dp_get_last_connected_port_and_mstb(struct
> > drm_dp_mst_topology_mgr *mgr,
> >
> > if (drm_dp_mst_topology_try_get_mstb(found_port-
> > > parent)) {
> > rmstb = found_port->parent;
> > - *port_num = found_port->port_num;
> > + *last_port = found_port;
> > + drm_dp_mst_get_port_malloc(found_port);
> > } else {
> > /* Search again, starting from this parent */
> > mstb = found_port->parent;
> > @@ -3170,7 +3171,7 @@ static int drm_dp_payload_send_msg(struct
> > drm_dp_mst_topology_mgr *mgr,
> > int pbn)
> > {
> > struct drm_dp_sideband_msg_tx *txmsg;
> > - struct drm_dp_mst_branch *mstb;
> > + struct drm_dp_mst_branch *mstb = NULL;
> > int ret, port_num;
> > u8 sinks[DRM_DP_MAX_SDP_STREAMS];
> > int i;
> > @@ -3178,12 +3179,22 @@ static int drm_dp_payload_send_msg(struct
> >
Re: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not VCPI slots
On Wed, 2022-06-15 at 04:28 +, Lin, Wayne wrote:
> [Public]
>
> Thank you Lyude for addressing this!
>
> VCPI is also a confusing naming to me at first glance since it stands for
> Virtual Channel Payload Identification which is just an ID number ( we can
> look up these payload IDs In DPCD 0x2C1 ~0x2FF).
>
> I also look up left VCPI terms in rest of the code. Seems like we still can
> modify
> some parts here? Like:
>
> /**
> * struct drm_dp_vcpi - Virtual Channel Payload Identifier
> * @vcpi: Virtual channel ID.
> * @pbn: Payload Bandwidth Number for this channel
> * @aligned_pbn: PBN aligned with slot size
> * @num_slots: number of slots for this PBN
> */
> struct drm_dp_vcpi {
> int vcpi;
> int pbn;
> int aligned_pbn;
> int num_slots;
> };
>
> Would like to change the structure name to "struct drm_dp_mst_vcp {}" to
> represent
> the virtual channel payload. Not specific to the ID.
> Would like to know your thoughts : )
JFYI - I didn't rename this structure because we actually remove it entirely
in later patches
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Wednesday, June 8, 2022 3:29 AM
> > To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Ville Syrjälä
> > ; Zuo, Jerry ; Jani
> > Nikula
> > ; Imre Deak ; Daniel Vetter
> > ; Sean Paul ; Wentland, Harry
> > ; Li, Sun peng (Leo) ;
> > Siqueira, Rodrigo ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; Jani Nikula
> > ; Joonas Lahtinen
> > ; Rodrigo Vivi ;
> > Tvrtko Ursulin ; Ben Skeggs
> > ; Karol Herbst ; Kazlauskas,
> > Nicholas ; Li, Roman
> > ; Shih, Jude ; Simon Ser
> > ; Wu, Hersen ; Thomas
> > Zimmermann ; Lakha, Bhawanpreet
> > ; José Roberto de Souza
> > ; He Ying ; Matt Roper
> > ; Sean Paul ; Hans
> > Verkuil ; Fernando Ramos ;
> > Javier Martinez Canillas ; open list > ker...@vger.kernel.org>; open list:INTEL DRM DRIVERS > g...@lists.freedesktop.org>
> > Subject: [RESEND RFC 04/18] drm/display/dp_mst: Call them time slots, not
> > VCPI slots
> >
> > VCPI is only sort of the correct term here, originally the majority of
> > this code
> > simply referred to timeslots vaguely as "slots" - and since I started
> > working
> > on it and adding atomic functionality, the name "VCPI slots" has been used
> > to
> > represent time slots.
> >
> > Now that we actually have consistent access to the DisplayPort spec thanks
> > to
> > VESA, I now know this isn't actually the proper term - as the
> > specification
> > refers to these as time slots.
> >
> > Since we're trying to make this code as easy to figure out as possible,
> > let's
> > take this opportunity to correct this nomenclature and call them by their
> > proper name - timeslots. Likewise, we rename various functions
> > appropriately, along with replacing references in the kernel documentation
> > and various debugging messages.
> >
> > It's important to note that this patch series leaves the legacy MST code
> > untouched for the most part, which is fine since we'll be removing it soon
> > anyhow. There should be no functional changes in this series.
> >
> > Signed-off-by: Lyude Paul
> > Cc: Wayne Lin
> > Cc: Ville Syrjälä
> > Cc: Fangzhi Zuo
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 ++---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +-
> > include/drm/display/drm_dp_mst_helper.h | 6 +-
> > 6 files changed, 75 insertions(+), 76 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 ad4571190a90..f84a4ad736d8 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7393,7 +7393,7 @@ static int dm_encoder_helper_atomic_check(struct
> > drm_encoder *encoder,
> > clock = adjusted_mode->clock;
> > dm_new_connector_state->pbn =
> > drm_dp_calc_pbn_mode(clock, bpp, false);
> > }
> > - dm_new_connector_state->vcpi_slots =
> > drm_dp_atomic_find_vcpi_slots(state,
> > + dm_new_connector_state->vcpi_slots =
> > +drm_dp_atomic_find_time_slots(state,
> >
> > mst_mgr,
> >
> > mst_port,
> >
> > dm_new_connector_state->pbn, diff --git
> > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index 9221b6690a4a..e40ff51e7be0 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -378,7
[PATCH] dma-buf: Use dma_fence_unwrap_for_each when importing fences
Ever since 68129f431faa ("dma-buf: warn about containers in dma_resv object"),
dma_resv_add_shared_fence will warn if you attempt to add a container fence.
While most drivers were fine, fences can also be added to a dma_resv via the
recently added DMA_BUF_IOCTL_IMPORT_SYNC_FILE. Use dma_fence_unwrap_for_each
to add each fence one at a time.
Fixes: 594740497e99 ("dma-buf: Add an API for importing sync files (v10)")
Signed-off-by: Jason Ekstrand
Reported-by: Sarah Walker
Cc: Christian König
---
drivers/dma-buf/dma-buf.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 630133284e2b..8d5d45112f52 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -391,8 +392,10 @@ static long dma_buf_import_sync_file(struct dma_buf
*dmabuf,
const void __user *user_data)
{
struct dma_buf_import_sync_file arg;
- struct dma_fence *fence;
+ struct dma_fence *fence, *f;
enum dma_resv_usage usage;
+ struct dma_fence_unwrap iter;
+ unsigned int num_fences;
int ret = 0;
if (copy_from_user(, user_data, sizeof(arg)))
@@ -411,13 +414,21 @@ static long dma_buf_import_sync_file(struct dma_buf
*dmabuf,
usage = (arg.flags & DMA_BUF_SYNC_WRITE) ? DMA_RESV_USAGE_WRITE :
DMA_RESV_USAGE_READ;
- dma_resv_lock(dmabuf->resv, NULL);
+ num_fences = 0;
+ dma_fence_unwrap_for_each(f, , fence)
+ ++num_fences;
- ret = dma_resv_reserve_fences(dmabuf->resv, 1);
- if (!ret)
- dma_resv_add_fence(dmabuf->resv, fence, usage);
+ if (num_fences > 0) {
+ dma_resv_lock(dmabuf->resv, NULL);
- dma_resv_unlock(dmabuf->resv);
+ ret = dma_resv_reserve_fences(dmabuf->resv, num_fences);
+ if (!ret) {
+ dma_fence_unwrap_for_each(f, , fence)
+ dma_resv_add_fence(dmabuf->resv, f, usage);
+ }
+
+ dma_resv_unlock(dmabuf->resv);
+ }
dma_fence_put(fence);
--
2.36.1
Re: [Intel-gfx] [PATCH 7/7] drm/i915/guc: Reduce spam from error capture
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Some debug code got left in when the GuC based register save for error
> capture was added. Remove that.
>
> Signed-off-by: John Harrison
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 67 ---
> 1 file changed, 28 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index d2ac53d4f3b6e..8f11651460131 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -1383,33 +1383,22 @@ guc_capture_reg_to_str(const struct intel_guc *guc,
> u32 owner, u32 type,
> return NULL;
> }
>
> -#ifdef CONFIG_DRM_I915_DEBUG_GUC
> -#define __out(a, ...) \
> - do { \
> - drm_warn((&(a)->i915->drm), __VA_ARGS__); \
> - i915_error_printf((a), __VA_ARGS__); \
> - } while (0)
> -#else
> -#define __out(a, ...) \
> - i915_error_printf(a, __VA_ARGS__)
> -#endif
> -
> #define GCAP_PRINT_INTEL_ENG_INFO(ebuf, eng) \
> do { \
> - __out(ebuf, "i915-Eng-Name: %s command stream\n", \
> - (eng)->name); \
> - __out(ebuf, "i915-Eng-Inst-Class: 0x%02x\n", (eng)->class);
> \
> - __out(ebuf, "i915-Eng-Inst-Id: 0x%02x\n", (eng)->instance);
> \
> - __out(ebuf, "i915-Eng-LogicalMask: 0x%08x\n", \
> - (eng)->logical_mask); \
> + i915_error_printf(ebuf, "i915-Eng-Name: %s command
> stream\n", \
> + (eng)->name); \
> + i915_error_printf(ebuf, "i915-Eng-Inst-Class: 0x%02x\n",
> (eng)->class); \
> + i915_error_printf(ebuf, "i915-Eng-Inst-Id: 0x%02x\n",
> (eng)->instance); \
> + i915_error_printf(ebuf, "i915-Eng-LogicalMask: 0x%08x\n", \
> + (eng)->logical_mask); \
> } while (0)
>
> #define GCAP_PRINT_GUC_INST_INFO(ebuf, node) \
> do { \
> - __out(ebuf, "GuC-Engine-Inst-Id: 0x%08x\n", \
> - (node)->eng_inst); \
> - __out(ebuf, "GuC-Context-Id: 0x%08x\n", (node)->guc_id); \
> - __out(ebuf, "LRCA: 0x%08x\n", (node)->lrca); \
> + i915_error_printf(ebuf, "GuC-Engine-Inst-Id: 0x%08x\n", \
> + (node)->eng_inst); \
> + i915_error_printf(ebuf, "GuC-Context-Id: 0x%08x\n",
> (node)->guc_id); \
> + i915_error_printf(ebuf, "LRCA: 0x%08x\n", (node)->lrca); \
> } while (0)
>
> int intel_guc_capture_print_engine_node(struct drm_i915_error_state_buf
> *ebuf,
> @@ -1441,57 +1430,57 @@ int intel_guc_capture_print_engine_node(struct
> drm_i915_error_state_buf *ebuf,
>
> guc = >engine->gt->uc.guc;
>
> - __out(ebuf, "global --- GuC Error Capture on %s command stream:\n",
> - ee->engine->name);
> + i915_error_printf(ebuf, "global --- GuC Error Capture on %s command
> stream:\n",
> + ee->engine->name);
>
> node = ee->guc_capture_node;
> if (!node) {
> - __out(ebuf, " No matching ee-node\n");
> + i915_error_printf(ebuf, " No matching ee-node\n");
> return 0;
> }
>
> - __out(ebuf, "Coverage: %s\n", grptype[node->is_partial]);
> + i915_error_printf(ebuf, "Coverage: %s\n", grptype[node->is_partial]);
>
> for (i = GUC_CAPTURE_LIST_TYPE_GLOBAL; i < GUC_CAPTURE_LIST_TYPE_MAX;
> ++i) {
> - __out(ebuf, " RegListType: %s\n",
> - datatype[i % GUC_CAPTURE_LIST_TYPE_MAX]);
> - __out(ebuf, "Owner-Id: %d\n", node->reginfo[i].vfid);
> + i915_error_printf(ebuf, " RegListType: %s\n",
> + datatype[i % GUC_CAPTURE_LIST_TYPE_MAX]);
> + i915_error_printf(ebuf, "Owner-Id: %d\n",
> node->reginfo[i].vfid);
>
> switch (i) {
> case GUC_CAPTURE_LIST_TYPE_GLOBAL:
> default:
> break;
> case GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS:
> - __out(ebuf, "GuC-Eng-Class: %d\n", node->eng_class);
> - __out(ebuf, "i915-Eng-Class: %d\n",
> - guc_class_to_engine_class(node->eng_class));
> + i915_error_printf(ebuf, "GuC-Eng-Class: %d\n",
> node->eng_class);
> + i915_error_printf(ebuf, "i915-Eng-Class: %d\n",
> +
> guc_class_to_engine_class(node->eng_class));
> break;
> case GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE:
> eng = intel_guc_lookup_engine(guc, node->eng_class,
> node->eng_inst);
> if (eng)
>
Re: [Intel-gfx] [PATCH 5/7] drm/i915/guc: Use streaming loads to speed up dumping the guc log
One concern below. Else, nice, simple yet good optimization here. :)
In the interest of quicker progression, I will provide a conditional R-B if you
can either fix the issue raised below on
the way in or provide a reason why that's not an issue:
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: Chris Wilson
>
> Use a temporary page and mempy_from_wc to reduce the time it takes to
> dump the guc log to debugfs.
>
> Signed-off-by: Chris Wilson
> Signed-off-by: John Harrison
> Reviewed-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 --
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index 07d31ae32f765..4722d4b18ed19 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -750,8 +750,9 @@ int intel_guc_log_dump(struct intel_guc_log *log, struct
> drm_printer *p,
> struct intel_guc *guc = log_to_guc(log);
> struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
> struct drm_i915_gem_object *obj = NULL;
> - u32 *map;
> - int i = 0;
> + void *map;
> + u32 *page;
> + int i, j;
>
> if (!intel_guc_is_supported(guc))
> return -ENODEV;
> @@ -764,23 +765,34 @@ int intel_guc_log_dump(struct intel_guc_log *log,
> struct drm_printer *p,
> if (!obj)
> return 0;
>
> + page = (u32 *)__get_free_page(GFP_KERNEL);
> + if (!page)
> + return -ENOMEM;
Alan: although unlikely, its possible that user could trigger debugfs mid of a
gt reset - not sure if we need to use the
"uc->reset_in_progress" before calling this allocation and return a different
error in that case like EAGAIN or EBUSY or
ECONNRESET.
> +
> intel_guc_dump_time_info(guc, p);
>
> map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
> if (IS_ERR(map)) {
> DRM_DEBUG("Failed to pin object\n");
> drm_puts(p, "(log data unaccessible)\n");
> + free_page((unsigned long)page);
> return PTR_ERR(map);
> }
>
> - for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
> - drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> -*(map + i), *(map + i + 1),
> -*(map + i + 2), *(map + i + 3));
> + for (i = 0; i < obj->base.size; i += PAGE_SIZE) {
> + if (!i915_memcpy_from_wc(page, map + i, PAGE_SIZE))
> + memcpy(page, map + i, PAGE_SIZE);
> +
> + for (j = 0; j < PAGE_SIZE / sizeof(u32); j += 4)
> + drm_printf(p, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> +*(page + j + 0), *(page + j + 1),
> +*(page + j + 2), *(page + j + 3));
> + }
>
> drm_puts(p, "\n");
>
> i915_gem_object_unpin_map(obj);
> + free_page((unsigned long)page);
>
> return 0;
> }
> --
> 2.37.1
>
Re: [PATCH 0/5] clk/qcom: Support gdsc collapse polling using 'reset' inteface
On Tue, Aug 2, 2022 at 12:02 AM Dmitry Baryshkov wrote: > > On 30/07/2022 12:17, Akhil P Oommen wrote: > > > > Some clients like adreno gpu driver would like to ensure that its gdsc > > is collapsed at hardware during a gpu reset sequence. This is because it > > has a votable gdsc which could be ON due to a vote from another subsystem > > like tz, hyp etc or due to an internal hardware signal. > > If this is votable, do we have any guarantee that the gdsc will collapse > at all? How can we proceed if it did not collapse? Other potential votes should be transient. But I guess we eventually need to timeout and give up. At which point we are no worse off than before. But hmm, we aren't using RBBM_SW_RESET_CMD for sw reset like we have on previous generations? That does seem a bit odd. Looks like kgsl does use it. BR, -R > > To allow > > this, gpucc driver can expose an interface to the client driver using > > reset framework. Using this the client driver can trigger a polling within > > the gdsc driver. > > Trigger the polling made me think initially that we will actually > trigger something in the HW. Instead the client uses reset framework to > poll for the gdsc to be reset. > > > > > This series is rebased on top of linus's master branch. > > > > Related discussion: https://patchwork.freedesktop.org/patch/493144/ > > > > > > Akhil P Oommen (5): > >dt-bindings: clk: qcom: Support gpu cx gdsc reset > >clk: qcom: Allow custom reset ops > >clk: qcom: gpucc-sc7280: Add cx collapse reset support > >clk: qcom: gdsc: Add a reset op to poll gdsc collapse > >arm64: dts: qcom: sc7280: Add Reset support for gpu > > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++ > > drivers/clk/qcom/gdsc.c | 23 +++ > > drivers/clk/qcom/gdsc.h | 7 +++ > > drivers/clk/qcom/gpucc-sc7280.c | 6 ++ > > drivers/clk/qcom/reset.c | 6 ++ > > drivers/clk/qcom/reset.h | 2 ++ > > include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ > > 7 files changed, 46 insertions(+), 4 deletions(-) > > > > > -- > With best wishes > Dmitry
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Record CTB info in error logs
One minor NIT (though i hope it could be fixed otw in as it adds a bit of
ease-of-log-readibility).
That said, everything else looks good.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When debugging GuC communication issues, it is useful to have the CTB
> info available. So add the state and buffer contents to the error
> capture log.
>
> Also, add a sub-structure for the GuC specific error capture info as
> it is now becoming numerous.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 59 +++
> drivers/gpu/drm/i915/i915_gpu_error.h | 20 +++--
> 2 files changed, 67 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index addba75252343..543ba63f958ea 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -671,6 +671,18 @@ static void err_print_pciid(struct
> drm_i915_error_state_buf *m,
> pdev->subsystem_device);
> }
>
> +static void err_print_guc_ctb(struct drm_i915_error_state_buf *m,
> + const char *name,
> + const struct intel_ctb_coredump *ctb)
> +{
> + if (!ctb->size)
> + return;
> +
> + err_printf(m, "GuC %s CTB: raw: 0x%08X, 0x%08X/%08X, cached:
> 0x%08X/%08X, desc = 0x%08X, buf = 0x%08X x 0x%08X\n",
> +name, ctb->raw_status, ctb->raw_head, ctb->raw_tail,
> +ctb->head, ctb->tail, ctb->desc_offset, ctb->cmds_offset,
> ctb->size);
>
NIT: to make it more readible on first glance, would be nice to add more
descriptive text like "raw: Sts:0x%08X,
Hd:0x%08X,Tl:0x@08X..." also, the not sure why cmds_offset is presented with a
"x size" as opposed to just "desc-off =
foo1, cmd-off = foo2, size = foo3"?
> +}
> +
> static void err_print_uc(struct drm_i915_error_state_buf *m,
>const struct intel_uc_coredump *error_uc)
> {
> @@ -678,8 +690,12 @@ static void err_print_uc(struct drm_i915_error_state_buf
> *m,
>
> intel_uc_fw_dump(_uc->guc_fw, );
> intel_uc_fw_dump(_uc->huc_fw, );
> - err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->timestamp);
> - intel_gpu_error_print_vma(m, NULL, error_uc->guc_log);
> + err_printf(m, "GuC timestamp: 0x%08x\n", error_uc->guc.timestamp);
> + intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_log);
> + err_printf(m, "GuC CTB fence: %d\n", error_uc->guc.last_fence);
> + err_print_guc_ctb(m, "Send", error_uc->guc.ctb + 0);
> + err_print_guc_ctb(m, "Recv", error_uc->guc.ctb + 1);
> + intel_gpu_error_print_vma(m, NULL, error_uc->guc.vma_ctb);
> }
>
> static void err_free_sgl(struct scatterlist *sgl)
> @@ -854,7 +870,7 @@ static void __err_print_to_sgl(struct
> drm_i915_error_state_buf *m,
> if (error->gt) {
> bool print_guc_capture = false;
>
> - if (error->gt->uc && error->gt->uc->is_guc_capture)
> + if (error->gt->uc && error->gt->uc->guc.is_guc_capture)
> print_guc_capture = true;
>
> err_print_gt_display(m, error->gt);
> @@ -1009,7 +1025,8 @@ static void cleanup_uc(struct intel_uc_coredump *uc)
> {
> kfree(uc->guc_fw.path);
> kfree(uc->huc_fw.path);
> - i915_vma_coredump_free(uc->guc_log);
> + i915_vma_coredump_free(uc->guc.vma_log);
> + i915_vma_coredump_free(uc->guc.vma_ctb);
>
> kfree(uc);
> }
> @@ -1658,6 +1675,23 @@ gt_record_engines(struct intel_gt_coredump *gt,
> }
> }
>
> +static void gt_record_guc_ctb(struct intel_ctb_coredump *saved,
> + const struct intel_guc_ct_buffer *ctb,
> + const void *blob_ptr, struct intel_guc *guc)
> +{
> + if (!ctb || !ctb->desc)
> + return;
> +
> + saved->raw_status = ctb->desc->status;
> + saved->raw_head = ctb->desc->head;
> + saved->raw_tail = ctb->desc->tail;
> + saved->head = ctb->head;
> + saved->tail = ctb->tail;
> + saved->size = ctb->size;
> + saved->desc_offset = ((void *)ctb->desc) - blob_ptr;
> + saved->cmds_offset = ((void *)ctb->cmds) - blob_ptr;
> +}
> +
> static struct intel_uc_coredump *
> gt_record_uc(struct intel_gt_coredump *gt,
>struct i915_vma_compress *compress)
> @@ -1684,9 +1718,16 @@ gt_record_uc(struct intel_gt_coredump *gt,
>* log times to system times (in conjunction with the error->boottime
> and
>* gt->clock_frequency fields saved elsewhere).
>*/
> - error_uc->timestamp = intel_uncore_read(gt->_gt->uncore,
> GUCPMTIMESTAMP);
> - error_uc->guc_log = create_vma_coredump(gt->_gt, uc->guc.log.vma,
> - "GuC log buffer", compress);
> + error_uc->guc.timestamp = intel_uncore_read(gt->_gt->uncore,
> GUCPMTIMESTAMP);
> +
Re: [PATCH drm-misc-next v7 0/5] drm: rename CMA helpers to DMA helpers
Hi Danilo,
On Tue, Aug 02, 2022 at 02:04:00AM +0200, Danilo Krummrich wrote:
> This patch series renames all CMA helpers to DMA helpers - considering the
> hierarchy of APIs (mm/cma -> dma -> gem/fb dma helpers) calling them DMA
> helpers seems to be more applicable.
>
> Additionally, commit e57924d4ae80 ("drm/doc: Task to rename CMA helpers")
> requests to rename the CMA helpers and implies that people seem to be confused
> about the naming.
>
> The patches are compile-time tested building a x86_64 kernel with
> `make allyesconfig && make drivers/gpu/drm`.
For good measure I build tested each patch on my setup - which covers a
few more archs (cross compiled).
There was a few checkpatch warnings when applying, which I happily ignored.
Most/all are existing flaws where you do other edits in the relevant
line.
I consider the series ready to be applied to drm-misc, but have not done
so myself.
I have pinged Daniel Vetter on irc - as he was the one suggesting the
task from the very beginning.
Sam
Re: [PATCH drm-misc-next v7 1/5] drm/fb: remove unused includes of drm_fb_cma_helper.h
Hi Danilo, On Tue, Aug 02, 2022 at 02:04:01AM +0200, Danilo Krummrich wrote: > Quite a lot of drivers include the drm_fb_cma_helper.h header file > without actually making use of it's provided API, hence remove those > includes. > > Suggested-by: Sam Ravnborg > Signed-off-by: Danilo Krummrich I forgot that I asked you to do this - sorry for the late feedback. Patch looks good, very good to get rid of the unused includes! Acked-by: Sam Ravnborg > --- > drivers/gpu/drm/arm/hdlcd_drv.c | 1 - > drivers/gpu/drm/arm/malidp_drv.c| 1 - > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 1 - > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 - > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 1 - > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 1 - > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > drivers/gpu/drm/imx/ipuv3-crtc.c| 1 - > drivers/gpu/drm/logicvc/logicvc_mode.c | 1 - > drivers/gpu/drm/pl111/pl111_drv.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 - > drivers/gpu/drm/shmobile/shmob_drm_kms.c| 1 - > drivers/gpu/drm/solomon/ssd130x.c | 1 - > drivers/gpu/drm/sti/sti_drv.c | 1 - > drivers/gpu/drm/sti/sti_plane.c | 1 - > drivers/gpu/drm/stm/drv.c | 1 - > drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - > drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 - > drivers/gpu/drm/tidss/tidss_crtc.c | 1 - > drivers/gpu/drm/tidss/tidss_kms.c | 1 - > drivers/gpu/drm/tidss/tidss_plane.c | 1 - > drivers/gpu/drm/tve200/tve200_drv.c | 1 - > drivers/gpu/drm/v3d/v3d_drv.c | 1 - > drivers/gpu/drm/vc4/vc4_drv.c | 1 - > 26 files changed, 26 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 350ca4e4eaa6..b32168e3f9ae 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -26,7 +26,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index d5aef21426cf..fa6c1a4254dc 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -19,7 +19,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > index 7780b72de9e8..54aa8af45829 100644 > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > index 7a503bf08d0f..4baa4977e473 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > @@ -20,7 +20,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > index d763f53f480c..5b47000738e4 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > #include > > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > index 2af51df6dca7..e8b0fe970969 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > @@ -19,7 +19,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > b/drivers/gpu/drm/imx/imx-drm-core.c > index 50fd7aac5198..e43345bd1346 100644 > --- a/drivers/gpu/drm/imx/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c > b/drivers/gpu/drm/imx/ipuv3-crtc.c > index f7863d6dea80..d9f832f952c2 100644 > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c > @@ -18,7 +18,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/logicvc/logicvc_mode.c > b/drivers/gpu/drm/logicvc/logicvc_mode.c > index 11940704f644..c59da7039dc1 100644 > --- a/drivers/gpu/drm/logicvc/logicvc_mode.c > +++ b/drivers/gpu/drm/logicvc/logicvc_mode.c > @@ -10,7 +10,6 @@ > #include > #include > #include > -#include > #include > #include >
Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Hi Sam, Regarding DRI1 era uAPI, I believe I am handling the matter similar to how Radeon DRM header (include/uapi/drm/radeon_drm.h) handled the matter. The header still contains old DRI1 uAPI calls, and it then adds new KMS generation uAPI calls. At this point, using drm_invalid_op() for OpenChrome DRM is the least intrusive option, and that's the way I will like to keep it. It is just that I did not know its existence, so it was not in the code. The older OpenChrome DDX releases might assume uAPI backward compatibility, but the use of drm_invalid_op() should gracefully tell the DDX that the legacy DRI1 VIA DRM uAPI is no longer supported. Personally, I do not anticipate Wayland use with OpenChrome. It will end up living out its life as X.Org X Server only solution considering its hardware age. Although it is somewhat hard, I use Gentoo Linux as development platform for OpenChrome, and 32-bit x86 ISA and X.Org X Server are still fully supported. Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com > Sent: Tuesday, August 02, 2022 at 4:09 AM > From: "Sam Ravnborg" > To: "Kevin Brace" > Cc: "Thomas Zimmermann" , dri-devel@lists.freedesktop.org > Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h > > Hi Kevin, > > > > OpenChrome DDX carries lots of legacy code. > > > > https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/tree/src/via_drm.h?h=main=dc661c59257e855cd9b29c14b91a8ee2d9b86ccb > > > > There is a requirement to use the same via_drm.h with both DDX and DRM. > > Hence, I need to keep a lot of the legacy DRI1 definitions inside via_drm.h. > > This part is fully understood. Also on top of this the via DRI1 driver > uses this. I am not asking to have anything deleted from the existing > uapi via_drm.h file. > > > My feedback is that the following code should be dropped from the > openchrome driver: > > + DRM_IOCTL_DEF_DRV(VIA_ALLOCMEM, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_FREEMEM, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_AGP_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER), > + DRM_IOCTL_DEF_DRV(VIA_FB_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER), > + DRM_IOCTL_DEF_DRV(VIA_MAP_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER), > + DRM_IOCTL_DEF_DRV(VIA_DEC_FUTEX, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_DMA_INIT, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_CMDBUFFER, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_FLUSH, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_PCICMD, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_CMDBUF_SIZE, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_WAIT_IRQ, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_DMA_BLIT, drm_invalid_op, DRM_AUTH), > + DRM_IOCTL_DEF_DRV(VIA_BLIT_SYNC, drm_invalid_op, DRM_AUTH), > > (Copied from openchrome-drm - I recall you did not post this code yet). > > The new openchrome driver should not care at all about the old UAPI, > so just drop the above. > > The comment above is based on the understanding that when we have a kms > compliant driver the user space is generic and we do not expect or need > any via specifics in user space. > > In other words - x86-video-openchrome should - according to my > understanding - not be needed. And we can have a fully operational > wayland (and maybe X) userspace using the generic UAPI. This is where > Thomas Zimmermann's comment about dumb buffers are relevant. > > Do I miss something obvious here? > > Sam >
Re: [Intel-gfx] [PATCH 2/7] drm/i915/guc: Fix capture size warning and bump the size
Straight forward change - LGTM.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There was a size check to warn if the GuC error state capture buffer
> allocation would be too small to fit a reasonable amount of capture
> data for the current platform. Unfortunately, the test was done too
> early in the boot sequence and was actually testing 'if(-ENODEV >
> size)'.
>
> Move the check to be later. The check is only used to print a warning
> message, so it doesn't really matter how early or late it is done.
> Note that it is not possible to dynamically size the buffer because
> the allocation needs to be done before the engine information is
> available (at least, it would be in the intended two-phase GuC init
> process).
>
> Now that the check works, it is reporting size too small for newer
> platforms. The check includes a 3x oversample multiplier to allow for
> multiple error captures to be bufferd by GuC before i915 has a chance
> to read them out. This is less important than simply being big enough
> to fit the first capture.
>
> So a) bump the default size to be large enough for one capture minimum
> and b) make the warning only if one capture won't fit, instead use a
> notice for the 3x size.
>
> Note that the size estimate is a worst case scenario. Actual captures
> will likely be smaller.
>
> Lastly, use drm_warn istead of DRM_WARN as the former provides more
> infmration and the latter is deprecated.
>
> Signed-off-by: John Harrison
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 40 ++-
> .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 -
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 4 --
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 4 +-
> 4 files changed, 31 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 75257bd20ff01..b54b7883320b1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -600,10 +600,8 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
> return 0;
> }
>
> -#define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
> -
> -int
> -intel_guc_capture_output_min_size_est(struct intel_guc *guc)
> +static int
> +guc_capture_output_min_size_est(struct intel_guc *guc)
> {
> struct intel_gt *gt = guc_to_gt(guc);
> struct intel_engine_cs *engine;
> @@ -623,13 +621,8 @@ intel_guc_capture_output_min_size_est(struct intel_guc
> *guc)
>* For each engine instance, there would be 1 x
> guc_state_capture_group_t output
>* followed by 3 x guc_state_capture_t lists. The latter is how the
> register
>* dumps are split across different register types (where the '3' are
> global vs class
> - * vs instance). Finally, let's multiply the whole thing by 3x (just so
> we are
> - * not limited to just 1 round of data in a worst case full register
> dump log)
> - *
> - * NOTE: intel_guc_log that allocates the log buffer would round this
> size up to
> - * a power of two.
> + * vs instance).
>*/
> -
> for_each_engine(engine, gt, id) {
> worst_min_size += sizeof(struct
> guc_state_capture_group_header_t) +
>(3 * sizeof(struct
> guc_state_capture_header_t));
> @@ -649,7 +642,30 @@ intel_guc_capture_output_min_size_est(struct intel_guc
> *guc)
>
> worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
>
> - return (worst_min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER);
> + return worst_min_size;
> +}
> +
> +/*
> + * Add on a 3x multiplier to allow for multiple back-to-back captures
> occurring
> + * before the i915 can read the data out and process it
> + */
> +#define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
> +
> +static void check_guc_capture_size(struct intel_guc *guc)
> +{
> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> + int min_size = guc_capture_output_min_size_est(guc);
> + int spare_size = min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER;
> +
> + if (min_size < 0)
> + drm_warn(>drm, "Failed to calculate GuC error state
> capture buffer minimum size: %d!\n",
> + min_size);
> + else if (min_size > CAPTURE_BUFFER_SIZE)
> + drm_warn(>drm, "GuC error state capture buffer is too
> small: %d < %d\n",
> + CAPTURE_BUFFER_SIZE, min_size);
> + else if (spare_size > CAPTURE_BUFFER_SIZE)
> + drm_notice(>drm, "GuC error state capture buffer maybe
> too small: %d < %d (min = %d)\n",
> +CAPTURE_BUFFER_SIZE, spare_size, min_size);
> }
>
> /*
> @@ -1580,5 +1596,7 @@ int intel_guc_capture_init(struct intel_guc *guc)
> INIT_LIST_HEAD(>capture->outlist);
> INIT_LIST_HEAD(>capture->cachelist);
>
> +
Re: [PATCH 1/7] drm/i915/guc: Add a helper for log buffer size
Something minor in comments, so conditional R-B (please fix on the way in or
reply to correct me):
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:
> From: Alan Previn
>
> Add a helper to get GuC log buffer size.
>
> Signed-off-by: Alan Previn
> Signed-off-by: John Harrison
> Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 49 --
> 1 file changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index 25b2d7ce6640d..492bbf419d4df 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -15,6 +15,32 @@
>
> static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
>
> +static u32 intel_guc_log_size(struct intel_guc_log *log)
> +{
> + /*
> + * GuC Log buffer Layout:
> + *
> + * NB: Ordering must follow "enum guc_log_buffer_type".
> + *
> + * +===+ 00B
> + * | Debug state header |
> + * +---+ 32B
>
Something we might have missed in prior updates but i think the bufer state is
now 36 bytes long no? (9 dwords).
> + * |Crash dump state header|
> + * +---+ 64B
> + * | Capture state header |
> + * +---+ 96B
> + * | |
> + * +===+ PAGE_SIZE (4KB)
> + * | Debug logs |
> + * +===+ + DEBUG_SIZE
> + * |Crash Dump logs|
> + * +===+ + CRASH_SIZE
> + * | Capture logs |
> + * +===+ + CAPTURE_SIZE
> + */
> + return PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +
> CAPTURE_BUFFER_SIZE;
> +}
> +
> /**
> * DOC: GuC firmware log
> *
> @@ -461,32 +487,11 @@ int intel_guc_log_create(struct intel_guc_log *log)
>
> GEM_BUG_ON(log->vma);
>
> - /*
> - * GuC Log buffer Layout
> - * (this ordering must follow "enum guc_log_buffer_type" definition)
> - *
> - * +===+ 00B
> - * | Debug state header |
> - * +---+ 32B
> - * |Crash dump state header|
> - * +---+ 64B
> - * | Capture state header |
> - * +---+ 96B
> - * | |
> - * +===+ PAGE_SIZE (4KB)
> - * | Debug logs |
> - * +===+ + DEBUG_SIZE
> - * |Crash Dump logs|
> - * +===+ + CRASH_SIZE
> - * | Capture logs |
> - * +===+ + CAPTURE_SIZE
> - */
> if (intel_guc_capture_output_min_size_est(guc) > CAPTURE_BUFFER_SIZE)
> DRM_WARN("GuC log buffer for state_capture maybe too small. %d
> < %d\n",
>CAPTURE_BUFFER_SIZE,
> intel_guc_capture_output_min_size_est(guc));
>
> - guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE +
> -CAPTURE_BUFFER_SIZE;
> + guc_log_size = intel_guc_log_size(log);
>
> vma = intel_guc_allocate_vma(guc, guc_log_size);
> if (IS_ERR(vma)) {
> --
> 2.37.1
>
Re: [PATCH 3/3] drm/amd/display: Fix static declaration follows non-static declaration compiler warn
On 2022-08-01 09:52, Imre Deak wrote:
Fix the
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:951:13:
error: static declaration of ‘get_min_max_dc_plane_scaling’ follows non-static
declaration
951 | static void get_min_max_dc_plane_scaling(struct drm_device *dev,
| ^~~~
In file included from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:36:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.h:39:6: note:
previous declaration of ‘get_min_max_dc_plane_scaling’ with type ‘void(struct
drm_device *, struct drm_framebuffer *, int *, int *)’
39 | void get_min_max_dc_plane_scaling(struct drm_device *dev,
complier warning.
Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Cc: Rodrigo Siqueira
Cc: Harry Wentland
Cc: Alan Liu
Signed-off-by: Imre Deak
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
index 95168c2cfa6fa..c391f4b53 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.h
@@ -36,10 +36,6 @@ int fill_dc_scaling_info(struct amdgpu_device *adev,
const struct drm_plane_state *state,
struct dc_scaling_info *scaling_info);
-void get_min_max_dc_plane_scaling(struct drm_device *dev,
- struct drm_framebuffer *fb,
- int *min_downscale, int *max_upscale);
-
int dm_plane_helper_check_state(struct drm_plane_state *state,
struct drm_crtc_state *new_crtc_state);
Reviewed-by: Rodrigo Siqueira
Re: [PATCH 2/3] drm/amd/display: Fix 'no previous prototype' compiler warns in amdgpu_dm_plane.c
On 2022-08-01 09:52, Imre Deak wrote:
Fix compiler warnings like the following triggered by
'-Wmissing-prototypes':
CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.o
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:83:31:
warning: no previous prototype for ‘amd_get_format_info’
[-Wmissing-prototypes]
I see "‘" around "amd_get_format_info"; I'm not sure if my email
client adds that or if there is something wrong in the commit message.
With the commit message change:
Reviewed-by: Rodrigo Siqueira
const struct drm_format_info *amd_get_format_info(const struct
drm_mode_fb_cmd2 *cmd)
Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Cc: Harry Wentland
Cc: Alan Liu
Cc: Rodrigo Siqueira
Signed-off-by: Imre Deak
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 5eb5d31e591de..da3b086b0d6ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -33,6 +33,7 @@
#include "amdgpu.h"
#include "dal_asic_id.h"
#include "amdgpu_display.h"
+#include "amdgpu_dm_plane.h"
#include "amdgpu_dm_trace.h"
#include "gc/gc_11_0_0_offset.h"
#include "gc/gc_11_0_0_sh_mask.h"
Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2 backlight devices for a single display really is undesirable.
On x86 laptops where the native GPU backlight device should be used,
the registering of other backlight devices is avoided by their drivers
using acpi_video_get_backlight_type() and only registering their backlight
if the return value matches their type.
acpi_video_get_backlight_type() uses
backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
driver is available and will never return native if this returns
false. This means that the GPU's native backlight registering code
cannot just call acpi_video_get_backlight_type() to determine if it
should register its backlight, since acpi_video_get_backlight_type() will
never return native until the native backlight has already registered.
To fix this add a new internal native function parameter to
acpi_video_get_backlight_type(), which when set to true will make
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.
And add a new acpi_video_backlight_use_native() helper, which sets this
to true, for use in native GPU backlight code.
Changes in v2:
- Replace adding a native parameter to acpi_video_get_backlight_type() with
adding a new acpi_video_backlight_use_native() helper.
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 24
include/acpi/video.h | 5 +
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index becc198e4c22..4346c990022d 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,8 +17,9 @@
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * Backlight drivers can use acpi_video_get_backlight_type() to determine which
+ * driver should handle the backlight. RAW/GPU-driver backlight drivers must
+ * use the acpi_video_backlight_use_native() helper for this.
*
* If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module
(m)
* this file will not be compiled and acpi_video_get_backlight_type() will
@@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
* Arguably the native on win8 check should be done first, but that would
* be a behavior change, which may causes issues.
*/
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool native_available;
static bool init_done;
static long video_caps;
@@ -570,6 +572,8 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
backlight_notifier_registered = true;
init_done = true;
}
+ if (native)
+ native_available = true;
mutex_unlock(_mutex);
if (acpi_backlight_cmdline != acpi_backlight_undef)
@@ -581,13 +585,25 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
- if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
+ if (acpi_osi_is_win8() &&
+ (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
return acpi_backlight_native;
return acpi_backlight_video;
So I ran into a minor problem when testing the NVIDIA proprietary driver
against this change set, after checking acpi_video_backlight_use_native()
before registering the NVIDIA proprietary driver's backlight handler. Namely,
for the case where a user installs the NVIDIA proprietary driver after the
video.ko has already registered its backlight handler, we end up with both the
firmware and native handlers registered simultaneously, since the ACPI video
driver no longer unregisters its backlight handler. In this state, desktop
environments end up preferring the registered but non-functional firmware
handler from video.ko. (Manually twiddling the sysfs interface for the native
NVIDIA handler works fine.) When rebooting the system after installing the
NVIDIA proprietary driver, it is able to register its native handler before the
delayed work to register the ACPI video backlight handler fires, so we end up
with only one (native) handler, and
Re: [PATCH v2 1/3] drm/amd/display: make variables static
On 2022-08-02 09:31, André Almeida wrote:
Às 22:06 de 29/07/22, Magali Lemes escreveu:
As "dcn3_1_soc", "dcn3_15_soc", and "dcn3_16_soc" are not used outside
of their corresponding "dcn3*_fpu.c", make them static and remove their
extern declaration.
Fixes: 26f4712aedbd ("drm/amd/display: move FPU related code from dcn31 to dml/dcn31
folder")
Fixes: fa896297b31b ("drm/amd/display: move FPU related code from dcn315 to
dml/dcn31 folder")
Fixes: 3f8951cc123f ("drm/amd/display: move FPU related code from dcn316 to
dml/dcn31 folder")
Signed-off-by: Magali Lemes
Reviewed-by: Maíra Canal
Reviewed-by: Melissa Wen
---
Series is Reviewed-by: André Almeida
Series also
Reviewed-by: Rodrigo Siqueira
Applied to amd-staging-drm-next.
Thanks
Siqueira
Re: [PATCH] drm/amd/display: remove DML Makefile duplicate lines
On 2022-08-02 09:05, Harry Wentland wrote: On 2022-08-02 08:04, Magali Lemes wrote: There are two identical CFLAGS entries for "display_mode_vba_20.o", so remove one of them. Also, as there's already an entry for "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being defined or not, remove the one entry between CONFIG_DRM_AMD_DC_DCN ifdef guards. Signed-off-by: Magali Lemes Reviewed-by: Harry Wentland Harry Applied to amd-staging-drm-next. Thanks Siqueira --- drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index 359f6e9a1da0..41bb6c3cc2d8 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -61,7 +61,6 @@ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) -CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags) @@ -82,7 +81,6 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn301/dcn301_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn302/dcn302_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn303/dcn303_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dsc/rc_calc_fpu.o := $(dml_ccflags) -CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calcs.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_auto.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_math.o := $(dml_ccflags) -Wno-tautological-compare
Re: [PATCH] amdgpu: add context creation flags in CS IOCTL
On 8/2/2022 5:58 PM, Michel Dänzer wrote: On 2022-08-02 15:55, Shashank Sharma wrote: This patch adds: - A new input parameter "flags" in the amdgpu_ctx_create2 call. - Some new flags defining workload type hints. - Some change in the caller function of amdgpu_ctx_create2, to accomodate this new parameter. The idea is to pass the workload hints while context creation, so that kernel GPU scheduler can pass this information to GPU FW, which in turn can adjust the GPU characterstics as per the workload type. Signed-off-by: Shashank Sharma Cc: Alex Deucher Cc: Marek Olsak Cc: Christian Koenig Cc: Amarnath Somalapuram --- amdgpu/amdgpu.h | 2 ++ amdgpu/amdgpu_cs.c | 5 - include/drm/amdgpu_drm.h | 10 +- See include/drm/README on how to handle changes to include/drm/*_drm.h . Also, libdrm changes are now reviewed and merged as GitLab merge requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fdrm%2F-%2Fmerge_requestsdata=05%7C01%7Cshashank.sharma%40amd.com%7C50e342a42eac4d4d4fd408da749fd574%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637950527087917031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=qU41z3Hxo0jKMWgehDWLYi7r4x1QDsA%2F2KfOigj9iew%3Dreserved=0 Noted, Thanks. Regards Shashank
Re: [PATCH] amdgpu: add context creation flags in CS IOCTL
On 2022-08-02 15:55, Shashank Sharma wrote: > This patch adds: > - A new input parameter "flags" in the amdgpu_ctx_create2 call. > - Some new flags defining workload type hints. > - Some change in the caller function of amdgpu_ctx_create2, to > accomodate this new parameter. > > The idea is to pass the workload hints while context creation, so > that kernel GPU scheduler can pass this information to GPU FW, which in > turn can adjust the GPU characterstics as per the workload type. > > Signed-off-by: Shashank Sharma > Cc: Alex Deucher > Cc: Marek Olsak > Cc: Christian Koenig > Cc: Amarnath Somalapuram > --- > amdgpu/amdgpu.h | 2 ++ > amdgpu/amdgpu_cs.c | 5 - > include/drm/amdgpu_drm.h | 10 +- See include/drm/README on how to handle changes to include/drm/*_drm.h . Also, libdrm changes are now reviewed and merged as GitLab merge requests: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
[PATCH v4 15/15] drm/msm/gem: Convert to lockdep assert
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 3c6add51d13b..c4844cf3a585 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -197,8 +197,8 @@ msm_gem_unlock(struct drm_gem_object *obj)
dma_resv_unlock(obj->resv);
}
-static inline bool
-msm_gem_is_locked(struct drm_gem_object *obj)
+static inline void
+msm_gem_assert_locked(struct drm_gem_object *obj)
{
/*
* Destroying the object is a special case.. msm_gem_free_object()
@@ -212,13 +212,10 @@ msm_gem_is_locked(struct drm_gem_object *obj)
* Unfortunately lockdep is not aware of this detail. So when the
* refcount drops to zero, we pretend it is already locked.
*/
- return dma_resv_is_locked(obj->resv) || (kref_read(>refcount) ==
0);
-}
-
-static inline void
-msm_gem_assert_locked(struct drm_gem_object *obj)
-{
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ lockdep_assert_once(
+ (kref_read(>refcount) == 0) ||
+ (lockdep_is_held(>resv->lock.base) != LOCK_STATE_NOT_HELD)
+ );
}
/* imported/exported objects are not purgeable: */
--
2.36.1
[PATCH v4 09/15] drm/gem: Add LRU/shrinker helper
From: Rob Clark
Add a simple LRU helper to assist with driver's shrinker implementation.
It handles tracking the number of backing pages associated with a given
LRU, and provides a helper to implement shrinker_scan.
A driver can use multiple LRU instances to track objects in various
states, for example a dontneed LRU for purgeable objects, a willneed LRU
for evictable objects, and an unpinned LRU for objects without backing
pages.
All LRUs that the object can be moved between must share a single lock.
v2: lockdep_assert_held() instead of WARN_ON(!mutex_is_locked())
v3: make drm_gem_lru_move_tail_locked() static until there is a user
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Dmitry Osipenko
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem.c | 170 ++
include/drm/drm_gem.h | 55
2 files changed, 225 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index eb0c2d041f13..556714c10472 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -165,6 +165,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->resv = >_resv;
drm_vma_node_reset(>vma_node);
+ INIT_LIST_HEAD(>lru_node);
}
EXPORT_SYMBOL(drm_gem_private_object_init);
@@ -951,6 +952,7 @@ drm_gem_object_release(struct drm_gem_object *obj)
dma_resv_fini(>_resv);
drm_gem_free_mmap_offset(obj);
+ drm_gem_lru_remove(obj);
}
EXPORT_SYMBOL(drm_gem_object_release);
@@ -1274,3 +1276,171 @@ drm_gem_unlock_reservations(struct drm_gem_object
**objs, int count,
ww_acquire_fini(acquire_ctx);
}
EXPORT_SYMBOL(drm_gem_unlock_reservations);
+
+/**
+ * drm_gem_lru_init - initialize a LRU
+ *
+ * @lru: The LRU to initialize
+ * @lock: The lock protecting the LRU
+ */
+void
+drm_gem_lru_init(struct drm_gem_lru *lru, struct mutex *lock)
+{
+ lru->lock = lock;
+ lru->count = 0;
+ INIT_LIST_HEAD(>list);
+}
+EXPORT_SYMBOL(drm_gem_lru_init);
+
+static void
+drm_gem_lru_remove_locked(struct drm_gem_object *obj)
+{
+ obj->lru->count -= obj->size >> PAGE_SHIFT;
+ WARN_ON(obj->lru->count < 0);
+ list_del(>lru_node);
+ obj->lru = NULL;
+}
+
+/**
+ * drm_gem_lru_remove - remove object from whatever LRU it is in
+ *
+ * If the object is currently in any LRU, remove it.
+ *
+ * @obj: The GEM object to remove from current LRU
+ */
+void
+drm_gem_lru_remove(struct drm_gem_object *obj)
+{
+ struct drm_gem_lru *lru = obj->lru;
+
+ if (!lru)
+ return;
+
+ mutex_lock(lru->lock);
+ drm_gem_lru_remove_locked(obj);
+ mutex_unlock(lru->lock);
+}
+EXPORT_SYMBOL(drm_gem_lru_remove);
+
+static void
+drm_gem_lru_move_tail_locked(struct drm_gem_lru *lru, struct drm_gem_object
*obj)
+{
+ lockdep_assert_held_once(lru->lock);
+
+ if (obj->lru)
+ drm_gem_lru_remove_locked(obj);
+
+ lru->count += obj->size >> PAGE_SHIFT;
+ list_add_tail(>lru_node, >list);
+ obj->lru = lru;
+}
+
+/**
+ * drm_gem_lru_move_tail - move the object to the tail of the LRU
+ *
+ * If the object is already in this LRU it will be moved to the
+ * tail. Otherwise it will be removed from whichever other LRU
+ * it is in (if any) and moved into this LRU.
+ *
+ * @lru: The LRU to move the object into.
+ * @obj: The GEM object to move into this LRU
+ */
+void
+drm_gem_lru_move_tail(struct drm_gem_lru *lru, struct drm_gem_object *obj)
+{
+ mutex_lock(lru->lock);
+ drm_gem_lru_move_tail_locked(lru, obj);
+ mutex_unlock(lru->lock);
+}
+EXPORT_SYMBOL(drm_gem_lru_move_tail);
+
+/**
+ * drm_gem_lru_scan - helper to implement shrinker.scan_objects
+ *
+ * If the shrink callback succeeds, it is expected that the driver
+ * move the object out of this LRU.
+ *
+ * If the LRU possibly contain active buffers, it is the responsibility
+ * of the shrink callback to check for this (ie. dma_resv_test_signaled())
+ * or if necessary block until the buffer becomes idle.
+ *
+ * @lru: The LRU to scan
+ * @nr_to_scan: The number of pages to try to reclaim
+ * @shrink: Callback to try to shrink/reclaim the object.
+ */
+unsigned long
+drm_gem_lru_scan(struct drm_gem_lru *lru, unsigned nr_to_scan,
+bool (*shrink)(struct drm_gem_object *obj))
+{
+ struct drm_gem_lru still_in_lru;
+ struct drm_gem_object *obj;
+ unsigned freed = 0;
+
+ drm_gem_lru_init(_in_lru, lru->lock);
+
+ mutex_lock(lru->lock);
+
+ while (freed < nr_to_scan) {
+ obj = list_first_entry_or_null(>list, typeof(*obj),
lru_node);
+
+ if (!obj)
+ break;
+
+ drm_gem_lru_move_tail_locked(_in_lru, obj);
+
+ /*
+* If it's in the process of being freed, gem_object->free()
+* may be blocked on lock waiting to remove it. So just
+* skip it.
+
[PATCH v4 14/15] drm/msm/gem: Add msm_gem_assert_locked()
From: Rob Clark
All use of msm_gem_is_locked() is just for WARN_ON()s, so extract out
into an msm_gem_assert_locked() patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 36 +--
drivers/gpu/drm/msm/msm_gem.h | 8 +++-
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index d4e8af46f4ef..1dee0d18abbb 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -97,7 +97,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
if (!msm_obj->pages) {
struct drm_device *dev = obj->dev;
@@ -183,7 +183,7 @@ static struct page **msm_gem_pin_pages_locked(struct
drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct page **p;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
if (GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
return ERR_PTR(-EBUSY);
@@ -278,7 +278,7 @@ static uint64_t mmap_offset(struct drm_gem_object *obj)
struct drm_device *dev = obj->dev;
int ret;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
/* Make it mmapable */
ret = drm_gem_create_mmap_offset(obj);
@@ -307,7 +307,7 @@ static struct msm_gem_vma *add_vma(struct drm_gem_object
*obj,
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
vma = kzalloc(sizeof(*vma), GFP_KERNEL);
if (!vma)
@@ -326,7 +326,7 @@ static struct msm_gem_vma *lookup_vma(struct drm_gem_object
*obj,
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
list_for_each_entry(vma, _obj->vmas, list) {
if (vma->aspace == aspace)
@@ -357,7 +357,7 @@ put_iova_spaces(struct drm_gem_object *obj, bool close)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
list_for_each_entry(vma, _obj->vmas, list) {
if (vma->aspace) {
@@ -375,7 +375,7 @@ put_iova_vmas(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma, *tmp;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
list_for_each_entry_safe(vma, tmp, _obj->vmas, list) {
del_vma(vma);
@@ -388,7 +388,7 @@ static struct msm_gem_vma *get_vma_locked(struct
drm_gem_object *obj,
{
struct msm_gem_vma *vma;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
vma = lookup_vma(obj, aspace);
@@ -428,7 +428,7 @@ int msm_gem_pin_vma_locked(struct drm_gem_object *obj,
struct msm_gem_vma *vma)
if (msm_obj->flags & MSM_BO_CACHED_COHERENT)
prot |= IOMMU_CACHE;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
if (GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
return -EBUSY;
@@ -448,7 +448,7 @@ void msm_gem_unpin_locked(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
msm_obj->pin_count--;
GEM_WARN_ON(msm_obj->pin_count < 0);
@@ -469,7 +469,7 @@ static int get_and_pin_iova_range_locked(struct
drm_gem_object *obj,
struct msm_gem_vma *vma;
int ret;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
vma = get_vma_locked(obj, aspace, range_start, range_end);
if (IS_ERR(vma))
@@ -630,7 +630,7 @@ static void *get_vaddr(struct drm_gem_object *obj, unsigned
madv)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
int ret = 0;
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
if (obj->import_attach)
return ERR_PTR(-ENODEV);
@@ -703,7 +703,7 @@ void msm_gem_put_vaddr_locked(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
GEM_WARN_ON(msm_obj->vmap_count < 1);
msm_obj->vmap_count--;
@@ -745,7 +745,7 @@ void msm_gem_purge(struct drm_gem_object *obj)
struct drm_device *dev = obj->dev;
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- GEM_WARN_ON(!msm_gem_is_locked(obj));
+ msm_gem_assert_locked(obj);
[PATCH v4 12/15] drm/msm/gem: Consolidate shrinker trace
From: Rob Clark
Combine separate trace events for purge vs evict into one. When we add
support for purging/evicting active buffers we'll just add more info
into this one trace event, rather than adding a bunch more events.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 19 ++-
drivers/gpu/drm/msm/msm_gpu_trace.h| 32 +++---
2 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 530b1102b46d..5cc05d669a08 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -71,25 +71,20 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
struct msm_drm_private *priv =
container_of(shrinker, struct msm_drm_private, shrinker);
long nr = sc->nr_to_scan;
- unsigned long freed;
+ unsigned long freed, purged, evicted = 0;
- freed = drm_gem_lru_scan(>lru.dontneed, nr, purge);
- nr -= freed;
-
- if (freed > 0)
- trace_msm_gem_purge(freed << PAGE_SHIFT);
+ purged = drm_gem_lru_scan(>lru.dontneed, nr, purge);
+ nr -= purged;
if (can_swap() && nr > 0) {
- unsigned long evicted;
-
evicted = drm_gem_lru_scan(>lru.willneed, nr, evict);
nr -= evicted;
+ }
- if (evicted > 0)
- trace_msm_gem_evict(evicted << PAGE_SHIFT);
+ freed = purged + evicted;
- freed += evicted;
- }
+ if (freed)
+ trace_msm_gem_shrink(sc->nr_to_scan, purged, evicted);
return (freed > 0) ? freed : SHRINK_STOP;
}
diff --git a/drivers/gpu/drm/msm/msm_gpu_trace.h
b/drivers/gpu/drm/msm/msm_gpu_trace.h
index ca0b08d7875b..8867fa0a0306 100644
--- a/drivers/gpu/drm/msm/msm_gpu_trace.h
+++ b/drivers/gpu/drm/msm/msm_gpu_trace.h
@@ -115,29 +115,23 @@ TRACE_EVENT(msm_gmu_freq_change,
);
-TRACE_EVENT(msm_gem_purge,
- TP_PROTO(u32 bytes),
- TP_ARGS(bytes),
+TRACE_EVENT(msm_gem_shrink,
+ TP_PROTO(u32 nr_to_scan, u32 purged, u32 evicted),
+ TP_ARGS(nr_to_scan, purged, evicted),
TP_STRUCT__entry(
- __field(u32, bytes)
+ __field(u32, nr_to_scan)
+ __field(u32, purged)
+ __field(u32, evicted)
),
TP_fast_assign(
- __entry->bytes = bytes;
+ __entry->nr_to_scan = nr_to_scan;
+ __entry->purged = purged;
+ __entry->evicted = evicted;
),
- TP_printk("Purging %u bytes", __entry->bytes)
-);
-
-
-TRACE_EVENT(msm_gem_evict,
- TP_PROTO(u32 bytes),
- TP_ARGS(bytes),
- TP_STRUCT__entry(
- __field(u32, bytes)
- ),
- TP_fast_assign(
- __entry->bytes = bytes;
- ),
- TP_printk("Evicting %u bytes", __entry->bytes)
+ TP_printk("nr_to_scan=%u pages, purged=%u pages, evicted=%u
pages",
+ __entry->nr_to_scan,
+ __entry->purged,
+ __entry->evicted)
);
--
2.36.1
[PATCH v4 11/15] drm/msm/gem: Unpin buffers earlier
From: Rob Clark
We've already attached the fences, so obj->resv (which shrinker checks)
tells us whether they are still active. So we can unpin sooner, before
we drop the queue lock.
This also avoids the need to grab the obj lock in the retire path,
avoiding potential for lock contention between submit and retire.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index adf358fb8e9d..5599d93ec0d2 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -501,11 +501,11 @@ static int submit_reloc(struct msm_gem_submit *submit,
struct msm_gem_object *ob
*/
static void submit_cleanup(struct msm_gem_submit *submit, bool error)
{
- unsigned cleanup_flags = BO_LOCKED;
+ unsigned cleanup_flags = BO_LOCKED | BO_OBJ_PINNED;
unsigned i;
if (error)
- cleanup_flags |= BO_VMA_PINNED | BO_OBJ_PINNED;
+ cleanup_flags |= BO_VMA_PINNED;
for (i = 0; i < submit->nr_bos; i++) {
struct msm_gem_object *msm_obj = submit->bos[i].obj;
@@ -522,10 +522,6 @@ void msm_submit_retire(struct msm_gem_submit *submit)
for (i = 0; i < submit->nr_bos; i++) {
struct drm_gem_object *obj = >bos[i].obj->base;
- msm_gem_lock(obj);
- /* Note, VMA already fence-unpinned before submit: */
- submit_cleanup_bo(submit, i, BO_OBJ_PINNED);
- msm_gem_unlock(obj);
drm_gem_object_put(obj);
}
}
--
2.36.1
[PATCH v4 13/15] drm/msm/gem: Evict active GEM objects when necessary
From: Rob Clark
If we are under enough memory pressure, we should stall waiting for
active buffers to become idle in order to evict.
v2: Check for __GFP_ATOMIC before blocking
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 70 +-
drivers/gpu/drm/msm/msm_gpu_trace.h| 16 +++---
2 files changed, 68 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 5cc05d669a08..f31054d25314 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -24,6 +24,13 @@ static bool can_swap(void)
return enable_eviction && get_nr_swap_pages() > 0;
}
+static bool can_block(struct shrink_control *sc)
+{
+ if (sc->gfp_mask & __GFP_ATOMIC)
+ return false;
+ return current_is_kswapd() || (sc->gfp_mask & __GFP_RECLAIM);
+}
+
static unsigned long
msm_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control *sc)
{
@@ -65,26 +72,65 @@ evict(struct drm_gem_object *obj)
return true;
}
+static bool
+wait_for_idle(struct drm_gem_object *obj)
+{
+ enum dma_resv_usage usage = dma_resv_usage_rw(true);
+ return dma_resv_wait_timeout(obj->resv, usage, false, 1000) > 0;
+}
+
+static bool
+active_purge(struct drm_gem_object *obj)
+{
+ if (!wait_for_idle(obj))
+ return false;
+
+ return purge(obj);
+}
+
+static bool
+active_evict(struct drm_gem_object *obj)
+{
+ if (!wait_for_idle(obj))
+ return false;
+
+ return evict(obj);
+}
+
static unsigned long
msm_gem_shrinker_scan(struct shrinker *shrinker, struct shrink_control *sc)
{
struct msm_drm_private *priv =
container_of(shrinker, struct msm_drm_private, shrinker);
+ struct {
+ struct drm_gem_lru *lru;
+ bool (*shrink)(struct drm_gem_object *obj);
+ bool cond;
+ unsigned long freed;
+ } stages[] = {
+ /* Stages of progressively more aggressive/expensive reclaim: */
+ { >lru.dontneed, purge,true },
+ { >lru.willneed, evict,can_swap() },
+ { >lru.dontneed, active_purge, can_block(sc) },
+ { >lru.willneed, active_evict, can_swap() &&
can_block(sc) },
+ };
long nr = sc->nr_to_scan;
- unsigned long freed, purged, evicted = 0;
-
- purged = drm_gem_lru_scan(>lru.dontneed, nr, purge);
- nr -= purged;
-
- if (can_swap() && nr > 0) {
- evicted = drm_gem_lru_scan(>lru.willneed, nr, evict);
- nr -= evicted;
+ unsigned long freed = 0;
+
+ for (unsigned i = 0; (nr > 0) && (i < ARRAY_SIZE(stages)); i++) {
+ if (!stages[i].cond)
+ continue;
+ stages[i].freed =
+ drm_gem_lru_scan(stages[i].lru, nr, stages[i].shrink);
+ nr -= stages[i].freed;
+ freed += stages[i].freed;
}
- freed = purged + evicted;
-
- if (freed)
- trace_msm_gem_shrink(sc->nr_to_scan, purged, evicted);
+ if (freed) {
+ trace_msm_gem_shrink(sc->nr_to_scan, stages[0].freed,
+stages[1].freed, stages[2].freed,
+stages[3].freed);
+ }
return (freed > 0) ? freed : SHRINK_STOP;
}
diff --git a/drivers/gpu/drm/msm/msm_gpu_trace.h
b/drivers/gpu/drm/msm/msm_gpu_trace.h
index 8867fa0a0306..ac40d857bc45 100644
--- a/drivers/gpu/drm/msm/msm_gpu_trace.h
+++ b/drivers/gpu/drm/msm/msm_gpu_trace.h
@@ -116,22 +116,26 @@ TRACE_EVENT(msm_gmu_freq_change,
TRACE_EVENT(msm_gem_shrink,
- TP_PROTO(u32 nr_to_scan, u32 purged, u32 evicted),
- TP_ARGS(nr_to_scan, purged, evicted),
+ TP_PROTO(u32 nr_to_scan, u32 purged, u32 evicted,
+u32 active_purged, u32 active_evicted),
+ TP_ARGS(nr_to_scan, purged, evicted, active_purged,
active_evicted),
TP_STRUCT__entry(
__field(u32, nr_to_scan)
__field(u32, purged)
__field(u32, evicted)
+ __field(u32, active_purged)
+ __field(u32, active_evicted)
),
TP_fast_assign(
__entry->nr_to_scan = nr_to_scan;
__entry->purged = purged;
__entry->evicted = evicted;
+ __entry->active_purged = active_purged;
+ __entry->active_evicted = active_evicted;
),
- TP_printk("nr_to_scan=%u pages, purged=%u pages, evicted=%u
pages",
- __entry->nr_to_scan,
- __entry->purged,
- __entry->evicted)
+
[PATCH v4 10/15] drm/msm/gem: Convert to using drm_gem_lru
From: Rob Clark
This converts over to use the shared GEM LRU/shrinker helpers. Note
that it means we are no longer tracking purgeable or willneed buffers
that are active separately. But the most recently pinned buffers should
be at the tail of the various LRUs, and the shrinker is already prepared
to encounter objects which are still active.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 14 +--
drivers/gpu/drm/msm/msm_drv.h | 70 +++
drivers/gpu/drm/msm/msm_gem.c | 58
drivers/gpu/drm/msm/msm_gem.h | 93
drivers/gpu/drm/msm/msm_gem_shrinker.c | 117 ++---
drivers/gpu/drm/msm/msm_gpu.c | 3 -
drivers/gpu/drm/msm/msm_gpu.h | 6 --
7 files changed, 104 insertions(+), 257 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d7ca025457b6..1ca4a92ba96e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -418,14 +418,18 @@ static int msm_drm_init(struct device *dev, const struct
drm_driver *drv)
INIT_LIST_HEAD(>objects);
mutex_init(>obj_lock);
- INIT_LIST_HEAD(>inactive_willneed);
- INIT_LIST_HEAD(>inactive_dontneed);
- INIT_LIST_HEAD(>inactive_unpinned);
- mutex_init(>mm_lock);
+ /*
+* Initialize the LRUs:
+*/
+ mutex_init(>lru.lock);
+ drm_gem_lru_init(>lru.unbacked, >lru.lock);
+ drm_gem_lru_init(>lru.pinned, >lru.lock);
+ drm_gem_lru_init(>lru.willneed, >lru.lock);
+ drm_gem_lru_init(>lru.dontneed, >lru.lock);
/* Teach lockdep about lock ordering wrt. shrinker: */
fs_reclaim_acquire(GFP_KERNEL);
- might_lock(>mm_lock);
+ might_lock(>lru.lock);
fs_reclaim_release(GFP_KERNEL);
drm_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b3689a2d27d7..208ae5bc5e6b 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -142,28 +142,60 @@ struct msm_drm_private {
struct mutex obj_lock;
/**
-* LRUs of inactive GEM objects. Every bo is either in one of the
-* inactive lists (depending on whether or not it is shrinkable) or
-* gpu->active_list (for the gpu it is active on[1]), or transiently
-* on a temporary list as the shrinker is running.
+* lru:
*
-* Note that inactive_willneed also contains pinned and vmap'd bos,
-* but the number of pinned-but-not-active objects is small (scanout
-* buffers, ringbuffer, etc).
+* The various LRU's that a GEM object is in at various stages of
+* it's lifetime. Objects start out in the unbacked LRU. When
+* pinned (for scannout or permanently mapped GPU buffers, like
+* ringbuffer, memptr, fw, etc) it moves to the pinned LRU. When
+* unpinned, it moves into willneed or dontneed LRU depending on
+* madvise state. When backing pages are evicted (willneed) or
+* purged (dontneed) it moves back into the unbacked LRU.
*
-* These lists are protected by mm_lock (which should be acquired
-* before per GEM object lock). One should *not* hold mm_lock in
-* get_pages()/vmap()/etc paths, as they can trigger the shrinker.
-*
-* [1] if someone ever added support for the old 2d cores, there could
be
-* more than one gpu object
+* The dontneed LRU is considered by the shrinker for objects
+* that are candidate for purging, and the willneed LRU is
+* considered for objects that could be evicted.
*/
- struct list_head inactive_willneed; /* inactive + potentially
unpin/evictable */
- struct list_head inactive_dontneed; /* inactive + shrinkable */
- struct list_head inactive_unpinned; /* inactive + purged or unpinned */
- long shrinkable_count; /* write access under mm_lock */
- long evictable_count;/* write access under mm_lock */
- struct mutex mm_lock;
+ struct {
+ /**
+* unbacked:
+*
+* The LRU for GEM objects without backing pages allocated.
+* This mostly exists so that objects are always is one
+* LRU.
+*/
+ struct drm_gem_lru unbacked;
+
+ /**
+* pinned:
+*
+* The LRU for pinned GEM objects
+*/
+ struct drm_gem_lru pinned;
+
+ /**
+* willneed:
+*
+* The LRU for unpinned GEM objects which are in madvise
+* WILLNEED state (ie. can be evicted)
+*/
+ struct drm_gem_lru willneed;
+
+ /**
+*
[PATCH v4 08/15] drm/msm/gem: Remove active refcnt
From: Rob Clark
At this point the pinned refcnt is sufficient, and the shrinker is
already prepared to encounter objects which are still active according
to fences attached to the resv.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 45 ++--
drivers/gpu/drm/msm/msm_gem.h| 14 ++---
drivers/gpu/drm/msm/msm_gem_submit.c | 22 ++
3 files changed, 8 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 407b18a24dc4..209438744bab 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -734,8 +734,7 @@ int msm_gem_madvise(struct drm_gem_object *obj, unsigned
madv)
/* If the obj is inactive, we might need to move it
* between inactive lists
*/
- if (msm_obj->active_count == 0)
- update_lru(obj);
+ update_lru(obj);
msm_gem_unlock(obj);
@@ -788,7 +787,6 @@ void msm_gem_evict(struct drm_gem_object *obj)
GEM_WARN_ON(!msm_gem_is_locked(obj));
GEM_WARN_ON(is_unevictable(msm_obj));
GEM_WARN_ON(!msm_obj->evictable);
- GEM_WARN_ON(msm_obj->active_count);
/* Get rid of any iommu mapping(s): */
put_iova_spaces(obj, false);
@@ -813,37 +811,6 @@ void msm_gem_vunmap(struct drm_gem_object *obj)
msm_obj->vaddr = NULL;
}
-void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu)
-{
- struct msm_gem_object *msm_obj = to_msm_bo(obj);
- struct msm_drm_private *priv = obj->dev->dev_private;
-
- might_sleep();
- GEM_WARN_ON(!msm_gem_is_locked(obj));
- GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
- GEM_WARN_ON(msm_obj->dontneed);
-
- if (msm_obj->active_count++ == 0) {
- mutex_lock(>mm_lock);
- if (msm_obj->evictable)
- mark_unevictable(msm_obj);
- list_move_tail(_obj->mm_list, >active_list);
- mutex_unlock(>mm_lock);
- }
-}
-
-void msm_gem_active_put(struct drm_gem_object *obj)
-{
- struct msm_gem_object *msm_obj = to_msm_bo(obj);
-
- might_sleep();
- GEM_WARN_ON(!msm_gem_is_locked(obj));
-
- if (--msm_obj->active_count == 0) {
- update_lru(obj);
- }
-}
-
static void update_lru(struct drm_gem_object *obj)
{
struct msm_drm_private *priv = obj->dev->dev_private;
@@ -851,9 +818,6 @@ static void update_lru(struct drm_gem_object *obj)
GEM_WARN_ON(!msm_gem_is_locked(_obj->base));
- if (msm_obj->active_count != 0)
- return;
-
mutex_lock(>mm_lock);
if (msm_obj->dontneed)
@@ -926,7 +890,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m,
stats->all.count++;
stats->all.size += obj->size;
- if (is_active(msm_obj)) {
+ if (msm_gem_active(obj)) {
stats->active.count++;
stats->active.size += obj->size;
}
@@ -954,7 +918,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m,
}
seq_printf(m, "%08x: %c %2d (%2d) %08llx %p",
- msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
+ msm_obj->flags, msm_gem_active(obj) ? 'A' : 'I',
obj->name, kref_read(>refcount),
off, msm_obj->vaddr);
@@ -1037,9 +1001,6 @@ static void msm_gem_free_object(struct drm_gem_object
*obj)
list_del(_obj->mm_list);
mutex_unlock(>mm_lock);
- /* object should not be on active list: */
- GEM_WARN_ON(is_active(msm_obj));
-
put_iova_spaces(obj, true);
if (obj->import_attach) {
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 6fe521ccda45..420ba49bf21a 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -138,7 +138,6 @@ struct msm_gem_object {
char name[32]; /* Identifier to print for the debugfs files */
- int active_count;
int pin_count;
};
#define to_msm_bo(x) container_of(x, struct msm_gem_object, base)
@@ -171,8 +170,6 @@ void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
void msm_gem_put_vaddr_locked(struct drm_gem_object *obj);
void msm_gem_put_vaddr(struct drm_gem_object *obj);
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
-void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu);
-void msm_gem_active_put(struct drm_gem_object *obj);
bool msm_gem_active(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
@@ -245,12 +242,6 @@ msm_gem_is_locked(struct drm_gem_object *obj)
return dma_resv_is_locked(obj->resv) || (kref_read(>refcount) ==
0);
}
-static inline bool is_active(struct msm_gem_object *msm_obj)
-{
-
[PATCH v4 06/15] drm/msm/gem: Rename to pin/unpin_pages
From: Rob Clark
Since that is what these fxns actually do.. they are getting *pinned*
pages (as opposed to cases where we need pages, but don't need them
pinned, like CPU mappings).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 18 +-
drivers/gpu/drm/msm/msm_gem.h | 4 ++--
drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 97467364dc0a..3da64c7f65a2 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -177,30 +177,38 @@ static void put_pages(struct drm_gem_object *obj)
}
}
-struct page **msm_gem_get_pages(struct drm_gem_object *obj)
+static struct page **msm_gem_pin_pages_locked(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct page **p;
- msm_gem_lock(obj);
+ GEM_WARN_ON(!msm_gem_is_locked(obj));
if (GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
- msm_gem_unlock(obj);
return ERR_PTR(-EBUSY);
}
p = get_pages(obj);
-
if (!IS_ERR(p)) {
msm_obj->pin_count++;
update_lru(obj);
}
+ return p;
+}
+
+struct page **msm_gem_pin_pages(struct drm_gem_object *obj)
+{
+ struct page **p;
+
+ msm_gem_lock(obj);
+ p = msm_gem_pin_pages_locked(obj);
msm_gem_unlock(obj);
+
return p;
}
-void msm_gem_put_pages(struct drm_gem_object *obj)
+void msm_gem_unpin_pages(struct drm_gem_object *obj)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 0ab0dc4f8c25..6fe521ccda45 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -159,8 +159,8 @@ int msm_gem_get_and_pin_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
void msm_gem_unpin_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace);
-struct page **msm_gem_get_pages(struct drm_gem_object *obj);
-void msm_gem_put_pages(struct drm_gem_object *obj);
+struct page **msm_gem_pin_pages(struct drm_gem_object *obj);
+void msm_gem_unpin_pages(struct drm_gem_object *obj);
int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c
b/drivers/gpu/drm/msm/msm_gem_prime.c
index dcc8a573bc76..c1d91863df05 100644
--- a/drivers/gpu/drm/msm/msm_gem_prime.c
+++ b/drivers/gpu/drm/msm/msm_gem_prime.c
@@ -63,12 +63,12 @@ struct drm_gem_object *msm_gem_prime_import_sg_table(struct
drm_device *dev,
int msm_gem_prime_pin(struct drm_gem_object *obj)
{
if (!obj->import_attach)
- msm_gem_get_pages(obj);
+ msm_gem_pin_pages(obj);
return 0;
}
void msm_gem_prime_unpin(struct drm_gem_object *obj)
{
if (!obj->import_attach)
- msm_gem_put_pages(obj);
+ msm_gem_unpin_pages(obj);
}
--
2.36.1
[PATCH v4 04/15] drm/msm/gem: Check for active in shrinker path
From: Rob Clark
Currently in our shrinker path we shouldn't be encountering anything
that is active, but this will change in subsequent patches. So check
if there are unsignaled fences.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 10 ++
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gem_shrinker.c | 6 ++
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 8ddbd2e001d4..b55d252aef17 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -870,6 +870,16 @@ static void update_inactive(struct msm_gem_object *msm_obj)
mutex_unlock(>mm_lock);
}
+bool msm_gem_active(struct drm_gem_object *obj)
+{
+ GEM_WARN_ON(!msm_gem_is_locked(obj));
+
+ if (to_msm_bo(obj)->pin_count)
+ return true;
+
+ return !dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true));
+}
+
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout)
{
bool write = !!(op & MSM_PREP_WRITE);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 432032ad4aed..0ab0dc4f8c25 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -173,6 +173,7 @@ void msm_gem_put_vaddr(struct drm_gem_object *obj);
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu);
void msm_gem_active_put(struct drm_gem_object *obj);
+bool msm_gem_active(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 6e39d959b9f0..ea8ed74982c1 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -43,6 +43,9 @@ purge(struct msm_gem_object *msm_obj)
if (!is_purgeable(msm_obj))
return false;
+ if (msm_gem_active(_obj->base))
+ return false;
+
/*
* This will move the obj out of still_in_list to
* the purged list
@@ -58,6 +61,9 @@ evict(struct msm_gem_object *msm_obj)
if (is_unevictable(msm_obj))
return false;
+ if (msm_gem_active(_obj->base))
+ return false;
+
msm_gem_evict(_obj->base);
return true;
--
2.36.1
[PATCH v4 03/15] drm/msm: Split out idr_lock
From: Rob Clark
Otherwise if we hit reclaim pinning objects in the submit path, we'll be
blocking retire_worker trying to free a submit.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
drivers/gpu/drm/msm/msm_gem_submit.c | 10 --
drivers/gpu/drm/msm/msm_gpu.h | 4 +++-
drivers/gpu/drm/msm/msm_submitqueue.c | 1 +
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1ed4cd09dbf8..d7ca025457b6 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -883,13 +883,13 @@ static int wait_fence(struct msm_gpu_submitqueue *queue,
uint32_t fence_id,
* retired, so if the fence is not found it means there is nothing
* to wait for
*/
- ret = mutex_lock_interruptible(>lock);
+ ret = mutex_lock_interruptible(>idr_lock);
if (ret)
return ret;
fence = idr_find(>fence_idr, fence_id);
if (fence)
fence = dma_fence_get_rcu(fence);
- mutex_unlock(>lock);
+ mutex_unlock(>idr_lock);
if (!fence)
return 0;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index c7819781879c..16c662808522 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -72,9 +72,9 @@ void __msm_gem_submit_destroy(struct kref *kref)
unsigned i;
if (submit->fence_id) {
- mutex_lock(>queue->lock);
+ mutex_lock(>queue->idr_lock);
idr_remove(>queue->fence_idr, submit->fence_id);
- mutex_unlock(>queue->lock);
+ mutex_unlock(>queue->idr_lock);
}
dma_fence_put(submit->user_fence);
@@ -881,6 +881,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit->nr_cmds = i;
+ mutex_lock(>idr_lock);
+
/*
* If using userspace provided seqno fence, validate that the id
* is available before arming sched job. Since access to fence_idr
@@ -889,6 +891,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
*/
if ((args->flags & MSM_SUBMIT_FENCE_SN_IN) &&
idr_find(>fence_idr, args->fence)) {
+ mutex_unlock(>idr_lock);
ret = -EINVAL;
goto out;
}
@@ -921,6 +924,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
submit->user_fence, 1,
INT_MAX, GFP_KERNEL);
}
+
+ mutex_unlock(>idr_lock);
+
if (submit->fence_id < 0) {
ret = submit->fence_id;
submit->fence_id = 0;
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 4d935fedd2ac..962d2070bcdf 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -466,7 +466,8 @@ static inline int msm_gpu_convert_priority(struct msm_gpu
*gpu, int prio,
* @node: node in the context's list of submitqueues
* @fence_idr: maps fence-id to dma_fence for userspace visible fence
* seqno, protected by submitqueue lock
- * @lock: submitqueue lock
+ * @idr_lock: for serializing access to fence_idr
+ * @lock: submitqueue lock for serializing submits on a queue
* @ref: reference count
* @entity:the submit job-queue
*/
@@ -479,6 +480,7 @@ struct msm_gpu_submitqueue {
struct msm_file_private *ctx;
struct list_head node;
struct idr fence_idr;
+ struct mutex idr_lock;
struct mutex lock;
struct kref ref;
struct drm_sched_entity *entity;
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c
b/drivers/gpu/drm/msm/msm_submitqueue.c
index f486a3cd4e55..c6929e205b51 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -200,6 +200,7 @@ int msm_submitqueue_create(struct drm_device *drm, struct
msm_file_private *ctx,
*id = queue->id;
idr_init(>fence_idr);
+ mutex_init(>idr_lock);
mutex_init(>lock);
list_add_tail(>node, >submitqueues);
--
2.36.1
[PATCH v4 07/15] drm/msm/gem: Consolidate pin/unpin paths
From: Rob Clark
Avoid having multiple spots where we increment/decrement pin_count (and
associated LRU updating)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 3da64c7f65a2..407b18a24dc4 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -190,7 +190,7 @@ static struct page **msm_gem_pin_pages_locked(struct
drm_gem_object *obj)
p = get_pages(obj);
if (!IS_ERR(p)) {
- msm_obj->pin_count++;
+ to_msm_bo(obj)->pin_count++;
update_lru(obj);
}
@@ -213,9 +213,7 @@ void msm_gem_unpin_pages(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
msm_gem_lock(obj);
- msm_obj->pin_count--;
- GEM_WARN_ON(msm_obj->pin_count < 0);
- update_lru(obj);
+ msm_gem_unpin_locked(obj);
msm_gem_unlock(obj);
}
@@ -436,14 +434,13 @@ int msm_gem_pin_vma_locked(struct drm_gem_object *obj,
struct msm_gem_vma *vma)
if (GEM_WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
return -EBUSY;
- pages = get_pages(obj);
+ pages = msm_gem_pin_pages_locked(obj);
if (IS_ERR(pages))
return PTR_ERR(pages);
ret = msm_gem_map_vma(vma->aspace, vma, prot, msm_obj->sgt, obj->size);
-
- if (!ret)
- msm_obj->pin_count++;
+ if (ret)
+ msm_gem_unpin_locked(obj);
return ret;
}
--
2.36.1
[PATCH v4 05/15] drm/msm/gem: Rename update_inactive
From: Rob Clark
Really what this is doing is updating various LRU lists.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index b55d252aef17..97467364dc0a 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -19,7 +19,7 @@
#include "msm_gpu.h"
#include "msm_mmu.h"
-static void update_inactive(struct msm_gem_object *msm_obj);
+static void update_lru(struct drm_gem_object *obj);
static dma_addr_t physaddr(struct drm_gem_object *obj)
{
@@ -132,7 +132,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
if (msm_obj->flags & MSM_BO_WC)
sync_for_device(msm_obj);
- update_inactive(msm_obj);
+ update_lru(obj);
}
return msm_obj->pages;
@@ -193,7 +193,7 @@ struct page **msm_gem_get_pages(struct drm_gem_object *obj)
if (!IS_ERR(p)) {
msm_obj->pin_count++;
- update_inactive(msm_obj);
+ update_lru(obj);
}
msm_gem_unlock(obj);
@@ -207,7 +207,7 @@ void msm_gem_put_pages(struct drm_gem_object *obj)
msm_gem_lock(obj);
msm_obj->pin_count--;
GEM_WARN_ON(msm_obj->pin_count < 0);
- update_inactive(msm_obj);
+ update_lru(obj);
msm_gem_unlock(obj);
}
@@ -449,7 +449,7 @@ void msm_gem_unpin_locked(struct drm_gem_object *obj)
msm_obj->pin_count--;
GEM_WARN_ON(msm_obj->pin_count < 0);
- update_inactive(msm_obj);
+ update_lru(obj);
}
struct msm_gem_vma *msm_gem_get_vma_locked(struct drm_gem_object *obj,
@@ -658,7 +658,7 @@ static void *get_vaddr(struct drm_gem_object *obj, unsigned
madv)
goto fail;
}
- update_inactive(msm_obj);
+ update_lru(obj);
}
return msm_obj->vaddr;
@@ -730,7 +730,7 @@ int msm_gem_madvise(struct drm_gem_object *obj, unsigned
madv)
* between inactive lists
*/
if (msm_obj->active_count == 0)
- update_inactive(msm_obj);
+ update_lru(obj);
msm_gem_unlock(obj);
@@ -757,7 +757,7 @@ void msm_gem_purge(struct drm_gem_object *obj)
put_iova_vmas(obj);
msm_obj->madv = __MSM_MADV_PURGED;
- update_inactive(msm_obj);
+ update_lru(obj);
drm_gem_free_mmap_offset(obj);
@@ -792,7 +792,7 @@ void msm_gem_evict(struct drm_gem_object *obj)
put_pages(obj);
- update_inactive(msm_obj);
+ update_lru(obj);
}
void msm_gem_vunmap(struct drm_gem_object *obj)
@@ -835,13 +835,14 @@ void msm_gem_active_put(struct drm_gem_object *obj)
GEM_WARN_ON(!msm_gem_is_locked(obj));
if (--msm_obj->active_count == 0) {
- update_inactive(msm_obj);
+ update_lru(obj);
}
}
-static void update_inactive(struct msm_gem_object *msm_obj)
+static void update_lru(struct drm_gem_object *obj)
{
- struct msm_drm_private *priv = msm_obj->base.dev->dev_private;
+ struct msm_drm_private *priv = obj->dev->dev_private;
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
GEM_WARN_ON(!msm_gem_is_locked(_obj->base));
--
2.36.1
[PATCH v4 02/15] drm/msm: Small submit cleanup
From: Rob Clark
Move more initialization into submit_create().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index b7c61a99d274..c7819781879c 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -26,6 +26,7 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
uint32_t nr_cmds)
{
+ static atomic_t ident = ATOMIC_INIT(0);
struct msm_gem_submit *submit;
uint64_t sz;
int ret;
@@ -52,9 +53,13 @@ static struct msm_gem_submit *submit_create(struct
drm_device *dev,
submit->gpu = gpu;
submit->cmd = (void *)>bos[nr_bos];
submit->queue = queue;
+ submit->pid = get_pid(task_pid(current));
submit->ring = gpu->rb[queue->ring_nr];
submit->fault_dumped = false;
+ /* Get a unique identifier for the submission for logging purposes */
+ submit->ident = atomic_inc_return() - 1;
+
INIT_LIST_HEAD(>node);
return submit;
@@ -718,7 +723,6 @@ static void msm_process_post_deps(struct
msm_submit_post_dep *post_deps,
int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct drm_file *file)
{
- static atomic_t ident = ATOMIC_INIT(0);
struct msm_drm_private *priv = dev->dev_private;
struct drm_msm_gem_submit *args = data;
struct msm_file_private *ctx = file->driver_priv;
@@ -729,10 +733,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
struct msm_submit_post_dep *post_deps = NULL;
struct drm_syncobj **syncobjs_to_reset = NULL;
int out_fence_fd = -1;
- struct pid *pid = get_pid(task_pid(current));
bool has_ww_ticket = false;
unsigned i;
- int ret, submitid;
+ int ret;
if (!gpu)
return -ENXIO;
@@ -764,12 +767,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (!queue)
return -ENOENT;
- /* Get a unique identifier for the submission for logging purposes */
- submitid = atomic_inc_return() - 1;
-
ring = gpu->rb[queue->ring_nr];
- trace_msm_gpu_submit(pid_nr(pid), ring->id, submitid,
- args->nr_bos, args->nr_cmds);
if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
@@ -783,13 +781,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (IS_ERR(submit))
return PTR_ERR(submit);
+ trace_msm_gpu_submit(pid_nr(submit->pid), ring->id, submit->ident,
+ args->nr_bos, args->nr_cmds);
+
ret = mutex_lock_interruptible(>lock);
if (ret)
goto out_post_unlock;
- submit->pid = pid;
- submit->ident = submitid;
-
if (args->flags & MSM_SUBMIT_SUDO)
submit->in_rb = true;
--
2.36.1
[PATCH v4 01/15] drm/msm: Reorder lock vs submit alloc
From: Rob Clark
This lets us drop the NORETRY.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index c9e4aeb14f4a..b7c61a99d274 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -36,7 +36,7 @@ static struct msm_gem_submit *submit_create(struct drm_device
*dev,
if (sz > SIZE_MAX)
return ERR_PTR(-ENOMEM);
- submit = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+ submit = kzalloc(sz, GFP_KERNEL);
if (!submit)
return ERR_PTR(-ENOMEM);
@@ -771,25 +771,21 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
trace_msm_gpu_submit(pid_nr(pid), ring->id, submitid,
args->nr_bos, args->nr_cmds);
- ret = mutex_lock_interruptible(>lock);
- if (ret)
- goto out_post_unlock;
-
if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
if (out_fence_fd < 0) {
ret = out_fence_fd;
- goto out_unlock;
+ return ret;
}
}
- submit = submit_create(dev, gpu, queue, args->nr_bos,
- args->nr_cmds);
- if (IS_ERR(submit)) {
- ret = PTR_ERR(submit);
- submit = NULL;
- goto out_unlock;
- }
+ submit = submit_create(dev, gpu, queue, args->nr_bos, args->nr_cmds);
+ if (IS_ERR(submit))
+ return PTR_ERR(submit);
+
+ ret = mutex_lock_interruptible(>lock);
+ if (ret)
+ goto out_post_unlock;
submit->pid = pid;
submit->ident = submitid;
@@ -965,9 +961,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
if (ret && (out_fence_fd >= 0))
put_unused_fd(out_fence_fd);
mutex_unlock(>lock);
+out_post_unlock:
if (submit)
msm_gem_submit_put(submit);
-out_post_unlock:
if (!IS_ERR_OR_NULL(post_deps)) {
for (i = 0; i < args->nr_out_syncobjs; ++i) {
kfree(post_deps[i].chain);
--
2.36.1
[PATCH v4 00/15] drm+msm: Shrinker and LRU rework
From: Rob Clark Unchanged other than small update in 09/15 original description below: This is mostly motivated by getting drm/msm to pass an i-g-t shrinker test that I've been working on. In particular the test creates and cycles between more GEM buffers than what will fit in RAM to force eviction and re-pin. (There are sub-tests that cover this case both single threaded and with many child processes in parallel.) Getting this test to pass necessitated a few improvements: 1. Re-ordering submit path to get rid of __GFP_NORETRY (in the common case, doing this for syncobjs is still TODO) 2. Decoupling locks needed in the retire path from locks that could be held while hitting reclaim in the submit path 3. If necessary, allow stalling on active BOs for reclaim. The latter point is because we pin objects in the synchronous part of the submit path (before queuing on the drm gpu-scheduler), which means in the parallel variant of the i-g-t test, we need to be able to block in the reclaim path until some queued work has completed/retired. In the process of re-working how drm/msm tracks buffer state in it's various LRU lists, I refactored out a drm_gem_lru helper which, in theory, should be usable by other drivers and drm shmem helpers for implementing LRU tracking and shrinker. v2: rebase + small fix in 13/13 v3: use lockdep_assert_held in GEM LRU helper, and add a couple patches at the end to convert MSM from WARN_ON(!is_locked()) to lockdep asserts v4: keep drm_gem_move_tail_locked() static until there is a user Rob Clark (15): drm/msm: Reorder lock vs submit alloc drm/msm: Small submit cleanup drm/msm: Split out idr_lock drm/msm/gem: Check for active in shrinker path drm/msm/gem: Rename update_inactive drm/msm/gem: Rename to pin/unpin_pages drm/msm/gem: Consolidate pin/unpin paths drm/msm/gem: Remove active refcnt drm/gem: Add LRU/shrinker helper drm/msm/gem: Convert to using drm_gem_lru drm/msm/gem: Unpin buffers earlier drm/msm/gem: Consolidate shrinker trace drm/msm/gem: Evict active GEM objects when necessary drm/msm/gem: Add msm_gem_assert_locked() drm/msm/gem: Convert to lockdep assert drivers/gpu/drm/drm_gem.c | 170 +++ drivers/gpu/drm/msm/msm_drv.c | 18 ++- drivers/gpu/drm/msm/msm_drv.h | 70 +++--- drivers/gpu/drm/msm/msm_gem.c | 179 + drivers/gpu/drm/msm/msm_gem.h | 123 ++--- drivers/gpu/drm/msm/msm_gem_prime.c| 4 +- drivers/gpu/drm/msm/msm_gem_shrinker.c | 164 +++--- drivers/gpu/drm/msm/msm_gem_submit.c | 78 --- drivers/gpu/drm/msm/msm_gpu.c | 3 - drivers/gpu/drm/msm/msm_gpu.h | 10 +- drivers/gpu/drm/msm/msm_gpu_trace.h| 36 +++-- drivers/gpu/drm/msm/msm_submitqueue.c | 1 + include/drm/drm_gem.h | 55 13 files changed, 491 insertions(+), 420 deletions(-) -- 2.36.1
Re: [PATCH drm-misc-next v7 2/5] drm/fb: rename FB CMA helpers to FB DMA helpers
On Tue, Aug 02, 2022 at 02:04:02AM +0200, Danilo Krummrich wrote:
> Rename "FB CMA" helpers to "FB DMA" helpers - considering the hierarchy
> of APIs (mm/cma -> dma -> fb dma) calling them "FB DMA" seems to be
> more applicable.
>
> Besides that, commit e57924d4ae80 ("drm/doc: Task to rename CMA helpers")
> requests to rename the CMA helpers and implies that people seem to be
> confused about the naming.
>
> In order to do this renaming the following script was used:
>
> ```
> #!/bin/bash
>
> DIRS="drivers/gpu include/drm Documentation/gpu"
>
> REGEX_SYM_UPPER="[0-9A-Z_\-]"
> REGEX_SYM_LOWER="[0-9a-z_\-]"
>
> REGEX_GREP_UPPER="(${REGEX_SYM_UPPER}*)(FB)_CMA_(${REGEX_SYM_UPPER}*)"
> REGEX_GREP_LOWER="(${REGEX_SYM_LOWER}*)(fb)_cma_(${REGEX_SYM_LOWER}*)"
>
> REGEX_SED_UPPER="s/${REGEX_GREP_UPPER}/\1\2_DMA_\3/g"
> REGEX_SED_LOWER="s/${REGEX_GREP_LOWER}/\1\2_dma_\3/g"
>
> # Find all upper case 'CMA' symbols and replace them with 'DMA'.
> for ff in $(grep -REHl "${REGEX_GREP_UPPER}" $DIRS)
> do
> sed -i -E "$REGEX_SED_UPPER" $ff
> done
>
> # Find all lower case 'cma' symbols and replace them with 'dma'.
> for ff in $(grep -REHl "${REGEX_GREP_LOWER}" $DIRS)
> do
> sed -i -E "$REGEX_SED_LOWER" $ff
> done
>
> # Replace all occurrences of 'CMA' / 'cma' in comments and
> # documentation files with 'DMA' / 'dma'.
> for ff in $(grep -RiHl " cma " $DIRS)
> do
> sed -i -E "s/ cma / dma /g" $ff
> sed -i -E "s/ CMA / DMA /g" $ff
> done
> ```
>
> Only a few more manual modifications were needed, e.g. reverting the
> following modifications in some DRM Kconfig files
>
> - select CMA if HAVE_DMA_CONTIGUOUS
> + select DMA if HAVE_DMA_CONTIGUOUS
>
> as well as manually picking the occurrences of 'CMA'/'cma' in comments and
> documentation which relate to "FB CMA", but not "GEM CMA".
>
> This patch is compile-time tested building a x86_64 kernel with
> `make allyesconfig && make drivers/gpu/drm`.
>
> Acked-by: Sam Ravnborg
> Acked-by: Thomas Zimmermann
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Danilo Krummrich
> ---
> Documentation/gpu/drm-kms-helpers.rst | 8 ++--
> drivers/gpu/drm/Makefile | 2 +-
> .../arm/display/komeda/komeda_framebuffer.c | 4 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +-
> drivers/gpu/drm/arm/malidp_mw.c | 4 +-
> drivers/gpu/drm/arm/malidp_planes.c | 8 ++--
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 4 +-
> .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +-
> ...rm_fb_cma_helper.c => drm_fb_dma_helper.c} | 43 +++
> drivers/gpu/drm/drm_format_helper.c | 4 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 4 +-
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +-
> drivers/gpu/drm/imx/dcss/dcss-plane.c | 6 +--
> drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++--
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 +--
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 10 ++---
> drivers/gpu/drm/kmb/kmb_plane.c | 8 ++--
> drivers/gpu/drm/logicvc/Kconfig | 2 +-
> drivers/gpu/drm/logicvc/logicvc_layer.c | 6 +--
> drivers/gpu/drm/mcde/mcde_display.c | 6 +--
> drivers/gpu/drm/mcde/mcde_drv.c | 4 +-
> drivers/gpu/drm/meson/meson_overlay.c | 8 ++--
> drivers/gpu/drm/meson/meson_plane.c | 4 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 6 +--
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 ++--
> drivers/gpu/drm/pl111/pl111_display.c | 6 +--
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +-
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 6 +--
> drivers/gpu/drm/shmobile/shmob_drm_plane.c| 6 +--
> drivers/gpu/drm/sprd/sprd_dpu.c | 4 +-
> drivers/gpu/drm/sti/sti_cursor.c | 6 +--
> drivers/gpu/drm/sti/sti_gdp.c | 6 +--
> drivers/gpu/drm/sti/sti_hqvdp.c | 6 +--
> drivers/gpu/drm/stm/ltdc.c| 14 +++---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +-
> drivers/gpu/drm/sun4i/sun4i_frontend.c| 8 ++--
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 4 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 4 +-
> drivers/gpu/drm/tegra/fb.c| 2 +-
> drivers/gpu/drm/tidss/tidss_dispc.c | 6 +--
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +-
> drivers/gpu/drm/tiny/arcpgu.c | 4 +-
> drivers/gpu/drm/tiny/ili9225.c| 4 +-
> drivers/gpu/drm/tiny/repaper.c| 4 +-
> drivers/gpu/drm/tiny/st7586.c | 4 +-
> drivers/gpu/drm/tve200/tve200_display.c | 10 ++---
>
Re: [PATCH 1/2] drm: Fix vblank refcount during modeset
[AMD Official Use Only - General] I found out that elsewhere in the drm code (e.g. in drm_atomic_helper.c) expects drm_vblank_get() to fail as part of normal operation. So this patch doesn't seem appropriate anymore and it seems more appropriate to hunt down all the unchecked calls for drm_vblank_get and fix them instead. I don't know how to best make sure this doesn't reoccur in the future though. Regards, Yunxiang
Re: [PATCH] drm/drm_edid: Refactor HFVSDB parsing for DSC1.2
On Fri, 22 Jul 2022, Ankit Nautiyal wrote:
> DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
> SCDS). Since minimum length of Data block is 7, all bytes greater than 7
> must be read only after checking the length of the data block.
>
> This patch adds check for data block length before reading relavant DSC
> bytes. It also corrects min DSC BPC to 8, and minor refactoring for
> better readability, and proper log messages.
I think this patch tries to do too much at once. Please split it up. One
thing per patch.
I think the logging is excessive, and what logging remains should use
drm_dbg_kms() instead of DRM_DEBUG_KMS().
Further comments inline.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/drm_edid.c | 124 +++--
> 1 file changed, 77 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bbc25e3b7220..f683a8d5fd31 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5703,12 +5703,58 @@ static void drm_parse_ycbcr420_deep_color_info(struct
> drm_connector *connector,
> hdmi->y420_dc_modes = dc_mask;
> }
>
> +static void drm_parse_dsc_slice_info(u8 dsc_max_slices,
> + struct drm_hdmi_dsc_cap *hdmi_dsc)
Arguments should always be in the order: context, destination, source.
> +{
> + switch (dsc_max_slices) {
> + case 1:
> + hdmi_dsc->max_slices = 1;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 2:
> + hdmi_dsc->max_slices = 2;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 3:
> + hdmi_dsc->max_slices = 4;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 4:
> + hdmi_dsc->max_slices = 8;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 5:
> + hdmi_dsc->max_slices = 8;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 6:
> + hdmi_dsc->max_slices = 12;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 7:
> + hdmi_dsc->max_slices = 16;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 0:
> + default:
> + hdmi_dsc->max_slices = 0;
> + hdmi_dsc->clk_per_slice = 0;
> + }
> +}
> +
> /* Sink Capability Data Structure */
> static void drm_parse_hdmi_forum_scds(struct drm_connector *connector,
> const u8 *hf_scds)
> {
> struct drm_display_info *display = >display_info;
> struct drm_hdmi_info *hdmi = >hdmi;
> + u8 db_length = hf_scds[0] & 0x1F;
There's cea_db_payload_len() for this, and you can use that directly
instead of caching the value to a local variable.
> + u8 dsc_max_frl_rate;
> + u8 dsc_max_slices;
These two are local to a tiny if block and should be declared there.
> + struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
> +
> + if (db_length < 7 || db_length > 31)
> + return;
Both cea_db_is_hdmi_forum_vsdb() and cea_db_is_hdmi_forum_scdb() check
the payload is >= 7 bytes before this one even gets called.
There's no reason to not parse the first 31 bytes if the length is > 31
bytes. That condition just breaks future compatibility for no reason.
>
> display->has_hdmi_infoframe = true;
>
> @@ -5749,17 +5795,25 @@ static void drm_parse_hdmi_forum_scds(struct
> drm_connector *connector,
>
> if (hf_scds[7]) {
> u8 max_frl_rate;
> - u8 dsc_max_frl_rate;
> - u8 dsc_max_slices;
> - struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
>
> - DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
> max_frl_rate = (hf_scds[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
> + if (max_frl_rate)
> + DRM_DEBUG_KMS("HDMI2.1 FRL support detected\n");
> +
> drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>>max_frl_rate_per_lane);
> +
> + drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
> + }
> +
> + if (db_length < 11)
> + return;
> +
> + if (hf_scds[11]) {
Matter of taste, but I'd probably make these
if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11])
and drop the early returns, and add a single (or very few) debug logging
call at the end.
> hdmi_dsc->v_1p2 = hf_scds[11] & DRM_EDID_DSC_1P2;
>
> if (hdmi_dsc->v_1p2) {
> + DRM_DEBUG_KMS("HDMI DSC1.2 support detected\n");
> hdmi_dsc->native_420 = hf_scds[11] &
> DRM_EDID_DSC_NATIVE_420;
> hdmi_dsc->all_bpp = hf_scds[11] & DRM_EDID_DSC_ALL_BPP;
>
> @@ -5770,52 +5824,28 @@ static void drm_parse_hdmi_forum_scds(struct
> drm_connector
Re: [PATCH 3/5] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Olivier,
Some comments below as I mentioned off-list.
One additional point: some devices need to know if a buffer is
protected, so that they can configure registers appropriately to make
use of that protected buffer. There was previously a discussion about
adding a flag to a dma_buf to indicate that it is allocated from
protected memory[1].
[1] https://lists.freedesktop.org/archives/dri-devel/2019-September/238059.html
On Tue, Aug 02, 2022 at 11:58:41AM +0200, Olivier Masse wrote:
> add Linaro secure heap bindings: linaro,secure-heap
> use genalloc to allocate/free buffer from buffer pool.
> buffer pool info is from dts.
> use sg_table instore the allocated memory info, the length of sg_table is 1.
> implement secure_heap_buf_ops to implement buffer share in difference device:
> 1. Userspace passes this fd to all drivers it wants this buffer
> to share with: First the filedescriptor is converted to a _buf using
> dma_buf_get(). Then the buffer is attached to the device using
> dma_buf_attach().
> 2. Once the buffer is attached to all devices userspace can initiate DMA
> access to the shared buffer. In the kernel this is done by calling
> dma_buf_map_attachment()
> 3. get sg_table with dma_buf_map_attachment in difference device.
>
> Signed-off-by: Olivier Masse
> ---
> drivers/dma-buf/heaps/Kconfig | 21 +-
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/secure_heap.c | 588
> 3 files changed, 606 insertions(+), 4 deletions(-)
> create mode 100644 drivers/dma-buf/heaps/secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 6a33193a7b3e..b2406932192e 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -1,8 +1,12 @@
> -config DMABUF_HEAPS_DEFERRED_FREE
> - tristate
> +menuconfig DMABUF_HEAPS_DEFERRED_FREE
> + bool "DMA-BUF heaps deferred-free library"
> + help
> + Choose this option to enable the DMA-BUF heaps deferred-free library.
>
> -config DMABUF_HEAPS_PAGE_POOL
> - tristate
> +menuconfig DMABUF_HEAPS_PAGE_POOL
> + bool "DMA-BUF heaps page-pool library"
> + help
> + Choose this option to enable the DMA-BUF heaps page-pool library.
>
> config DMABUF_HEAPS_SYSTEM
> bool "DMA-BUF System Heap"
> @@ -26,3 +30,12 @@ config DMABUF_HEAPS_DSP
>Choose this option to enable the dsp dmabuf heap. The dsp heap
>is allocated by gen allocater. it's allocated according the dts.
>If in doubt, say Y.
> +
> +config DMABUF_HEAPS_SECURE
> + tristate "DMA-BUF Secure Heap"
> + depends on DMABUF_HEAPS && DMABUF_HEAPS_DEFERRED_FREE
> + help
> + Choose this option to enable the secure dmabuf heap. The secure heap
> + pools are defined according to the DT. Heaps are allocated
> + in the pools using gen allocater.
> + If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index e70722ea615e..08f6aa5919d1 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DMABUF_HEAPS_PAGE_POOL) += page_pool.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> new file mode 100644
> index ..31aac5d050b4
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -0,0 +1,588 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF secure heap exporter
> + *
> + * Copyright 2021 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "deferred-free-helper.h"
> +#include "page_pool.h"
> +
> +#define MAX_SECURE_HEAP 2
> +#define MAX_HEAP_NAME_LEN 32
> +
> +struct secure_heap_buffer {
> + struct dma_heap *heap;
> + struct list_head attachments;
> + struct mutex lock;
> + unsigned long len;
> + struct sg_table sg_table;
> + int vmap_cnt;
> + struct deferred_freelist_item deferred_free;
> + void *vaddr;
> + bool uncached;
> +};
> +
> +struct dma_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> + bool no_map;
> + bool mapped;
> + bool uncached;
> +};
I think dma_heap_attachment should have a more specific name,
otherwise it looks like some generic part of the dma_heap framework.
> +
> +struct secure_heap_info {
> + struct gen_pool *pool;
> +
> + bool no_map;
> +};
> +
> +struct rmem_secure {
> + phys_addr_t base;
> + phys_addr_t size;
> +
> + char name[MAX_HEAP_NAME_LEN];
> +
> + bool no_map;
> +};
Re: [PATCH] drm: Fix EDID firmware load on resume
On Wed, 27 Jul 2022, Matthieu CHARETTE wrote:
> Loading an EDID using drm.edid_firmware parameter makes resume to fail
> after firmware cache is being cleaned. This is because edid_load() use a
> temporary device to request the firmware. This cause the EDID firmware
> not to be cached from suspend. And, requesting the EDID firmware return
> an error during resume.
> So the request_firmware() call should use a permanent device for each
> connector. Also, we should cache the EDID even if no monitor is
> connected, in case it's plugged while suspended.
AFAICT this breaks changing drm.edid_firmware runtime.
BR,
Jani.
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2061
> Signed-off-by: Matthieu CHARETTE
> ---
> drivers/gpu/drm/drm_connector.c | 9
> drivers/gpu/drm/drm_edid_load.c | 81 -
> include/drm/drm_connector.h | 12 +
> include/drm/drm_edid.h | 3 ++
> 4 files changed, 94 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1c48d162c77e..e8819ebf1c4b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -31,6 +31,7 @@
> #include
> #include
>
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -289,6 +290,9 @@ int drm_connector_init(struct drm_device *dev,
>
> drm_connector_get_cmdline_mode(connector);
>
> + connector->edid_load_pdev = NULL;
> + drm_cache_edid_firmware(connector);
> +
> /* We should add connectors at the end to avoid upsetting the connector
>* index too much.
>*/
> @@ -473,6 +477,11 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> connector->tile_group = NULL;
> }
>
> + if (connector->edid_load_pdev) {
> + platform_device_unregister(connector->edid_load_pdev);
> + connector->edid_load_pdev = NULL;
> + }
> +
> list_for_each_entry_safe(mode, t, >probed_modes, head)
> drm_mode_remove(connector, mode);
>
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 37d8ba3ddb46..5a82be9917ec 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -167,6 +167,19 @@ static int edid_size(const u8 *edid, int data_size)
> return (edid[0x7e] + 1) * EDID_LENGTH;
> }
>
> +static struct platform_device *edid_pdev(const char *connector_name)
> +{
> + struct platform_device *pdev =
> platform_device_register_simple(connector_name, -1, NULL, 0);
> +
> + if (IS_ERR(pdev)) {
> + DRM_ERROR("Failed to register EDID firmware platform device "
> + "for connector \"%s\"\n", connector_name);
> + return ERR_CAST(pdev);
> + }
> +
> + return pdev;
> +}
> +
> static void *edid_load(struct drm_connector *connector, const char *name,
> const char *connector_name)
> {
> @@ -182,18 +195,17 @@ static void *edid_load(struct drm_connector *connector,
> const char *name,
> fwdata = generic_edid[builtin];
> fwsize = sizeof(generic_edid[builtin]);
> } else {
> - struct platform_device *pdev;
> + struct platform_device *pdev = connector->edid_load_pdev;
> int err;
>
> - pdev = platform_device_register_simple(connector_name, -1,
> NULL, 0);
> - if (IS_ERR(pdev)) {
> - DRM_ERROR("Failed to register EDID firmware platform
> device "
> - "for connector \"%s\"\n", connector_name);
> - return ERR_CAST(pdev);
> + if (WARN_ON(!pdev)) {
> + pdev = edid_pdev(connector_name);
> + if (IS_ERR(pdev))
> + return ERR_CAST(pdev);
> + connector->edid_load_pdev = pdev;
> }
>
> err = request_firmware(, name, >dev);
> - platform_device_unregister(pdev);
> if (err) {
> DRM_ERROR("Requesting EDID firmware \"%s\" failed
> (err=%d)\n",
> name, err);
> @@ -263,11 +275,9 @@ static void *edid_load(struct drm_connector *connector,
> const char *name,
> return edid;
> }
>
> -struct edid *drm_load_edid_firmware(struct drm_connector *connector)
> +static char *edid_name(const char *connector_name)
> {
> - const char *connector_name = connector->name;
> char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
> - struct edid *edid;
>
> if (edid_firmware[0] == '\0')
> return ERR_PTR(-ENOENT);
> @@ -310,8 +320,57 @@ struct edid *drm_load_edid_firmware(struct drm_connector
> *connector)
> if (*last == '\n')
> *last = '\0';
>
> - edid = edid_load(connector, edidname, connector_name);
> + edidname =
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Hi
Am 02.08.22 um 15:58 schrieb Jani Nikula:
On Fri, 29 Jul 2022, Maxime Ripard wrote:
Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
modes in the drivers.
Since those modes are fairly standards, and that we'll need to use them in
more places in the future, let's move the meson definition into the
framework.
I think you should always expose interfaces, not data. Data is not an
interface, and I think this sets a bad example that will be cargo
culted.
Although I wrote the opposite wrt patch 8, I agree with Jani here when
it comes to 'official' interfaces. The cases I've seen of exported data
structures often lead to intransparent code.
Best regards
Thomas
BR,
Jani.
The meson one was chosen because vc4's isn't accurate and doesn't amount to
525 and 625 lines.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..a4c1bd688338 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -48,6 +48,24 @@
#include "drm_crtc_internal.h"
+const struct drm_display_mode drm_mode_480i = {
+ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
+720, 739, 801, 858, 0,
+480, 488, 494, 525, 0,
+DRM_MODE_FLAG_INTERLACE),
+ .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
+};
+EXPORT_SYMBOL_GPL(drm_mode_480i);
+
+const struct drm_display_mode drm_mode_576i = {
+ DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
+720, 732, 795, 864, 0,
+576, 580, 586, 625, 0,
+DRM_MODE_FLAG_INTERLACE),
+ .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
+};
+EXPORT_SYMBOL_GPL(drm_mode_576i);
+
/**
* drm_mode_debug_printmodeline - print a mode to dmesg
* @mode: mode to print
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
index 8110a6e39320..98ec3e563155 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
@@ -45,21 +45,11 @@ struct meson_encoder_cvbs {
struct meson_cvbs_mode meson_cvbs_modes[MESON_CVBS_MODES_COUNT] = {
{ /* PAL */
.enci = _cvbs_enci_pal,
- .mode = {
- DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
-720, 732, 795, 864, 0, 576, 580, 586, 625, 0,
-DRM_MODE_FLAG_INTERLACE),
- .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
- },
+ .mode = _mode_576i,
},
{ /* NTSC */
.enci = _cvbs_enci_ntsc,
- .mode = {
- DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
- 720, 739, 801, 858, 0, 480, 488, 494, 525, 0,
- DRM_MODE_FLAG_INTERLACE),
- .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
- },
+ .mode = _mode_480i,
},
};
@@ -71,7 +61,7 @@ meson_cvbs_get_mode(const struct drm_display_mode *req_mode)
for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
struct meson_cvbs_mode *meson_mode = _cvbs_modes[i];
- if (drm_mode_match(req_mode, _mode->mode,
+ if (drm_mode_match(req_mode, meson_mode->mode,
DRM_MODE_MATCH_TIMINGS |
DRM_MODE_MATCH_CLOCK |
DRM_MODE_MATCH_FLAGS |
@@ -104,7 +94,7 @@ static int meson_encoder_cvbs_get_modes(struct drm_bridge
*bridge,
for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
struct meson_cvbs_mode *meson_mode = _cvbs_modes[i];
- mode = drm_mode_duplicate(priv->drm, _mode->mode);
+ mode = drm_mode_duplicate(priv->drm, meson_mode->mode);
if (!mode) {
dev_err(priv->dev, "Failed to create a new display
mode\n");
return 0;
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
index 61d9d183ce7f..26cefb202924 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
@@ -16,7 +16,7 @@
struct meson_cvbs_mode {
struct meson_cvbs_enci_mode *enci;
- struct drm_display_mode mode;
+ const struct drm_display_mode *mode;
};
#define MESON_CVBS_MODES_COUNT 2
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index a80ae9639e96..b4a440e2688c 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -394,6 +394,9 @@ struct drm_display_mode {
};
+extern const struct drm_display_mode drm_mode_480i;
+extern const struct drm_display_mode drm_mode_576i;
+
/**
* DRM_MODE_FMT - printf string for drm_display_mode
*/
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Re: [PATCH v15 03/11] drm/edid: Add cea_sad helpers for freq/length
On Wed, 27 Jul 2022, Bo-Chen Chen wrote:
> From: Guillaume Ranquet
>
> This patch adds two helper functions that extract the frequency and word
> length from a struct cea_sad.
>
> For these helper functions new defines are added that help translate the
> 'freq' and 'byte2' fields into real numbers.
I think we should stop adding a plethora of functions that deal with
sads like this.
There should probably be *one* struct that contains all the details you
and everyone need extracted. There should be *one* function that fills
in all the details. The struct should be placed in
connector->display_info, and the function should be called *once* from
update_display_info().
Ideally, the function shouldn't even be exposed from drm_edid.c, but if
you still need to deal with situations where you don't call connector
update, maybe it needs to be exposed.
BR,
Jani.
>
> Signed-off-by: Markus Schneider-Pargmann
> Signed-off-by: Guillaume Ranquet
> Signed-off-by: Bo-Chen Chen
> ---
> drivers/gpu/drm/drm_edid.c | 63 ++
> include/drm/drm_edid.h | 14 +
> 2 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bc43e1b32092..2a6f92da5ff3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4916,6 +4916,69 @@ int drm_edid_to_speaker_allocation(const struct edid
> *edid, u8 **sadb)
> }
> EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
>
> +/**
> + * drm_cea_sad_get_sample_rate - Extract the sample rate from cea_sad
> + * @sad: Pointer to the cea_sad struct
> + *
> + * Extracts the cea_sad frequency field and returns the sample rate in Hz.
> + *
> + * Return: Sample rate in Hz or a negative errno if parsing failed.
> + */
> +int drm_cea_sad_get_sample_rate(const struct cea_sad *sad)
> +{
> + switch (sad->freq) {
> + case DRM_CEA_SAD_FREQ_32KHZ:
> + return 32000;
> + case DRM_CEA_SAD_FREQ_44KHZ:
> + return 44100;
> + case DRM_CEA_SAD_FREQ_48KHZ:
> + return 48000;
> + case DRM_CEA_SAD_FREQ_88KHZ:
> + return 88200;
> + case DRM_CEA_SAD_FREQ_96KHZ:
> + return 96000;
> + case DRM_CEA_SAD_FREQ_176KHZ:
> + return 176400;
> + case DRM_CEA_SAD_FREQ_192KHZ:
> + return 192000;
> + default:
> + return -EINVAL;
> + }
> +}
> +EXPORT_SYMBOL(drm_cea_sad_get_sample_rate);
> +
> +/**
> + * drm_cea_sad_get_uncompressed_word_length - Extract word length
> + * @sad: Pointer to the cea_sad struct
> + *
> + * Extracts the cea_sad byte2 field and returns the word length for an
> + * uncompressed stream.
> + *
> + * Note: This function may only be called for uncompressed audio.
> + *
> + * Return: Word length in bits or a negative errno if parsing failed.
> + */
> +int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad)
> +{
> + if (sad->format != HDMI_AUDIO_CODING_TYPE_PCM) {
> + DRM_WARN("Unable to get the uncompressed word length for
> format: %u\n",
> + sad->format);
> + return -EINVAL;
> + }
> +
> + switch (sad->byte2) {
> + case DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT:
> + return 16;
> + case DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT:
> + return 20;
> + case DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT:
> + return 24;
> + default:
> + return -EINVAL;
> + }
> +}
> +EXPORT_SYMBOL(drm_cea_sad_get_uncompressed_word_length);
> +
> /**
> * drm_av_sync_delay - compute the HDMI/DP sink audio-video sync delay
> * @connector: connector associated with the HDMI/DP sink
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index c2c43a4af681..779b710aed40 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -373,6 +373,18 @@ struct cea_sad {
> u8 byte2;
> };
>
> +#define DRM_CEA_SAD_FREQ_32KHZ BIT(0)
> +#define DRM_CEA_SAD_FREQ_44KHZ BIT(1)
> +#define DRM_CEA_SAD_FREQ_48KHZ BIT(2)
> +#define DRM_CEA_SAD_FREQ_88KHZ BIT(3)
> +#define DRM_CEA_SAD_FREQ_96KHZ BIT(4)
> +#define DRM_CEA_SAD_FREQ_176KHZ BIT(5)
> +#define DRM_CEA_SAD_FREQ_192KHZ BIT(6)
> +
> +#define DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT BIT(0)
> +#define DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT BIT(1)
> +#define DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT BIT(2)
> +
> struct drm_encoder;
> struct drm_connector;
> struct drm_connector_state;
> @@ -380,6 +392,8 @@ struct drm_display_mode;
>
> int drm_edid_to_sad(const struct edid *edid, struct cea_sad **sads);
> int drm_edid_to_speaker_allocation(const struct edid *edid, u8 **sadb);
> +int drm_cea_sad_get_sample_rate(const struct cea_sad *sad);
> +int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad);
> int drm_av_sync_delay(struct drm_connector *connector,
> const struct drm_display_mode *mode);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
On Fri, 29 Jul 2022, Maxime Ripard wrote:
> Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> modes in the drivers.
>
> Since those modes are fairly standards, and that we'll need to use them in
> more places in the future, let's move the meson definition into the
> framework.
I think you should always expose interfaces, not data. Data is not an
interface, and I think this sets a bad example that will be cargo
culted.
BR,
Jani.
>
> The meson one was chosen because vc4's isn't accurate and doesn't amount to
> 525 and 625 lines.
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 304004fb80aa..a4c1bd688338 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -48,6 +48,24 @@
>
> #include "drm_crtc_internal.h"
>
> +const struct drm_display_mode drm_mode_480i = {
> + DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
> + 720, 739, 801, 858, 0,
> + 480, 488, 494, 525, 0,
> + DRM_MODE_FLAG_INTERLACE),
> + .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> +};
> +EXPORT_SYMBOL_GPL(drm_mode_480i);
> +
> +const struct drm_display_mode drm_mode_576i = {
> + DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
> + 720, 732, 795, 864, 0,
> + 576, 580, 586, 625, 0,
> + DRM_MODE_FLAG_INTERLACE),
> + .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> +};
> +EXPORT_SYMBOL_GPL(drm_mode_576i);
> +
> /**
> * drm_mode_debug_printmodeline - print a mode to dmesg
> * @mode: mode to print
> diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> index 8110a6e39320..98ec3e563155 100644
> --- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> +++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> @@ -45,21 +45,11 @@ struct meson_encoder_cvbs {
> struct meson_cvbs_mode meson_cvbs_modes[MESON_CVBS_MODES_COUNT] = {
> { /* PAL */
> .enci = _cvbs_enci_pal,
> - .mode = {
> - DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
> - 720, 732, 795, 864, 0, 576, 580, 586, 625, 0,
> - DRM_MODE_FLAG_INTERLACE),
> - .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> - },
> + .mode = _mode_576i,
> },
> { /* NTSC */
> .enci = _cvbs_enci_ntsc,
> - .mode = {
> - DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
> - 720, 739, 801, 858, 0, 480, 488, 494, 525, 0,
> - DRM_MODE_FLAG_INTERLACE),
> - .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> - },
> + .mode = _mode_480i,
> },
> };
>
> @@ -71,7 +61,7 @@ meson_cvbs_get_mode(const struct drm_display_mode *req_mode)
> for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
> struct meson_cvbs_mode *meson_mode = _cvbs_modes[i];
>
> - if (drm_mode_match(req_mode, _mode->mode,
> + if (drm_mode_match(req_mode, meson_mode->mode,
> DRM_MODE_MATCH_TIMINGS |
> DRM_MODE_MATCH_CLOCK |
> DRM_MODE_MATCH_FLAGS |
> @@ -104,7 +94,7 @@ static int meson_encoder_cvbs_get_modes(struct drm_bridge
> *bridge,
> for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
> struct meson_cvbs_mode *meson_mode = _cvbs_modes[i];
>
> - mode = drm_mode_duplicate(priv->drm, _mode->mode);
> + mode = drm_mode_duplicate(priv->drm, meson_mode->mode);
> if (!mode) {
> dev_err(priv->dev, "Failed to create a new display
> mode\n");
> return 0;
> diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> index 61d9d183ce7f..26cefb202924 100644
> --- a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> +++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> @@ -16,7 +16,7 @@
>
> struct meson_cvbs_mode {
> struct meson_cvbs_enci_mode *enci;
> - struct drm_display_mode mode;
> + const struct drm_display_mode *mode;
> };
>
> #define MESON_CVBS_MODES_COUNT 2
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index a80ae9639e96..b4a440e2688c 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -394,6 +394,9 @@ struct drm_display_mode {
>
> };
>
> +extern const struct drm_display_mode drm_mode_480i;
> +extern const struct drm_display_mode drm_mode_576i;
> +
> /**
> * DRM_MODE_FMT - printf string for drm_display_mode
> */
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH] amdgpu: add context creation flags in CS IOCTL
This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
accomodate this new parameter.
The idea is to pass the workload hints while context creation, so
that kernel GPU scheduler can pass this information to GPU FW, which in
turn can adjust the GPU characterstics as per the workload type.
Signed-off-by: Shashank Sharma
Cc: Alex Deucher
Cc: Marek Olsak
Cc: Christian Koenig
Cc: Amarnath Somalapuram
---
amdgpu/amdgpu.h | 2 ++
amdgpu/amdgpu_cs.c | 5 -
include/drm/amdgpu_drm.h | 10 +-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b118dd48..1ebb46e6 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -874,6 +874,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle handle,
*
* \param dev - \c [in] Device handle. See #amdgpu_device_initialize()
* \param priority - \c [in] Context creation flags. See
AMDGPU_CTX_PRIORITY_*
+ * \param flags- \c [in] Context flags. See AMDGPU_CTX_FLAGS_*
* \param context - \c [out] GPU Context handle
*
* \return 0 on success\n
@@ -884,6 +885,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle handle,
*/
int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
uint32_t priority,
+uint32_t flags,
amdgpu_context_handle *context);
/**
* Create GPU execution Context
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index fad484bf..d4723ea5 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -44,12 +44,14 @@ static int amdgpu_cs_reset_sem(amdgpu_semaphore_handle sem);
*
* \param dev - \c [in] Device handle. See #amdgpu_device_initialize()
* \param priority - \c [in] Context creation flags. See
AMDGPU_CTX_PRIORITY_*
+ * \param flags- \c [in] Context flags. See AMDGPU_CTX_FLAGS_*
* \param context - \c [out] GPU Context handle
*
* \return 0 on success otherwise POSIX Error code
*/
drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
uint32_t priority,
+uint32_t flags,
amdgpu_context_handle *context)
{
struct amdgpu_context *gpu_context;
@@ -74,6 +76,7 @@ drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
memset(, 0, sizeof(args));
args.in.op = AMDGPU_CTX_OP_ALLOC_CTX;
args.in.priority = priority;
+ args.in.flags = flags;
r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_CTX, , sizeof(args));
if (r)
@@ -97,7 +100,7 @@ error:
drm_public int amdgpu_cs_ctx_create(amdgpu_device_handle dev,
amdgpu_context_handle *context)
{
- return amdgpu_cs_ctx_create2(dev, AMDGPU_CTX_PRIORITY_NORMAL, context);
+ return amdgpu_cs_ctx_create2(dev, AMDGPU_CTX_PRIORITY_NORMAL, 0,
context);
}
/**
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 0cbd1540..d9fb1f20 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -238,10 +238,18 @@ union drm_amdgpu_bo_list {
#define AMDGPU_CTX_PRIORITY_HIGH512
#define AMDGPU_CTX_PRIORITY_VERY_HIGH 1023
+/* GPU context workload hint bitmask */
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_MASK0xFF
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_NONE0
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_3D (1 << 1)
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_VIDEO (1 << 2)
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_VR (1 << 3)
+#define AMDGPU_CTX_FLAGS_WORKLOAD_HINT_COMPUTE (1 << 4)
+
struct drm_amdgpu_ctx_in {
/** AMDGPU_CTX_OP_* */
__u32 op;
- /** For future use, no flags defined so far */
+ /** AMDGPU_CTX_FLAGS_* */
__u32 flags;
__u32 ctx_id;
/** AMDGPU_CTX_PRIORITY_* */
--
2.34.1
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote: > > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > > > Hi Adam, Fabio, > > > > On 22-08-01, Adam Ford wrote: > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > > > 1080p. I haven't yet been able to get other modes to work. > > > > > > > > Ok, good. On another thread, you mentioned that you were also trying > > > > to get LVDS to work via SN65DSI83. > > > > > > > > Does LVDS work for you on this branch? > > > > > > I haven't tried with Marek's latest suggestion. In the other thread > > > he mentioned a burst mode and setting the DSI speeds to higher > > > frequencies, but the patch he had didn't look like it would apply > > > cleanly, so I will need to dig into that a bit further. > > > > Can you provide me a link to this thread? > > Sure, > > https://www.spinics.net/lists/dri-devel/msg358301.html > > > > > > Since my company doesn't really ship the LVDS displays with the kits, > > > the HDMI is the default video, so I've been focusing on it. > > > > > > To answer Marco's question, I was able to revert "MLK-21958-13: > > > drm/bridge: adv7511: Limit supported clocks" and still get a display > > > at 1080p, but all the other resolutions I tried appear to come up > > > blank. > > > > Cool so now you have the same state as we are. > > I have a couple patches applied to mine which mimic some of the stuff > that NXP did. Since I have access to a programmer manual, i was able > to confirm some of the 7535 specific stuff and the low-refresh rate > changes in their kernel appear appropriate and I also created a second > table of default settings for the 7535 and if the type is set > properly, i'll use the newer table instead of the older one. If anyone > wants any of these patches, I can certainly share them, but I am not > certain they make any difference. > > There are a few other items in the programmer manual that I want to > attempt to implement once I have a chance to further review the > document. > > > > > I think that the most important one is the blanking calc. Can you try to > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > > if you can get a output still? Also something to try would be to disable > > the internal timing generator by specifying > > 'adi,disable-timing-generator'. Also if you have an oscilloscope for I did some reading about the internal timing generator. It appears that it's required when video formats use fractional bytes, and it's preconfigured to run at 720p by default, but registers 28h through 37h configure it for other video modes. Are you thinking the imx8mm DSI generator would do it better? > > such frequencies you can check the hdmi clk-lane. I noticed that this is > > sometimes wrong. > > I am doing this from my home office as a side project, so I don't have > a scope, but I can try to revert the other patch and try to disable > the internal timing generator when I get home tonight. I'll report my > findings. > > > > > Regards, > > Marco > > > > > I didn't try every one. With that revert, more options come > > > available, but 1440x900 and 800x600 were options I tried > > > unsuccessfullyl. > > > > > > > > adam > > >
Re: [PATCH] drm/amd/display: remove DML Makefile duplicate lines
Às 09:04 de 02/08/22, Magali Lemes escreveu: > There are two identical CFLAGS entries for "display_mode_vba_20.o", so > remove one of them. Also, as there's already an entry for > "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being > defined or not, remove the one entry between CONFIG_DRM_AMD_DC_DCN ifdef > guards. > > Signed-off-by: Magali Lemes > --- Reviewed-by: André Almeida
Re: [PATCH v2 1/3] drm/amd/display: make variables static
Às 22:06 de 29/07/22, Magali Lemes escreveu:
> As "dcn3_1_soc", "dcn3_15_soc", and "dcn3_16_soc" are not used outside
> of their corresponding "dcn3*_fpu.c", make them static and remove their
> extern declaration.
>
> Fixes: 26f4712aedbd ("drm/amd/display: move FPU related code from dcn31 to
> dml/dcn31 folder")
> Fixes: fa896297b31b ("drm/amd/display: move FPU related code from dcn315 to
> dml/dcn31 folder")
> Fixes: 3f8951cc123f ("drm/amd/display: move FPU related code from dcn316 to
> dml/dcn31 folder")
> Signed-off-by: Magali Lemes
> Reviewed-by: Maíra Canal
> Reviewed-by: Melissa Wen
> ---
Series is Reviewed-by: André Almeida
Re: [PATCH] drm/amd/display: remove DML Makefile duplicate lines
On 2022-08-02 08:04, Magali Lemes wrote: > There are two identical CFLAGS entries for "display_mode_vba_20.o", so > remove one of them. Also, as there's already an entry for > "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being > defined or not, remove the one entry between CONFIG_DRM_AMD_DC_DCN ifdef > guards. > > Signed-off-by: Magali Lemes Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index 359f6e9a1da0..41bb6c3cc2d8 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -61,7 +61,6 @@ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := > $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) > -CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := > $(dml_ccflags) > @@ -82,7 +81,6 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn301/dcn301_fpu.o := > $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn302/dcn302_fpu.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dcn303/dcn303_fpu.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/dsc/rc_calc_fpu.o := $(dml_ccflags) > -CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calcs.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_auto.o := $(dml_ccflags) > CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_math.o := $(dml_ccflags) > -Wno-tautological-compare
Re: [Intel-gfx] [PATCH v6 0/4] drm/i915/display: stop HPD workers before display driver unregister
Hi Jani, Ville and Imre, If there are no problems after reviewing this patch series, could you please merge it? Many thanks, G.G. On 7/22/22 3:51 PM, Andrzej Hajda wrote: Hi Jani, Ville, Arun, This patchset is replacement of patch "drm/i915/display: disable HPD workers before display driver unregister" [1]. Ive decided to split patch into two parts - fbdev and MST, there are different issues. Ive also dropped shutdown path, as it has slightly different requirements, and more importantly I am not able to test properly. v2 (thx Arun for review): - reword of commit message (Arun) - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun) v3: - new patch adding suspended flag, to handle https://gitlab.freedesktop.org/drm/intel/-/issues/5950 v4: - check suspend flag also in i915_digport_work_func v5: - added patch blocking FB creation in case HPD is supended, - added R-B from Arun to patch 3, thx v6: - finally, after getting direct access to bat-rpls-2, I have found the source of last WARN, intel_fbdev_hpd_set_suspend was not called in case of deferred setup, fixed in patch 2. [1]: https://patchwork.freedesktop.org/series/103811/ Regards Andrzej Andrzej Hajda (4): drm/i915/hpd: postpone HPD cancel work after last user suspension drm/i915/fbdev: suspend HPD before fbdev unregistration drm/i915/display: add hotplug.suspended flag drm/i915/fbdev: do not create fbdev if HPD is suspended drivers/gpu/drm/i915/display/intel_display.c | 3 +++ drivers/gpu/drm/i915/display/intel_fbdev.c | 12 ++-- drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++- drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +- drivers/gpu/drm/i915/i915_driver.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_irq.c | 1 - 7 files changed, 28 insertions(+), 7 deletions(-)
Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine
Sorry, the previous one contains html data. > On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote: > > On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote: >> Sent from my iPad On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote: >>> CAUTION: Email originated externally, do not click links or open >>> attachments unless you recognize the sender and know the content is safe. On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li wrote: > On 8/1/22 14:19, Tomasz Figa wrote: Hello Tomasz > ?Hi Randy, > On Mon, Aug 1, 2022 at 5:21 AM wrote: >> From: Randy Li >> This module is still at a early stage, I wrote this for showing what >> APIs we need here. >> Let me explain why we need such a module here. >> If you won't allocate buffers from a V4L2 M2M device, this module >> may not be very useful. I am sure the most of users won't know a >> device would require them allocate buffers from a DMA-Heap then >> import those buffers into a V4L2's queue. >> Then the question goes back to why DMA-Heap. From the Android's >> description, we know it is about the copyright's DRM. >> When we allocate a buffer in a DMA-Heap, it may register that buffer >> in the trusted execution environment so the firmware which is running >> or could only be acccesed from there could use that buffer later. >> The answer above leads to another thing which is not done in this >> version, the DMA mapping. Although in some platforms, a DMA-Heap >> responses a IOMMU device as well. For the genernal purpose, we would >> be better assuming the device mapping should be done for each device >> itself. The problem here we only know alloc_devs in those DMAbuf >> methods, which are DMA-heaps in my design, the device from the queue >> is not enough, a plane may requests another IOMMU device or table >> for mapping. >> Signed-off-by: Randy Li >> --- >> drivers/media/common/videobuf2/Kconfig| 6 + >> drivers/media/common/videobuf2/Makefile | 1 + >> .../common/videobuf2/videobuf2-dma-heap.c | 350 ++ >> include/media/videobuf2-dma-heap.h| 30 ++ >> 4 files changed, 387 insertions(+) >> create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c >> create mode 100644 include/media/videobuf2-dma-heap.h > First of all, thanks for the series. > Possibly a stupid question, but why not just allocate the DMA-bufs > directly from the DMA-buf heap device in the userspace and just import > the buffers to the V4L2 device using V4L2_MEMORY_DMABUF? Sometimes the allocation policy could be very complex, let's suppose a multiple planes pixel format enabling with frame buffer compression. Its luma, chroma data could be allocated from a pool which is delegated for large buffers while its metadata would come from a pool which many users could take some few slices from it(likes system pool). Then when we have a new users knowing nothing about this platform, if we just configure the alloc_devs in each queues well. The user won't need to know those complex rules. The real situation could be more complex, Samsung MFC's left and right banks could be regarded as two pools, many devices would benefit from this either from the allocation times or the security buffers policy. In our design, when we need to do some security decoding(DRM video), codecs2 would allocate buffers from the pool delegated for that. While the non-DRM video, users could not care about this. >>> I'm a little bit surprised about this, because on Android all the >>> graphics buffers are allocated from the system IAllocator and imported >>> to the specific devices. >> In the non-tunnel mode, yes it is. While the tunnel mode is completely >> vendor defined. Neither HWC nor codec2 cares about where the buffers coming >> from, you could do what ever you want. >> Besides there are DRM video in GNU Linux platform, I heard the webkit has >> made huge effort here and Playready is one could work in non-Android Linux. >>> Would it make sense to instead extend the UAPI to expose enough >>> information about the allocation requirements to the userspace, so it >>> can allocate correctly? >> Yes, it could. But as I said it would need the users to do more works. >>> My reasoning here is that it's not a driver's decision to allocate >>> from a DMA-buf heap (and which one) or not. It's the userspace which >>> knows that, based on the specific use case that it wants to fulfill. >> Although I would like to let the users decide that, users just can’t do that >> which would violate the security rules in some platforms. >> For example, video codec and display device could only access a region of >> memory, any other device or trusted apps can’t access it. Users have to >> allocate the buffer from the pool the vendor decided. >> So why not we offer a quick way
Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine
Sent from my iPad > On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote: > > On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote: >> >> >> >> Sent from my iPad >> On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote: >>> >>> CAUTION: Email originated externally, do not click links or open >>> attachments unless you recognize the sender and know the content is safe. >>> >>> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li wrote: > On 8/1/22 14:19, Tomasz Figa wrote: Hello Tomasz > ?Hi Randy, > On Mon, Aug 1, 2022 at 5:21 AM wrote: >> From: Randy Li >> This module is still at a early stage, I wrote this for showing what >> APIs we need here. >> Let me explain why we need such a module here. >> If you won't allocate buffers from a V4L2 M2M device, this module >> may not be very useful. I am sure the most of users won't know a >> device would require them allocate buffers from a DMA-Heap then >> import those buffers into a V4L2's queue. >> Then the question goes back to why DMA-Heap. From the Android's >> description, we know it is about the copyright's DRM. >> When we allocate a buffer in a DMA-Heap, it may register that buffer >> in the trusted execution environment so the firmware which is running >> or could only be acccesed from there could use that buffer later. >> The answer above leads to another thing which is not done in this >> version, the DMA mapping. Although in some platforms, a DMA-Heap >> responses a IOMMU device as well. For the genernal purpose, we would >> be better assuming the device mapping should be done for each device >> itself. The problem here we only know alloc_devs in those DMAbuf >> methods, which are DMA-heaps in my design, the device from the queue >> is not enough, a plane may requests another IOMMU device or table >> for mapping. >> Signed-off-by: Randy Li >> --- >> drivers/media/common/videobuf2/Kconfig| 6 + >> drivers/media/common/videobuf2/Makefile | 1 + >> .../common/videobuf2/videobuf2-dma-heap.c | 350 ++ >> include/media/videobuf2-dma-heap.h| 30 ++ >> 4 files changed, 387 insertions(+) >> create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c >> create mode 100644 include/media/videobuf2-dma-heap.h > First of all, thanks for the series. > Possibly a stupid question, but why not just allocate the DMA-bufs > directly from the DMA-buf heap device in the userspace and just import > the buffers to the V4L2 device using V4L2_MEMORY_DMABUF? Sometimes the allocation policy could be very complex, let's suppose a multiple planes pixel format enabling with frame buffer compression. Its luma, chroma data could be allocated from a pool which is delegated for large buffers while its metadata would come from a pool which many users could take some few slices from it(likes system pool). Then when we have a new users knowing nothing about this platform, if we just configure the alloc_devs in each queues well. The user won't need to know those complex rules. The real situation could be more complex, Samsung MFC's left and right banks could be regarded as two pools, many devices would benefit from this either from the allocation times or the security buffers policy. In our design, when we need to do some security decoding(DRM video), codecs2 would allocate buffers from the pool delegated for that. While the non-DRM video, users could not care about this. >>> >>> I'm a little bit surprised about this, because on Android all the >>> graphics buffers are allocated from the system IAllocator and imported >>> to the specific devices. >> In the non-tunnel mode, yes it is. While the tunnel mode is completely >> vendor defined. Neither HWC nor codec2 cares about where the buffers coming >> from, you could do what ever you want. >> >> Besides there are DRM video in GNU Linux platform, I heard the webkit has >> made huge effort here and Playready is one could work in non-Android Linux. >>> Would it make sense to instead extend the UAPI to expose enough >>> information about the allocation requirements to the userspace, so it >>> can allocate correctly? >> Yes, it could. But as I said it would need the users to do more works. >>> My reasoning here is that it's not a driver's decision to allocate >>> from a DMA-buf heap (and which one) or not. It's the userspace which >>> knows that, based on the specific use case that it wants to fulfill. >> Although I would like to let the users decide that, users just can’t do that >> which would violate the security rules in some platforms. >> For example, video codec and display device could only access a region of >> memory, any other device or trusted apps can’t access it. Users have to >> allocate the buffer from the pool the vendor decided. >> >> So why not we
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote: > > Hi Adam, Fabio, > > On 22-08-01, Adam Ford wrote: > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > > 1080p. I haven't yet been able to get other modes to work. > > > > > > Ok, good. On another thread, you mentioned that you were also trying > > > to get LVDS to work via SN65DSI83. > > > > > > Does LVDS work for you on this branch? > > > > I haven't tried with Marek's latest suggestion. In the other thread > > he mentioned a burst mode and setting the DSI speeds to higher > > frequencies, but the patch he had didn't look like it would apply > > cleanly, so I will need to dig into that a bit further. > > Can you provide me a link to this thread? Sure, https://www.spinics.net/lists/dri-devel/msg358301.html > > > Since my company doesn't really ship the LVDS displays with the kits, > > the HDMI is the default video, so I've been focusing on it. > > > > To answer Marco's question, I was able to revert "MLK-21958-13: > > drm/bridge: adv7511: Limit supported clocks" and still get a display > > at 1080p, but all the other resolutions I tried appear to come up > > blank. > > Cool so now you have the same state as we are. I have a couple patches applied to mine which mimic some of the stuff that NXP did. Since I have access to a programmer manual, i was able to confirm some of the 7535 specific stuff and the low-refresh rate changes in their kernel appear appropriate and I also created a second table of default settings for the 7535 and if the type is set properly, i'll use the newer table instead of the older one. If anyone wants any of these patches, I can certainly share them, but I am not certain they make any difference. There are a few other items in the programmer manual that I want to attempt to implement once I have a chance to further review the document. > > I think that the most important one is the blanking calc. Can you try to > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check > if you can get a output still? Also something to try would be to disable > the internal timing generator by specifying > 'adi,disable-timing-generator'. Also if you have an oscilloscope for > such frequencies you can check the hdmi clk-lane. I noticed that this is > sometimes wrong. I am doing this from my home office as a side project, so I don't have a scope, but I can try to revert the other patch and try to disable the internal timing generator when I get home tonight. I'll report my findings. > > Regards, > Marco > > > I didn't try every one. With that revert, more options come > > available, but 1440x900 and 800x600 were options I tried > > unsuccessfullyl. > > > > > adam > >
[PATCH] drm/amd/display: remove DML Makefile duplicate lines
There are two identical CFLAGS entries for "display_mode_vba_20.o", so remove one of them. Also, as there's already an entry for "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being defined or not, remove the one entry between CONFIG_DRM_AMD_DC_DCN ifdef guards. Signed-off-by: Magali Lemes --- drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index 359f6e9a1da0..41bb6c3cc2d8 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -61,7 +61,6 @@ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) -CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags) @@ -82,7 +81,6 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn301/dcn301_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn302/dcn302_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dcn303/dcn303_fpu.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/dsc/rc_calc_fpu.o := $(dml_ccflags) -CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calcs.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_auto.o := $(dml_ccflags) CFLAGS_$(AMDDALPATH)/dc/dml/calcs/dcn_calc_math.o := $(dml_ccflags) -Wno-tautological-compare -- 2.37.1
[PATCH] drm/gem: Fix GEM handle release errors
Currently we are assuming a one to one mapping between dmabuf and handle
when releasing GEM handles.
But that is not always true, since we would create extra handles for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was reported at:
https://lore.kernel.org/all/20211105083308.392156-1-jay...@rock-chips.com/
Another problem is that the drm_gem_remove_prime_handles() now only
remove handle to the exported dmabuf (gem_obj->dma_buf), so the imported
ones would leak:
WARNING: CPU: 2 PID: 236 at drivers/gpu/drm/drm_prime.c:228
drm_prime_destroy_file_private+0x18/0x24
Let's fix these by using handle to find the exact map to remove.
Signed-off-by: Jeffy Chen
---
drivers/gpu/drm/drm_gem.c | 17 +
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c| 16 ++--
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index eb0c2d041f13..ed39da383570 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -168,21 +168,6 @@ void drm_gem_private_object_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_gem_private_object_init);
-static void
-drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp)
-{
- /*
-* Note: obj->dma_buf can't disappear as long as we still hold a
-* handle reference in obj->handle_count.
-*/
- mutex_lock(>prime.lock);
- if (obj->dma_buf) {
- drm_prime_remove_buf_handle_locked(>prime,
- obj->dma_buf);
- }
- mutex_unlock(>prime.lock);
-}
-
/**
* drm_gem_object_handle_free - release resources bound to userspace handles
* @obj: GEM object to clean up.
@@ -253,7 +238,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
if (obj->funcs->close)
obj->funcs->close(obj, file_priv);
- drm_gem_remove_prime_handles(obj, file_priv);
+ drm_prime_remove_buf_handle(_priv->prime, id);
drm_vma_node_revoke(>vma_node, file_priv);
drm_gem_object_handle_put_unlocked(obj);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 1fbbc19f1ac0..7bb98e6a446d 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -74,8 +74,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void
*data,
void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv);
void drm_prime_destroy_file_private(struct drm_prime_file_private
*prime_fpriv);
-void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
- struct dma_buf *dma_buf);
+void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
+uint32_t handle);
/* drm_drv.c */
struct drm_minor *drm_minor_acquire(unsigned int minor_id);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index e3f09f18110c..c28518ab62d0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -190,29 +190,33 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
return -ENOENT;
}
-void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
- struct dma_buf *dma_buf)
+void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
+uint32_t handle)
{
struct rb_node *rb;
+ mutex_lock(_fpriv->lock);
+
rb = prime_fpriv->dmabufs.rb_node;
while (rb) {
struct drm_prime_member *member;
member = rb_entry(rb, struct drm_prime_member, dmabuf_rb);
- if (member->dma_buf == dma_buf) {
+ if (member->handle == handle) {
rb_erase(>handle_rb, _fpriv->handles);
rb_erase(>dmabuf_rb, _fpriv->dmabufs);
- dma_buf_put(dma_buf);
+ dma_buf_put(member->dma_buf);
kfree(member);
- return;
- } else if (member->dma_buf < dma_buf) {
+ break;
+ } else if (member->handle < handle) {
rb = rb->rb_right;
} else {
rb = rb->rb_left;
}
}
+
+ mutex_unlock(_fpriv->lock);
}
void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv)
--
2.20.1
Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Hi Am 02.08.22 um 05:45 schrieb Kevin Brace: Hi Thomas, I hope I am comprehending this right. Yes, I am adding 3 new uAPI calls, not 6 of them. Correspondingly, there are 3 new structs added. That's understood. While I may drop one (unmap uAPI), I personally do not wish to drop the other two at this point. Instead, I may need to add setparam and / or getparam uAPI to pass PCI Device ID back to the userspace. This is mainly needed by Mesa, although there is no code for Mesa at this point. Exactly my point! There's no userspace for it. That's why Sam and me are asking you to remove all kinds if uapi changes or ioctls from the patchset until Mesa (or some other component) requires it. I fear dropping the remaining two will require substantial redesign, and I will like to avoid this since the code is already working. No, it won't require a redesign. You'll have to remove the changes to the uapi header and any new ioctls that are in the patchset. Userspace programs; such as X11's modesetting driver, Weston or Gnome; will use the kernel's dumb-buffer ioctls to create unaccelerated buffers. You won't need any via-specific code in userspace. It's all there already and fully driver independent. Mesa will do software rendering. For the kernel's dumb buffers, please see [1]. It is my plan to proceed to adding acceleration after the code is added to the mainline kernel tree, so I will like to do it the way it is set up now. You can still send the current uapi changes when you add 3d acceleration to the kernel and Mesa. But once these interfaces have been added to the kernel, they are nearly impossible to change or remove. That's why we don't want to do this now. Best regards Thomas [1] https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#dumb-buffer-objects Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com Sent: Monday, August 01, 2022 at 11:49 AM From: "Thomas Zimmermann" To: "Kevin Brace" Cc: dri-devel@lists.freedesktop.org Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h Hi Kevin Am 31.07.22 um 00:48 schrieb Kevin Brace: Hi Thomas, I cannot drop the older DRI1 based uAPI calls. This is because include/uapi/drm/via_drm.h needs to retain backward compatibility with the existing OpenChrome DDX's XvMC library (it gets compiled when OpenChrome DDX is built) and likely with the existing DDX Xv code as well. If I remove the DRI1 based uAPI calls, the XvMC library will not get compiled (compile error will occur since the XvMC library assumes the presence of DRI1 based uAPI), and I assume the same for the DDX Xv code (I cannot even reach here since the XvMC library is compiled first). Although the v3 patch does not contain it, v4 patch will utilize drm_invalid_op() for the discontinued (not deprecated since OpenChrome DRM does not support the older DRI1 based uAPI at all) DRI1 based uAPI. https://cgit.freedesktop.org/openchrome/drm-openchrome/commit/?h=drm-next-5.20=16b3d68f95c9ccd15b7a3310e5d752fabbc76518 drm_invalid_op() is related to drm_ioctl.c, and is meant for legacy DRMs like Radeon, i915, etc. Since OpenChrome DRM is not a clean sheet design (related to VIA DRM to some extent), I will use this function for properly handling discontinued legacy uAPI calls. I hope this explanation / reasoning is okay with you. I'm not sure I understand your reply ormaybe I'm just missing something here. I'm not asking you to remove the existing DRI1 uapi. I'm just asking to not add the 6 new _GEM_ defines and 3 new _gem_ structures now. You mentioned that the driver does not yet support acceleration of any kind. So there should be no need to extend to uapi now. You can still do this when you add acceleration to the driver. Until then, the Xorg modesetting driver or any Compositor can use the generic dumb-buffer ioctls that create buffers with no acceleration. Best regards Thomas Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com Sent: Tuesday, July 26, 2022 at 11:24 AM From: "Thomas Zimmermann" To: "Kevin Brace" , dri-devel@lists.freedesktop.org Cc: "Kevin Brace" Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h Hi Am 26.07.22 um 01:53 schrieb Kevin Brace: From: Kevin Brace Changed the uAPI. Signed-off-by: Kevin Brace --- include/uapi/drm/via_drm.h | 35 +++ 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h index a1e125d42208..e9da45ce130a 100644 --- a/include/uapi/drm/via_drm.h +++ b/include/uapi/drm/via_drm.h @@ -1,4 +1,5 @@ /* + * Copyright © 2020 Kevin Brace * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved. * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved. * @@ -16,10 +17,10 @@ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
Re: [PATCH 1/2] dt-bindings: display: bridge: icn6211: Add support for RGB/BGR swap
On 8/1/22 18:32, Rob Herring wrote: On Mon, Aug 01, 2022 at 03:19:00PM +0200, Marek Vasut wrote: The ICN6211 is capable of swapping the output DPI RGB/BGR color channels, document a DT property to select this swap in DT. This can be useful on hardware where such swap happens. We should ensure this series[1] works for you instead. [...] Rob [1] https://lore.kernel.org/r/20220628181838.2031-3-max.oss...@gmail.com I'm still not convinced that we should encode this pixel format value directly into the DT instead of trying to describe the DPI bus color channel width/order/shift in the DT instead. I think I mentioned that before in one of the previous versions of that series.
Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
>
> On 7/21/22 16:24, Daniel Dadap wrote:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> ATM on x86 laptops where we want userspace to use the acpi_video backlight
>>> device we often register both the GPU's native backlight device and
>>> acpi_video's firmware acpi_video# backlight device. This relies on
>>> userspace preferring firmware type backlight devices over native ones, but
>>> registering 2 backlight devices for a single display really is undesirable.
>>>
>>> On x86 laptops where the native GPU backlight device should be used,
>>> the registering of other backlight devices is avoided by their drivers
>>> using acpi_video_get_backlight_type() and only registering their backlight
>>> if the return value matches their type.
>>>
>>> acpi_video_get_backlight_type() uses
>>> backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
>>> driver is available and will never return native if this returns
>>> false. This means that the GPU's native backlight registering code
>>> cannot just call acpi_video_get_backlight_type() to determine if it
>>> should register its backlight, since acpi_video_get_backlight_type() will
>>> never return native until the native backlight has already registered.
>>>
>>> To fix this add a new internal native function parameter to
>>> acpi_video_get_backlight_type(), which when set to true will make
>>> acpi_video_get_backlight_type() behave as if a native backlight has
>>> already been registered.
>>>
>>> And add a new acpi_video_backlight_use_native() helper, which sets this
>>> to true, for use in native GPU backlight code.
>>>
>>> Changes in v2:
>>> - Replace adding a native parameter to acpi_video_get_backlight_type() with
>>> adding a new acpi_video_backlight_use_native() helper.
>>>
>>> Signed-off-by: Hans de Goede
>>> ---
>>> drivers/acpi/video_detect.c | 24
>>> include/acpi/video.h | 5 +
>>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index becc198e4c22..4346c990022d 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -17,8 +17,9 @@
>>> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>>> * sony_acpi,... can take care about backlight brightness.
>>> *
>>> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>> - * which driver should handle the backlight.
>>> + * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>> which
>>> + * driver should handle the backlight. RAW/GPU-driver backlight drivers
>>> must
>>> + * use the acpi_video_backlight_use_native() helper for this.
>>> *
>>> * If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a
>>> module (m)
>>> * this file will not be compiled and acpi_video_get_backlight_type() will
>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct
>>> notifier_block *nb,
>>> * Arguably the native on win8 check should be done first, but that would
>>> * be a behavior change, which may causes issues.
>>> */
>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool
>>> native)
>>> {
>>> static DEFINE_MUTEX(init_mutex);
>>> + static bool native_available;
>>> static bool init_done;
>>> static long video_caps;
>>> @@ -570,6 +572,8 @@ enum acpi_backlight_type
>>> acpi_video_get_backlight_type(void)
>>> backlight_notifier_registered = true;
>>> init_done = true;
>>> }
>>> + if (native)
>>> + native_available = true;
>>> mutex_unlock(_mutex);
>>> if (acpi_backlight_cmdline != acpi_backlight_undef)
>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type
>>> acpi_video_get_backlight_type(void)
>>> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>> return acpi_backlight_vendor;
>>> - if (acpi_osi_is_win8() &&
>>> backlight_device_get_by_type(BACKLIGHT_RAW))
>>> + if (acpi_osi_is_win8() &&
>>> + (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
>>> return acpi_backlight_native;
>>> return acpi_backlight_video;
>>
>>
>> So I ran into a minor problem when testing the NVIDIA proprietary driver
>> against this change set, after checking acpi_video_backlight_use_native()
>> before registering the NVIDIA proprietary driver's backlight handler.
>> Namely, for the case where a user installs the NVIDIA proprietary driver
>> after the video.ko has already registered its backlight handler, we end up
>> with both the firmware and native handlers registered simultaneously, since
>> the ACPI video driver no longer unregisters its backlight handler. In this
>> state, desktop environments end up preferring the registered but
>> non-functional firmware handler from video.ko.
Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Hi Kevin, > > OpenChrome DDX carries lots of legacy code. > > https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/tree/src/via_drm.h?h=main=dc661c59257e855cd9b29c14b91a8ee2d9b86ccb > > There is a requirement to use the same via_drm.h with both DDX and DRM. > Hence, I need to keep a lot of the legacy DRI1 definitions inside via_drm.h. This part is fully understood. Also on top of this the via DRI1 driver uses this. I am not asking to have anything deleted from the existing uapi via_drm.h file. My feedback is that the following code should be dropped from the openchrome driver: + DRM_IOCTL_DEF_DRV(VIA_ALLOCMEM, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_FREEMEM, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_AGP_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER), + DRM_IOCTL_DEF_DRV(VIA_FB_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER), + DRM_IOCTL_DEF_DRV(VIA_MAP_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER), + DRM_IOCTL_DEF_DRV(VIA_DEC_FUTEX, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_DMA_INIT, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_CMDBUFFER, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_FLUSH, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_PCICMD, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_CMDBUF_SIZE, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_WAIT_IRQ, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_DMA_BLIT, drm_invalid_op, DRM_AUTH), + DRM_IOCTL_DEF_DRV(VIA_BLIT_SYNC, drm_invalid_op, DRM_AUTH), (Copied from openchrome-drm - I recall you did not post this code yet). The new openchrome driver should not care at all about the old UAPI, so just drop the above. The comment above is based on the understanding that when we have a kms compliant driver the user space is generic and we do not expect or need any via specifics in user space. In other words - x86-video-openchrome should - according to my understanding - not be needed. And we can have a fully operational wayland (and maybe X) userspace using the generic UAPI. This is where Thomas Zimmermann's comment about dumb buffers are relevant. Do I miss something obvious here? Sam
Re: [PATCH drm-misc-next v7 1/5] drm/fb: remove unused includes of drm_fb_cma_helper.h
Hi Danilo, Thank you for the patch. On Tue, Aug 02, 2022 at 02:04:01AM +0200, Danilo Krummrich wrote: > Quite a lot of drivers include the drm_fb_cma_helper.h header file > without actually making use of it's provided API, hence remove those > includes. > > Suggested-by: Sam Ravnborg > Signed-off-by: Danilo Krummrich Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/arm/hdlcd_drv.c | 1 - > drivers/gpu/drm/arm/malidp_drv.c| 1 - > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 1 - > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 - > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 1 - > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 1 - > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > drivers/gpu/drm/imx/ipuv3-crtc.c| 1 - > drivers/gpu/drm/logicvc/logicvc_mode.c | 1 - > drivers/gpu/drm/pl111/pl111_drv.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 - > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 - > drivers/gpu/drm/shmobile/shmob_drm_kms.c| 1 - > drivers/gpu/drm/solomon/ssd130x.c | 1 - > drivers/gpu/drm/sti/sti_drv.c | 1 - > drivers/gpu/drm/sti/sti_plane.c | 1 - > drivers/gpu/drm/stm/drv.c | 1 - > drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - > drivers/gpu/drm/sun4i/sun8i_mixer.c | 1 - > drivers/gpu/drm/tidss/tidss_crtc.c | 1 - > drivers/gpu/drm/tidss/tidss_kms.c | 1 - > drivers/gpu/drm/tidss/tidss_plane.c | 1 - > drivers/gpu/drm/tve200/tve200_drv.c | 1 - > drivers/gpu/drm/v3d/v3d_drv.c | 1 - > drivers/gpu/drm/vc4/vc4_drv.c | 1 - > 26 files changed, 26 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 350ca4e4eaa6..b32168e3f9ae 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -26,7 +26,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index d5aef21426cf..fa6c1a4254dc 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -19,7 +19,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > index 7780b72de9e8..54aa8af45829 100644 > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > index 7a503bf08d0f..4baa4977e473 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > @@ -20,7 +20,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > index d763f53f480c..5b47000738e4 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > @@ -6,7 +6,6 @@ > */ > > #include > -#include > #include > #include > > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > index 2af51df6dca7..e8b0fe970969 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > @@ -19,7 +19,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > b/drivers/gpu/drm/imx/imx-drm-core.c > index 50fd7aac5198..e43345bd1346 100644 > --- a/drivers/gpu/drm/imx/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c > b/drivers/gpu/drm/imx/ipuv3-crtc.c > index f7863d6dea80..d9f832f952c2 100644 > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c > @@ -18,7 +18,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/logicvc/logicvc_mode.c > b/drivers/gpu/drm/logicvc/logicvc_mode.c > index 11940704f644..c59da7039dc1 100644 > --- a/drivers/gpu/drm/logicvc/logicvc_mode.c > +++ b/drivers/gpu/drm/logicvc/logicvc_mode.c > @@ -10,7 +10,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/pl111/pl111_drv.c > b/drivers/gpu/drm/pl111/pl111_drv.c >
Re: [PATCH v1 08/35] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
Hi Maxime
Am 29.07.22 um 18:34 schrieb Maxime Ripard:
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..ee6b8f193c24 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
*client, int mode)
return ret;
}
EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_mode_test.c"
+#endif
Including source files is somewhat ugly, prolongs compile times and
could even interfere with the actual source code. Can we do this in some
other way?
I suggest to add the tests here and export them for use in the test
case. Something like
#ifdef CONFIG_DRM_KUNIT_TEST
static drm_mode_res_1920_1080_60()
{
...
}
struct kunit_case drm_mode_tests[] = {
drm_mode_res_1920_1080_60
};
EXPORT_SYMBOL(drm_mode_tests);
#endif
This would add the tests next to the tested code, but leave the test
driver in drm_mode_test.c.
Best regards
Thomas
diff --git a/drivers/gpu/drm/tests/drm_mode_test.c
b/drivers/gpu/drm/tests/drm_mode_test.c
new file mode 100644
index ..0f71519788a7
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_mode_test.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Maxime Ripard
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct drm_mode_test_priv {
+ struct device *dev;
+ struct drm_device *drm;
+ struct drm_connector connector;
+};
+
+static const struct drm_mode_config_funcs drm_mode_config_funcs = {
+};
+
+static const struct drm_driver drm_mode_driver = {
+};
+
+static int drm_mode_connector_get_modes(struct drm_connector *connector)
+{
+ struct drm_display_mode *mode;
+ int ret;
+
+ ret = drm_add_modes_noedid(connector, 1920, 1200);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static const struct drm_connector_helper_funcs drm_mode_connector_helper_funcs
= {
+ .get_modes = drm_mode_connector_get_modes,
+};
+
+static const struct drm_connector_funcs drm_mode_connector_funcs = {
+};
+
+static int drm_mode_test_init(struct kunit *test)
+{
+ struct drm_mode_test_priv *priv;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ test->priv = priv;
+
+ priv->dev = root_device_register("drm-mode-test");
+ if (IS_ERR(priv->dev))
+ return PTR_ERR(priv->dev);
+
+ priv->drm = drm_dev_alloc(_mode_driver, priv->dev);
+ if (IS_ERR(priv->drm))
+ return PTR_ERR(priv->drm);
+ priv->drm->mode_config.funcs = _mode_config_funcs;
+
+ ret = drmm_mode_config_init(priv->drm);
+ if (ret)
+ return ret;
+
+ ret = drmm_connector_init(priv->drm, >connector,
+ _mode_connector_funcs,
+ DRM_MODE_CONNECTOR_Unknown,
+ NULL);
+ if (ret)
+ return ret;
+ drm_connector_helper_add(>connector,
_mode_connector_helper_funcs);
+
+ return 0;
+}
+
+static void drm_mode_test_exit(struct kunit *test)
+{
+ struct drm_mode_test_priv *priv = test->priv;
+
+ drm_dev_put(priv->drm);
+ root_device_unregister(priv->dev);
+}
+
+static void drm_mode_res_1920_1080_60(struct kunit *test)
+{
+ struct drm_mode_test_priv *priv = test->priv;
+ struct drm_device *drm = priv->drm;
+ struct drm_connector *connector = >connector;
+ struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+ struct drm_display_mode *expected_mode, *mode;
+ const char *cmdline = "1920x1080@60";
+ int ret;
+
+ expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
+ KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
+
+ KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+ connector,
+
cmdline_mode));
+
+ mutex_lock(>mode_config.mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+ mutex_unlock(>mode_config.mutex);
+ KUNIT_ASSERT_GT(test, ret, 0);
+
+ mode = drm_connector_pick_cmdline_mode(connector);
+ KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+ KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
+}
+
+static struct kunit_case drm_mode_tests[] = {
+ KUNIT_CASE(drm_mode_res_1920_1080_60),
+
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam, Fabio, On 22-08-01, Adam Ford wrote: > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote: > > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote: > > > > > I managed to get my HDMI output working. I had the lanes set to 2 > > > instead of 4. Once I switched to 4-lanes, the monitor came up in > > > 1080p. I haven't yet been able to get other modes to work. > > > > Ok, good. On another thread, you mentioned that you were also trying > > to get LVDS to work via SN65DSI83. > > > > Does LVDS work for you on this branch? > > I haven't tried with Marek's latest suggestion. In the other thread > he mentioned a burst mode and setting the DSI speeds to higher > frequencies, but the patch he had didn't look like it would apply > cleanly, so I will need to dig into that a bit further. Can you provide me a link to this thread? > Since my company doesn't really ship the LVDS displays with the kits, > the HDMI is the default video, so I've been focusing on it. > > To answer Marco's question, I was able to revert "MLK-21958-13: > drm/bridge: adv7511: Limit supported clocks" and still get a display > at 1080p, but all the other resolutions I tried appear to come up > blank. Cool so now you have the same state as we are. I think that the most important one is the blanking calc. Can you try to revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check if you can get a output still? Also something to try would be to disable the internal timing generator by specifying 'adi,disable-timing-generator'. Also if you have an oscilloscope for such frequencies you can check the hdmi clk-lane. I noticed that this is sometimes wrong. Regards, Marco > I didn't try every one. With that revert, more options come > available, but 1440x900 and 800x600 were options I tried > unsuccessfullyl. > > adam >
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/guc: Define CTB based TLB invalidation routines
On Thu, 14 Jul 2022 16:06:28 +0200
Michal Wajdeczko wrote:
> On 14.07.2022 14:06, Mauro Carvalho Chehab wrote:
> > From: Prathap Kumar Valsan
> >
> > Add routines to interface with GuC firmware for TLB invalidation.
> >
> > Signed-off-by: Prathap Kumar Valsan
> > Cc: Bruce Chang
> > Cc: Michal Wajdeczko
> > Cc: Matthew Brost
> > Cc: Chris Wilson
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/21] at:
> > https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
> >
> > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 35 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 90 ++
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 -
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 6 ++
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 91 ++-
> > 6 files changed, 253 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > index 4ef9990ed7f8..2e39d8df4c82 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > @@ -134,6 +134,10 @@ enum intel_guc_action {
> > INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
> > INTEL_GUC_ACTION_CLIENT_SOFT_RESET = 0x5507,
> > INTEL_GUC_ACTION_SET_ENG_UTIL_BUFF = 0x550A,
> > + INTEL_GUC_ACTION_NOTIFY_MEMORY_CAT_ERROR = 0x6000,
>
> should this be part of this patch ?
No, I'll drop...
>
> > + INTEL_GUC_ACTION_PAGE_FAULT_NOTIFICATION = 0x6001,
... and also drop this one.
> > + INTEL_GUC_ACTION_TLB_INVALIDATION = 0x7000,
> > + INTEL_GUC_ACTION_TLB_INVALIDATION_DONE = 0x7001,
>
> can we document layout of these actions ?
Where should we document it? At intel_guc_invalidate_tlb_guc()
function & friends, or are you thinking on something else, at this
header file?
>
> > INTEL_GUC_ACTION_STATE_CAPTURE_NOTIFICATION = 0x8002,
> > INTEL_GUC_ACTION_NOTIFY_FLUSH_LOG_BUFFER_TO_FILE = 0x8003,
> > INTEL_GUC_ACTION_NOTIFY_CRASH_DUMP_POSTED = 0x8004,
> > @@ -177,4 +181,35 @@ enum intel_guc_state_capture_event_status {
> >
> > #define INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_MASK 0x00FF
> >
> > +#define INTEL_GUC_TLB_INVAL_TYPE_SHIFT 0
> > +#define INTEL_GUC_TLB_INVAL_MODE_SHIFT 8
>
> can we stop using SHIFT-based definitions and start using MASK-based
> instead ? then we will be able to use FIELD_PREP/GET like we do for i915_reg
Ok.
>
> > +/* Flush PPC or SMRO caches along with TLB invalidation request */
> > +#define INTEL_GUC_TLB_INVAL_FLUSH_CACHE (1 << 31)
> > +
> > +enum intel_guc_tlb_invalidation_type {
> > + INTEL_GUC_TLB_INVAL_GUC = 0x3,
> > +};
> > +
> > +/*
> > + * 0: Heavy mode of Invalidation:
> > + * The pipeline of the engine(s) for which the invalidation is targeted to
> > is
> > + * blocked, and all the in-flight transactions are guaranteed to be
> > Globally
> > + * Observed before completing the TLB invalidation
> > + * 1: Lite mode of Invalidation:
> > + * TLBs of the targeted engine(s) are immediately invalidated.
> > + * In-flight transactions are NOT guaranteed to be Globally Observed before
> > + * completing TLB invalidation.
> > + * Light Invalidation Mode is to be used only when
> > + * it can be guaranteed (by SW) that the address translations remain
> > invariant
> > + * for the in-flight transactions across the TLB invalidation. In other
> > words,
> > + * this mode can be used when the TLB invalidation is intended to clear
> > out the
> > + * stale cached translations that are no longer in use. Light Invalidation
> > Mode
> > + * is much faster than the Heavy Invalidation Mode, as it does not wait
> > for the
> > + * in-flight transactions to be GOd.
> > + */
>
> either drop this comment or squash with patch 10/21 to fix it
Ok.
>
> > +enum intel_guc_tlb_inval_mode {
> > + INTEL_GUC_TLB_INVAL_MODE_HEAVY = 0x0,
> > + INTEL_GUC_TLB_INVAL_MODE_LITE = 0x1,
> > +};
> > +
> > #endif /* _ABI_GUC_ACTIONS_ABI_H */
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > index 2706a8c65090..5c59f9b144a3 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -855,6 +855,96 @@ int intel_guc_self_cfg64(struct intel_guc *guc, u16
> > key, u64 value)
> > return __guc_self_cfg(guc, key, 2, value);
> > }
> >
> > +static int guc_send_invalidate_tlb(struct intel_guc *guc, u32 *action, u32
> > size)
>
> nit: maybe since MMIO TLB has moved to dedicated file, we can do the
> same with GUC TLB code like "intel_guc_tlb.c" ?
I'll add a patch at the end of this series moving the code.
> > +{
> > + struct intel_guc_tlb_wait _wq, *wq = &_wq;
> > +
Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine
On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote: > > > > Sent from my iPad > > > On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote: > > > > CAUTION: Email originated externally, do not click links or open > > attachments unless you recognize the sender and know the content is safe. > > > > > >> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li wrote: > >>> On 8/1/22 14:19, Tomasz Figa wrote: > >> Hello Tomasz > >>> ?Hi Randy, > >>> On Mon, Aug 1, 2022 at 5:21 AM wrote: > From: Randy Li > This module is still at a early stage, I wrote this for showing what > APIs we need here. > Let me explain why we need such a module here. > If you won't allocate buffers from a V4L2 M2M device, this module > may not be very useful. I am sure the most of users won't know a > device would require them allocate buffers from a DMA-Heap then > import those buffers into a V4L2's queue. > Then the question goes back to why DMA-Heap. From the Android's > description, we know it is about the copyright's DRM. > When we allocate a buffer in a DMA-Heap, it may register that buffer > in the trusted execution environment so the firmware which is running > or could only be acccesed from there could use that buffer later. > The answer above leads to another thing which is not done in this > version, the DMA mapping. Although in some platforms, a DMA-Heap > responses a IOMMU device as well. For the genernal purpose, we would > be better assuming the device mapping should be done for each device > itself. The problem here we only know alloc_devs in those DMAbuf > methods, which are DMA-heaps in my design, the device from the queue > is not enough, a plane may requests another IOMMU device or table > for mapping. > Signed-off-by: Randy Li > --- > drivers/media/common/videobuf2/Kconfig| 6 + > drivers/media/common/videobuf2/Makefile | 1 + > .../common/videobuf2/videobuf2-dma-heap.c | 350 ++ > include/media/videobuf2-dma-heap.h| 30 ++ > 4 files changed, 387 insertions(+) > create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c > create mode 100644 include/media/videobuf2-dma-heap.h > >>> First of all, thanks for the series. > >>> Possibly a stupid question, but why not just allocate the DMA-bufs > >>> directly from the DMA-buf heap device in the userspace and just import > >>> the buffers to the V4L2 device using V4L2_MEMORY_DMABUF? > >> Sometimes the allocation policy could be very complex, let's suppose a > >> multiple planes pixel format enabling with frame buffer compression. > >> Its luma, chroma data could be allocated from a pool which is delegated > >> for large buffers while its metadata would come from a pool which many > >> users could take some few slices from it(likes system pool). > >> Then when we have a new users knowing nothing about this platform, if we > >> just configure the alloc_devs in each queues well. The user won't need > >> to know those complex rules. > >> The real situation could be more complex, Samsung MFC's left and right > >> banks could be regarded as two pools, many devices would benefit from > >> this either from the allocation times or the security buffers policy. > >> In our design, when we need to do some security decoding(DRM video), > >> codecs2 would allocate buffers from the pool delegated for that. While > >> the non-DRM video, users could not care about this. > > > > I'm a little bit surprised about this, because on Android all the > > graphics buffers are allocated from the system IAllocator and imported > > to the specific devices. > In the non-tunnel mode, yes it is. While the tunnel mode is completely vendor > defined. Neither HWC nor codec2 cares about where the buffers coming from, > you could do what ever you want. > > Besides there are DRM video in GNU Linux platform, I heard the webkit has > made huge effort here and Playready is one could work in non-Android Linux. > > Would it make sense to instead extend the UAPI to expose enough > > information about the allocation requirements to the userspace, so it > > can allocate correctly? > Yes, it could. But as I said it would need the users to do more works. > > My reasoning here is that it's not a driver's decision to allocate > > from a DMA-buf heap (and which one) or not. It's the userspace which > > knows that, based on the specific use case that it wants to fulfill. > Although I would like to let the users decide that, users just can’t do that > which would violate the security rules in some platforms. > For example, video codec and display device could only access a region of > memory, any other device or trusted apps can’t access it. Users have to > allocate the buffer from the pool the vendor decided. > > So why not we offer a quick way that users don’t need to try and error. In principle, I'm not against integrating
Re: [PATCH 3/5] clk: qcom: gpucc-sc7280: Add cx collapse reset support
On 30/07/2022 12:17, Akhil P Oommen wrote:
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
drivers/clk/qcom/gpucc-sc7280.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..f5df51d 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,18 @@ static const struct regmap_config
gpu_cc_sc7280_regmap_config = {
.fast_io = true,
};
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+ [GPU_CX_COLLAPSE] = { .op = gdsc_wait_for_collapse, .priv = _gdsc },
+};
+
static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
.config = _cc_sc7280_regmap_config,
.clks = gpu_cc_sc7280_clocks,
.num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
.gdscs = gpu_cc_sc7180_gdscs,
.num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+ .resets = gpucc_sc7280_resets,
+ .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
An implementation question. Do we have to poll for the GDSC on platforms
like sm8150/sm8250 which have the plain BCR resets?
};
static const struct of_device_id gpu_cc_sc7280_match_table[] = {
--
With best wishes
Dmitry
Re: [PATCH v3 5/8] drm/msm/a6xx: Ensure CX collapse during gpu recovery
On 30/07/2022 12:40, Akhil P Oommen wrote:
Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.
This feature requires support from the platform's gpucc driver.
Signed-off-by: Akhil P Oommen
---
Changes in v3:
- Use reset interface from gpucc driver to poll for cx gdsc collapse
https://patchwork.freedesktop.org/series/106860/
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.h | 4
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 1b049c5..721d5e6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#define GPU_PAS_ID 13
@@ -1224,6 +1225,9 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(>pdev->dev);
+ /* Call into gpucc driver to poll for cx gdsc collapse */
+ reset_control_reset(gpu->cx_collapse);
Do we have a race between the last pm_runtime_put_sync(), this polling
and other voters removing their votes beforehand?
+
pm_runtime_use_autosuspend(>pdev->dev);
if (active_submits)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 07e55a6..4a57627 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
/*
@@ -903,6 +904,9 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
if (IS_ERR(gpu->gpu_cx))
gpu->gpu_cx = NULL;
+ gpu->cx_collapse = devm_reset_control_get_optional(>dev,
+ "cx_collapse");
+
gpu->pdev = pdev;
platform_set_drvdata(pdev, >adreno_smmu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6def008..ab59fd2 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "msm_drv.h"
#include "msm_fence.h"
@@ -268,6 +269,9 @@ struct msm_gpu {
bool hw_apriv;
struct thermal_cooling_device *cooling;
+
+ /* To poll for cx gdsc collapse during gpu recovery */
+ struct reset_control *cx_collapse;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
With best wishes
Dmitry
Re: [PATCH 2/5] clk: qcom: Allow custom reset ops
On 30/07/2022 12:17, Akhil P Oommen wrote:
Add support to allow soc specific clk drivers to specify a custom reset
operation. A consumer-driver of the reset framework can call
"reset_control_reset()" api to trigger this.
Signed-off-by: Akhil P Oommen
---
drivers/clk/qcom/reset.c | 6 ++
drivers/clk/qcom/reset.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/clk/qcom/reset.c b/drivers/clk/qcom/reset.c
index 819d194..4782bf1 100644
--- a/drivers/clk/qcom/reset.c
+++ b/drivers/clk/qcom/reset.c
@@ -13,6 +13,12 @@
static int qcom_reset(struct reset_controller_dev *rcdev, unsigned long id)
{
+ struct qcom_reset_controller *rst = to_qcom_reset_controller(rcdev);
+ const struct qcom_reset_map *map = >reset_map[id];
+
+ if (map->op)
+ return map->op(map);
This looks like a hack. For example, assert() and deassert() would still
follow the usual pattern of updating the bits. Please at least make them
return -EOPNOTSUP if map->op is defined.
A slightly better solution would be to make qcom_reset implementation
optional (and depending on desc->num_resets being greater than 0). Then
you can register your own reset controller implementation from the gpucc
driver.
+
rcdev->ops->assert(rcdev, id);
udelay(1);
rcdev->ops->deassert(rcdev, id);
diff --git a/drivers/clk/qcom/reset.h b/drivers/clk/qcom/reset.h
index 2a08b5e..295deeb 100644
--- a/drivers/clk/qcom/reset.h
+++ b/drivers/clk/qcom/reset.h
@@ -11,6 +11,8 @@
struct qcom_reset_map {
unsigned int reg;
u8 bit;
+ int (*op)(const struct qcom_reset_map *map);
+ void *priv;
};
struct regmap;
--
With best wishes
Dmitry
Re: [PATCH 3/5] clk: qcom: gpucc-sc7280: Add cx collapse reset support
On 30/07/2022 12:17, Akhil P Oommen wrote:
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
drivers/clk/qcom/gpucc-sc7280.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..f5df51d 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,18 @@ static const struct regmap_config
gpu_cc_sc7280_regmap_config = {
.fast_io = true,
};
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+ [GPU_CX_COLLAPSE] = { .op = gdsc_wait_for_collapse, .priv = _gdsc },
This will break bisectability. Please swap this one and the patch 4.
+};
+
static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
.config = _cc_sc7280_regmap_config,
.clks = gpu_cc_sc7280_clocks,
.num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
.gdscs = gpu_cc_sc7180_gdscs,
.num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+ .resets = gpucc_sc7280_resets,
+ .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
};
static const struct of_device_id gpu_cc_sc7280_match_table[] = {
--
With best wishes
Dmitry
Re: [PATCH 0/5] clk/qcom: Support gdsc collapse polling using 'reset' inteface
On 30/07/2022 12:17, Akhil P Oommen wrote: Some clients like adreno gpu driver would like to ensure that its gdsc is collapsed at hardware during a gpu reset sequence. This is because it has a votable gdsc which could be ON due to a vote from another subsystem like tz, hyp etc or due to an internal hardware signal. If this is votable, do we have any guarantee that the gdsc will collapse at all? How can we proceed if it did not collapse? To allow this, gpucc driver can expose an interface to the client driver using reset framework. Using this the client driver can trigger a polling within the gdsc driver. Trigger the polling made me think initially that we will actually trigger something in the HW. Instead the client uses reset framework to poll for the gdsc to be reset. This series is rebased on top of linus's master branch. Related discussion: https://patchwork.freedesktop.org/patch/493144/ Akhil P Oommen (5): dt-bindings: clk: qcom: Support gpu cx gdsc reset clk: qcom: Allow custom reset ops clk: qcom: gpucc-sc7280: Add cx collapse reset support clk: qcom: gdsc: Add a reset op to poll gdsc collapse arm64: dts: qcom: sc7280: Add Reset support for gpu arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++ drivers/clk/qcom/gdsc.c | 23 +++ drivers/clk/qcom/gdsc.h | 7 +++ drivers/clk/qcom/gpucc-sc7280.c | 6 ++ drivers/clk/qcom/reset.c | 6 ++ drivers/clk/qcom/reset.h | 2 ++ include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ 7 files changed, 46 insertions(+), 4 deletions(-) -- With best wishes Dmitry
Re: [PATCH] drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails
On 08/07/2022 19:26, Bjorn Andersson wrote:
In the event that devm_devfreq_add_device() fails the device's qos freq
list is left referencing df->idle_freq and df->boost_freq. Attempting to
initialize devfreq again after a probe deferral will then cause invalid
memory accesses in dev_pm_qos_add_request().
Fix this by dropping the requests in the error path.
Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints")
Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 ++
1 file changed, 2 insertions(+)
--
With best wishes
Dmitry
Re: [PATCH v2] drm/msm/dp: delete DP_RECOVERED_CLOCK_OUT_EN to fix tps4
On 01/08/2022 23:13, Kuogee Hsieh wrote:
Data Symbols scrambled is required for tps4 at link training 2.
Therefore SCRAMBLING_DISABLE bit should not be set for tps4 to
work.
RECOVERED_CLOCK_OUT_EN is for enable simple EYE test for jitter
measurement with minimal equipment for embedded applications purpose
and is not required to be set during normal operation.
Current implementation always have RECOVERED_CLOCK_OUT_EN bit set
which cause SCRAMBLING_DISABLE bit wrongly set at tps4 which prevent
tps4 from working.
This patch delete setting RECOVERED_CLOCK_OUT_EN to fix SCRAMBLING_DISABLE
be wrongly set at tps4.
Minor nits, more likely concerning feature patches:
- Please insert blank lines between paragraphs, it makes commit message
easier to read. And please add no extra line breaks if you do not intent
to end the paragraph here.
- "This patch" is generally the frowned upon phrase (see
Documentation/process/submitting-patches.rst)
Nevertheless:
Reviewed-by: Dmitry Baryshkov
Changes in v2:
-- fix Fixes tag
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index ab6aa13..013ca02 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1214,7 +1214,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private
*ctrl,
if (ret)
return ret;
- dp_ctrl_train_pattern_set(ctrl, pattern | DP_RECOVERED_CLOCK_OUT_EN);
+ dp_ctrl_train_pattern_set(ctrl, pattern);
for (tries = 0; tries <= maximum_retries; tries++) {
drm_dp_link_train_channel_eq_delay(ctrl->aux,
ctrl->panel->dpcd);
--
With best wishes
Dmitry
