Re: [PATCH] drm/ast: Update the sequence of Clearing Fast-reset
Hi
Am 18.01.21 um 09:57 schrieb KuoHsiang Chou:
[Bug][AST2500]
If SCU00 is not unlocked, just enter its password again.
It is unnecessary to clear AHB lock condition and restore WDT default
setting again, before Fast-reset clearing.
Signed-off-by: KuoHsiang Chou
Is this a separate issue? This patch looks like a fix for the previous
patch. [1] Can you add this change to v3 of the other patch?
Best regards
Thomas
[1]
https://lore.kernel.org/dri-devel/20210112075811.9354-1-kuohsiang_c...@aspeedtech.com/
---
drivers/gpu/drm/ast/ast_post.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 1f0007daa005..4f194c5fd2c2 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -2030,7 +2030,6 @@ void ast_patch_ahb_2500(struct ast_private *ast)
{
u32 data;
-patch_ahb_lock:
/* Clear bus lock condition */
ast_moutdwm(ast, 0x1e60, 0xAEED1A03);
ast_moutdwm(ast, 0x1e600084, 0x0001);
@@ -2044,11 +2043,9 @@ void ast_patch_ahb_2500(struct ast_private *ast)
ast_moutdwm(ast, 0x1E78500c, 0x0033);
udelay(1000);
}
- ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
do {
+ ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8);
data = ast_mindwm(ast, 0x1e6e2000);
- if (data == 0x)
- goto patch_ahb_lock;
} while (data != 1);
ast_moutdwm(ast, 0x1e6e207c, 0x0800); /* clear fast reset */
}
--
2.18.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] drm/uapi: Add USB connector type
Hi Noralf,
glad to hear from you! Welcome back!
Am 20.01.21 um 18:42 schrieb Daniel Vetter:
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes wrote:
Add a connector type for USB connected display panels.
Signed-off-by: Noralf Trønnes
---
include/uapi/drm/drm_mode.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fed66a03c7ae..33024cc5d26e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -367,6 +367,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_USB 20
I would not call it USB. I could imagine that at some point a generic
USB protocol could serve simple displays (i.e. in the sense of USB HID
or data or imaging). (Maybe Thunderbold already counts.) Anyway, USB
should be reserved for this case.
Best regards
Thomas
Beware, new connector types have in the past resulted in userspace
burning Maybe it's become better ...
Acked-by: Daniel Vetter
/**
* struct drm_mode_get_connector - Get connector metadata.
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Enable fp16 display support for DCE8+, next try.
On Mon, Jan 4, 2021 at 6:16 PM Alex Deucher wrote: > > On Mon, Dec 28, 2020 at 1:51 PM Mario Kleiner > wrote: > > > > Hi and happy post-christmas! > > > > I wrote a patch 1/1 that now checks plane scaling factors against > > the pixel-format specific limits in the asic specific dc_plane_cap > > structures during atomic check and other appropriate places. > > > > This should prevent things like asking for scaling on fp16 framebuffers > > if the hw can't do that. Hopefully this will now allow to safely enable > > fp16 scanout also on older asic's like DCE-11.0, DCE-10 and DCE-8. > > Patch 2/2 enables those DCE's now for fp16. > > > > I used some quickly hacked up of IGT test kms_plane_scaling, manually > > hacking the src fb size to make sure the patch correctly accepts or > > rejects atomic commits based on allowable scaling factors for rgbx/a > > 8 bit, 10, and fp16. > > > > This fp16 support has been successfully tested with a Sea Islands / > > DCE-8 laptop. I also confirmed that at least basic HDR signalling > > over HDMI works for that DCE-8 machine with a HDR monitor. For this > > i used the amdvlk driver which exposes fp16 since a while on supported > > hw. > > Patches look good to me, but I'd like to get some feedback from the > display folks as well. > > > > > There are other bugs in DC wrt. DCE-8 though, which didn't prevent > > my testing, but may be worth looking into. My DCE-8 machine scrambles > > the video output picture somewhat under Vulkan (radv and admvlk) if the > > output signal precision isn't 8 bpc, ie. on 6 bpc (eDP laptop panel) > > and 10 bpc, 12 bpc (HDMI deep color on external HDR monitor). > > > > Another fun thing is getting a black screen if DC is enabled on at least > > Linux 5.10+ (but not if i use the classic kms code in amdgpu-kms). If > > i recompile the driver with a Ubuntu kconfig for Linux 5.9, the 5.10 > > kernel works, and the only obvious DC related difference is that DC's > > new SI / DCE-6 asic support is disabled at compile time. > > Fixed here: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bdeff12a96c9a5da95c8d11fefd145eb165e32a > Patch should be in stable for 5.10 as well. Yes, in recent 5.10 stable these fix the problem I experienced. Thanks Alex, -mario > > Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amd/display: Fix HDMI deep color output for DCE 6-11.
This fixes corrupted display output in HDMI deep color
10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3.
It will hopefully also provide fixes for other DCE's up to
DCE-11, assuming those will need similar fixes, but i could
not test that for HDMI due to lack of suitable hw, so viewer
discretion is advised.
dce110_stream_encoder_hdmi_set_stream_attribute() is used for
HDMI setup on all DCE's and is missing color_depth assignment.
dce110_program_pix_clk() is used for pixel clock setup on HDMI
for DCE 6-11, and is missing color_depth assignment.
Additionally some of the underlying Atombios specific encoder
and pixelclock setup functions are missing code which is in
the classic amdgpu kms modesetting path and the in the radeon
kms driver for DCE6/DCE8.
encoder_control_digx_v3() - Was missing setup code wrt. amdgpu
and radeon kms classic drivers. Added here, but untested due to
lack of suitable test hw.
encoder_control_digx_v4() - Added missing setup code.
Successfully tested on AMD mullins / DCE-8.3 with HDMI deep color
output at 10 bpc and 12 bpc.
Note that encoder_control_digx_v5() has proper setup code in place
and is used, e.g., by DCE-11.2, but this code wasn't used for deep
color setup due to the missing cntl.color_depth setup in the calling
function for HDMI.
set_pixel_clock_v5() - Missing setup code wrt. classic amdgpu/radeon
kms. Added here, but untested due to lack of hw.
set_pixel_clock_v6() - Missing setup code added. Successfully tested
on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI
deep color output with 10 bpc or 12 bpc.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
---
.../drm/amd/display/dc/bios/command_table.c | 61 +++
.../drm/amd/display/dc/dce/dce_clock_source.c | 14 +
.../amd/display/dc/dce/dce_stream_encoder.c | 1 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
index 070459e3e407..afc10b954ffa 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/command_table.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/command_table.c
@@ -245,6 +245,23 @@ static enum bp_result encoder_control_digx_v3(
cntl->enable_dp_audio);
params.ucLaneNum = (uint8_t)(cntl->lanes_number);
+ switch (cntl->color_depth) {
+ case COLOR_DEPTH_888:
+ params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_101010:
+ params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_121212:
+ params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_161616:
+ params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
+ break;
+ default:
+ break;
+ }
+
if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
result = BP_RESULT_OK;
@@ -274,6 +291,23 @@ static enum bp_result encoder_control_digx_v4(
cntl->enable_dp_audio));
params.ucLaneNum = (uint8_t)(cntl->lanes_number);
+ switch (cntl->color_depth) {
+ case COLOR_DEPTH_888:
+ params.ucBitPerColor = PANEL_8BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_101010:
+ params.ucBitPerColor = PANEL_10BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_121212:
+ params.ucBitPerColor = PANEL_12BIT_PER_COLOR;
+ break;
+ case COLOR_DEPTH_161616:
+ params.ucBitPerColor = PANEL_16BIT_PER_COLOR;
+ break;
+ default:
+ break;
+ }
+
if (EXEC_BIOS_CMD_TABLE(DIGxEncoderControl, params))
result = BP_RESULT_OK;
@@ -1057,6 +1091,19 @@ static enum bp_result set_pixel_clock_v5(
* driver choose program it itself, i.e. here we program it
* to 888 by default.
*/
+ if (bp_params->signal_type == SIGNAL_TYPE_HDMI_TYPE_A)
+ switch (bp_params->color_depth) {
+ case TRANSMITTER_COLOR_DEPTH_30:
+ /* yes this is correct, the atom define is
wrong */
+ clk.sPCLKInput.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_32BPP;
+ break;
+ case TRANSMITTER_COLOR_DEPTH_36:
+ /* yes this is correct, the atom define is
wrong */
+ clk.sPCLKInput.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
+ break;
+ default:
+ break;
+ }
if (EXEC_BIOS_CMD_TABLE(SetPixelClock, clk))
result =
[PATCH 1/2] drm/amd/display: Fix 10/12 bpc setup in DCE output bit depth reduction.
In set_clamp(), the comments and definitions for the COLOR_DEPTH_101010
and COLOR_DEPTH_121212 cases directly contradict the code comment which
explains how this should work, whereas the COLOR_DEPTH_888 case
is consistent with the code comments. Comment says the bitmask should
be chosen to align to the top-most 10 or 12 MSB's on a 14 bit bus, but
the implementation contradicts that: 10 bit case sets a mask for 12 bpc
clamping, whereas 12 bit case sets a mask for 14 bpc clamping.
Note that during my limited testing on DCE-8.3 (HDMI deep color)
and DCE-11.2 (DP deep color), this didn't have any obvious ill
effects, neither did fixing it change anything obvious for the
better, so this fix may be inconsequential on DCE, and just
reduce the confusion of innocent bystanders when reading the code
and trying to investigate problems with 10 bpc+ output.
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Mario Kleiner
Cc: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
index 130a0a0c8332..68028ec995e7 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -601,12 +601,12 @@ static void set_clamp(
clamp_max = 0x3FC0;
break;
case COLOR_DEPTH_101010:
- /* 10bit MSB aligned on 14 bit bus '11 1100' */
- clamp_max = 0x3FFC;
+ /* 10bit MSB aligned on 14 bit bus '11 ' */
+ clamp_max = 0x3FF0;
break;
case COLOR_DEPTH_121212:
- /* 12bit MSB aligned on 14 bit bus '11 ' */
- clamp_max = 0x3FFF;
+ /* 12bit MSB aligned on 14 bit bus '11 1100' */
+ clamp_max = 0x3FFC;
break;
default:
clamp_max = 0x3FC0;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Some HDMI deep color output fixes for DC on DCE 6-11
Hi, these two patches fix non-working HDMI deep color output on DCE-8.3, AMD Mullins when amdgpu-kms is used with Displaycore force-enabled, ie. for radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1: I suspect they might fix similar problems on other older asics of DCE-11.0 and earlier. Patch 1/2 is a fix for some oddity i found while hunting for the HDMI deep color bug. It fixes what looks like an obvious mistake, but the fix did not improve or degrade anything, so maybe the hw doesn't care all too much about the wrong clamping/truncation mask? Anyway, it makes the code less confusing. Patch 2/2 fixes HDMI deep color output at 10 bpc or 12 bpc output on AMD Mullins, DCE-8.3, where at output_bpc 10 or 12 the display would be scrambled. With the patch, the display looks correct, and photometer measurements on a HDR-10 monitor suggest we probably get the correct output signal. I found the fix by comparing DC against the classic amdgpu-kms and radeon-kms modesetting path, readding missing stuff. Given other encoder/pixelclock setup functions than the ones used on DCE-8.3 showed the same omissions, i added missing code there as well, but i couldn't test it due to lack of hw, so i hope that fixes instead of breaks things on asic's other than DCE-8.3. I also created a similar patch for DCE-11.2 and later, not included here, but during testing on a Raven Ridge DCN-1, the patch neither helped nor hurt. Output was correct without the patch, and adding the patch didn't change or break anything on DCN-1. Looking at disassembled AtomBios tables for DCN-1 and a DCE-11.2, i think AtomBios may not do much with the info that was missing, which would explain why the current upstream code seems to work fine without it? At least as verified on DCN-1. I can't test on DCE-11.2 or DCE-12 due to lack of hw with actual HDMI output. But it would be interesting for me to know what changed wrt. Atombios in later asic versions to make some of this setup apparently redundant in DC? Do you test DC wrt. HDMI deep color starting at a specific DCE revision, given that the bug went unnoticed in DCE-8.3, but things seem to be fine on at least DCN-1? Thanks, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm: Improve the output_poll_changed description
From: zhangzhijie
this callback was used by drm_kms_helper_hotplug_event()
V2: (Thanks for Daniel's suggestions)
- remove the FIXME below.since with the drm_client
- infrastructure and the generic fbdev emulation we've
- resolved this all very neatly now.
V3: Add comments that This hook is deprecated
- new implementation methods instead of this hook
Signed-off-by: ZhiJie.Zhang
---
include/drm/drm_mode_config.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index ab424ddd7665..fbc0da25d7c5 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -103,14 +103,13 @@ struct drm_mode_config_funcs {
* Callback used by helpers to inform the driver of output configuration
* changes.
*
-* Drivers implementing fbdev emulation with the helpers can call
-* drm_fb_helper_hotplug_changed from this hook to inform the fbdev
-* helper of output changes.
+* Drivers implementing fbdev emulation use
drm_kms_helper_hotplug_event()
+* to call this hook to inform the fbdev helper of output changes.
*
-* FIXME:
-*
-* Except that there's no vtable for device-level helper callbacks
-* there's no reason this is a core function.
+* This hook is deprecated, drivers should instead use
+* drm_fbdev_generic_setup() which takes care of any necessary
+* hotplug event forwarding already without further involvement by
+* the driver.
*/
void (*output_poll_changed)(struct drm_device *dev);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the amdgpu tree
On Wed, Jan 20, 2021 at 7:53 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Wed, 20 Jan 2021 17:15:01 +1100 Stephen Rothwell
> wrote:
> >
> > On Fri, 15 Jan 2021 12:00:14 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the amdgpu tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> > > 'dm_set_vblank':
> > > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33:
> > > warning: unused variable 'dm' [-Wunused-variable]
> > > 5380 | struct amdgpu_display_manager *dm = >dm;
> > > | ^~
> > >
> > > Caused by commit
> > >
> > > 98ab5f3513f9 ("drm/amd/display: Fix deadlock during gpu reset v3")
> >
> > I am still getting this warning.
>
> I now get this warning from the drm tree merge.
Bhawan sent out the fix today:
https://patchwork.freedesktop.org/patch/415092/
Alex
>
> --
> Cheers,
> Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/ttm/ttm_pool.c
between commit:
bb52cb0dec8d ("drm/ttm: make the pool shrinker lock a mutex")
from Linus' tree and commits:
ba051901d10f ("drm/ttm: add a debugfs file for the global page pools")
f987c9e0f537 ("drm/ttm: optimize ttm pool shrinker a bit")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/ttm/ttm_pool.c
index 11e0313db0ea,e0617717113f..
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@@ -503,11 -505,14 +506,13 @@@ void ttm_pool_init(struct ttm_pool *poo
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
- ttm_pool_type_init(>caching[i].orders[j],
- pool, i, j);
+ if (use_dma_alloc) {
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+ for (j = 0; j < MAX_ORDER; ++j)
+ ttm_pool_type_init(>caching[i].orders[j],
+ pool, i, j);
+ }
}
-EXPORT_SYMBOL(ttm_pool_init);
/**
* ttm_pool_fini - Cleanup a pool
@@@ -521,9 -526,34 +526,33 @@@ void ttm_pool_fini(struct ttm_pool *poo
{
unsigned int i, j;
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
- ttm_pool_type_fini(>caching[i].orders[j]);
+ if (pool->use_dma_alloc) {
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+ for (j = 0; j < MAX_ORDER; ++j)
+ ttm_pool_type_fini(>caching[i].orders[j]);
+ }
+ }
-EXPORT_SYMBOL(ttm_pool_fini);
+
+ /* As long as pages are available make sure to release at least one */
+ static unsigned long ttm_pool_shrinker_scan(struct shrinker *shrink,
+ struct shrink_control *sc)
+ {
+ unsigned long num_freed = 0;
+
+ do
+ num_freed += ttm_pool_shrink();
+ while (!num_freed && atomic_long_read(_pages));
+
+ return num_freed;
+ }
+
+ /* Return the number of pages available or SHRINK_EMPTY if we have none */
+ static unsigned long ttm_pool_shrinker_count(struct shrinker *shrink,
+struct shrink_control *sc)
+ {
+ unsigned long num_pages = atomic_long_read(_pages);
+
+ return num_pages ? num_pages : SHRINK_EMPTY;
}
#ifdef CONFIG_DEBUG_FS
@@@ -553,6 -594,35 +593,35 @@@ static void ttm_pool_debugfs_orders(str
seq_puts(m, "\n");
}
+ /* Dump the total amount of allocated pages */
+ static void ttm_pool_debugfs_footer(struct seq_file *m)
+ {
+ seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
+ atomic_long_read(_pages), page_pool_size);
+ }
+
+ /* Dump the information for the global pools */
+ static int ttm_pool_debugfs_globals_show(struct seq_file *m, void *data)
+ {
+ ttm_pool_debugfs_header(m);
+
- spin_lock(_lock);
++ mutex_lock(_lock);
+ seq_puts(m, "wc\t:");
+ ttm_pool_debugfs_orders(global_write_combined, m);
+ seq_puts(m, "uc\t:");
+ ttm_pool_debugfs_orders(global_uncached, m);
+ seq_puts(m, "wc 32\t:");
+ ttm_pool_debugfs_orders(global_dma32_write_combined, m);
+ seq_puts(m, "uc 32\t:");
+ ttm_pool_debugfs_orders(global_dma32_uncached, m);
- spin_unlock(_lock);
++ mutex_unlock(_lock);
+
+ ttm_pool_debugfs_footer(m);
+
+ return 0;
+ }
+ DEFINE_SHOW_ATTRIBUTE(ttm_pool_debugfs_globals);
+
/**
* ttm_pool_debugfs - Debugfs dump function for a pool
*
@@@ -565,23 -635,14 +634,14 @@@ int ttm_pool_debugfs(struct ttm_pool *p
{
unsigned int i;
- mutex_lock(_lock);
-
- seq_puts(m, "\t ");
- for (i = 0; i < MAX_ORDER; ++i)
- seq_printf(m, " ---%2u---", i);
- seq_puts(m, "\n");
-
- seq_puts(m, "wc\t:");
- ttm_pool_debugfs_orders(global_write_combined, m);
- seq_puts(m, "uc\t:");
- ttm_pool_debugfs_orders(global_uncached, m);
+ if (!pool->use_dma_alloc) {
+ seq_puts(m, "unused\n");
+ return 0;
+ }
- seq_puts(m, "wc 32\t:");
- ttm_pool_debugfs_orders(global_dma32_write_combined, m);
- seq_puts(m, "uc 32\t:");
- ttm_pool_debugfs_orders(global_dma32_uncached, m);
+ ttm_pool_debugfs_header(m);
-
Re: linux-next: build failure after merge of the drm-intel tree
Hi all,
On Wed, 20 Jan 2021 10:57:15 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-intel tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/msm/dp/dp_ctrl.c: In function 'dp_ctrl_use_fixed_nvid':
> drivers/gpu/drm/msm/dp/dp_ctrl.c:1425:16: error: implicit declaration of
> function 'drm_dp_get_edid_quirks'; did you mean 'drm_do_get_edid'?
> [-Werror=implicit-function-declaration]
> 1425 | edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
> |^~
> |drm_do_get_edid
> drivers/gpu/drm/msm/dp/dp_ctrl.c:1431:11: error: too many arguments to
> function 'drm_dp_has_quirk'
> 1431 | return (drm_dp_has_quirk(>panel->desc, edid_quirks,
> | ^~~~
> In file included from drivers/gpu/drm/msm/dp/dp_ctrl.c:15:
> include/drm/drm_dp_helper.h:2087:1: note: declared here
> 2087 | drm_dp_has_quirk(const struct drm_dp_desc *desc, enum drm_dp_quirk
> quirk)
> | ^~~~
>
> Caused by commit
>
> 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based quirks"")
>
> Since the drm-intel tree still has its other build failure, I used the
> version from next-20210108 again today.
I still get this failure, but not the one from the drm tree, so I have
used the drm-intel tree from next-20210119 for today.
--
Cheers,
Stephen Rothwell
pgp2GbYwDzd1m.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build warning after merge of the amdgpu tree
Hi all,
On Wed, 20 Jan 2021 17:15:01 +1100 Stephen Rothwell
wrote:
>
> On Fri, 15 Jan 2021 12:00:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the amdgpu tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> > 'dm_set_vblank':
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5380:33:
> > warning: unused variable 'dm' [-Wunused-variable]
> > 5380 | struct amdgpu_display_manager *dm = >dm;
> > | ^~
> >
> > Caused by commit
> >
> > 98ab5f3513f9 ("drm/amd/display: Fix deadlock during gpu reset v3")
>
> I am still getting this warning.
I now get this warning from the drm tree merge.
--
Cheers,
Stephen Rothwell
pgpCv3KAW7iv4.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v6 2/6] verbs: Support dma-buf based memory region
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
CMakeLists.txt | 2 +-
debian/control | 2 +-
debian/libibverbs1.symbols | 4 +++-
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38 ++
libibverbs/driver.h | 8
libibverbs/dummy_ops.c | 11 +++
libibverbs/libibverbs.map.in | 6 ++
libibverbs/man/ibv_reg_mr.3 | 27 +--
libibverbs/verbs.c | 19 +++
libibverbs/verbs.h | 7 +++
11 files changed, 120 insertions(+), 6 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 30ae0cc..4113423 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -76,7 +76,7 @@ set(PACKAGE_VERSION "34.0")
# When this is changed the values in these files need changing too:
# debian/control
# debian/libibverbs1.symbols
-set(IBVERBS_PABI_VERSION "33")
+set(IBVERBS_PABI_VERSION "34")
set(IBVERBS_PROVIDER_SUFFIX "-rdmav${IBVERBS_PABI_VERSION}.so")
#-
diff --git a/debian/control b/debian/control
index a423e4f..9022644 100644
--- a/debian/control
+++ b/debian/control
@@ -152,7 +152,7 @@ Section: libs
Pre-Depends: ${misc:Pre-Depends}
Depends: adduser, ${misc:Depends}, ${shlibs:Depends}
Recommends: ibverbs-providers
-Breaks: ibverbs-providers (<< 33~)
+Breaks: ibverbs-providers (<< 34~)
Description: Library for direct userspace use of RDMA (InfiniBand/iWARP)
libibverbs is a library that allows userspace processes to use RDMA
"verbs" as described in the InfiniBand Architecture Specification and
diff --git a/debian/libibverbs1.symbols b/debian/libibverbs1.symbols
index 9130f41..6cf5c2f 100644
--- a/debian/libibverbs1.symbols
+++ b/debian/libibverbs1.symbols
@@ -9,7 +9,8 @@ libibverbs.so.1 libibverbs1 #MINVER#
IBVERBS_1.9@IBVERBS_1.9 30
IBVERBS_1.10@IBVERBS_1.10 31
IBVERBS_1.11@IBVERBS_1.11 32
- (symver)IBVERBS_PRIVATE_33 33
+ IBVERBS_1.12@IBVERBS_1.12 34
+ (symver)IBVERBS_PRIVATE_34 34
_ibv_query_gid_ex@IBVERBS_1.11 32
_ibv_query_gid_table@IBVERBS_1.11 32
ibv_ack_async_event@IBVERBS_1.0 1.1.6
@@ -99,6 +100,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
ibv_rate_to_mbps@IBVERBS_1.1 1.1.8
ibv_rate_to_mult@IBVERBS_1.0 1.1.6
ibv_read_sysfs_file@IBVERBS_1.0 1.1.6
+ ibv_reg_dmabuf_mr@IBVERBS_1.12 34
ibv_reg_mr@IBVERBS_1.0 1.1.6
ibv_reg_mr@IBVERBS_1.1 1.1.6
ibv_reg_mr_iova@IBVERBS_1.7 25
diff --git a/libibverbs/CMakeLists.txt b/libibverbs/CMakeLists.txt
index 0fe4256..d075225 100644
--- a/libibverbs/CMakeLists.txt
+++ b/libibverbs/CMakeLists.txt
@@ -21,7 +21,7 @@ configure_file("libibverbs.map.in"
rdma_library(ibverbs "${CMAKE_CURRENT_BINARY_DIR}/libibverbs.map"
# See Documentation/versioning.md
- 1 1.11.${PACKAGE_VERSION}
+ 1 1.12.${PACKAGE_VERSION}
all_providers.c
cmd.c
cmd_ah.c
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index 42dbe42..af0fad7 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018 Mellanox Technologies, Ltd. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr
*vmr,
return 0;
}
+int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
+ uint64_t iova, int fd, int access,
+ struct verbs_mr *vmr)
+{
+ DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
+ 9);
+ struct ib_uverbs_attr *handle;
+ uint32_t lkey, rkey;
+ int ret;
+
+ handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, );
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, );
+
+ fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
access);
+
+ ret = execute_ioctl(pd->context, cmdb);
+ if (ret)
+ return errno;
+
+ vmr->ibv_mr.handle = read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ handle);
+ vmr->ibv_mr.context = pd->context;
+ vmr->ibv_mr.lkey = lkey;
+ vmr->ibv_mr.rkey = rkey;
+
[PATCH rdma-core v6 4/6] pyverbs: Add dma-buf based MR support
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.
Signed-off-by: Jianxin Xiong
---
buildlib/pyverbs_functions.cmake | 78 +++
pyverbs/CMakeLists.txt | 11 +-
pyverbs/dmabuf.pxd | 15 +++
pyverbs/dmabuf.pyx | 73 ++
pyverbs/dmabuf_alloc.c | 278 +++
pyverbs/dmabuf_alloc.h | 19 +++
pyverbs/libibverbs.pxd | 2 +
pyverbs/mr.pxd | 6 +
pyverbs/mr.pyx | 105 ++-
9 files changed, 557 insertions(+), 30 deletions(-)
create mode 100644 pyverbs/dmabuf.pxd
create mode 100644 pyverbs/dmabuf.pyx
create mode 100644 pyverbs/dmabuf_alloc.c
create mode 100644 pyverbs/dmabuf_alloc.h
diff --git a/buildlib/pyverbs_functions.cmake b/buildlib/pyverbs_functions.cmake
index 953cec2..0792410 100644
--- a/buildlib/pyverbs_functions.cmake
+++ b/buildlib/pyverbs_functions.cmake
@@ -1,35 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2018, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved. See COPYING file
+
+function(build_module_from_cfiles PY_MODULE MODULE_NAME ALL_CFILES
LINKER_FLAGS)
+ string(REGEX REPLACE "\\.so$" "" SONAME
"${MODULE_NAME}${CMAKE_PYTHON_SO_SUFFIX}")
+ add_library(${SONAME} SHARED ${ALL_CFILES})
+ set_target_properties(${SONAME} PROPERTIES
+COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
+LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
+PREFIX "")
+ target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
+ install(TARGETS ${SONAME}
+DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+endfunction()
function(rdma_cython_module PY_MODULE LINKER_FLAGS)
- foreach(PYX_FILE ${ARGN})
-get_filename_component(FILENAME ${PYX_FILE} NAME_WE)
-get_filename_component(DIR ${PYX_FILE} DIRECTORY)
- if (DIR)
- set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}/${FILENAME}.pyx")
- else()
- set(PYX "${CMAKE_CURRENT_SOURCE_DIR}/${FILENAME}.pyx")
- endif()
-set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
-include_directories(${PYTHON_INCLUDE_DIRS})
-add_custom_command(
- OUTPUT "${CFILE}"
- MAIN_DEPENDENCY "${PYX}"
- COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
- "-I${PYTHON_INCLUDE_DIRS}"
- COMMENT "Cythonizing ${PYX}"
+ set(ALL_CFILES "")
+ set(MODULE_NAME "")
+ foreach(SRC_FILE ${ARGN})
+get_filename_component(FILENAME ${SRC_FILE} NAME_WE)
+get_filename_component(DIR ${SRC_FILE} DIRECTORY)
+get_filename_component(EXT ${SRC_FILE} EXT)
+if (DIR)
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}")
+else()
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+endif()
+if (${EXT} STREQUAL ".pyx")
+ # each .pyx file starts a new module, finish the previous module first
+ if (ALL_CFILES AND MODULE_NAME)
+build_module_from_cfiles(${PY_MODULE} ${MODULE_NAME} "${ALL_CFILES}"
"${LINKER_FLAGS}")
+ endif()
+ set(PYX "${SRC_PATH}/${FILENAME}.pyx")
+ set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
+ include_directories(${PYTHON_INCLUDE_DIRS})
+ add_custom_command(
+OUTPUT "${CFILE}"
+MAIN_DEPENDENCY "${PYX}"
+COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
+"-I${PYTHON_INCLUDE_DIRS}"
+COMMENT "Cythonizing ${PYX}"
)
-
-string(REGEX REPLACE "\\.so$" "" SONAME
"${FILENAME}${CMAKE_PYTHON_SO_SUFFIX}")
-add_library(${SONAME} SHARED ${CFILE})
-set_target_properties(${SONAME} PROPERTIES
- COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
- LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
- PREFIX "")
-target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
-install(TARGETS ${SONAME}
- DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+ set(MODULE_NAME ${FILENAME})
+ set(ALL_CFILES "${CFILE}")
+elseif(${EXT} STREQUAL ".c")
+ # .c files belong to the same module as the most recent .pyx file,
+ # ignored if appearing before all .pyx files
+ set(CFILE
[PATCH rdma-core v6 3/6] mlx5: Support dma-buf based memory region
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/providers/mlx5/mlx5.c b/providers/mlx5/mlx5.c
index a2a1696..b3c49af 100644
--- a/providers/mlx5/mlx5.c
+++ b/providers/mlx5/mlx5.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -95,6 +96,7 @@ static const struct verbs_context_ops mlx5_ctx_common_ops = {
.async_event = mlx5_async_event,
.dealloc_pd= mlx5_free_pd,
.reg_mr= mlx5_reg_mr,
+ .reg_dmabuf_mr = mlx5_reg_dmabuf_mr,
.rereg_mr = mlx5_rereg_mr,
.dereg_mr = mlx5_dereg_mr,
.alloc_mw = mlx5_alloc_mw,
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index bafe077..decc7f8 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -941,6 +942,8 @@ void mlx5_async_event(struct ibv_context *context,
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd);
struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
uint64_t hca_va, int access);
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int access);
int mlx5_rereg_mr(struct verbs_mr *mr, int flags, struct ibv_pd *pd, void
*addr,
size_t length, int access);
int mlx5_dereg_mr(struct verbs_mr *mr);
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index b2391e8..cc0bc42 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -626,6 +627,27 @@ struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr,
size_t length,
return >vmr.ibv_mr;
}
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int acc)
+{
+ struct mlx5_mr *mr;
+ int ret;
+
+ mr = calloc(1, sizeof(*mr));
+ if (!mr)
+ return NULL;
+
+ ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, acc,
+ >vmr);
+ if (ret) {
+ free(mr);
+ return NULL;
+ }
+ mr->alloc_flags = acc;
+
+ return >vmr.ibv_mr;
+}
+
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd)
{
struct mlx5_mr *mr;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v6 5/6] tests: Add tests for dma-buf based memory regions
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/args_parser.py | 4 +
tests/test_mr.py | 264 ++-
tests/utils.py | 26 +
3 files changed, 293 insertions(+), 1 deletion(-)
diff --git a/tests/args_parser.py b/tests/args_parser.py
index 446535a..5bc53b0 100644
--- a/tests/args_parser.py
+++ b/tests/args_parser.py
@@ -19,6 +19,10 @@ class ArgsParser(object):
parser.add_argument('--port',
help='Use port of RDMA device', type=int,
default=1)
+parser.add_argument('--gpu', nargs='?', type=int, const=0, default=0,
+help='GPU unit to allocate dmabuf from')
+parser.add_argument('--gtt', action='store_true', default=False,
+help='Allocate dmabuf from GTT instead of VRAM')
parser.add_argument('-v', '--verbose', dest='verbosity',
action='store_const',
const=2, help='Verbose output')
diff --git a/tests/test_mr.py b/tests/test_mr.py
index adc649c..6915853 100644
--- a/tests/test_mr.py
+++ b/tests/test_mr.py
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019 Mellanox Technologies, Inc. All rights reserved. See
COPYING file
+# Copyright (c) 2020 Intel Corporation. All rights reserved. See COPYING file
"""
Test module for pyverbs' mr module.
"""
@@ -9,9 +10,10 @@ import errno
from tests.base import PyverbsAPITestCase, RCResources, RDMATestCase
from pyverbs.pyverbs_error import PyverbsRDMAError, PyverbsError
-from pyverbs.mr import MR, MW, DMMR, MWBindInfo, MWBind
+from pyverbs.mr import MR, MW, DMMR, DmaBufMR, MWBindInfo, MWBind
from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
from pyverbs.wr import SendWR
+from pyverbs.dmabuf import DmaBuf
import pyverbs.device as d
from pyverbs.pd import PD
import pyverbs.enums as e
@@ -366,3 +368,263 @@ class DMMRTest(PyverbsAPITestCase):
dm_mr = DMMR(pd, dm_mr_len, e.IBV_ACCESS_ZERO_BASED,
dm=dm, offset=dm_mr_offset)
dm_mr.close()
+
+
+def check_dmabuf_support(unit=0):
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.ENOENT:
+raise unittest.SkipTest(f'Device /dev/dri/renderD{device_num} is
not present')
+if ex.error_code == errno.EACCES:
+raise unittest.SkipTest(f'Lack of permission to access
/dev/dri/renderD{device_num}')
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest(f'Allocating dmabuf is not supported by
/dev/dri/renderD{device_num}')
+
+
+def check_dmabuf_mr_support(pd, unit=0):
+"""
+Check if dma-buf MR registration is supported by the driver.
+Skip the test on failure
+"""
+try:
+DmaBufMR(pd, 1, 0, unit=unit)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest('Reg dma-buf MR is not supported by the
RDMA driver')
+
+
+class DmaBufMRTest(PyverbsAPITestCase):
+"""
+Test various functionalities of the DmaBufMR class.
+"""
+def setUp(self):
+super().setUp()
+self.unit = self.config['gpu']
+self.gtt = self.config['gtt']
+
+def test_dmabuf_reg_mr(self):
+"""
+Test ibv_reg_dmabuf_mr()
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+ gtt=self.gtt) as mr:
+pass
+
+def test_dmabuf_dereg_mr(self):
+"""
+Test ibv_dereg_mr() with DmaBufMR
+"""
+check_dmabuf_support(self.unit)
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd, self.unit)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off, unit=self.unit,
+ gtt=self.gtt) as mr:
+
[PATCH rdma-core v6 0/6] Add user space dma-buf support
This is the sixth version of the patch series. Change log: v6: * Rebase to the latest rdma-core master (commit 14006f2f841b0c) * Update the ABI symbol version to match new package version; also bump the private ABI version because new function has been added to the provider interface * Avoid changing 'struct ibv_context_ops' by replacing SET_OP() with SET_PRIV_OP_IC() * Replace sprintf() with snprintf() * Keep the ops in verbs_set_ops() sorted * Fix some styling issues: extra spaces, struct 0-initialization, error checking control flow v5: https://www.spinics.net/lists/linux-rdma/msg99015.html * Use a different mr_type for dmabuf so that ibv_dofork_range() is not called inside ibv_dereg_mr() for dmabuf based mr v4: https://www.spinics.net/lists/linux-rdma/msg98135.html * Rework the cmake funciton rdma_cython_module to support both single source (.pyx) and multiple source (.pyx + [.c]*) scenarios instead of using two separate functions * Rename 'dri_*' to 'drm_*' for the dmabuf allocation interface * Add option to dmabuf allocation routine to allow allocation from GTT instead of VRAM * Add proper CPU access flags when allocating dmabufs * Remove 'radeon' driver support from the dmabuf allocation routines * Add comand line arguments to the tests for selecting GPU unit and setting the option for allocating from GTT v3: https://www.spinics.net/lists/linux-rdma/msg98059.html * Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API * Change the way of allocating dma-buf object - use /dev/dri/renderD* instead of /dev/dri/card* and use GEM object instead of dumb buffer * Add cmake function to allow building modules with mixed cython and C source files * Add new tests that use dma-buf MRs for send/recv and rdma traffic * Skip dma-buf tests on unsupported systems * Remove some use of random values in the new tests * Add dealloc() and close() methods to the new classes * Replace string.format with f-string in python code * Fix some coding style issues: spacing, indentation, typo, comments v2: https://www.spinics.net/lists/linux-rdma/msg97936.html * Put the kernel header updates into a separate commit * Add comments for the data structure used in python ioctl calls * Fix issues related to symbol versioning * Fix styling issues: extra spaces, unncecessary variable, typo * Fix an inproper error code usage * Put the new op into ibv_context_ops instead if verbs_context v1: https://www.spinics.net/lists/linux-rdma/msg97865.html * Add user space API for registering dma-buf based memory regions * Update pyverbs with the new API * Add new tests This is the user space counter-part of the kernel patch set to add dma-buf support to the RDMA subsystem. This series consists of six patches. The first patch updates the kernel headers for dma-buf support. Patch 2 adds the new API function and updates the man pages. Patch 3 implements the new API in the mlx5 provider. Patch 4 adds new class definitions to pyverbs for the new API. Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in the utility code of the tests. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895 Jianxin Xiong (6): Update kernel headers verbs: Support dma-buf based memory region mlx5: Support dma-buf based memory region pyverbs: Add dma-buf based MR support tests: Add tests for dma-buf based memory regions tests: Bug fix for get_access_flags() CMakeLists.txt | 2 +- buildlib/pyverbs_functions.cmake | 78 ++--- debian/control | 2 +- debian/libibverbs1.symbols | 4 +- kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++ libibverbs/CMakeLists.txt| 2 +- libibverbs/cmd_mr.c | 38 + libibverbs/driver.h | 8 + libibverbs/dummy_ops.c | 11 ++ libibverbs/libibverbs.map.in | 6 + libibverbs/man/ibv_reg_mr.3 | 27 ++- libibverbs/verbs.c | 19 +++ libibverbs/verbs.h | 7 + providers/mlx5/mlx5.c| 2 + providers/mlx5/mlx5.h| 3 + providers/mlx5/verbs.c | 22 +++ pyverbs/CMakeLists.txt | 11 +- pyverbs/dmabuf.pxd | 15 ++ pyverbs/dmabuf.pyx | 73 pyverbs/dmabuf_alloc.c | 278 +++ pyverbs/dmabuf_alloc.h | 19 +++ pyverbs/libibverbs.pxd | 2 + pyverbs/mr.pxd | 6 + pyverbs/mr.pyx | 105 +++- tests/args_parser.py | 4 + tests/test_mr.py | 264 - tests/utils.py | 30 +++- 27 files changed, 1013 insertions(+), 39 deletions(-) create mode 100644 pyverbs/dmabuf.pxd create mode 100644
[PATCH rdma-core v6 6/6] tests: Bug fix for get_access_flags()
The filter definition is wrong and causes get_access_flags() always returning empty list. As the result the MR tests using this function are effectively skipped (but report success). Signed-off-by: Jianxin Xiong --- tests/utils.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/utils.py b/tests/utils.py index 8546329..c41cb3b 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -58,8 +58,8 @@ def filter_illegal_access_flags(element): :param element: A list of access flags to check :return: True if this list is legal, else False """ -if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE: -if e.IBV_ACCESS_LOCAL_WRITE: +if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE in element: +if not e.IBV_ACCESS_LOCAL_WRITE in element: return False return True -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v6 1/6] Update kernel headers
To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
b/kernel-headers/rdma/ib_user_ioctl_cmds.h
index 7968a18..dafc7eb 100644
--- a/kernel-headers/rdma/ib_user_ioctl_cmds.h
+++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -251,6 +252,7 @@ enum uverbs_methods_mr {
UVERBS_METHOD_MR_DESTROY,
UVERBS_METHOD_ADVISE_MR,
UVERBS_METHOD_QUERY_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
};
enum uverbs_attrs_mr_destroy_ids {
@@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
UVERBS_ATTR_QUERY_MR_RESP_IOVA,
};
+enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
+ UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+};
+
enum uverbs_attrs_create_counters_cmd_attr_ids {
UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
};
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] drm/mediatek: Change disp/ddp term to mutex in mtk mutex driver
Hi, Matthias:
Matthias Brugger 於 2021年1月21日 週四 上午2:27寫道：
>
> On Thu, Jan 07, 2021 at 07:17:27AM +0800, Chun-Kuang Hu wrote:
> > From: CK Hu
> >
> > mtk mutex is used by both drm and mdp driver, so change disp/ddp term to
> > mutex to show that it's a common driver for drm and mdp.
> >
> > Signed-off-by: CK Hu
> > Signed-off-by: Chun-Kuang Hu
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 30 +--
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> > drivers/gpu/drm/mediatek/mtk_mutex.c| 305
> > drivers/gpu/drm/mediatek/mtk_mutex.h| 26 +-
> > 5 files changed, 182 insertions(+), 183 deletions(-)
> >
> [...]
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.c
> > b/drivers/gpu/drm/mediatek/mtk_mutex.c
> > index 1c8a253f4788..98a060bf225d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mutex.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mutex.c
> [...]
> >
> > -static const struct of_device_id ddp_driver_dt_match[] = {
> > +static const struct of_device_id mutex_driver_dt_match[] = {
> > { .compatible = "mediatek,mt2701-disp-mutex",
> > - .data = _ddp_driver_data},
> > + .data = _mutex_driver_data},
> > { .compatible = "mediatek,mt2712-disp-mutex",
> > - .data = _ddp_driver_data},
> > + .data = _mutex_driver_data},
> > { .compatible = "mediatek,mt8167-disp-mutex",
> > - .data = _ddp_driver_data},
> > + .data = _mutex_driver_data},
> > { .compatible = "mediatek,mt8173-disp-mutex",
> > - .data = _ddp_driver_data},
> > + .data = _mutex_driver_data},
> > {},
> > };
> > -MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
> > +MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
>
> I think it would make sense in a follow-up patch to update the binding
> to use "mediatek,mt2701-mutex" to reflect that mutex is used for drm and
> mdp driver. Make sense?
Yes, it make sense. I would try to update the binding, but I wonder
device tree should be backward compatible? Let's discuss in that
follow-up patches.
Regards,
Chun-Kuang.
>
> Regards,
> Matthias
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] soc / drm: mediatek: Move mtk mutex driver to soc folder
Hi, Matthias:
Matthias Brugger 於 2021年1月21日 週四 上午2:33寫道：
>
> On Thu, Jan 07, 2021 at 07:17:29AM +0800, Chun-Kuang Hu wrote:
> > From: CK Hu
> >
> > mtk mutex is used by DRM and MDP driver, and its function is SoC-specific,
> > so move it to soc folder.
> >
> > Signed-off-by: CK Hu
> > Signed-off-by: Chun-Kuang Hu
>
> Acked-by: Matthias Brugger
>
> Please take the patch through your tree. Thanks!
Applied, thanks.
Regards,
Chun-Kuang.
>
> > ---
> > drivers/gpu/drm/mediatek/Makefile | 3 +--
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c| 1 -
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h| 1 -
> > drivers/soc/mediatek/Makefile | 1 +
> > .../mtk_mutex.c => soc/mediatek/mtk-mutex.c} | 15 +--
> > .../linux/soc/mediatek/mtk-mutex.h| 0
> > 7 files changed, 16 insertions(+), 7 deletions(-)
> > rename drivers/{gpu/drm/mediatek/mtk_mutex.c => soc/mediatek/mtk-mutex.c}
> > (96%)
> > rename drivers/gpu/drm/mediatek/mtk_mutex.h =>
> > include/linux/soc/mediatek/mtk-mutex.h (100%)
> >
> > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > b/drivers/gpu/drm/mediatek/Makefile
> > index 09979c4c340a..01d06332f767 100644
> > --- a/drivers/gpu/drm/mediatek/Makefile
> > +++ b/drivers/gpu/drm/mediatek/Makefile
> > @@ -9,8 +9,7 @@ mediatek-drm-y := mtk_disp_color.o \
> > mtk_drm_gem.o \
> > mtk_drm_plane.o \
> > mtk_dsi.o \
> > - mtk_dpi.o \
> > - mtk_mutex.o
> > + mtk_dpi.o
> >
> > obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 1e3a9450680b..e9b6788d52cd 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -22,7 +23,6 @@
> > #include "mtk_drm_ddp_comp.h"
> > #include "mtk_drm_gem.h"
> > #include "mtk_drm_plane.h"
> > -#include "mtk_mutex.h"
> >
> > /*
> > * struct mtk_drm_crtc - MediaTek specific crtc structure.
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index b99a06e6834e..5d39dd54255d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -588,7 +588,6 @@ static struct platform_driver mtk_drm_platform_driver =
> > {
> > };
> >
> > static struct platform_driver * const mtk_drm_drivers[] = {
> > - _mutex_driver,
> > _disp_color_driver,
> > _disp_ovl_driver,
> > _disp_rdma_driver,
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > index ae366868d01a..e8238fa4aa2a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > @@ -46,7 +46,6 @@ struct mtk_drm_private {
> > struct drm_atomic_state *suspend_state;
> > };
> >
> > -extern struct platform_driver mtk_mutex_driver;
> > extern struct platform_driver mtk_disp_color_driver;
> > extern struct platform_driver mtk_disp_ovl_driver;
> > extern struct platform_driver mtk_disp_rdma_driver;
> > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> > index b6908db534c2..90270f8114ed 100644
> > --- a/drivers/soc/mediatek/Makefile
> > +++ b/drivers/soc/mediatek/Makefile
> > @@ -6,3 +6,4 @@ obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> > obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
> > obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> > +obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mutex.c
> > b/drivers/soc/mediatek/mtk-mutex.c
> > similarity index 96%
> > rename from drivers/gpu/drm/mediatek/mtk_mutex.c
> > rename to drivers/soc/mediatek/mtk-mutex.c
> > index 66344759e622..f531b119da7a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mutex.c
> > +++ b/drivers/soc/mediatek/mtk-mutex.c
> > @@ -10,8 +10,7 @@
> > #include
> > #include
> > #include
> > -
> > -#include "mtk_mutex.h"
> > +#include
> >
> > #define MT2701_MUTEX0_MOD0 0x2c
> > #define MT2701_MUTEX0_SOF0 0x30
> > @@ -241,6 +240,7 @@ struct mtk_mutex *mtk_mutex_get(struct device *dev)
> >
> > return ERR_PTR(-EBUSY);
> > }
> > +EXPORT_SYMBOL_GPL(mtk_mutex_get);
> >
> > void mtk_mutex_put(struct mtk_mutex *mutex)
> > {
> > @@ -251,6 +251,7 @@ void mtk_mutex_put(struct mtk_mutex *mutex)
> >
> > mutex->claimed = false;
> > }
> > +EXPORT_SYMBOL_GPL(mtk_mutex_put);
> >
> > int mtk_mutex_prepare(struct mtk_mutex *mutex)
> > {
> > @@ -258,6 +259,7 @@ int mtk_mutex_prepare(struct mtk_mutex *mutex)
> >
Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"
On Wed, Jan 20, 2021 at 3:20 AM Ard Biesheuvel wrote: > > On Tue, 5 Jan 2021 at 17:23, Alex Deucher wrote: > > > > On Tue, Jan 5, 2021 at 8:05 AM Will Deacon wrote: > > > > > > On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote: > > > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > > > > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > > > > > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher > > > > > > wrote: > > > > > > > > > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel > > > > > > > wrote: > > > > > > > > > > > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > > > > > > > > > > > > > > > Simply disabling -mgeneral-regs-only left and right is risky, > > > > > > > > given that > > > > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers > > > > > > > > anywhere, > > > > > > > > and GCC is known to use SIMD registers for spilling, and may > > > > > > > > invent > > > > > > > > other uses of the FP/SIMD register file that have nothing to do > > > > > > > > with the > > > > > > > > floating point code in question. Note that putting > > > > > > > > kernel_neon_begin() > > > > > > > > and kernel_neon_end() around the code that does use FP is not > > > > > > > > sufficient > > > > > > > > here, the problem is in all the other code that may be emitted > > > > > > > > with > > > > > > > > references to SIMD registers in it. > > > > > > > > > > > > > > > > So the only way to do this properly is to put all floating > > > > > > > > point code in > > > > > > > > a separate compilation unit, and only compile that unit with > > > > > > > > -mgeneral-regs-only. But perhaps the use of floating point here > > > > > > > > is > > > > > > > > something that should be reconsidered entirely. > > > > > > > > > > > > > > > > Cc: Catalin Marinas > > > > > > > > Cc: Will Deacon > > > > > > > > Cc: Dave Martin > > > > > > > > Cc: Rob Herring > > > > > > > > Cc: Leo Li > > > > > > > > Cc: Alex Deucher > > > > > > > > Cc: "Christian König" > > > > > > > > Cc: David Airlie > > > > > > > > Cc: Daniel Vetter > > > > > > > > Cc: Daniel Kolesa > > > > > > > > Cc: amd-...@lists.freedesktop.org > > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > > > > > > > Can rebase this on Linus' master branch? There were a number of > > > > > > > new > > > > > > > asics added which copy pasted the ARM64 support. > > > > > > > > > > > > > > > > > > > Not sure what you are asking me here. Reverting commit > > > > > > c38d444e44badc5 > > > > > > on top of mainline is not going to fix the other code that was > > > > > > added. > > > > > > Or are you asking me to go and find the patches (how many?) that > > > > > > added > > > > > > new ASICs and fix them for arm64? > > > > > > > > > > > > Note that this code is critically broken, as it may corrupt user > > > > > > process state arbitrarily. So if new code was added that contains > > > > > > the > > > > > > same bug, it should be reverted so that the respective authors can > > > > > > fix > > > > > > it and resubmit. > > > > > > > > > > > > > > > > Is this simply about dropping the newly added references to > > > > > $(dml_rcflags) from the Makefile? Because that is quite trivial ... > > > > > > > > Yes, I was thinking something like the attached patch. > > > > > > > > Alex > > > > > > > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001 > > > > From: Alex Deucher > > > > Date: Mon, 4 Jan 2021 11:24:20 -0500 > > > > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64 > > > > > > > > From Ard: > > > > > > > > "Simply disabling -mgeneral-regs-only left and right is risky, given > > > > that > > > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, > > > > and GCC is known to use SIMD registers for spilling, and may invent > > > > other uses of the FP/SIMD register file that have nothing to do with the > > > > floating point code in question. Note that putting kernel_neon_begin() > > > > and kernel_neon_end() around the code that does use FP is not sufficient > > > > here, the problem is in all the other code that may be emitted with > > > > references to SIMD registers in it. > > > > > > > > So the only way to do this properly is to put all floating point code in > > > > a separate compilation unit, and only compile that unit with > > > > -mgeneral-regs-only." > > > > > > > > Disable support until the code can be properly refactored to support > > > > this > > > > properly on aarch64. > > > > > > > > Reported-by: Ard Biesheuvel > > > > Signed-off-by: Alex Deucher > > > > --- > > > > drivers/gpu/drm/amd/display/Kconfig | 2 +- > > > > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 4 > > > > .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 21 --- > > > > drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 --- > > > >
Re: [PATCH] drm/amdgpu: Assign boolean values to a bool variable
Applied. Thanks!
Alex
On Wed, Jan 20, 2021 at 10:05 AM Harry Wentland wrote:
>
> On 2021-01-20 2:16 a.m., Jiapeng Zhong wrote:
> > Fix the following coccicheck warnings:
> >
> > ./drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c:
> > 1009:6-16: WARNING: Assignment of 0/1 to bool variable.
> >
> > ./drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c:
> > 200:2-10: WARNING: Assignment of 0/1 to bool variable.
> >
> > Reported-by: Abaci Robot
> > Signed-off-by: Jiapeng Zhong
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > .../display/dc/dml/dcn30/display_rq_dlg_calc_30.c | 32
> > +++---
> > 1 file changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
> > b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
> > index 5b5916b..0f14f20 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
> > @@ -165,8 +165,8 @@ static void handle_det_buf_split(struct
> > display_mode_lib *mode_lib,
> > unsigned int swath_bytes_c = 0;
> > unsigned int full_swath_bytes_packed_l = 0;
> > unsigned int full_swath_bytes_packed_c = 0;
> > - bool req128_l = 0;
> > - bool req128_c = 0;
> > + bool req128_l = false;
> > + bool req128_c = false;
> > bool surf_linear = (pipe_src_param.sw_mode == dm_sw_linear);
> > bool surf_vert = (pipe_src_param.source_scan == dm_vert);
> > unsigned int log2_swath_height_l = 0;
> > @@ -191,37 +191,37 @@ static void handle_det_buf_split(struct
> > display_mode_lib *mode_lib,
> > total_swath_bytes = 2 * full_swath_bytes_packed_l;
> >
> > if (total_swath_bytes <= detile_buf_size_in_bytes) { //full 256b
> > request
> > - req128_l = 0;
> > - req128_c = 0;
> > + req128_l = false;
> > + req128_c = false;
> > swath_bytes_l = full_swath_bytes_packed_l;
> > swath_bytes_c = full_swath_bytes_packed_c;
> > } else if (!rq_param->yuv420) {
> > - req128_l = 1;
> > - req128_c = 0;
> > + req128_l = true;
> > + req128_c = false;
> > swath_bytes_c = full_swath_bytes_packed_c;
> > swath_bytes_l = full_swath_bytes_packed_l / 2;
> > } else if ((double)full_swath_bytes_packed_l /
> > (double)full_swath_bytes_packed_c < 1.5) {
> > - req128_l = 0;
> > - req128_c = 1;
> > + req128_l = false;
> > + req128_c = true;
> > swath_bytes_l = full_swath_bytes_packed_l;
> > swath_bytes_c = full_swath_bytes_packed_c / 2;
> >
> > total_swath_bytes = 2 * swath_bytes_l + 2 * swath_bytes_c;
> >
> > if (total_swath_bytes > detile_buf_size_in_bytes) {
> > - req128_l = 1;
> > + req128_l = true;
> > swath_bytes_l = full_swath_bytes_packed_l / 2;
> > }
> > } else {
> > - req128_l = 1;
> > - req128_c = 0;
> > + req128_l = true;
> > + req128_c = false;
> > swath_bytes_l = full_swath_bytes_packed_l/2;
> > swath_bytes_c = full_swath_bytes_packed_c;
> >
> > total_swath_bytes = 2 * swath_bytes_l + 2 * swath_bytes_c;
> >
> > if (total_swath_bytes > detile_buf_size_in_bytes) {
> > - req128_c = 1;
> > + req128_c = true;
> > swath_bytes_c = full_swath_bytes_packed_c/2;
> > }
> > }
> > @@ -1006,8 +1006,8 @@ static void dml_rq_dlg_get_dlg_params(struct
> > display_mode_lib *mode_lib,
> >
> > double min_dst_y_ttu_vblank = 0;
> > unsigned int dlg_vblank_start = 0;
> > - bool dual_plane = 0;
> > - bool mode_422 = 0;
> > + bool dual_plane = false;
> > + bool mode_422 = false;
> > unsigned int access_dir = 0;
> > unsigned int vp_height_l = 0;
> > unsigned int vp_width_l = 0;
> > @@ -1021,7 +1021,7 @@ static void dml_rq_dlg_get_dlg_params(struct
> > display_mode_lib *mode_lib,
> > double hratio_c = 0;
> > double vratio_l = 0;
> > double vratio_c = 0;
> > - bool scl_enable = 0;
> > + bool scl_enable = false;
> >
> > double line_time_in_us = 0;
> > // double vinit_l;
> > @@ -1156,7 +1156,7 @@ static void dml_rq_dlg_get_dlg_params(struct
> > display_mode_lib *mode_lib,
> > // Source
> > // dcc_en = src.dcc;
> > dual_plane = is_dual_plane((enum
> > source_format_class)(src->source_format));
> > - mode_422 = 0; // TODO
> > + mode_422 = false; // TODO
> > access_dir = (src->source_scan == dm_vert); // vp access direction:
> > horizontal or
Re: [PATCH][next] drm/amd/display: Fix spelling mistake of function name
Applied. Thanks!
Alex
On Wed, Jan 20, 2021 at 9:46 AM Harry Wentland wrote:
>
> On 2021-01-20 4:26 a.m., Colin King wrote:
> > From: Colin Ian King
> >
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > There are two spelling mistakes of the function name, fix this
> > by using __func__ instead of a hard coded name string.
> >
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index c16af3983fdb..91d4130cd2cb 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -1602,7 +1602,7 @@ static bool dc_link_construct(struct dc_link *link,
> >
> > link->psr_settings.psr_version = DC_PSR_VERSION_UNSUPPORTED;
> >
> > - DC_LOG_DC("BIOS object table - dc_link_contruct finished
> > successfully.\n");
> > + DC_LOG_DC("BIOS object table - %s finished successfully.\n",
> > __func__);
> > return true;
> > device_tag_fail:
> > link->link_enc->funcs->destroy(>link_enc);
> > @@ -1619,7 +1619,7 @@ static bool dc_link_construct(struct dc_link *link,
> > link->hpd_gpio = NULL;
> > }
> >
> > - DC_LOG_DC("BIOS object table - dc_link_contruct failed.\n");
> > + DC_LOG_DC("BIOS object table - %s failed.\n", __func__);
> > kfree(info);
> >
> > return false;
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Added orientation quirk for OneGX1 Pro
Hi,
On 1/20/21 10:18 PM, Hans de Goede wrote:
> Hi,
>
> On 1/20/21 9:56 PM, Jared Baldridge wrote:
>> The OneGX1 Pro has a fairly unique combination of generic strings,
>> but we additionally match on the BIOS date just to be safe.
>>
>> Signed-off-by: Jared Baldridge
>
> Thanks, patch looks good to me:
>
> Reviewed-by: Hans de Goede
>
> I will push this to drm-misc-next right away.
So it looks like your mail client ate all the tabs replacing them
with spaces (using tab stops every 8 chars).
I've manually fixed this up this time.
Next time please use git send-email and do NOT invoke an editor to
change e.g. the subject, instead use the command line options to set
a patch subject prefix.
Regards,
Hans
>> ---
>> drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> index 58f5dc2f6dd5..f6bdec7fa925 100644
>> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> @@ -84,6 +84,13 @@ static const struct drm_dmi_panel_orientation_data
>> itworks_tw891 = {
>> .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>> };
>>
>> +static const struct drm_dmi_panel_orientation_data onegx1_pro = {
>> + .width = 1200,
>> + .height = 1920,
>> + .bios_dates = (const char * const []){ "12/17/2020", NULL },
>> + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>> +};
>> +
>> static const struct drm_dmi_panel_orientation_data lcd720x1280_rightside_up
>> = {
>> .width = 720,
>> .height = 1280,
>> @@ -211,6 +218,13 @@ static const struct dmi_system_id orientation_data[] = {
>> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
>> D330-10IGM"),
>> },
>> .driver_data = (void *)_rightside_up,
>> + }, {/* OneGX1 Pro */
>> + .matches = {
>> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SYSTEM_MANUFACTURER"),
>> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "SYSTEM_PRODUCT_NAME"),
>> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
>> + },
>> + .driver_data = (void *)_pro,
>> }, {/* VIOS LTH17 */
>> .matches = {
>> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: dp-connector: Drop maxItems from -supply
On Wed, Jan 20, 2021 at 09:59:22AM -0800, Bjorn Andersson wrote:
> The meta-schema recently gained a definition for the common -supply$
> property, which denotes that maxItems is not a valid property. Drop this
> to clear up the binding validation error.
>
> Fixes: a46c112512de ("dt-bindings: dp-connector: add binding for DisplayPort
> connector")
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/display/connector/dp-connector.yaml | 1 -
> 1 file changed, 1 deletion(-)
Applied to drm-misc-next.
Thanks,
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] kbuild: use always-y instead of extra-y
On Wed, Jan 20, 2021 at 03:23:51PM +0900, Masahiro Yamada wrote:
> As commit d0e628cd817f ("kbuild: doc: clarify the difference between
> extra-y and always-y") explained, extra-y should be used for listing
> the prerequsites of vmlinux. always-y is a better fix here.
prerequisites
Glad to see this clarified. I think just tried both and picked one.
Reviewed-by: Rob Herring
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Documentation/devicetree/bindings/Makefile | 8
> drivers/gpu/drm/i915/Makefile | 2 +-
> scripts/Makefile.lib | 10 +-
> scripts/gdb/linux/Makefile | 2 +-
> 4 files changed, 11 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Added orientation quirk for OneGX1 Pro
Hi,
On 1/20/21 9:56 PM, Jared Baldridge wrote:
> The OneGX1 Pro has a fairly unique combination of generic strings,
> but we additionally match on the BIOS date just to be safe.
>
> Signed-off-by: Jared Baldridge
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
I will push this to drm-misc-next right away.
Regards,
Hans
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 58f5dc2f6dd5..f6bdec7fa925 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -84,6 +84,13 @@ static const struct drm_dmi_panel_orientation_data
> itworks_tw891 = {
> .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +static const struct drm_dmi_panel_orientation_data onegx1_pro = {
> + .width = 1200,
> + .height = 1920,
> + .bios_dates = (const char * const []){ "12/17/2020", NULL },
> + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> +};
> +
> static const struct drm_dmi_panel_orientation_data lcd720x1280_rightside_up
> = {
> .width = 720,
> .height = 1280,
> @@ -211,6 +218,13 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> D330-10IGM"),
> },
> .driver_data = (void *)_rightside_up,
> + }, {/* OneGX1 Pro */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SYSTEM_MANUFACTURER"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "SYSTEM_PRODUCT_NAME"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
> + },
> + .driver_data = (void *)_pro,
> }, {/* VIOS LTH17 */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dma-buf: dma-heap: Keep track of the heap device struct
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: Bing Song
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 33 +
include/linux/dma-heap.h | 9 +
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..72c746755d89 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -30,6 +30,7 @@
* @heap_devt heap device node
* @list list head connecting to list of heaps
* @heap_cdev heap char device
+ * @heap_dev heap device struct
*
* Represents a heap of memory from which buffers can be made.
*/
@@ -40,6 +41,7 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+ struct device *heap_dev;
};
static LIST_HEAD(heap_list);
@@ -190,10 +192,21 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap)
+{
+ return heap->heap_dev;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
- struct device *dev_ret;
unsigned int minor;
int ret;
@@ -247,16 +260,20 @@ struct dma_heap *dma_heap_add(const struct
dma_heap_export_info *exp_info)
goto err1;
}
- dev_ret = device_create(dma_heap_class,
- NULL,
- heap->heap_devt,
- NULL,
- heap->name);
- if (IS_ERR(dev_ret)) {
+ heap->heap_dev = device_create(dma_heap_class,
+ NULL,
+ heap->heap_devt,
+ NULL,
+ heap->name);
+ if (IS_ERR(heap->heap_dev)) {
pr_err("dma_heap: Unable to create device\n");
- err_ret = ERR_CAST(dev_ret);
+ err_ret = ERR_CAST(heap->heap_dev);
goto err2;
}
+
+ /* Make sure it doesn't disappear on us */
+ heap->heap_dev = get_device(heap->heap_dev);
+
/* Add heap to the list */
mutex_lock(_list_lock);
list_add(>list, _list);
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..82857e096910 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_dev() - get device struct for the heap
+ * @heap: DMA-Heap to retrieve device struct from
+ *
+ * Returns:
+ * The device struct for the heap.
+ */
+struct device *dma_heap_get_dev(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dma-buf: system_heap: Add a system-uncached heap re-using the system heap
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)
This is a rework of earlier efforts to add a uncached system heap,
done utilizing the exisitng system heap, adding just a bit of
logic to handle the uncached case.
Feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
- https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
- Visibly improves performance over the system heap
* AOSP Codec2:
- https://android-review.googlesource.com/c/platform/frameworks/av/+/1543685
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: Bing Song
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v4:
* Make sys_uncached_heap static, as
Reported-by: kernel test robot
* Fix wrong return value, caught by smatch
Reported-by: kernel test robot
Reported-by: Dan Carpenter
* Ensure we call flush/invalidate_kernel_vmap_range() in the
uncached cases to try to address feedback about VIVT caches
from Christoph
* Reorder a few lines as suggested by BrianS
* Avoid holding the initial mapping for the lifetime of the buffer
as suggested by BrianS
* Fix a unlikely race between allocate and updating the dma_mask
that BrianS noticed.
---
drivers/dma-buf/heaps/system_heap.c | 111
1 file changed, 95 insertions(+), 16 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..3548b20cb98c 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,7 @@
#include
static struct dma_heap *sys_heap;
+static struct dma_heap *sys_uncached_heap;
struct system_heap_buffer {
struct dma_heap *heap;
@@ -31,6 +32,8 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+
+ bool uncached;
};
struct dma_heap_attachment {
@@ -38,6 +41,8 @@ struct dma_heap_attachment {
struct sg_table *table;
struct list_head list;
bool mapped;
+
+ bool uncached;
};
#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
@@ -100,7 +105,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(>list);
a->mapped = false;
-
+ a->uncached = buffer->uncached;
attachment->priv = a;
mutex_lock(>lock);
@@ -130,9 +135,13 @@ static struct sg_table *system_heap_map_dma_buf(struct
dma_buf_attachment *attac
{
struct dma_heap_attachment *a = attachment->priv;
struct sg_table *table = a->table;
+ int attr = 0;
int ret;
- ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, attr);
if (ret)
return ERR_PTR(ret);
@@ -145,9 +154,12 @@ static void system_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_heap_attachment *a = attachment->priv;
+ int attr = 0;
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
a->mapped = false;
- dma_unmap_sgtable(attachment->dev, table, direction, 0);
+ dma_unmap_sgtable(attachment->dev, table, direction, attr);
}
static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
@@ -161,10 +173,12 @@ static int
[PATCH 3/3] dma-buf: cma_heap: Add a cma-uncached heap re-using the cma heap
From: Bing Song
This adds a heap that allocates CMA buffers that are
marked as writecombined, so they are not cached by the CPU.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Bing Song
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c | 119 +++
1 file changed, 107 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 364fc2f3e499..1b8c6eb0a8ea 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -38,6 +38,7 @@ struct cma_heap_buffer {
pgoff_t pagecount;
int vmap_cnt;
void *vaddr;
+ bool uncached;
};
struct dma_heap_attachment {
@@ -45,6 +46,7 @@ struct dma_heap_attachment {
struct sg_table table;
struct list_head list;
bool mapped;
+ bool uncached;
};
static int cma_heap_attach(struct dma_buf *dmabuf,
@@ -70,6 +72,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(>list);
a->mapped = false;
+ a->uncached = buffer->uncached;
attachment->priv = a;
@@ -99,8 +102,12 @@ static struct sg_table *cma_heap_map_dma_buf(struct
dma_buf_attachment *attachme
{
struct dma_heap_attachment *a = attachment->priv;
struct sg_table *table = >table;
+ int attr = 0;
int ret;
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
+
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
return ERR_PTR(-ENOMEM);
@@ -113,7 +120,10 @@ static void cma_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_heap_attachment *a = attachment->priv;
+ int attr = 0;
+ if (a->uncached)
+ attr = DMA_ATTR_SKIP_CPU_SYNC;
a->mapped = false;
dma_unmap_sgtable(attachment->dev, table, direction, 0);
}
@@ -128,10 +138,12 @@ static int cma_heap_dma_buf_begin_cpu_access(struct
dma_buf *dmabuf,
invalidate_kernel_vmap_range(buffer->vaddr, buffer->len);
mutex_lock(>lock);
- list_for_each_entry(a, >attachments, list) {
- if (!a->mapped)
- continue;
- dma_sync_sgtable_for_cpu(a->dev, >table, direction);
+ if (!buffer->uncached) {
+ list_for_each_entry(a, >attachments, list) {
+ if (!a->mapped)
+ continue;
+ dma_sync_sgtable_for_cpu(a->dev, >table, direction);
+ }
}
mutex_unlock(>lock);
@@ -148,10 +160,12 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
flush_kernel_vmap_range(buffer->vaddr, buffer->len);
mutex_lock(>lock);
- list_for_each_entry(a, >attachments, list) {
- if (!a->mapped)
- continue;
- dma_sync_sgtable_for_device(a->dev, >table, direction);
+ if (!buffer->uncached) {
+ list_for_each_entry(a, >attachments, list) {
+ if (!a->mapped)
+ continue;
+ dma_sync_sgtable_for_device(a->dev, >table,
direction);
+ }
}
mutex_unlock(>lock);
@@ -183,6 +197,9 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma)
if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
return -EINVAL;
+ if (buffer->uncached)
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+
vma->vm_ops = _heap_vm_ops;
vma->vm_private_data = buffer;
@@ -191,9 +208,13 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma)
static void *cma_heap_do_vmap(struct cma_heap_buffer *buffer)
{
+ pgprot_t pgprot = PAGE_KERNEL;
void *vaddr;
- vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
+ if (buffer->uncached)
+ pgprot = pgprot_writecombine(PAGE_KERNEL);
+
+ vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, pgprot);
if (!vaddr)
return ERR_PTR(-ENOMEM);
@@ -271,10 +292,11 @@ static const struct dma_buf_ops cma_heap_buf_ops = {
.release = cma_heap_dma_buf_release,
};
-static int cma_heap_allocate(struct dma_heap *heap,
+static int cma_heap_do_allocate(struct dma_heap *heap,
unsigned long len,
unsigned long fd_flags,
-
[RFC][PATCH 0/3] dmabuf heaps: system uncached and cma uncached heaps
After the last round submitting the system-uncached heap, I got some feedback that Daniel would like to see it demonstrated with a mesa based system. I'm still working on such a gralloc implementation (using the db845c), but along with other work, so I don't yet have something to share there. However, Bing Song reached out and was interested in having a uncached variant for the CMA heap as well, and he shared this patch providing an initial implementation. This gave me some hesitation with regards to the earlier discussion around what sort of attributes would be useful for the flags field of the allocation IOCTL. In earlier discussions, folks seemed happy to provide the uncached system heap functionality as its own heap chardev, as it seemed uncertain that the uncached attribute would truely be generic across all heaps. But with Bing's patch, it seems like it may be generically useful, and utilizing a flag might be a bit cleaner then adding lots of duplicative heap names postfixed with "-uncached". So I wanted to re-submit both of these together to reopen that discussion on the question of if a BUF_FLAG_UNCACHED flag would make sense, or if folks still think separate heap chardevs is the way to go. thanks -john Cc: Daniel Vetter Cc: Sumit Semwal Cc: Liam Mark Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: Chris Goldsworthy Cc: Ørjan Eide Cc: Robin Murphy Cc: Ezequiel Garcia Cc: Simon Ser Cc: James Jones Cc: Bing Song Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Bing Song (1): dma-buf: cma_heap: Add a cma-uncached heap re-using the cma heap John Stultz (2): dma-buf: dma-heap: Keep track of the heap device struct dma-buf: system_heap: Add a system-uncached heap re-using the system heap drivers/dma-buf/dma-heap.c | 33 ++-- drivers/dma-buf/heaps/cma_heap.c| 119 +--- drivers/dma-buf/heaps/system_heap.c | 111 ++ include/linux/dma-heap.h| 9 +++ 4 files changed, 236 insertions(+), 36 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm tree
Hi Daniel, On Wed, 20 Jan 2021 13:12:21 +0100 Daniel Vetter wrote: > > I've pulled drm-misc-next into drm-next now, so as long as all other > drm trees are merged after drm, this should be solved now. > drm-intel-next also has their msm build breakage fixed (I acked the > patch already), so hopefully we should be all clean again. Thanks. -- Cheers, Stephen Rothwell pgpjWtDWJVvwG.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209713] amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state
https://bugzilla.kernel.org/show_bug.cgi?id=209713 --- Comment #8 from Oliver Reeh (oli...@diereehs.de) --- It's fixed in kernel 5.10.9 with Mesa 20.3.3. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/scheduler: Job timeout handler returns status (v3)
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the device (GPU) is no longer available, such as
after it's been unplugged, or whether all is
normal, i.e. current behaviour.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_GPU_SCHED_STAT_NOMINAL to restart the task's
timeout timer--this is the old behaviour, and is
preserved by this patch.
v2: Use enum as the status of a driver's job
timeout callback method.
v3: Return scheduler/device information, rather
than task information.
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
Reported-by: kernel test robot
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 7 +-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32 +
include/drm/gpu_scheduler.h | 18 +++---
7 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..759b34799221 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_gpu_sched_stat amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, );
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
} else {
drm_sched_suspend_timeout(>sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..2a9439cbb0fb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct
drm_sched_job *sched_job)
return fence;
}
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_gpu_sched_stat etnaviv_sched_timedout_job(struct drm_sched_job
+ *sched_job)
{
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *gpu = submit->gpu;
@@ -120,9 +121,13 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
drm_sched_resubmit_jobs(>sched);
+ drm_sched_start(>sched, true);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
+
out_no_timeout:
/* restart scheduler after GPU is usable again */
drm_sched_start(>sched, true);
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 63b4c5643f9c..6e4273852712 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -415,7 +415,7 @@ static void lima_sched_build_error_task_list(struct
lima_sched_task *task)
mutex_unlock(>error_task_list_lock);
}
-static void lima_sched_timedout_job(struct drm_sched_job *job)
+static enum drm_gpu_sched_stat lima_sched_timedout_job(struct drm_sched_job
*job)
{
struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
struct lima_sched_task *task = to_lima_task(job);
@@ -449,6 +449,8 @@ static void lima_sched_timedout_job(struct drm_sched_job
*job)
drm_sched_resubmit_jobs(>base);
drm_sched_start(>base, true);
+
+ return DRM_GPU_SCHED_STAT_NOMINAL;
}
static void lima_sched_free_job(struct drm_sched_job *job)
diff --git
[PATCH 0/1] Timeout handler now returns a value
The driver's timeout handler now returns a value back up to DRM. This patch doesn't change current behaviour. I request it'd be applied so that Andrey G. can take advantage of the value sent back up to DRM from the GPU driver. This patch can be applied safely without changing the current DRM behaviour. Luben Tuikov (1): drm/scheduler: Job timeout handler returns status (v3) drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++-- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 7 +- drivers/gpu/drm/lima/lima_sched.c | 4 +++- drivers/gpu/drm/panfrost/panfrost_job.c | 9 --- drivers/gpu/drm/scheduler/sched_main.c | 4 +--- drivers/gpu/drm/v3d/v3d_sched.c | 32 + include/drm/gpu_scheduler.h | 18 +++--- 7 files changed, 52 insertions(+), 28 deletions(-) -- 2.30.0.81.g72c4083ddf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4, 03/10] soc: mediatek: mmsys: move register operation into mmsys path select function
On Tue, Jan 05, 2021 at 11:06:26AM +0800, Yongqiang Niu wrote:
> move register operation into mmsys path select function
Why do you want to do that. It seems the register access pattern is the
same for all SoCs so far supported, so I don't see the need to duplicate
the code in every SoC.
Regards,
Matthias
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/soc/mediatek/mmsys/mtk-mmsys.c | 140
> +
> 1 file changed, 71 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> index 6c03282..64c8030 100644
> --- a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> @@ -106,141 +106,161 @@ struct mtk_mmsys {
> .clk_driver = "clk-mt8183-mm",
> };
>
> -static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
> - enum mtk_ddp_comp_id next,
> - unsigned int *addr)
> +static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
> + enum mtk_ddp_comp_id cur,
> + enum mtk_ddp_comp_id next,
> + bool enable)
> {
> - unsigned int value;
> + unsigned int addr, value, reg;
>
> if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
> - *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
> value = OVL0_MOUT_EN_COLOR0;
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> - *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> value = OVL_MOUT_EN_RDMA;
> } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
> - *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
> - *addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
> value = UFOE_MOUT_EN_DSI0;
> } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> - *addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
> value = OVL1_MOUT_EN_COLOR1;
> } else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
> - *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
> value = GAMMA_MOUT_EN_RDMA1;
> } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> - *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD1_MOUT_EN_RDMA1;
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> value = RDMA0_SOUT_DPI0;
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> value = RDMA0_SOUT_DPI1;
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> value = RDMA0_SOUT_DSI1;
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> value = RDMA0_SOUT_DSI2;
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> value = RDMA0_SOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DSI1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DSI2;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> value = RDMA1_SOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> - *addr =
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
Ping
Andrey
On 1/20/21 12:01 AM, Andrey Grodzovsky wrote:
On 1/19/21 3:48 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
++
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
6 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 478a7d8..2953420 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1041,6 +1042,10 @@ struct amdgpu_device {
bool in_pci_err_recovery;
struct pci_saved_state *pci_state;
+
+ struct notifier_block nb;
+ struct blocking_notifier_head notifier;
+ struct list_head device_bo_list;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 45e23e3..e99f4f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -70,6 +70,8 @@
#include
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -3200,6 +3202,39 @@ static const struct attribute
*amdgpu_dev_attributes[] = {
};
+static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
+ struct amdgpu_bo *bo = NULL;
+
+ /*
+ * Following is a set of IOMMU group dependencies taken care of before
+ * device's IOMMU group is removed
+ */
+ if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
+
+ spin_lock(_bo_glob.lru_lock);
+ list_for_each_entry(bo, >device_bo_list, bo) {
+ if (bo->tbo.ttm)
+ ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
+ }
+ spin_unlock(_bo_glob.lru_lock);
That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
You need to use a mutex here or even better make sure you can access the
device_bo_list without a lock in this moment.
Christian.
I can think of switching to RCU list ? Otherwise, elements are added
on BO create and deleted on BO destroy, how can i prevent any of those from
happening while in this section besides mutex ? Make a copy list and run over
it instead ?
Andrey
+
+ if (adev->irq.ih.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, >irq.ih);
+ if (adev->irq.ih1.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, >irq.ih1);
+ if (adev->irq.ih2.use_bus_addr)
+ amdgpu_ih_ring_fini(adev, >irq.ih2);
+
+ amdgpu_gart_dummy_page_fini(adev);
+ }
+
+ return NOTIFY_OK;
+}
+
+
/**
* amdgpu_device_init - initialize the driver
*
@@ -3304,6 +3339,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
INIT_WORK(>xgmi_reset_work, amdgpu_device_xgmi_reset_func);
+ INIT_LIST_HEAD(>device_bo_list);
+
adev->gfx.gfx_off_req_count = 1;
adev->pm.ac_power = power_supply_is_system_supplied() > 0;
@@ -3575,6 +3612,15 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (amdgpu_device_cache_pci_state(adev->pdev))
pci_restore_state(pdev);
+ BLOCKING_INIT_NOTIFIER_HEAD(>notifier);
+ adev->nb.notifier_call = amdgpu_iommu_group_notifier;
+
+ if (adev->dev->iommu_group) {
+ r = iommu_group_register_notifier(adev->dev->iommu_group, >nb);
+ if (r)
+ goto failed;
+ }
+
return 0;
failed:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 0db9330..486ad6d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -92,7 +92,7 @@ static int amdgpu_gart_dummy_page_init(struct
amdgpu_device *adev)
*
* Frees the dummy page used by the driver (all asics).
*/
-static void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
+void amdgpu_gart_dummy_page_fini(struct amdgpu_device *adev)
{
if (!adev->dummy_page_addr)
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
index afa2e28..5678d9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h
@@ -61,6 +61,7 @@ int
Re: [PATCH v4 11/14] drm/amdgpu: Guard against write accesses after device removal
On 1/19/21 2:16 PM, Andrey Grodzovsky wrote:
On 1/19/21 1:59 PM, Christian König wrote:
Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky:
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F767885%2Fdata=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cee61fb937d2d4baedf6f08d8bcac5b02%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637466795752297305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a9Y4ZMEVYaMP7IeMVxQgXGpAkDXSkedMAiWkyqwzEe8%3Dreserved=0
"A perfect solution seems nearly impossible though; we cannot acquire a
mutex on
the user
to prevent them from yanking a device and we cannot check for a presence
change
after every
device access for performance reasons. "
But I assumed srcu_read_lock should be pretty seamless performance wise, no ?
The read side is supposed to be dirt cheap, the write side is were we
just stall for all readers to eventually complete on their own.
Definitely should be much cheaper than mmio read, on the mmio write
side it might actually hurt a bit. Otoh I think those don't stall the
cpu by default when they're timing out, so maybe if the overhead is
too much for those, we could omit them?
Maybe just do a small microbenchmark for these for testing, with a
register that doesn't change hw state. So with and without
drm_dev_enter/exit, and also one with the hw plugged out so that we
have actual timeouts in the transactions.
-Daniel
So say writing in a loop to some harmless scratch register for many times
both for plugged
and unplugged case and measure total time delta ?
I think we should at least measure the following:
1. Writing X times to a scratch reg without your patch.
2. Writing X times to a scratch reg with your patch.
3. Writing X times to a scratch reg with the hardware physically disconnected.
Just realized, I can't test this part since I don't have eGPU to yank out.
Andrey
I suggest to repeat that once for Polaris (or older) and once for Vega or Navi.
The SRBM on Polaris is meant to introduce some delay in each access, so it
might react differently then the newer hardware.
Christian.
Will do.
Andrey
Andrey
The other solution would be as I suggested to keep all the device IO ranges
reserved and system
memory pages unfreed until the device is finalized in the driver but
Daniel said
this would upset the PCI layer (the MMIO ranges reservation part).
Andrey
On 1/19/21 3:55 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
This should prevent writing to memory or IO ranges possibly
already allocated for other uses after our device is removed.
Wow, that adds quite some overhead to every register access. I'm not sure we
can do this.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 53 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 49 ++---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 ++-
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +---
9 files changed, 184 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e99f4f1..0a9d73c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -72,6 +72,8 @@
#include
+#include
+
MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
@@ -404,13 +406,21 @@ uint8_t amdgpu_mm_rreg8(struct amdgpu_device *adev,
uint32_t offset)
*/
void amdgpu_mm_wreg8(struct amdgpu_device *adev, uint32_t offset,
uint8_t
value)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+
+ if (!drm_dev_enter(>ddev, ))
+ return;
+
if (offset < adev->rmmio_size)
writeb(value, adev->rmmio + offset);
else
BUG();
+
+ drm_dev_exit(idx);
}
/**
@@ -427,9 +437,14 @@ void amdgpu_device_wreg(struct amdgpu_device *adev,
uint32_t reg, uint32_t v,
uint32_t acc_flags)
{
+ int idx;
+
if (adev->in_pci_err_recovery)
return;
+ if (!drm_dev_enter(>ddev, ))
+ return;
+
if ((reg * 4) < adev->rmmio_size) {
if (!(acc_flags & AMDGPU_REGS_NO_KIQ) &&
amdgpu_sriov_runtime(adev) &&
@@ -444,6 +459,8 @@ void
Re: [PATCH v4 1/3] drm/uapi: Add USB connector type
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes wrote:
>
> Add a connector type for USB connected display panels.
>
> Signed-off-by: Noralf Trønnes
> ---
> include/uapi/drm/drm_mode.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index fed66a03c7ae..33024cc5d26e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -367,6 +367,7 @@ enum drm_mode_subconnector {
> #define DRM_MODE_CONNECTOR_DPI 17
> #define DRM_MODE_CONNECTOR_WRITEBACK 18
> #define DRM_MODE_CONNECTOR_SPI 19
> +#define DRM_MODE_CONNECTOR_USB 20
Beware, new connector types have in the past resulted in userspace
burning Maybe it's become better ...
Acked-by: Daniel Vetter
>
> /**
> * struct drm_mode_get_connector - Get connector metadata.
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] drm/probe-helper: Check epoch counter in output_poll_execute()
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes wrote:
>
> drm_helper_hpd_irq_event() checks the epoch counter to determine
> connector status change. This was introduced in
> commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector").
> Do the same for output_poll_execute() so it can detect other changes
> beside connection status value changes.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_probe_helper.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index d6017726cc2a..e5432dcf6999 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -623,6 +623,7 @@ static void output_poll_execute(struct work_struct *work)
> struct drm_connector_list_iter conn_iter;
> enum drm_connector_status old_status;
> bool repoll = false, changed;
> + u64 old_epoch_counter;
>
> if (!dev->mode_config.poll_enabled)
> return;
> @@ -659,8 +660,9 @@ static void output_poll_execute(struct work_struct *work)
>
> repoll = true;
>
> + old_epoch_counter = connector->epoch_counter;
> connector->status = drm_helper_probe_detect(connector, NULL,
> false);
> - if (old_status != connector->status) {
Was about to ask whether we're not missing connector status changes
here, but that's already handled. Not sure why this wasn't done as
part of the original patch, I'd include a cc: stable here.
Reviewed-by: Daniel Vetter
> + if (old_epoch_counter != connector->epoch_counter) {
> const char *old, *new;
>
> /*
> @@ -689,6 +691,9 @@ static void output_poll_execute(struct work_struct *work)
> connector->base.id,
> connector->name,
> old, new);
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] epoch counter %llu
> -> %llu\n",
> + connector->base.id, connector->name,
> + old_epoch_counter,
> connector->epoch_counter);
>
> changed = true;
> }
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach
On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
>
>
>
> Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a
> écrit :
> > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil
> > wrote:
> >>
> >> If we don't call drm_connector_cleanup() manually in
> >> panel_bridge_detach(), the connector will be cleaned up with the
> >> other
> >> DRM objects in the call to drm_mode_config_cleanup(). However,
> >> since our
> >> drm_connector is devm-allocated, by the time
> >> drm_mode_config_cleanup()
> >> will be called, our connector will be long gone. Therefore, the
> >> connector must be cleaned up when the bridge is detached to avoid
> >> use-after-free conditions.
> >
> > For -fixes this sounds ok, but for -next I think switching to drmm_
> > would be much better.
>
> The API would need to change to have access to the drm_device struct,
> though. That would be quite a big patch, there are a few dozens source
> files that use this API already.
Hm right pure drmm_ doesn't work for panel or bridge since it's
usually a separate driver. But devm_ also doesn't work. I think what
we need here is two-stage: first kmalloc the panel (or bridge, it's
really the same) in the panel/bridge driver load. Then when we bind it
to the drm_device we can tie it into the managed resources with
drmm_add_action_or_reset. Passing the drm_device to the point where we
allocate the panel/bridge doesn't work for these.
I think minimally we need a FIXME here and ack from Laurent on how
this should be solved at least, since panel bridge is used rather
widely.
-Daniel
>
> Cheers,
> -Paul
>
> >
> >> v2: Cleanup connector only if it was created
> >>
> >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper
> >> from the lvds-encoder bridge.")
> >> Cc: # 4.12+
> >> Cc: Andrzej Hajda
> >> Cc: Neil Armstrong
> >> Cc: Laurent Pinchart
> >> Cc: Jonas Karlman
> >> Cc: Jernej Skrabec
> >> Signed-off-by: Paul Cercueil
> >> ---
> >> drivers/gpu/drm/bridge/panel.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/panel.c
> >> b/drivers/gpu/drm/bridge/panel.c
> >> index 0ddc37551194..df86b0ee0549 100644
> >> --- a/drivers/gpu/drm/bridge/panel.c
> >> +++ b/drivers/gpu/drm/bridge/panel.c
> >> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge
> >> *bridge,
> >>
> >> static void panel_bridge_detach(struct drm_bridge *bridge)
> >> {
> >> + struct panel_bridge *panel_bridge =
> >> drm_bridge_to_panel_bridge(bridge);
> >> + struct drm_connector *connector = _bridge->connector;
> >> +
> >> + /* Cleanup the connector if we know it was initialized */
> >> + if (!!panel_bridge->connector.dev)
> >> + drm_connector_cleanup(connector);
> >> }
> >>
> >> static void panel_bridge_pre_enable(struct drm_bridge *bridge)
> >> --
> >> 2.29.2
> >>
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: fix build after dp quirk helper change
Reviewed-by: Lyude Paul
On Wed, 2021-01-20 at 13:07 +0200, Jani Nikula wrote:
> Commit 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based
> quirks"") removed drm_dp_get_edid_quirks() and changed the signature of
> drm_dp_has_quirk() while they were still being used in msm. Fix the
> breakage. Functionally, removing the EDID-based quirks has no impact on
> msm.
>
> [The above commit was merged to drm-intel-next; make two wrongs a right
> by merging this fix through drm-intel-next as well.]
>
> Reported-by: Stephen Rothwell
> References:
> http://lore.kernel.org/r/20210120105715.4391d...@canb.auug.org.au
> Fixes: 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based quirks"")
> Cc: Lyude Paul
> Acked-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula
>
> ---
>
> Note: I admit to not even build testing this one. I'd need a config,
> possibly also a toolchain setup for that.
> ---
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index e3462f5d96d7..36b39c381b3f 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1420,16 +1420,14 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
> static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
> {
> u8 *dpcd = ctrl->panel->dpcd;
> - u32 edid_quirks = 0;
>
> - edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
> /*
> * For better interop experience, used a fixed NVID=0x8000
> * whenever connected to a VGA dongle downstream.
> */
> if (drm_dp_is_branch(dpcd))
> - return (drm_dp_has_quirk(>panel->desc, edid_quirks,
> - DP_DPCD_QUIRK_CONSTANT_N));
> + return (drm_dp_has_quirk(>panel->desc,
> + DP_DPCD_QUIRK_CONSTANT_N));
>
> return false;
> }
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] Generic USB Display driver
Hi, A while back I had the idea to turn a Raspberry Pi Zero into a $5 USB to HDMI/SDTV/DSI/DPI display adapter. The reason for calling it 'Generic' is so anyone can make a USB display/adapter against this driver, all that's needed is to add a USB vid:pid. Unfortunately I've had some compounding health problems that have severally limited the time I can spend in front of a computer. For this reason I've decided to keep the gadget driver out-of-tree and focus on getting the host driver merged first. See the wiki[1] for more information and images for the Raspberry Pi Zero/4. One big change this time is that I've followed Peter Stuge's advice to not let DRM stuff leak into the USB protocol. This has made the protocol easier to understand just from reading the header file. Noralf. [1] https://github.com/notro/gud/wiki Noralf Trønnes (3): drm/uapi: Add USB connector type drm/probe-helper: Check epoch counter in output_poll_execute() drm: Add Generic USB Display driver MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_probe_helper.c | 7 +- drivers/gpu/drm/gud/Kconfig | 14 + drivers/gpu/drm/gud/Makefile| 4 + drivers/gpu/drm/gud/gud_connector.c | 722 drivers/gpu/drm/gud/gud_drv.c | 620 drivers/gpu/drm/gud/gud_internal.h | 148 ++ drivers/gpu/drm/gud/gud_pipe.c | 472 ++ include/drm/gud.h | 356 ++ include/uapi/drm/drm_mode.h | 1 + 12 files changed, 2354 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/gud/Kconfig create mode 100644 drivers/gpu/drm/gud/Makefile create mode 100644 drivers/gpu/drm/gud/gud_connector.c create mode 100644 drivers/gpu/drm/gud/gud_drv.c create mode 100644 drivers/gpu/drm/gud/gud_internal.h create mode 100644 drivers/gpu/drm/gud/gud_pipe.c create mode 100644 include/drm/gud.h -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm: Add Generic USB Display driver
This adds a generic USB display driver with the intention that it can be used with future USB interfaced low end displays/adapters. The Linux gadget device driver will serve as the canonical device implementation. The following DRM properties are supported: - Plane rotation - Connector TV properties There is also support for backlight brightness exposed as a backlight device. Display modes can be made available to the host driver either as DRM display modes or through EDID. If both are present, EDID is just passed on to userspace. Performance is preferred over color depth, so if the device supports RGB565, DRM_CAP_DUMB_PREFERRED_DEPTH will return 16. If the device transfer buffer can't fit an uncompressed framebuffer update, the update is split up into parts that do fit. Optimal user experience is achieved by providing damage reports either by setting FB_DAMAGE_CLIPS on pageflips or calling DRM_IOCTL_MODE_DIRTYFB. LZ4 compression is used if the device supports it. The driver supports a one bit monochrome transfer format: R1. This is not implemented in the gadget driver. It is added in preparation for future monochrome e-ink displays. The driver is MIT licensed to smooth the path for any BSD port of the driver. v2: - Use devm_drm_dev_alloc() and drmm_mode_config_init() - drm_fbdev_generic_setup: Use preferred_bpp=0, 16 was a copy paste error - The drm_backlight_helper is dropped, copy in the code - Support protocol version backwards compatibility for device v3: - Use donated Openmoko USB pid - Use direct compression from framebuffer when pitch matches, not only on full frames, so split updates can benefit - Use __le16 in struct gud_drm_req_get_connector_status - Set edid property when the device only provides edid - Clear compression fields in struct gud_drm_req_set_buffer - Fix protocol version negotiation - Remove mode->vrefresh, it's calculated v4: - Drop the status req polling which was a workaround for something that turned out to be a dwc2 udc driver problem - Add a flag for the Linux gadget to require a status request on SET operations. Other devices will only get status req on STALL errors - Use protocol specific error codes (Peter) - Add a flag for devices that want to receive the entire framebuffer on each flush (Lubomir) - Retry a failed framebuffer flush - If mode has changed wait for worker and clear pending damage before queuing up new damage, fb width/height might have changed - Increase error counter on bulk transfer failures - Use DRM_MODE_CONNECTOR_USB - Handle R1 kmalloc error (Peter) - Don't try and replicate the USB get descriptor request standard for the display descriptor (Peter) - Make max_buffer_size optional (Peter), drop the pow2 requirement since it's not necessary anymore. - Don't pre-alloc a control request buffer, it was only 4k - Let gud.h describe the whole protocol explicitly and don't let DRM leak into it (Peter) - Drop display mode .hskew and .vscan from the protocol - Shorten names: s/GUD_DRM_/GUD_/ s/gud_drm_/gud_/ (Peter) - Fix gud_pipe_check() connector picking when switching connector - Drop gud_drm_driver_gem_create_object() cached is default now - Retrieve USB device from struct drm_device.dev instead of keeping a pointer - Honour fb->offsets[0] - Fix mode fetching when connector status is forced - Check EDID length reported by the device - Use drm_do_get_edid() so userspace can overrride EDID - Set epoch counter to signal connector status change - gud_drm_driver can be const now Cc: Peter Stuge Cc: Lubomir Rintel Signed-off-by: Noralf Trønnes --- MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/gud/Kconfig | 14 + drivers/gpu/drm/gud/Makefile| 4 + drivers/gpu/drm/gud/gud_connector.c | 722 drivers/gpu/drm/gud/gud_drv.c | 620 drivers/gpu/drm/gud/gud_internal.h | 148 ++ drivers/gpu/drm/gud/gud_pipe.c | 472 ++ include/drm/gud.h | 356 ++ 10 files changed, 2347 insertions(+) create mode 100644 drivers/gpu/drm/gud/Kconfig create mode 100644 drivers/gpu/drm/gud/Makefile create mode 100644 drivers/gpu/drm/gud/gud_connector.c create mode 100644 drivers/gpu/drm/gud/gud_drv.c create mode 100644 drivers/gpu/drm/gud/gud_internal.h create mode 100644 drivers/gpu/drm/gud/gud_pipe.c create mode 100644 include/drm/gud.h diff --git a/MAINTAINERS b/MAINTAINERS index 00112c044608..e7f71ac55f08 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5525,6 +5525,14 @@ S: Maintained F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c +DRM DRIVER FOR GENERIC USB DISPLAY +M: Noralf Trønnes +S: Maintained +W: https://github.com/notro/gud/wiki +T: git git://anongit.freedesktop.org/drm/drm-misc +F:
[PATCH v4 1/3] drm/uapi: Add USB connector type
Add a connector type for USB connected display panels.
Signed-off-by: Noralf Trønnes
---
include/uapi/drm/drm_mode.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fed66a03c7ae..33024cc5d26e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -367,6 +367,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_USB 20
/**
* struct drm_mode_get_connector - Get connector metadata.
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] drm/probe-helper: Check epoch counter in output_poll_execute()
drm_helper_hpd_irq_event() checks the epoch counter to determine
connector status change. This was introduced in
commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector").
Do the same for output_poll_execute() so it can detect other changes
beside connection status value changes.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_probe_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index d6017726cc2a..e5432dcf6999 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -623,6 +623,7 @@ static void output_poll_execute(struct work_struct *work)
struct drm_connector_list_iter conn_iter;
enum drm_connector_status old_status;
bool repoll = false, changed;
+ u64 old_epoch_counter;
if (!dev->mode_config.poll_enabled)
return;
@@ -659,8 +660,9 @@ static void output_poll_execute(struct work_struct *work)
repoll = true;
+ old_epoch_counter = connector->epoch_counter;
connector->status = drm_helper_probe_detect(connector, NULL,
false);
- if (old_status != connector->status) {
+ if (old_epoch_counter != connector->epoch_counter) {
const char *old, *new;
/*
@@ -689,6 +691,9 @@ static void output_poll_execute(struct work_struct *work)
connector->base.id,
connector->name,
old, new);
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] epoch counter %llu ->
%llu\n",
+ connector->base.id, connector->name,
+ old_epoch_counter,
connector->epoch_counter);
changed = true;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu drm-next-5.12
On Wed, Jan 20, 2021 at 7:10 AM Daniel Vetter wrote: > > On Wed, Jan 20, 2021 at 01:09:51AM -0500, Alex Deucher wrote: > > Hi Dave, Daniel, > > > > More new stuff for 5.12. Now with non-x86 fixed. > > > > The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075: > > > > drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug > > 210921) (2021-01-08 15:18:57 -0500) > > > > are available in the Git repository at: > > > > https://gitlab.freedesktop.org/agd5f/linux.git > > tags/amd-drm-next-5.12-2021-01-20 > > There was a silly conflict, I picked yours, but maybe double check. > Details in the merge commit. Also maybe we want to fast-forward. You picked correctly. Thanks! Alex > -Daniel > > > > > for you to fetch changes up to 4aef0ebc6b65e8583bc3d96e05c7a039912b3ee6: > > > > drm/amdgpu: fix build error without x86 kconfig (v2) (2021-01-19 15:16:10 > > -0500) > > > > > > amd-drm-next-5.12-2021-01-20: > > > > amdgpu: > > - Fix non-x86 build > > - W=1 fixes from Lee Jones > > - Enable GPU reset on Navy Flounder > > - Kernel doc fixes > > - SMU workload profile fixes for APUs > > - Display updates > > - SR-IOV fixes > > - Vangogh SMU feature enablment and bug fixes > > - GPU reset support for Vangogh > > - Misc cleanups > > > > > > Alex Deucher (5): > > MAINTAINERS: update radeon/amdgpu/amdkfd git trees > > drm/amdgpu: add mode2 reset support for vangogh > > drm/amdgpu/nv: add mode2 reset handling > > drm/amdgpu: fix mode2 reset sequence for vangogh > > drm/amdgpu: Enable GPU reset for vangogh > > > > Aric Cyr (2): > > drm/amd/display: 3.2.117 > > drm/amd/display: 3.2.118 > > > > Bhawanpreet Lakha (2): > > drm/amd/display: enable HUBP blank behaviour > > drm/amd/display: Fix deadlock during gpu reset v3 > > > > Charlene Liu (1): > > drm/amd/display: change SMU repsonse timeout to 2s > > > > Chiawen Huang (1): > > drm/amd/display: removed unnecessary check when dpp clock increasing > > > > Colin Ian King (1): > > drm/amdgpu: Add missing BOOTUP_DEFAULT to profile_name[] > > > > Emily.Deng (1): > > drm/amdgpu: Decrease compute timeout to 10 s for sriov multiple VF > > > > Guchun Chen (1): > > drm/amdgpu: toggle on DF Cstate after finishing xgmi injection > > > > Huang Rui (13): > > drm/amd/pm: remove vcn/jpeg powergating feature checking for vangogh > > drm/amd/pm: enhance the real response for smu message (v2) > > drm/amd/pm: clean up get_allowed_feature_mask function > > drm/amd/pm: initial feature_enabled/feature_support bitmap for vangogh > > drm/amd/pm: don't mark all apu as true on feature mask > > drm/amdgpu: revise the mode2 reset for vangogh > > drm/amd/pm: fix the return value of pm message > > drm/amd/pm: implement the processor clocks which read by metric > > drm/amd/pm: implement processor fine grain feature for vangogh (v3) > > drm/amdgpu: fix vram type and bandwidth error for DDR5 and DDR4 > > drm/amd/display: fix the system memory page fault because of copy > > overflow > > drm/amd/display: fix the coding style issue of integrated_info > > drm/amdgpu: fix build error without x86 kconfig (v2) > > > > Jack Zhang (1): > > drm/amdgpu/sriov Stop data exchange for wholegpu reset > > > > Jacky Liao (1): > > drm/amd/display: Fix assert being hit with GAMCOR memory shut down > > > > Jeremy Cline (1): > > drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu() > > > > Jiansong Chen (2): > > drm/amdgpu: enable gpu recovery for navy_flounder > > drm/amd/pm: update driver if version for navy_flounder > > > > Jinzhou Su (4): > > drm/amd/pm: Add GFXOFF interface for Vangogh > > drm/amd/pm: Enable GfxOff for Vangogh > > drm/amdgpu: Add Secure Display TA header file > > drm/amdgpu: Add secure display TA interface > > > > John Clements (1): > > drm/amdgpu: updated fw attestation interface > > > > Jun Lei (1): > > drm/amd/display: implement T12 compliance > > > > Lee Jones (90): > > drm/amd/amdgpu/amdgpu_ih: Update 'amdgpu_ih_decode_iv_helper()'s > > function header > > drm/amd/amdgpu/vega20_ih: Add missing descriptions for 'ih' and fix > > spelling error > > drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Provide description > > of 'call_back_func' > > drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix documentation for > > 'mpll_param' > > drm/amd/pm/powerplay/hwmgr/vega12_hwmgr: Fix legacy function header > > formatting > > drm/amd/pm/powerplay/hwmgr/vega20_hwmgr: Fix legacy function header > > formatting > > drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix formatting and spelling > > issues > > drm/amd/pm/powerplay/hwmgr/hwmgr: Move prototype into shared header >
Re: [PATCH v2 3/3] drm/ingenic: Fix non-OSD mode
On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil wrote:
>
> Even though the JZ4740 did not have the OSD mode, it had (according to
> the documentation) two DMA channels, but there is absolutely no
> information about how to select the second DMA channel.
>
> Make the ingenic-drm driver work in non-OSD mode by using the
> foreground0 plane (which is bound to the DMA0 channel) as the primary
> plane, instead of the foreground1 plane, which is the primary plane
> when in OSD mode.
>
> Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode")
> Cc: # v5.8+
> Signed-off-by: Paul Cercueil
Does what it says on the tin^Wcommit message.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 158433b4c084..963dcbfeaba2 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -554,7 +554,7 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> height = state->src_h >> 16;
> cpp = state->fb->format->cpp[0];
>
> - if (priv->soc_info->has_osd && plane->type ==
> DRM_PLANE_TYPE_OVERLAY)
> + if (!priv->soc_info->has_osd || plane->type ==
> DRM_PLANE_TYPE_OVERLAY)
> hwdesc = >dma_hwdescs->hwdesc_f0;
> else
> hwdesc = >dma_hwdescs->hwdesc_f1;
> @@ -826,6 +826,7 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> const struct jz_soc_info *soc_info;
> struct ingenic_drm *priv;
> struct clk *parent_clk;
> + struct drm_plane *primary;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> struct drm_encoder *encoder;
> @@ -940,9 +941,11 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> if (soc_info->has_osd)
> priv->ipu_plane = drm_plane_from_index(drm, 0);
>
> - drm_plane_helper_add(>f1, _drm_plane_helper_funcs);
> + primary = priv->soc_info->has_osd ? >f1 : >f0;
>
> - ret = drm_universal_plane_init(drm, >f1, 1,
> + drm_plane_helper_add(primary, _drm_plane_helper_funcs);
> +
> + ret = drm_universal_plane_init(drm, primary, 1,
>_drm_primary_plane_funcs,
>priv->soc_info->formats_f1,
>priv->soc_info->num_formats_f1,
> @@ -954,7 +957,7 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
>
> drm_crtc_helper_add(>crtc, _drm_crtc_helper_funcs);
>
> - ret = drm_crtc_init_with_planes(drm, >crtc, >f1,
> + ret = drm_crtc_init_with_planes(drm, >crtc, primary,
> NULL, _drm_crtc_funcs, NULL);
> if (ret) {
> dev_err(dev, "Failed to init CRTC: %i\n", ret);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach
On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil wrote:
>
> If we don't call drm_connector_cleanup() manually in
> panel_bridge_detach(), the connector will be cleaned up with the other
> DRM objects in the call to drm_mode_config_cleanup(). However, since our
> drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
> will be called, our connector will be long gone. Therefore, the
> connector must be cleaned up when the bridge is detached to avoid
> use-after-free conditions.
For -fixes this sounds ok, but for -next I think switching to drmm_
would be much better.
-Daniel
> v2: Cleanup connector only if it was created
>
> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
> lvds-encoder bridge.")
> Cc: # 4.12+
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/bridge/panel.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 0ddc37551194..df86b0ee0549 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>
> static void panel_bridge_detach(struct drm_bridge *bridge)
> {
> + struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_connector *connector = _bridge->connector;
> +
> + /* Cleanup the connector if we know it was initialized */
> + if (!!panel_bridge->connector.dev)
> + drm_connector_cleanup(connector);
> }
>
> static void panel_bridge_pre_enable(struct drm_bridge *bridge)
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On Wed, Jan 20, 2021 at 3:20 PM Andrey Grodzovsky wrote: > > > On 1/20/21 4:05 AM, Daniel Vetter wrote: > > On Tue, Jan 19, 2021 at 01:18:15PM -0500, Andrey Grodzovsky wrote: > >> On 1/19/21 1:08 PM, Daniel Vetter wrote: > >>> On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky > >>> wrote: > On 1/19/21 9:16 AM, Daniel Vetter wrote: > > On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: > >> Until now extracting a card either by physical extraction (e.g. eGPU > >> with > >> thunderbolt connection or by emulation through syfs -> > >> /sys/bus/pci/devices/device_id/remove) > >> would cause random crashes in user apps. The random crashes in apps > >> were > >> mostly due to the app having mapped a device backed BO into its address > >> space was still trying to access the BO while the backing device was > >> gone. > >> To answer this first problem Christian suggested to fix the handling > >> of mapped > >> memory in the clients when the device goes away by forcibly unmap all > >> buffers the > >> user processes has by clearing their respective VMAs mapping the > >> device BOs. > >> Then when the VMAs try to fill in the page tables again we check in > >> the fault > >> handlerif the device is removed and if so, return an error. This will > >> generate a > >> SIGBUS to the application which can then cleanly terminate.This indeed > >> was done > >> but this in turn created a problem of kernel OOPs were the OOPSes were > >> due to the > >> fact that while the app was terminating because of the SIGBUSit would > >> trigger use > >> after free in the driver by calling to accesses device structures that > >> were already > >> released from the pci remove sequence.This was handled by introducing > >> a 'flush' > >> sequence during device removal were we wait for drm file reference to > >> drop to 0 > >> meaning all user clients directly using this device terminated. > >> > >> v2: > >> Based on discussions in the mailing list with Daniel and Pekka [1] and > >> based on the document > >> produced by Pekka from those discussions [2] the whole approach with > >> returning SIGBUS and > >> waiting for all user clients having CPU mapping of device BOs to die > >> was dropped. > >> Instead as per the document suggestion the device structures are kept > >> alive until > >> the last reference to the device is dropped by user client and in the > >> meanwhile all existing and new CPU mappings of the BOs > >> belonging to the device directly or by dma-buf import are rerouted to > >> per user > >> process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' > >> section of [2] > >> since i am trying to get the minimal set of requirements that still > >> give useful solution > >> to work and this is the'Requirements for Render and Cross-Device UAPI' > >> section and so my > >> test case is removing a secondary device, which is render only and is > >> not involved > >> in KMS. > >> > >> v3: > >> More updates following comments from v2 such as removing loop to find > >> DRM file when rerouting > >> page faults to dummy page,getting rid of unnecessary sysfs handling > >> refactoring and moving > >> prevention of GPU recovery post device unplug from amdgpu to scheduler > >> layer. > >> On top of that added unplug support for the IOMMU enabled system. > >> > >> v4: > >> Drop last sysfs hack and use sysfs default attribute. > >> Guard against write accesses after device removal to avoid modifying > >> released memory. > >> Update dummy pages handling to on demand allocation and release > >> through drm managed framework. > >> Add return value to scheduler job TO handler (by Luben Tuikov) and use > >> this in amdgpu for prevention > >> of GPU recovery post device unplug > >> Also rebase on top of drm-misc-mext instead of amd-staging-drm-next > >> > >> With these patches I am able to gracefully remove the secondary card > >> using sysfs remove hook while glxgears > >> is running off of secondary card (DRI_PRIME=1) without kernel oopses > >> or hangs and keep working > >> with the primary card or soft reset the device without hangs or oopses > >> > >> TODOs for followup work: > >> Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff > >> and allocations) (Daniel) > >> Support plugging the secondary device back after unplug - currently > >> still experiencing HW error on plugging back. > >> Add support for 'Requirements for KMS UAPI' section of [2] - > >> unplugging primary, display connected card. > >> > >> [1] - Discussions during v3 of the patchset > >>
Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
This seems like an underlying bug/lack of clear documentation for the
underlying find_*_bit() functions. dp_for_each_set_bit() tries to do the
right thing:
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
i.e. passing the actual size of type. However because of the case to
unsigned long (and subsequent accesses using that type) the compiler is
free to make accesses beyond the size of the variable (and indeed this
is completely broken on big-endian). The implementation actually
requires that the bitmap is really an array of unsigned long - no other
type will work.
So I think the fix should also include fixing the dp_for_each_set_bit()
macro - the cast is bogus as it stands.
Doing that I also get warnings on komeda_pipeline::avail_comps and
komeda_pipeline::supported_inputs - although I note there are other
bitmasks mentioned.
The other option is to fix dp_for_each_set_bit() itself using a little hack:
- for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
+ for_each_set_bit((bit), (&((unsigned long){mask})), sizeof(mask) * 8)
With that I don't think you need any other change as the mask is actually
in a new unsigned long on the stack.
Steve
Signed-off-by: Carsten Haitzler
---
.../drm/arm/display/komeda/komeda_pipeline_state.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index e8b1e15312d8..f7dddb9f015d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -1232,7 +1232,8 @@ komeda_pipeline_unbound_components(struct komeda_pipeline
*pipe,
struct komeda_pipeline_state *old = priv_to_pipe_st(pipe->obj.state);
struct komeda_component_state *c_st;
struct komeda_component *c;
- u32 disabling_comps, id;
+ u32 id;
+ unsigned long disabling_comps;
WARN_ON(!old);
@@ -1262,7 +1263,6 @@ int komeda_release_unclaimed_resources(struct komeda_pipeline *pipe,
st = komeda_pipeline_get_new_state(pipe, drm_st);
else
st = komeda_pipeline_get_state_and_set_crtc(pipe, drm_st, NULL);
-
NIT: Random white space change
if (WARN_ON(IS_ERR_OR_NULL(st)))
return -EINVAL;
@@ -1287,7 +1287,8 @@ bool komeda_pipeline_disable(struct komeda_pipeline *pipe,
struct komeda_pipeline_state *old;
struct komeda_component *c;
struct komeda_component_state *c_st;
- u32 id, disabling_comps = 0;
+ u32 id;
+ unsigned long disabling_comps;
old = komeda_pipeline_get_old_state(pipe, old_state);
@@ -1297,7 +1298,7 @@ bool komeda_pipeline_disable(struct komeda_pipeline *pipe,
disabling_comps = old->active_comps &
pipe->standalone_disabled_comps;
- DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, disabling_comps: 0x%x.\n",
+ DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, disabling_comps:
0x%lx.\n",
pipe->id, old->active_comps, disabling_comps);
dp_for_each_set_bit(id, disabling_comps) {
@@ -1331,13 +1332,14 @@ void komeda_pipeline_update(struct komeda_pipeline
*pipe,
struct komeda_pipeline_state *new = priv_to_pipe_st(pipe->obj.state);
struct komeda_pipeline_state *old;
struct komeda_component *c;
- u32 id, changed_comps = 0;
+ u32 id;
+ unsigned long changed_comps;
old = komeda_pipeline_get_old_state(pipe, old_state);
changed_comps = new->active_comps | old->active_comps;
- DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, changed: 0x%x.\n",
+ DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, changed: 0x%lx.\n",
pipe->id, new->active_comps, changed_comps);
dp_for_each_set_bit(id, changed_comps) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Assign boolean values to a bool variable
On 2021-01-20 2:16 a.m., Jiapeng Zhong wrote:
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c:
1009:6-16: WARNING: Assignment of 0/1 to bool variable.
./drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c:
200:2-10: WARNING: Assignment of 0/1 to bool variable.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Zhong
Reviewed-by: Harry Wentland
Harry
---
.../display/dc/dml/dcn30/display_rq_dlg_calc_30.c | 32 +++---
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
index 5b5916b..0f14f20 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_rq_dlg_calc_30.c
@@ -165,8 +165,8 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
unsigned int swath_bytes_c = 0;
unsigned int full_swath_bytes_packed_l = 0;
unsigned int full_swath_bytes_packed_c = 0;
- bool req128_l = 0;
- bool req128_c = 0;
+ bool req128_l = false;
+ bool req128_c = false;
bool surf_linear = (pipe_src_param.sw_mode == dm_sw_linear);
bool surf_vert = (pipe_src_param.source_scan == dm_vert);
unsigned int log2_swath_height_l = 0;
@@ -191,37 +191,37 @@ static void handle_det_buf_split(struct display_mode_lib
*mode_lib,
total_swath_bytes = 2 * full_swath_bytes_packed_l;
if (total_swath_bytes <= detile_buf_size_in_bytes) { //full 256b request
- req128_l = 0;
- req128_c = 0;
+ req128_l = false;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l;
swath_bytes_c = full_swath_bytes_packed_c;
} else if (!rq_param->yuv420) {
- req128_l = 1;
- req128_c = 0;
+ req128_l = true;
+ req128_c = false;
swath_bytes_c = full_swath_bytes_packed_c;
swath_bytes_l = full_swath_bytes_packed_l / 2;
} else if ((double)full_swath_bytes_packed_l /
(double)full_swath_bytes_packed_c < 1.5) {
- req128_l = 0;
- req128_c = 1;
+ req128_l = false;
+ req128_c = true;
swath_bytes_l = full_swath_bytes_packed_l;
swath_bytes_c = full_swath_bytes_packed_c / 2;
total_swath_bytes = 2 * swath_bytes_l + 2 * swath_bytes_c;
if (total_swath_bytes > detile_buf_size_in_bytes) {
- req128_l = 1;
+ req128_l = true;
swath_bytes_l = full_swath_bytes_packed_l / 2;
}
} else {
- req128_l = 1;
- req128_c = 0;
+ req128_l = true;
+ req128_c = false;
swath_bytes_l = full_swath_bytes_packed_l/2;
swath_bytes_c = full_swath_bytes_packed_c;
total_swath_bytes = 2 * swath_bytes_l + 2 * swath_bytes_c;
if (total_swath_bytes > detile_buf_size_in_bytes) {
- req128_c = 1;
+ req128_c = true;
swath_bytes_c = full_swath_bytes_packed_c/2;
}
}
@@ -1006,8 +1006,8 @@ static void dml_rq_dlg_get_dlg_params(struct
display_mode_lib *mode_lib,
double min_dst_y_ttu_vblank = 0;
unsigned int dlg_vblank_start = 0;
- bool dual_plane = 0;
- bool mode_422 = 0;
+ bool dual_plane = false;
+ bool mode_422 = false;
unsigned int access_dir = 0;
unsigned int vp_height_l = 0;
unsigned int vp_width_l = 0;
@@ -1021,7 +1021,7 @@ static void dml_rq_dlg_get_dlg_params(struct
display_mode_lib *mode_lib,
double hratio_c = 0;
double vratio_l = 0;
double vratio_c = 0;
- bool scl_enable = 0;
+ bool scl_enable = false;
double line_time_in_us = 0;
// double vinit_l;
@@ -1156,7 +1156,7 @@ static void dml_rq_dlg_get_dlg_params(struct
display_mode_lib *mode_lib,
// Source
// dcc_en = src.dcc;
dual_plane = is_dual_plane((enum
source_format_class)(src->source_format));
- mode_422 = 0; // TODO
+ mode_422 = false; // TODO
access_dir = (src->source_scan == dm_vert); // vp access direction:
horizontal or vertical accessed
vp_height_l = src->viewport_height;
vp_width_l = src->viewport_width;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/display: Fix spelling mistake of function name
On 2021-01-20 4:26 a.m., Colin King wrote:
From: Colin Ian King
Reviewed-by: Harry Wentland
Harry
There are two spelling mistakes of the function name, fix this
by using __func__ instead of a hard coded name string.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c16af3983fdb..91d4130cd2cb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1602,7 +1602,7 @@ static bool dc_link_construct(struct dc_link *link,
link->psr_settings.psr_version = DC_PSR_VERSION_UNSUPPORTED;
- DC_LOG_DC("BIOS object table - dc_link_contruct finished successfully.\n");
+ DC_LOG_DC("BIOS object table - %s finished successfully.\n", __func__);
return true;
device_tag_fail:
link->link_enc->funcs->destroy(>link_enc);
@@ -1619,7 +1619,7 @@ static bool dc_link_construct(struct dc_link *link,
link->hpd_gpio = NULL;
}
- DC_LOG_DC("BIOS object table - dc_link_contruct failed.\n");
+ DC_LOG_DC("BIOS object table - %s failed.\n", __func__);
kfree(info);
return false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On 1/20/21 4:05 AM, Daniel Vetter wrote: On Tue, Jan 19, 2021 at 01:18:15PM -0500, Andrey Grodzovsky wrote: On 1/19/21 1:08 PM, Daniel Vetter wrote: On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky wrote: On 1/19/21 9:16 AM, Daniel Vetter wrote: On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handlerif the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate.This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUSit would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence.This was handled by introducing a 'flush' sequence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. v2: Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted to per user process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requirements that still give useful solution to work and this is the'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS. v3: More updates following comments from v2 such as removing loop to find DRM file when rerouting page faults to dummy page,getting rid of unnecessary sysfs handling refactoring and moving prevention of GPU recovery post device unplug from amdgpu to scheduler layer. On top of that added unplug support for the IOMMU enabled system. v4: Drop last sysfs hack and use sysfs default attribute. Guard against write accesses after device removal to avoid modifying released memory. Update dummy pages handling to on demand allocation and release through drm managed framework. Add return value to scheduler job TO handler (by Luben Tuikov) and use this in amdgpu for prevention of GPU recovery post device unplug Also rebase on top of drm-misc-mext instead of amd-staging-drm-next With these patches I am able to gracefully remove the secondary card using sysfs remove hook while glxgears is running off of secondary card (DRI_PRIME=1) without kernel oopses or hangs and keep working with the primary card or soft reset the device without hangs or oopses TODOs for followup work: Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and allocations) (Daniel) Support plugging the secondary device back after unplug - currently still experiencing HW error on plugging back. Add support for 'Requirements for KMS UAPI' section of [2] - unplugging primary, display connected card. [1] - Discussions during v3 of the patchset https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg55576.htmldata=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cbe51719dbdac41f5176b08d8bd2279ec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637467303085005502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=T4JLiSl7m4R%2FhcfcAxomY%2FMJ8QiTHaJ%2FJaqNZVT%2FDsk%3Dreserved=0 [2] - drm/doc: device hot-unplug for userspace https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Fdri-devel%2Fmsg259755.htmldata=04%7C01%7CAndrey.Grodzovsky%40amd.com%7Cbe51719dbdac41f5176b08d8bd2279ec%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637467303085005502%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qitlHw6tqm4eGRstKccgh8zIPgILbS%2FJUa5yZGmSQcU%3Dreserved=0 [3] - Related gitlab ticket
Re: [PATCH v2 2/3] drm/ingenic: Register devm action to cleanup encoders
On Wed, Jan 20, 2021 at 2:21 PM Paul Cercueil wrote:
>
>
>
> Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
> écrit :
> > On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
> > wrote:
> >>
> >> Since the encoders have been devm-allocated, they will be freed way
> >> before drm_mode_config_cleanup() is called. To avoid use-after-free
> >> conditions, we then must ensure that drm_encoder_cleanup() is called
> >> before the encoders are freed.
> >>
> >> v2: Use the new __drmm_simple_encoder_alloc() function
> >>
> >> Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
> >> Cc: # 5.8+
> >> Signed-off-by: Paul Cercueil
> >> ---
> >>
> >> Notes:
> >> Use the V1 of this patch to fix v5.11 and older kernels. This
> >> V2 only
> >> applies on the current drm-misc-next branch.
> >>
> >> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16 +++-
> >> 1 file changed, 7 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> index 7bb31fbee29d..158433b4c084 100644
> >> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> >> @@ -1014,20 +1014,18 @@ static int ingenic_drm_bind(struct device
> >> *dev, bool has_components)
> >> bridge =
> >> devm_drm_panel_bridge_add_typed(dev, panel,
> >>
> >> DRM_MODE_CONNECTOR_DPI);
> >>
> >> - encoder = devm_kzalloc(dev, sizeof(*encoder),
> >> GFP_KERNEL);
> >> - if (!encoder)
> >> - return -ENOMEM;
> >> + encoder = __drmm_simple_encoder_alloc(drm,
> >> sizeof(*encoder), 0,
> >
> > Please don't use the __ prefixed functions, those are the internal
> > ones. The official one comes with type checking and all that included.
> > Otherwise lgtm.
> > -Daniel
>
> The non-prefixed one assumes that I want to allocate a struct that
> contains the encoder, not just the drm_encoder itself.
Hm, but using the internal one is also a bit too ugly. A
drm_plain_simple_enocder_alloc(drm, type) wrapper would be the right
thing here I think? Setting the offsets and struct sizes directly in
these in drivers really doesn't feel like a good idea. I think simple
encoder is the only case where we really have a need for a
non-embeddable struct.
-Daniel
>
> -Paul
>
> >> +
> >> DRM_MODE_ENCODER_DPI);
> >> + if (IS_ERR(encoder)) {
> >> + ret = PTR_ERR(encoder);
> >> + dev_err(dev, "Failed to init encoder:
> >> %d\n", ret);
> >> + return ret;
> >> + }
> >>
> >> encoder->possible_crtcs = 1;
> >>
> >> drm_encoder_helper_add(encoder,
> >> _drm_encoder_helper_funcs);
> >>
> >> - ret = drm_simple_encoder_init(drm, encoder,
> >> DRM_MODE_ENCODER_DPI);
> >> - if (ret) {
> >> - dev_err(dev, "Failed to init encoder:
> >> %d\n", ret);
> >> - return ret;
> >> - }
> >> -
> >> ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> >> if (ret) {
> >> dev_err(dev, "Unable to attach bridge\n");
> >> --
> >> 2.29.2
> >>
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
Hi,
> > > > > + select TRACE_GPU_MEM
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
That doesn't make sense btw.
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > +static inline void virtio_gpu_trace_total_mem(struct
> > > > > virtio_gpu_device *vgdev,
> > > > > + s64 delta)
> > > > > +{
> > > > > + u64 total_mem = atomic64_add_return(delta, >total_mem);
> > > > > +
> > > > > + trace_gpu_mem_total(0, 0, total_mem);
Hmm, so no per process tracking (pid arg hard-coded to zero)?
Any plans for that?
The cgroups patches mentioned by Daniel should address that btw.
The gpu_id is hardcoded to zero too. Shouldn't that be something like
the minor number of the drm device? Or maybe something else in case you
need drm and non-drm gpu devices work side-by-side?
> > > Thanks for your reply! Android Cuttlefish virtual platform is using
> > > the virtio-gpu driver, and we currently are carrying this small patch
> > > at the downstream side. This is essential for us because:
> > > (1) Android has deprecated debugfs on production devices already
IIRC there have been discussions about a statfs, so you can export stats
with a sane interface without also enabling all the power provided by
debugfs, exactly because of the concerns to do that on production
systems.
Not sure what the state is, seems to not be upstream yet. That would be
(beside cgroups) another thing to look at.
> > > Android relies on this tracepoint + eBPF to make the GPU memory totals
> > > available at runtime on production devices, which has been enforced
> > > already. Not only game developers can have a reliable kernel total GPU
> > > memory to look at, but also Android leverages this to take GPU memory
> > > usage out from the system lost ram.
Sounds like you define "gpu memory" as "system memory used to store gpu
data". Is that correct? What about device memory?
> > > I'm not sure whether the other DRM drivers would like to integrate
> > > this tracepoint(maybe upstream drivers will move away from debugfs
> > > later as well?), but at least we hope virtio-gpu can take this.
Well, it is basically the same for all drivers using the gem shmem
helpers. So I see little reason why we should do that at virtio-gpu
level.
> Android GPU vendors have integrated this tracepoint to track gpu
> memory usage total(mapped into the gpu address space), which consists
> of below:
> (1) directly allocated via physical page allocator
> (2) imported external memory backed by dma-bufs
> (3) allocated exportable memory backed by dma-bufs
Hmm, the tracepoint doesn't track which of the three groups the memory
belongs to. Which I think is important, specifically group (2) because
that might already be accounted for by the exporting driver ...
> Our Android kernel team is leading the other side of effort to help
> remove the dma-bufs overlap(those mapped into a gpu device) as a joint
> effort, so that we can accurately explain the memory usage of the
> entire Android system.
I suspect once you figured that you'll notice that this little hack is
rather incomplete.
> For virtio-gpu, since that's used by our reference platform
> Cuttlefish(Cloud Android), we have to integrate the same tracepoint as
> well to enforce the use of this tracepoint and the eBPF stuff built on
> top to support runtime query of gpu memory on production devices. For
> virtio-gpu at this moment, we only want to track GEM allocations since
> PRIME import is currently not supported/used in Cuttlefish. That's all
> we are doing in this small patch.
take care,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: remove zte display driver
From: Arnd Bergmann The zte zx platform is getting removed, so this driver is no longer needed. Cc: Jun Nie Cc: Shawn Guo Link: https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/ Signed-off-by: Arnd Bergmann --- .../devicetree/bindings/display/zte,vou.txt | 120 --- drivers/gpu/drm/Kconfig | 2 - drivers/gpu/drm/Makefile | 1 - drivers/gpu/drm/zte/Kconfig | 11 - drivers/gpu/drm/zte/Makefile | 10 - drivers/gpu/drm/zte/zx_common_regs.h | 28 - drivers/gpu/drm/zte/zx_drm_drv.c | 190 drivers/gpu/drm/zte/zx_drm_drv.h | 34 - drivers/gpu/drm/zte/zx_hdmi.c | 760 --- drivers/gpu/drm/zte/zx_hdmi_regs.h| 66 -- drivers/gpu/drm/zte/zx_plane.c| 533 -- drivers/gpu/drm/zte/zx_plane.h| 26 - drivers/gpu/drm/zte/zx_plane_regs.h | 120 --- drivers/gpu/drm/zte/zx_tvenc.c| 400 drivers/gpu/drm/zte/zx_tvenc_regs.h | 27 - drivers/gpu/drm/zte/zx_vga.c | 527 -- drivers/gpu/drm/zte/zx_vga_regs.h | 33 - drivers/gpu/drm/zte/zx_vou.c | 921 -- drivers/gpu/drm/zte/zx_vou.h | 64 -- drivers/gpu/drm/zte/zx_vou_regs.h | 212 20 files changed, 4085 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt delete mode 100644 drivers/gpu/drm/zte/Kconfig delete mode 100644 drivers/gpu/drm/zte/Makefile delete mode 100644 drivers/gpu/drm/zte/zx_common_regs.h delete mode 100644 drivers/gpu/drm/zte/zx_drm_drv.c delete mode 100644 drivers/gpu/drm/zte/zx_drm_drv.h delete mode 100644 drivers/gpu/drm/zte/zx_hdmi.c delete mode 100644 drivers/gpu/drm/zte/zx_hdmi_regs.h delete mode 100644 drivers/gpu/drm/zte/zx_plane.c delete mode 100644 drivers/gpu/drm/zte/zx_plane.h delete mode 100644 drivers/gpu/drm/zte/zx_plane_regs.h delete mode 100644 drivers/gpu/drm/zte/zx_tvenc.c delete mode 100644 drivers/gpu/drm/zte/zx_tvenc_regs.h delete mode 100644 drivers/gpu/drm/zte/zx_vga.c delete mode 100644 drivers/gpu/drm/zte/zx_vga_regs.h delete mode 100644 drivers/gpu/drm/zte/zx_vou.c delete mode 100644 drivers/gpu/drm/zte/zx_vou.h delete mode 100644 drivers/gpu/drm/zte/zx_vou_regs.h diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt deleted file mode 100644 index 38476475fd60.. --- a/Documentation/devicetree/bindings/display/zte,vou.txt +++ /dev/null @@ -1,120 +0,0 @@ -ZTE VOU Display Controller - -This is a display controller found on ZTE ZX296718 SoC. It includes multiple -Graphic Layer (GL) and Video Layer (VL), two Mixers/Channels, and a few blocks -handling scaling, color space conversion etc. VOU also integrates the support -for typical output devices, like HDMI, TV Encoder, VGA, and RGB LCD. - -* Master VOU node - -It must be the parent node of all the sub-device nodes. - -Required properties: - - compatible: should be "zte,zx296718-vou" - - #address-cells: should be <1> - - #size-cells: should be <1> - - ranges: list of address translations between VOU and sub-devices - -* VOU DPC device - -Required properties: - - compatible: should be "zte,zx296718-dpc" - - reg: Physical base address and length of DPC register regions, one for each - entry in 'reg-names' - - reg-names: The names of register regions. The following regions are required: - "osd" - "timing_ctrl" - "dtrc" - "vou_ctrl" - "otfppu" - - interrupts: VOU DPC interrupt number to CPU - - clocks: A list of phandle + clock-specifier pairs, one for each entry - in 'clock-names' - - clock-names: A list of clock names. The following clocks are required: - "aclk" - "ppu_wclk" - "main_wclk" - "aux_wclk" - -* HDMI output device - -Required properties: - - compatible: should be "zte,zx296718-hdmi" - - reg: Physical base address and length of the HDMI device IO region - - interrupts : HDMI interrupt number to CPU - - clocks: A list of phandle + clock-specifier pairs, one for each entry - in 'clock-names' - - clock-names: A list of clock names. The following clocks are required: - "osc_cec" - "osc_clk" - "xclk" - -* TV Encoder output device - -Required properties: - - compatible: should be "zte,zx296718-tvenc" - - reg: Physical base address and length of the TVENC device IO region - - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two - integer cells. The first cell is the offset of SYSCTRL register used - to control TV Encoder DAC power, and the second cell is the bit mask. - -* VGA output device - -Required properties: - - compatible: should be "zte,zx296718-vga" - - reg: Physical base address and length of the VGA device IO region - - interrupts : VGA interrupt number
Re: [PATCH v2 2/3] drm/ingenic: Register devm action to cleanup encoders
On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil wrote:
>
> Since the encoders have been devm-allocated, they will be freed way
> before drm_mode_config_cleanup() is called. To avoid use-after-free
> conditions, we then must ensure that drm_encoder_cleanup() is called
> before the encoders are freed.
>
> v2: Use the new __drmm_simple_encoder_alloc() function
>
> Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
> Cc: # 5.8+
> Signed-off-by: Paul Cercueil
> ---
>
> Notes:
> Use the V1 of this patch to fix v5.11 and older kernels. This V2 only
> applies on the current drm-misc-next branch.
>
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 7bb31fbee29d..158433b4c084 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -1014,20 +1014,18 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> bridge = devm_drm_panel_bridge_add_typed(dev, panel,
>
> DRM_MODE_CONNECTOR_DPI);
>
> - encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
> - if (!encoder)
> - return -ENOMEM;
> + encoder = __drmm_simple_encoder_alloc(drm, sizeof(*encoder),
> 0,
Please don't use the __ prefixed functions, those are the internal
ones. The official one comes with type checking and all that included.
Otherwise lgtm.
-Daniel
> + DRM_MODE_ENCODER_DPI);
> + if (IS_ERR(encoder)) {
> + ret = PTR_ERR(encoder);
> + dev_err(dev, "Failed to init encoder: %d\n", ret);
> + return ret;
> + }
>
> encoder->possible_crtcs = 1;
>
> drm_encoder_helper_add(encoder,
> _drm_encoder_helper_funcs);
>
> - ret = drm_simple_encoder_init(drm, encoder,
> DRM_MODE_ENCODER_DPI);
> - if (ret) {
> - dev_err(dev, "Failed to init encoder: %d\n", ret);
> - return ret;
> - }
> -
> ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> if (ret) {
> dev_err(dev, "Unable to attach bridge\n");
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] Immutable branch between Backlight Arm and SPI due for the v5.12 merge window
Enjoy! The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git ib-backlight-arm-spi-v5.12 for you to fetch changes up to 93cc26fa8f37fbd320f36525bfedd4b3e2b3e2ba: backlight: lms283gf05: Convert to GPIO descriptors (2021-01-20 12:47:11 +) Immutable branch between Backlight Arm and SPI due for the v5.12 merge window Linus Walleij (1): backlight: lms283gf05: Convert to GPIO descriptors arch/arm/mach-pxa/z2.c | 12 ++ drivers/video/backlight/lms283gf05.c | 43 ++-- include/linux/spi/lms283gf05.h | 16 -- 3 files changed, 25 insertions(+), 46 deletions(-) delete mode 100644 include/linux/spi/lms283gf05.h -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH v2] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Wed, Jan 20, 2021 at 1:22 PM Christian König wrote: > > Am 19.01.21 um 23:57 schrieb Hridya Valsaraju: > > This patch allows statistics to be enabled for each DMA-BUF in > > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > > > The following stats will be exposed by the interface: > > > > /sys/kernel/dmabuf/buffers//exporter_name > > /sys/kernel/dmabuf/buffers//size > > /sys/kernel/dmabuf/buffers//attachments//device > > /sys/kernel/dmabuf/buffers//attachments//map_counter > > > > The inode_number is unique for each DMA-BUF and was added earlier [1] > > in order to allow userspace to track DMA-BUF usage across different > > processes. > > > > Currently, this information is exposed in > > /sys/kernel/debug/dma_buf/bufinfo. > > However, since debugfs is considered unsafe to be mounted in production, > > it is being duplicated in sysfs. > > > > This information will be used to derive DMA-BUF > > per-exporter stats and per-device usage stats for Android Bug reports. > > The corresponding userspace changes can be found at [2]. > > Telemetry tools will also capture this information(along with other > > memory metrics) periodically as well as on important events like a > > foreground app kill (which might have been triggered by Low Memory > > Killer). It will also contribute to provide a snapshot of the system > > memory usage on other events such as OOM kills and Application Not > > Responding events. > > > > A shell script that can be run on a classic Linux environment to read > > out the DMA-BUF statistics can be found at [3](suggested by John > > Stultz). > > > > The patch contains the following improvements over the previous version: > > 1) Each attachment is represented by its own directory to allow creating > > a symlink to the importing device and to also provide room for future > > expansion. > > 2) The number of distinct mappings of each attachment is exposed in a > > separate file. > > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > > inorder to make the interface expandable in future. > > > > All of the improvements above are based on suggestions/feedback from > > Daniel Vetter and Christian König. > > > > [1]: https://lore.kernel.org/patchwork/patch/1088791/ > > [2]: > > https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > > [3]: > > https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > > > > Signed-off-by: Hridya Valsaraju > > --- > > Changes in v2: > > -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition > > of other DMA-BUF-related sysfs stats in future. Based on feedback from > > Daniel Vetter. > > -Each attachment has its own directory to represent attaching devices as > > symlinks and to introduce map_count as a separate file. Based on > > feedback from Daniel Vetter and Christian König. Thank you both! > > -Commit messages updated to point to userspace code in AOSP that will > > read the DMA-BUF sysfs stats. > > > > .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 > > drivers/dma-buf/Kconfig | 11 + > > drivers/dma-buf/Makefile | 1 + > > drivers/dma-buf/dma-buf-sysfs-stats.c | 283 ++ > > drivers/dma-buf/dma-buf-sysfs-stats.h | 62 > > drivers/dma-buf/dma-buf.c | 37 +++ > > include/linux/dma-buf.h | 20 ++ > > 7 files changed, 466 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h > > > > diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > new file mode 100644 > > index ..6f7c65209f07 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > @@ -0,0 +1,52 @@ > > +What:/sys/kernel/dmabuf/buffers > > +Date:January 2021 > > +KernelVersion: v5.12 > > +Contact: Hridya Valsaraju > > +Description: The /sys/kernel/dmabuf/buffers directory contains a > > + snapshot of the internal state of every DMA-BUF. > > + /sys/kernel/dmabuf/buffers/ will contain the > > + statistics for the DMA-BUF with the unique inode number > > + > > +Users: kernel memory tuning/debugging tools > > + > > +What: > > /sys/kernel/dmabuf/buffers//exporter_name > > +Date:January 2021 > > +KernelVersion: v5.12 > > +Contact: Hridya Valsaraju > > +Description: This file is read-only and contains the name of the exporter > > of > > + the DMA-BUF. > > + > > +What:/sys/kernel/dmabuf/buffers//size > > +Date:January 2021 > > +KernelVersion: v5.12 > > +Contact: Hridya
Re: [PATCH 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge
On Wed, Jan 20, 2021 at 12:55:40PM +0100, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 20, 2021 at 12:29 PM Jagan Teki wrote: > > On Wed, Jan 20, 2021 at 4:55 PM Michael Nazzareno Trimarchi wrote: > > > On Wed, Jan 20, 2021 at 12:22 PM Jagan Teki wrote: > > > > > > > > SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from > > > > Texas Instruments. > > > > > > > > SN65DSI83, SN65DSI85 are variants of the same family of bridge > > > > controllers. > > > > > > > > Right now the bridge driver is supporting a single link, dual-link > > > > support requires to initiate I2C Channel B registers. > > > > > > > > Tested with STM32MP1 MIPI DSI host design configuration. > > > > > > > > Signed-off-by: Matteo Lisi > > > > Signed-off-by: Jagan Teki > > > > --- > > > > MAINTAINERS | 6 + > > > > drivers/gpu/drm/bridge/Kconfig| 19 + > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > drivers/gpu/drm/bridge/ti-sn65dsi84.c | 488 ++ > > > > 4 files changed, 514 insertions(+) > > > > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index 12dd1fff2a39..44750ff7640c 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -5984,6 +5984,12 @@ S: Maintained > > > > F: Documentation/devicetree/bindings/display/ti/ > > > > F: drivers/gpu/drm/omapdrm/ > > > > > > > > +DRM DRIVERS FOR TI SN65DSI84 DSI TO LVDS BRIDGE > > > > +M: Jagan Teki > > > > +S: Maintained > > > > +F: > > > > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml > > > > +F: drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > + > > > > DRM DRIVERS FOR V3D > > > > M: Eric Anholt > > > > S: Supported > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig > > > > b/drivers/gpu/drm/bridge/Kconfig > > > > index e4110d6ca7b3..6494881bffb3 100644 > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > @@ -232,6 +232,25 @@ config DRM_TI_TFP410 > > > > help > > > > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > > > > > > > +config DRM_TI_SN65DSI84 > > > > + tristate "TI SN65DSI84 DSI to LVDS bridge" > > > > + depends on OF > > > > + select DRM_KMS_HELPER > > > > + select REGMAP_I2C > > > > + select DRM_PANEL > > > > + select DRM_MIPI_DSI > > > > + help > > > > + Texas Instruments SN65DSI84 Single Channel DSI to Dual-link > > > > LVDS > > > > + bridge driver. > > > > + > > > > + Bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets > > > > and > > > > + converts the formatted video data stream to a FlatLink > > > > compatible > > > > + LVDS output operating at pixel clocks operating from 25 MHx to > > > > + 154 MHz. > > > > + > > > > + SN65DSI84 offers a Dual-Link LVDS, Single-Link LVDS interface > > > > with > > > > + four data lanes per link. > > > > + > > > > config DRM_TI_SN65DSI86 > > > > tristate "TI SN65DSI86 DSI to eDP bridge" > > > > depends on OF > > > > diff --git a/drivers/gpu/drm/bridge/Makefile > > > > b/drivers/gpu/drm/bridge/Makefile > > > > index 86e7acc76f8d..3906052ef639 100644 > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > > > > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > > > > obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > > > > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > > > > +obj-$(CONFIG_DRM_TI_SN65DSI84) += ti-sn65dsi84.o > > > > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > > > > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > > > > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > new file mode 100644 > > > > index ..3ed1f9a7d898 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > @@ -0,0 +1,488 @@ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +/* > > > > + * Copyright (c) 2021 Engicam srl > > > > + * Copyright (C) 2021 Amarula Solutions(India) > > > > + * Author: Jagan Teki > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +/* sn65dsi84 registers */ > > > > +#define SN65DSI_SOFT_RESET 0x09 > > > > +#define SN65DSI_LVDS_CLK 0x0a > > > > +#define SN65DSI_CLK_DIV0x0b > > > > +#define SN65DSI_CLK_PLL0x0d > > > > +#define SN65DSI_DSI_CFG0x10 > > > > +#define SN65DSI_DSI_CLK_EQ 0x11 > > > > +#define SN65DSI_DSI_CLK_RANGE 0x12 > > > >
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Wed, Jan 20, 2021 at 10:51 AM Yiwei Zhang wrote:
>
> On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > > >
> > > > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang
> > > > wrote:
> > > > >
> > > > > On the success of virtio_gpu_object_create, add size of newly
> > > > > allocated
> > > > > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the
> > > > > gem
> > > > > bo lost its last refcount, subtract the bo size from the tracked
> > > > > total_mem if the original underlying memory allocation is successful.
> > > > >
> > > > > Signed-off-by: Yiwei Zhang
> > > >
> > > > Isn't this something that ideally we'd for everyone? Also tracepoint
> > > > for showing the total feels like tracepoint abuse, usually we show
> > > > totals somewhere in debugfs or similar, and tracepoint just for what's
> > > > happening (i.e. which object got deleted/created).
> > > >
> > > > What is this for exactly?
> > > > -Daniel
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/virtio/Kconfig | 1 +
> > > > > drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> > > > > drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> > > > > 3 files changed, 24 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/virtio/Kconfig
> > > > > b/drivers/gpu/drm/virtio/Kconfig
> > > > > index b925b8b1da16..e103b7e883b1 100644
> > > > > --- a/drivers/gpu/drm/virtio/Kconfig
> > > > > +++ b/drivers/gpu/drm/virtio/Kconfig
> > > > > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > > > > select DRM_KMS_HELPER
> > > > > select DRM_GEM_SHMEM_HELPER
> > > > > select VIRTIO_DMA_SHARED_BUFFER
> > > > > + select TRACE_GPU_MEM
> > > > > help
> > > > >This is the virtual GPU driver for virtio. It can be used
> > > > > with
> > > > >QEMU based VMMs (like KVM or Xen).
> > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > index 6a232553c99b..7c60e7486bc4 100644
> > > > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > > > @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> > > > > spinlock_t resource_export_lock;
> > > > > /* protects map state and host_visible_mm */
> > > > > spinlock_t host_visible_lock;
> > > > > +
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > + atomic64_t total_mem;
> > > > > +#endif
> > > > > };
> > > > >
> > > > > struct virtio_gpu_fpriv {
> > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > index d69a5b6da553..1e16226cebbe 100644
> > > > > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > > > @@ -25,12 +25,29 @@
> > > > >
> > > > > #include
> > > > > #include
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > +#include
> > > > > +#endif
> > > > >
> > > > > #include "virtgpu_drv.h"
> > > > >
> > > > > static int virtio_gpu_virglrenderer_workaround = 1;
> > > > > module_param_named(virglhack, virtio_gpu_virglrenderer_workaround,
> > > > > int, 0400);
> > > > >
> > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > > > +static inline void virtio_gpu_trace_total_mem(struct
> > > > > virtio_gpu_device *vgdev,
> > > > > + s64 delta)
> > > > > +{
> > > > > + u64 total_mem = atomic64_add_return(delta, >total_mem);
> > > > > +
> > > > > + trace_gpu_mem_total(0, 0, total_mem);
> > > > > +}
> > > > > +#else
> > > > > +static inline void virtio_gpu_trace_total_mem(struct
> > > > > virtio_gpu_device *, s64)
> > > > > +{
> > > > > +}
> > > > > +#endif
> > > > > +
> > > > > int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
> > > > > uint32_t *resid)
> > > > > {
> > > > > if (virtio_gpu_virglrenderer_workaround) {
> > > > > @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct
> > > > > drm_gem_object *obj)
> > > > > struct virtio_gpu_device *vgdev =
> > > > > bo->base.base.dev->dev_private;
> > > > >
> > > > > if (bo->created) {
> > > > > + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> > > > > virtio_gpu_cmd_unref_resource(vgdev, bo);
> > > > > virtio_gpu_notify(vgdev);
> > > > > /* completion handler calls
> > > > > virtio_gpu_cleanup_object() */
> > > > > @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct
> > > > > virtio_gpu_device *vgdev,
> > > > > virtio_gpu_object_attach(vgdev, bo, ents, nents);
> > > > > }
> > > > >
> > > > > + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> > > > > *bo_ptr = bo;
> > > > > return 0;
> > > > >
> > > > > --
> > > > > 2.30.0.284.gd98b1dd5eaa7-goog
> > > > >
> > >
Re: [Linaro-mm-sig] [PATCH v2] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Am 19.01.21 um 23:57 schrieb Hridya Valsaraju: This patch allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers//exporter_name /sys/kernel/dmabuf/buffers//size /sys/kernel/dmabuf/buffers//attachments//device /sys/kernel/dmabuf/buffers//attachments//map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Currently, this information is exposed in /sys/kernel/debug/dma_buf/bufinfo. However, since debugfs is considered unsafe to be mounted in production, it is being duplicated in sysfs. This information will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). The patch contains the following improvements over the previous version: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 Signed-off-by: Hridya Valsaraju --- Changes in v2: -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition of other DMA-BUF-related sysfs stats in future. Based on feedback from Daniel Vetter. -Each attachment has its own directory to represent attaching devices as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. Thank you both! -Commit messages updated to point to userspace code in AOSP that will read the DMA-BUF sysfs stats. .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-sysfs-stats.c | 283 ++ drivers/dma-buf/dma-buf-sysfs-stats.h | 62 drivers/dma-buf/dma-buf.c | 37 +++ include/linux/dma-buf.h | 20 ++ 7 files changed, 466 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index ..6f7c65209f07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/ will contain the + statistics for the DMA-BUF with the unique inode number + +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers//exporter_name +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//size +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers//attachments +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//attachments/ +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya
Re: [PULL] drm-misc-fixes
Am 20.01.21 um 13:09 schrieb Thomas Zimmermann: Hi Dave and Daniel, here's this week's PR for drm-misc-next. drm-misc-fixes Best regards Thomas drm-misc-fixes-2021-01-20: Short summary of fixes pull (less than what git shortlog provides): * drm/atomic: Release state on error * drm/syncobj: Fix use-after-free * drm/ttm: Don't use GFP_TRANSHUGE_LIGTH * drm/vc4: Unify driver naming for PCM * drm/vram-helper: Fix memory leak in vmap The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31: Linux 5.11-rc4 (2021-01-17 16:37:05 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-20 for you to fetch changes up to a37eef63bc9e16e06361b539e528058146af80ab: drm/syncobj: Fix use-after-free (2021-01-20 10:28:39 +0100) Short summary of fixes pull (less than what git shortlog provides): * drm/atomic: Release state on error * drm/syncobj: Fix use-after-free * drm/ttm: Don't use GFP_TRANSHUGE_LIGTH * drm/vc4: Unify driver naming for PCM * drm/vram-helper: Fix memory leak in vmap Christian König (1): drm/ttm: stop using GFP_TRANSHUGE_LIGHT Daniel Vetter (1): drm/syncobj: Fix use-after-free Nicolas Saenz Julienne (1): drm/vc4: Unify PCM card's driver_name Pan Bian (1): drm/atomic: put state on error path Thomas Zimmermann (1): drm/vram-helper: Reuse existing page mappings in vmap drivers/gpu/drm/drm_atomic_helper.c | 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 14 +++--- drivers/gpu/drm/drm_syncobj.c | 8 +--- drivers/gpu/drm/ttm/ttm_pool.c| 11 ++- drivers/gpu/drm/vc4/vc4_hdmi.c| 1 + 5 files changed, 24 insertions(+), 12 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm tree
On Mon, Jan 18, 2021 at 2:06 AM Dave Airlie wrote:
>
> On Mon, 18 Jan 2021 at 10:59, Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell
> > > > wrote:
> > > > >
> > > > > After merging the drm tree, today's linux-next build (x86_64
> > > > > allmodconfig)
> > > > > failed like this:
> > > > >
> > > > > error: the following would cause module name conflict:
> > > > > drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > > > > drivers/gpu/drm/panel/panel-dsi-cm.ko
> > > > >
> > > > > Maybe caused by commit
> > > > >
> > > > > cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel
> > > > > driver")
> > > > >
> > > > > I have used the drm tree from next-20210107 for today.
> > > >
> > > > This has affected the drm-misc tree as well (since it merged in the drm
> > > > tree).
> > > >
> > > > I have used the drm-misc tree from next-20210107 for today.
> > >
> > > And now the drm-intel tree.
> > >
> > > I have used the drm-intel tree from next-20210108 for today.
> >
> > This is still affecting the drm and drm-intel trees.
>
> I think the fix for this is in drm-misc-next, Maarten can you send me
> a -next PR to fix this?
I've pulled drm-misc-next into drm-next now, so as long as all other
drm trees are merged after drm, this should be solved now.
drm-intel-next also has their msm build breakage fixed (I acked the
patch already), so hopefully we should be all clean again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-next
On Tue, Jan 19, 2021 at 12:39:22PM +0100, Maarten Lankhorst wrote: > drm-misc-next-2021-01-19: > drm-misc-next for v5.12: > > UAPI Changes: > - Fix fourcc macro for amlogic video fbc. > > Cross-subsystem Changes: > - Export pci_rebar_bytes_to_size. > - Add a PCI quirk to increase bar0 for RX 5600 XT Pulse to max possible size. > - Convert devicetree bindings to use the OF graph schema. > - Update s6e63m0 bindings. > - Make omapfb2 DSI_CM incompatible with drm/omap2 DSI-CM because of > module conflicts. > - Add Zack Rusin as vmwgfx maintainer. > - Add CONFIG_DMABUF_DEBUG for validating dma-buf users don't loo kat struct > page when importing or detaching. > > Core Changes: > - Remove references to drm_device.pdev > - Fix regression in ttm_bo_move_to_lru_tail(). > - Assorted docbook updates. > - Do not send dp-mst hotplug events on error when probing. > - Move some agp macros to agpsupport.c, so it's not always compiled. > - Move drm_need_swiotlb.h to drm_cache.c > - Only build drm_memory.o for legacy drivers, and move CONFIG_DRM_VM to > legacy. > - Nuke drm_device.hose > - Warn when the ttm resource manager is non-empty when disabling. > - Assorted small fixes. > > Driver Changes: > - Small assorted fixes in radeon, v3d, hisilicon, mipi-dbi, panfrost, hibmc, > vc4, amdgpu, vkms, vmwgfx. > - Move hisilicon to use simple encode. > - Add writeback connector to vkms. > - Add support for BT2020 to DE3. > - Use gem prime mmap helpers in vc4, and move the mmap function upwards. > - Use managed drm device, and cleanup error paths and display registers in > vmwgfx. > - Use correct bus_format and connector_type for innolux_n116bge. > - Fix a lot of warnings with W=1 (Lee Jones) > The following changes since commit cb3cfbf79aff7decb4e5ee69a7c74864497f61dc: > > Merge tag 'drm-misc-next-2021-01-06' of > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-01-07 13:40:20 > +0100) Pulled, thanks. -Daniel > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-01-19 > > for you to fetch changes up to c31eb10fd5aee124b78ce72ebf7d0cd13fca6095: > > drm/amdgpu: Remove accidentally added small unused hunk. (2021-01-19 > 11:18:39 +0100) > > > drm-misc-next for v5.12: > > UAPI Changes: > - Fix fourcc macro for amlogic video fbc. > > Cross-subsystem Changes: > - Export pci_rebar_bytes_to_size. > - Add a PCI quirk to increase bar0 for RX 5600 XT Pulse to max possible size. > - Convert devicetree bindings to use the OF graph schema. > - Update s6e63m0 bindings. > - Make omapfb2 DSI_CM incompatible with drm/omap2 DSI-CM because of > module conflicts. > - Add Zack Rusin as vmwgfx maintainer. > - Add CONFIG_DMABUF_DEBUG for validating dma-buf users don't loo kat struct > page when importing or detaching. > > Core Changes: > - Remove references to drm_device.pdev > - Fix regression in ttm_bo_move_to_lru_tail(). > - Assorted docbook updates. > - Do not send dp-mst hotplug events on error when probing. > - Move some agp macros to agpsupport.c, so it's not always compiled. > - Move drm_need_swiotlb.h to drm_cache.c > - Only build drm_memory.o for legacy drivers, and move CONFIG_DRM_VM to > legacy. > - Nuke drm_device.hose > - Warn when the ttm resource manager is non-empty when disabling. > - Assorted small fixes. > > Driver Changes: > - Small assorted fixes in radeon, v3d, hisilicon, mipi-dbi, panfrost, hibmc, > vc4, amdgpu, vkms, vmwgfx. > - Move hisilicon to use simple encode. > - Add writeback connector to vkms. > - Add support for BT2020 to DE3. > - Use gem prime mmap helpers in vc4, and move the mmap function upwards. > - Use managed drm device, and cleanup error paths and display registers in > vmwgfx. > - Use correct bus_format and connector_type for innolux_n116bge. > - Fix a lot of warnings with W=1 (Lee Jones) > > > Andrey Grodzovsky (2): > drm: Unamp the entire device address space on device unplug > drm/sched: Cancel and flush all outstanding jobs before finish. > > Chia-I Wu (2): > drm/virtio: make sure context is created in gem open > drm/virtio: fix prime export for vram objects > > Colin Ian King (1): > drm/vkms: Fix missing kmalloc allocation failure check > > Daniel Vetter (4): > drm/vmwgfx: Drop svga_lock > drm/vmwgfx: Always evict vram _before_ disabling it > drm/ttm: WARN_ON non-empty lru when disabling a resource manager > dma-buf: Add debug option > > Darren Salt (1): > PCI: Export pci_rebar_get_possible_sizes() > > Giulio Benetti (1): > drm/sun4i: tcon: fix inverted DCLK polarity > > Heiko Stuebner (1): > drm/panel: panel-simple: add bus-format and connector-type to Innolux > n116bge > > Jernej Skrabec (3): > drm/sun4i: csc: Rework DE3 CSC macros > drm/sun4i: de2/de3: Remove redundant CSC
Re: [pull] amdgpu drm-next-5.12
On Wed, Jan 20, 2021 at 01:09:51AM -0500, Alex Deucher wrote: > Hi Dave, Daniel, > > More new stuff for 5.12. Now with non-x86 fixed. > > The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075: > > drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug > 210921) (2021-01-08 15:18:57 -0500) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-next-5.12-2021-01-20 There was a silly conflict, I picked yours, but maybe double check. Details in the merge commit. Also maybe we want to fast-forward. -Daniel > > for you to fetch changes up to 4aef0ebc6b65e8583bc3d96e05c7a039912b3ee6: > > drm/amdgpu: fix build error without x86 kconfig (v2) (2021-01-19 15:16:10 > -0500) > > > amd-drm-next-5.12-2021-01-20: > > amdgpu: > - Fix non-x86 build > - W=1 fixes from Lee Jones > - Enable GPU reset on Navy Flounder > - Kernel doc fixes > - SMU workload profile fixes for APUs > - Display updates > - SR-IOV fixes > - Vangogh SMU feature enablment and bug fixes > - GPU reset support for Vangogh > - Misc cleanups > > > Alex Deucher (5): > MAINTAINERS: update radeon/amdgpu/amdkfd git trees > drm/amdgpu: add mode2 reset support for vangogh > drm/amdgpu/nv: add mode2 reset handling > drm/amdgpu: fix mode2 reset sequence for vangogh > drm/amdgpu: Enable GPU reset for vangogh > > Aric Cyr (2): > drm/amd/display: 3.2.117 > drm/amd/display: 3.2.118 > > Bhawanpreet Lakha (2): > drm/amd/display: enable HUBP blank behaviour > drm/amd/display: Fix deadlock during gpu reset v3 > > Charlene Liu (1): > drm/amd/display: change SMU repsonse timeout to 2s > > Chiawen Huang (1): > drm/amd/display: removed unnecessary check when dpp clock increasing > > Colin Ian King (1): > drm/amdgpu: Add missing BOOTUP_DEFAULT to profile_name[] > > Emily.Deng (1): > drm/amdgpu: Decrease compute timeout to 10 s for sriov multiple VF > > Guchun Chen (1): > drm/amdgpu: toggle on DF Cstate after finishing xgmi injection > > Huang Rui (13): > drm/amd/pm: remove vcn/jpeg powergating feature checking for vangogh > drm/amd/pm: enhance the real response for smu message (v2) > drm/amd/pm: clean up get_allowed_feature_mask function > drm/amd/pm: initial feature_enabled/feature_support bitmap for vangogh > drm/amd/pm: don't mark all apu as true on feature mask > drm/amdgpu: revise the mode2 reset for vangogh > drm/amd/pm: fix the return value of pm message > drm/amd/pm: implement the processor clocks which read by metric > drm/amd/pm: implement processor fine grain feature for vangogh (v3) > drm/amdgpu: fix vram type and bandwidth error for DDR5 and DDR4 > drm/amd/display: fix the system memory page fault because of copy > overflow > drm/amd/display: fix the coding style issue of integrated_info > drm/amdgpu: fix build error without x86 kconfig (v2) > > Jack Zhang (1): > drm/amdgpu/sriov Stop data exchange for wholegpu reset > > Jacky Liao (1): > drm/amd/display: Fix assert being hit with GAMCOR memory shut down > > Jeremy Cline (1): > drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu() > > Jiansong Chen (2): > drm/amdgpu: enable gpu recovery for navy_flounder > drm/amd/pm: update driver if version for navy_flounder > > Jinzhou Su (4): > drm/amd/pm: Add GFXOFF interface for Vangogh > drm/amd/pm: Enable GfxOff for Vangogh > drm/amdgpu: Add Secure Display TA header file > drm/amdgpu: Add secure display TA interface > > John Clements (1): > drm/amdgpu: updated fw attestation interface > > Jun Lei (1): > drm/amd/display: implement T12 compliance > > Lee Jones (90): > drm/amd/amdgpu/amdgpu_ih: Update 'amdgpu_ih_decode_iv_helper()'s > function header > drm/amd/amdgpu/vega20_ih: Add missing descriptions for 'ih' and fix > spelling error > drm/amd/pm/powerplay/hwmgr/process_pptables_v1_0: Provide description > of 'call_back_func' > drm/amd/pm/powerplay/hwmgr/ppatomctrl: Fix documentation for > 'mpll_param' > drm/amd/pm/powerplay/hwmgr/vega12_hwmgr: Fix legacy function header > formatting > drm/amd/pm/powerplay/hwmgr/vega20_hwmgr: Fix legacy function header > formatting > drm/amd/pm/powerplay/hwmgr/smu7_hwmgr: Fix formatting and spelling > issues > drm/amd/pm/powerplay/hwmgr/hwmgr: Move prototype into shared header > drm/amd/pm/powerplay/hwmgr/vega10_hwmgr: Fix a bunch of kernel-doc > formatting issues > drm/amd/display/dc/basics/conversion: Demote obvious kernel-doc abuse > drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs: Demote non-kernel-doc > comment blocks > drm/amd/display/dc/bios/command_table_helper: Fix
[PULL] drm-misc-fixes
Hi Dave and Daniel, here's this week's PR for drm-misc-next. Best regards Thomas drm-misc-fixes-2021-01-20: Short summary of fixes pull (less than what git shortlog provides): * drm/atomic: Release state on error * drm/syncobj: Fix use-after-free * drm/ttm: Don't use GFP_TRANSHUGE_LIGTH * drm/vc4: Unify driver naming for PCM * drm/vram-helper: Fix memory leak in vmap The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31: Linux 5.11-rc4 (2021-01-17 16:37:05 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-20 for you to fetch changes up to a37eef63bc9e16e06361b539e528058146af80ab: drm/syncobj: Fix use-after-free (2021-01-20 10:28:39 +0100) Short summary of fixes pull (less than what git shortlog provides): * drm/atomic: Release state on error * drm/syncobj: Fix use-after-free * drm/ttm: Don't use GFP_TRANSHUGE_LIGTH * drm/vc4: Unify driver naming for PCM * drm/vram-helper: Fix memory leak in vmap Christian König (1): drm/ttm: stop using GFP_TRANSHUGE_LIGHT Daniel Vetter (1): drm/syncobj: Fix use-after-free Nicolas Saenz Julienne (1): drm/vc4: Unify PCM card's driver_name Pan Bian (1): drm/atomic: put state on error path Thomas Zimmermann (1): drm/vram-helper: Reuse existing page mappings in vmap drivers/gpu/drm/drm_atomic_helper.c | 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 14 +++--- drivers/gpu/drm/drm_syncobj.c | 8 +--- drivers/gpu/drm/ttm/ttm_pool.c| 11 ++- drivers/gpu/drm/vc4/vc4_hdmi.c| 1 + 5 files changed, 24 insertions(+), 12 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge
On Wed, Jan 20, 2021 at 4:55 PM Michael Nazzareno Trimarchi wrote: > > Hi Jagan > > On Wed, Jan 20, 2021 at 12:22 PM Jagan Teki > wrote: > > > > SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from > > Texas Instruments. > > > > SN65DSI83, SN65DSI85 are variants of the same family of bridge > > controllers. > > > > Right now the bridge driver is supporting a single link, dual-link > > support requires to initiate I2C Channel B registers. > > > > Tested with STM32MP1 MIPI DSI host design configuration. > > > > Signed-off-by: Matteo Lisi > > Signed-off-by: Jagan Teki > > --- > > MAINTAINERS | 6 + > > drivers/gpu/drm/bridge/Kconfig| 19 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/ti-sn65dsi84.c | 488 ++ > > 4 files changed, 514 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi84.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 12dd1fff2a39..44750ff7640c 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5984,6 +5984,12 @@ S: Maintained > > F: Documentation/devicetree/bindings/display/ti/ > > F: drivers/gpu/drm/omapdrm/ > > > > +DRM DRIVERS FOR TI SN65DSI84 DSI TO LVDS BRIDGE > > +M: Jagan Teki > > +S: Maintained > > +F: Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml > > +F: drivers/gpu/drm/bridge/ti-sn65dsi84.c > > + > > DRM DRIVERS FOR V3D > > M: Eric Anholt > > S: Supported > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index e4110d6ca7b3..6494881bffb3 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -232,6 +232,25 @@ config DRM_TI_TFP410 > > help > > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > > > +config DRM_TI_SN65DSI84 > > + tristate "TI SN65DSI84 DSI to LVDS bridge" > > + depends on OF > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + select DRM_PANEL > > + select DRM_MIPI_DSI > > + help > > + Texas Instruments SN65DSI84 Single Channel DSI to Dual-link LVDS > > + bridge driver. > > + > > + Bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and > > + converts the formatted video data stream to a FlatLink compatible > > + LVDS output operating at pixel clocks operating from 25 MHx to > > + 154 MHz. > > + > > + SN65DSI84 offers a Dual-Link LVDS, Single-Link LVDS interface with > > + four data lanes per link. > > + > > config DRM_TI_SN65DSI86 > > tristate "TI SN65DSI86 DSI to eDP bridge" > > depends on OF > > diff --git a/drivers/gpu/drm/bridge/Makefile > > b/drivers/gpu/drm/bridge/Makefile > > index 86e7acc76f8d..3906052ef639 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > > obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > > +obj-$(CONFIG_DRM_TI_SN65DSI84) += ti-sn65dsi84.o > > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > new file mode 100644 > > index ..3ed1f9a7d898 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi84.c > > @@ -0,0 +1,488 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2021 Engicam srl > > + * Copyright (C) 2021 Amarula Solutions(India) > > + * Author: Jagan Teki > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* sn65dsi84 registers */ > > +#define SN65DSI_SOFT_RESET 0x09 > > +#define SN65DSI_LVDS_CLK 0x0a > > +#define SN65DSI_CLK_DIV0x0b > > +#define SN65DSI_CLK_PLL0x0d > > +#define SN65DSI_DSI_CFG0x10 > > +#define SN65DSI_DSI_CLK_EQ 0x11 > > +#define SN65DSI_DSI_CLK_RANGE 0x12 > > +#define SN65DSI_LVDS_MODE 0x18 > > +#define SN65DSI_CHA_LINE_LO0x20 > > +#define SN65DSI_CHA_LINE_HI0x21 > > +#define SN65DSI_CHA_VIRT_LO0x24 > > +#define SN65DSI_CHA_VIRT_HI0x25 > > +#define SN65DSI_CHA_SYNC_DELAY_LO 0x28 > > +#define SN65DSI_CHA_SYNC_DELAY_HI 0x29 > > +#define SN65DSI_CHA_HSYNC_WIDTH_LO 0x2c > > +#define SN65DSI_CHA_HSYNC_WIDTH_HI 0x2d > > +#define SN65DSI_CHA_VSYNC_WIDTH_LO 0x30 > > +#define SN65DSI_CHA_VSYNC_WIDTH_HI 0x31 > > +#define SN65DSI_CHA_HBACK_PORCH0x34 > > +#define SN65DSI_CHA_VBACK_PORCH
Re: [PATCH] video: fbdev: simplefb: Fix info message during probe
On Wed, Jan 20, 2021 at 12:16 PM Hans de Goede wrote: > > Hi, > > On 1/7/21 6:04 PM, Daniel Vetter wrote: > > Hi Hans, > > > > On Tue, Dec 29, 2020 at 02:02:30PM +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 12/28/20 7:39 PM, Peter Robinson wrote: > >>> The info message was showing the mapped address for the framebuffer. To > >>> avoid > >>> security problems, all virtual addresses are converted to __ptrval__, so > >>> the message has pointless information: > >>> > >>> simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, > >>> 0x12c000 bytes, mapped to 0x(ptrval) > >>> > >>> Drop the extraneous bits to clean up the message: > >>> > >>> simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, > >>> 0x12c000 bytes > >>> > >>> Signed-off-by: Peter Robinson > >> > >> Thanks, patch looks good to me: > >> > >> Reviewed-by: Hans de Goede > > > > Since you have commit rights for drm-misc I'm assuming you're also going > > to push this one? > > I knew there was some discussion about using drm-misc for drivers/video/fbdev > stuff > but I missed that it was decided to go ahead with that. > > Good to know that this is handled through drm-misc now. This is official since a while: commit 6a7553e8d84d5322d883cb83bb9888c49a0f04e0 Author: Bartlomiej Zolnierkiewicz Date: Fri Aug 9 15:46:40 2019 +0200 MAINTAINERS: handle fbdev changes through drm-misc tree Cheers, Daniel > > I've pushed this patch to drm-misc-next. > > Regards, > > Hans > > > > >>> --- > >>> drivers/video/fbdev/simplefb.c | 5 ++--- > >>> 1 file changed, 2 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/video/fbdev/simplefb.c > >>> b/drivers/video/fbdev/simplefb.c > >>> index 533a047d07a2..62f0ded70681 100644 > >>> --- a/drivers/video/fbdev/simplefb.c > >>> +++ b/drivers/video/fbdev/simplefb.c > >>> @@ -477,9 +477,8 @@ static int simplefb_probe(struct platform_device > >>> *pdev) > >>> simplefb_clocks_enable(par, pdev); > >>> simplefb_regulators_enable(par, pdev); > >>> > >>> - dev_info(>dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to > >>> 0x%p\n", > >>> -info->fix.smem_start, info->fix.smem_len, > >>> -info->screen_base); > >>> + dev_info(>dev, "framebuffer at 0x%lx, 0x%x bytes\n", > >>> +info->fix.smem_start, info->fix.smem_len); > >>> dev_info(>dev, "format=%s, mode=%dx%dx%d, linelength=%d\n", > >>> params.format->name, > >>> info->var.xres, info->var.yres, > >>> > >> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: bridge: Add SN65DSI84 DSI to LVDS bridge
SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from Texas Instruments. SN65DSI83, SN65DSI85 are variants of the same family of bridge controllers. Right now the bridge driver is supporting a single link, dual-link support requires to initiate I2C Channel B registers. Tested with STM32MP1 MIPI DSI host design configuration. Signed-off-by: Matteo Lisi Signed-off-by: Jagan Teki --- MAINTAINERS | 6 + drivers/gpu/drm/bridge/Kconfig| 19 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi84.c | 488 ++ 4 files changed, 514 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi84.c diff --git a/MAINTAINERS b/MAINTAINERS index 12dd1fff2a39..44750ff7640c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5984,6 +5984,12 @@ S: Maintained F: Documentation/devicetree/bindings/display/ti/ F: drivers/gpu/drm/omapdrm/ +DRM DRIVERS FOR TI SN65DSI84 DSI TO LVDS BRIDGE +M: Jagan Teki +S: Maintained +F: Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml +F: drivers/gpu/drm/bridge/ti-sn65dsi84.c + DRM DRIVERS FOR V3D M: Eric Anholt S: Supported diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..6494881bffb3 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -232,6 +232,25 @@ config DRM_TI_TFP410 help Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI84 + tristate "TI SN65DSI84 DSI to LVDS bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Texas Instruments SN65DSI84 Single Channel DSI to Dual-link LVDS + bridge driver. + + Bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and + converts the formatted video data stream to a FlatLink compatible + LVDS output operating at pixel clocks operating from 25 MHx to + 154 MHz. + + SN65DSI84 offers a Dual-Link LVDS, Single-Link LVDS interface with + four data lanes per link. + config DRM_TI_SN65DSI86 tristate "TI SN65DSI86 DSI to eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 86e7acc76f8d..3906052ef639 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_SN65DSI84) += ti-sn65dsi84.o obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi84.c b/drivers/gpu/drm/bridge/ti-sn65dsi84.c new file mode 100644 index ..3ed1f9a7d898 --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi84.c @@ -0,0 +1,488 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2021 Engicam srl + * Copyright (C) 2021 Amarula Solutions(India) + * Author: Jagan Teki + */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* sn65dsi84 registers */ +#define SN65DSI_SOFT_RESET 0x09 +#define SN65DSI_LVDS_CLK 0x0a +#define SN65DSI_CLK_DIV0x0b +#define SN65DSI_CLK_PLL0x0d +#define SN65DSI_DSI_CFG0x10 +#define SN65DSI_DSI_CLK_EQ 0x11 +#define SN65DSI_DSI_CLK_RANGE 0x12 +#define SN65DSI_LVDS_MODE 0x18 +#define SN65DSI_CHA_LINE_LO0x20 +#define SN65DSI_CHA_LINE_HI0x21 +#define SN65DSI_CHA_VIRT_LO0x24 +#define SN65DSI_CHA_VIRT_HI0x25 +#define SN65DSI_CHA_SYNC_DELAY_LO 0x28 +#define SN65DSI_CHA_SYNC_DELAY_HI 0x29 +#define SN65DSI_CHA_HSYNC_WIDTH_LO 0x2c +#define SN65DSI_CHA_HSYNC_WIDTH_HI 0x2d +#define SN65DSI_CHA_VSYNC_WIDTH_LO 0x30 +#define SN65DSI_CHA_VSYNC_WIDTH_HI 0x31 +#define SN65DSI_CHA_HBACK_PORCH0x34 +#define SN65DSI_CHA_VBACK_PORCH0x36 +#define SN65DSI_CHA_HFRONT_PORCH 0x38 +#define SN65DSI_CHA_VFRONT_PORCH 0x3a +#define SN65DSI_CHA_ERR0xe5 + +/* sn65dsi register bits */ +#define SN65DSI_RESET_EN BIT(0) +#define SN65DSI_PLL_EN BIT(0) +#define SN65DSI_LVDS_CLK_MASK GENMASK(3, 1) +#define SN65DSI_LVDS_CLK_SHIFT 1 +#define SN65DSI_LVDS_CLK_SRC_DSI BIT(0) +#define SN65DSI_CLK_DIV_MASK GENMASK(7, 3) +#define SN65DSI_CLK_DIV_SHIFT 3 +#define SN65DSI_DSI_LANE_MASK GENMASK(4, 3) +#define SN65DSI_DSI_LANE_SHIFT 3 +#define SN65DSI_LVDS_LINK_CFG
[PATCH 1/2] dt-bindings: display: bridge: Add documentation for SN65DSI84
SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from
Texas Instruments.
SN65DSI83, SN65DSI85 are variants of the same family of bridge
controllers.
Right now the bridge driver is supporting a single link, dual-link
support requires to initiate I2C Channel B registers, so dt-bindings
documented with single link LVDS.
Signed-off-by: Jagan Teki
---
.../bindings/display/bridge/ti,sn65dsi84.yaml | 127 ++
1 file changed, 127 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
new file mode 100644
index ..891382a76c1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi84.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI SN65DSI84 MIPI DSI to LVDS bridge bindings
+
+maintainers:
+ - Jagan Teki
+
+description: |
+ The SN65DSI84 DSI to FlatLink bridge features a single channel MIPI D-PHY
receiver
+ front-end configuration with 4 lanes per channel operating at 1 Gbps per
lanes.
+ The bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and
converts
+ the formatted video data stream to a FlatLink compatible LVDS output
operating
+ at pixel clocks operating from 25 MHx to 154 MHz, offering a Dual-Link LVDS,
+ Single-Link LVDS interface with four data lanes per link.
+
+ https://www.ti.com/product/SN65DSI84
+
+properties:
+ compatible:
+const: ti,sn65dsi84
+
+ reg:
+maxItems: 1
+description: i2c address of the bridge, 0x2c
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge enable pin (active high).
+
+ ports:
+type: object
+description:
+ A node containing input and output port nodes with endpoint definitions
+ as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ DSI Input. The remote endpoint phandle should be a
+ reference to a valid mipi_dsi_host device node.
+
+ port@1:
+type: object
+description: |
+ Video port for LVDS output (panel or connector).
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi_in: endpoint {
+ remote-endpoint = <_ep0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi_out: endpoint {
+ remote-endpoint = <_in>;
+ data-lanes = <0 1>;
+ };
+ };
+ };
+};
+
+i2c6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2c {
+ compatible = "ti,sn65dsi84";
+ reg = <0x2c>;
+ enable-gpios = < 15 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ bridge_in: endpoint {
+remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ bridge_out: endpoint {
+remote-endpoint = <_in_lvds>;
+ };
+ };
+ };
+ };
+};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: simplefb: Fix info message during probe
Hi, On 1/7/21 6:04 PM, Daniel Vetter wrote: > Hi Hans, > > On Tue, Dec 29, 2020 at 02:02:30PM +0100, Hans de Goede wrote: >> Hi, >> >> On 12/28/20 7:39 PM, Peter Robinson wrote: >>> The info message was showing the mapped address for the framebuffer. To >>> avoid >>> security problems, all virtual addresses are converted to __ptrval__, so >>> the message has pointless information: >>> >>> simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, >>> 0x12c000 bytes, mapped to 0x(ptrval) >>> >>> Drop the extraneous bits to clean up the message: >>> >>> simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, >>> 0x12c000 bytes >>> >>> Signed-off-by: Peter Robinson >> >> Thanks, patch looks good to me: >> >> Reviewed-by: Hans de Goede > > Since you have commit rights for drm-misc I'm assuming you're also going > to push this one? I knew there was some discussion about using drm-misc for drivers/video/fbdev stuff but I missed that it was decided to go ahead with that. Good to know that this is handled through drm-misc now. I've pushed this patch to drm-misc-next. Regards, Hans >>> --- >>> drivers/video/fbdev/simplefb.c | 5 ++--- >>> 1 file changed, 2 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c >>> index 533a047d07a2..62f0ded70681 100644 >>> --- a/drivers/video/fbdev/simplefb.c >>> +++ b/drivers/video/fbdev/simplefb.c >>> @@ -477,9 +477,8 @@ static int simplefb_probe(struct platform_device *pdev) >>> simplefb_clocks_enable(par, pdev); >>> simplefb_regulators_enable(par, pdev); >>> >>> - dev_info(>dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to >>> 0x%p\n", >>> -info->fix.smem_start, info->fix.smem_len, >>> -info->screen_base); >>> + dev_info(>dev, "framebuffer at 0x%lx, 0x%x bytes\n", >>> +info->fix.smem_start, info->fix.smem_len); >>> dev_info(>dev, "format=%s, mode=%dx%dx%d, linelength=%d\n", >>> params.format->name, >>> info->var.xres, info->var.yres, >>> >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/qxl: use drmm_mode_config_init
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 012bce0cdb65..38d6b596094d 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1195,7 +1195,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
int i;
int ret;
- drm_mode_config_init(>ddev);
+ ret = drmm_mode_config_init(>ddev);
+ if (ret)
+ return ret;
ret = qxl_create_monitors_object(qdev);
if (ret)
@@ -1228,5 +1230,4 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
qxl_destroy_monitors_object(qdev);
- drm_mode_config_cleanup(>ddev);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/qxl: release shadow on shutdown
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b596094d..60331e31861a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1229,5 +1229,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
+ if (qdev->dumb_shadow_bo) {
+ drm_gem_object_put(>dumb_shadow_bo->tbo.base);
+ qdev->dumb_shadow_bo = NULL;
+ }
qxl_destroy_monitors_object(qdev);
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] drm/qxl: handle shadow in primary destroy
qxl_primary_atomic_disable must check whenever the framebuffer bo has a
shadow surface and in case it has check the shadow primary status.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 60331e31861a..f5ee8cd72b5b 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -562,6 +562,8 @@ static void qxl_primary_atomic_disable(struct drm_plane
*plane,
if (old_state->fb) {
struct qxl_bo *bo = gem_to_qxl_bo(old_state->fb->obj[0]);
+ if (bo->shadow)
+ bo = bo->shadow;
if (bo->is_primary) {
qxl_io_destroy_primary(qdev);
bo->is_primary = false;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] drm/qxl: fix some driver shutdown issues.
Some progress. Not complete though, I still get an unclean mm warning on shutdown due to some release objects not being freed yet. Gerd Hoffmann (4): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/qxl: handle shadow in primary destroy drivers/gpu/drm/qxl/qxl_display.c | 11 +-- drivers/gpu/drm/qxl/qxl_release.c | 1 + 2 files changed, 10 insertions(+), 2 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/qxl: unpin release objects
Balances the qxl_create_bo(..., pinned=true, ...); call in qxl_release_bo_alloc(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c index 0fcfc952d5e9..add979cba11b 100644 --- a/drivers/gpu/drm/qxl/qxl_release.c +++ b/drivers/gpu/drm/qxl/qxl_release.c @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release) entry = container_of(release->bos.next, struct qxl_bo_list, tv.head); bo = to_qxl_bo(entry->tv.bo); + bo->tbo.pin_count = 0; /* ttm_bo_unpin(>tbo); */ qxl_bo_unref(); list_del(>tv.head); kfree(entry); -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: fix build after dp quirk helper change
Commit 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based
quirks"") removed drm_dp_get_edid_quirks() and changed the signature of
drm_dp_has_quirk() while they were still being used in msm. Fix the
breakage. Functionally, removing the EDID-based quirks has no impact on
msm.
[The above commit was merged to drm-intel-next; make two wrongs a right
by merging this fix through drm-intel-next as well.]
Reported-by: Stephen Rothwell
References: http://lore.kernel.org/r/20210120105715.4391d...@canb.auug.org.au
Fixes: 7c553f8b5a7d ("drm/dp: Revert "drm/dp: Introduce EDID-based quirks"")
Cc: Lyude Paul
Acked-by: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
Note: I admit to not even build testing this one. I'd need a config,
possibly also a toolchain setup for that.
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index e3462f5d96d7..36b39c381b3f 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1420,16 +1420,14 @@ void dp_ctrl_host_deinit(struct dp_ctrl *dp_ctrl)
static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
{
u8 *dpcd = ctrl->panel->dpcd;
- u32 edid_quirks = 0;
- edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
/*
* For better interop experience, used a fixed NVID=0x8000
* whenever connected to a VGA dongle downstream.
*/
if (drm_dp_is_branch(dpcd))
- return (drm_dp_has_quirk(>panel->desc, edid_quirks,
- DP_DPCD_QUIRK_CONSTANT_N));
+ return (drm_dp_has_quirk(>panel->desc,
+DP_DPCD_QUIRK_CONSTANT_N));
return false;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/syncobj: Fix use-after-free
On Tue, Jan 19, 2021 at 02:08:12PM +0100, Christian König wrote:
> Am 19.01.21 um 14:03 schrieb Daniel Vetter:
> > While reviewing Christian's annotation patch I noticed that we have a
> > user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
> > reference before we've completed the waiting.
> >
> > Of course usually there's nothing bad happening here since userspace
> > keeps the reference, but we can't rely on userspace to play nice here!
> >
> > Signed-off-by: Daniel Vetter
> > Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in
> > drm_syncobj_find_fence v4")
> > Cc: Christian König
> > Cc: Lionel Landwerlin
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: # v5.2+
>
> Reviewed-by: Christian König
Pushed to drm-misc-fixes, thanks for reviewing.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 6e74e6745eca..349146049849 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -388,19 +388,18 @@ int drm_syncobj_find_fence(struct drm_file
> > *file_private,
> > return -ENOENT;
> > *fence = drm_syncobj_fence_get(syncobj);
> > - drm_syncobj_put(syncobj);
> > if (*fence) {
> > ret = dma_fence_chain_find_seqno(fence, point);
> > if (!ret)
> > - return 0;
> > + goto out;
> > dma_fence_put(*fence);
> > } else {
> > ret = -EINVAL;
> > }
> > if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
> > - return ret;
> > + goto out;
> > memset(, 0, sizeof(wait));
> > wait.task = current;
> > @@ -432,6 +431,9 @@ int drm_syncobj_find_fence(struct drm_file
> > *file_private,
> > if (wait.node.next)
> > drm_syncobj_remove_wait(syncobj, );
> > +out:
> > + drm_syncobj_put(syncobj);
> > +
> > return ret;
> > }
> > EXPORT_SYMBOL(drm_syncobj_find_fence);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi Liu Ying, On Wed, Jan 20, 2021 at 04:42:50PM +0800, Liu Ying wrote: > Hi Laurentiu, > > On Fri, 2021-01-15 at 19:27 +0200, Laurentiu Palcu wrote: > > Hi Liu Ying, > > > > I promised I would have a second, more in-depth, look at this and I finally > > managed to do it. > > Thanks. > > > > > I have to admit it was a challenge. Partially because I'm not very familiar > > with DPU but mostly because of the abundance of macros used. It's true, > > macros > > make the code more compact. However they made the entire code hard to read, > > as neither ctags nor cscope were able to cross-reference it properly, and I > > fear it will be even harder to maintain in the long run... :/ For example, > > trying to figure out where dpu_*_hw_init() functions were called from was no > > easy task. Or dpu_*_put(). Or dpu_*_get(). :/ > > > > Also, most of the macros are not in-line with Linux Kernel coding > > style when it comes to macro usage: they affect control flow and some depend > > on other local variables being already defined. > > > > The good news is most macros can be replaced with helper functions and it > > would > > not add too much extra code. > > Ok, I'll remove macros where possible. > > > > > More comments below. > > Please find feedbacks below. > > > > > On Fri, Dec 18, 2020 at 11:23:52AM +0800, Liu Ying wrote: > > > This patch introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM > > > support. > > > > > > DPU is comprised of two main components that include a blit engine for > > > 2D graphics accelerations(with composition support) and a display > > > controller > > > for display output processing, as well as a command sequencer. Outside of > > > DPU, optional prefetch engines, a.k.a, Prefetch Resolve Gasket(PRG) and > > > Display Prefetch Resolve(DPR), can fetch data from memory prior to some > > > DPU > > > fetchunits of blit engine and display controller. The prefetch engines > > > support reading linear formats and resolving Vivante GPU tile formats. > > > > > > This patch adds kernel modesetting support for the display controller > > > part. > > > The driver supports two CRTCs per display controller, planes backed by > > > four fetchunits(decode0/1, fetchlayer, fetchwarp), fetchunit allocation > > > logic for the two CRTCs, prefetch engines(with tile resolving supported), > > > plane upscaling/deinterlacing/yuv2rgb CSC/alpha blending and CRTC gamma > > > correction. The registers of the controller is accessed without command > > > sequencer involved, instead just by using CPU. > > > > > > Reference manual can be found at: > > > https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM > > > > > > Signed-off-by: Liu Ying > > > --- > > > v4->v5: > > > * Rebase up onto the latest drm-misc-next branch and remove the hook to > > > drm_atomic_helper_legacy_gamma_set(), because it was dropped by the > > > newly > > > landed commit 'drm: automatic legacy gamma support'. > > > * Remove a redundant blank line from dpu_plane_atomic_update(). > > > > > > v3->v4: > > > * No change. > > > > > > v2->v3: > > > * Fix build warnings Reported-by: kernel test robot . > > > * Drop build dependency on IMX_SCU, as dummy SCU functions have been > > > added in > > > header files by the patch 'firmware: imx: add dummy functions' which has > > > landed in linux-next/master branch. > > > > > > v1->v2: > > > * Add compatible for i.MX8qm DPU, as this is tested with i.MX8qm LVDS > > > displays. > > > (Laurentiu) > > > * Fix PRG burst size and stride. (Laurentiu) > > > * Put 'ports' OF node to fix the bail-out logic in dpu_drm_probe(). > > > (Laurentiu) > > > > > > drivers/gpu/drm/imx/Kconfig | 1 + > > > drivers/gpu/drm/imx/Makefile | 1 + > > > drivers/gpu/drm/imx/dpu/Kconfig | 10 + > > > drivers/gpu/drm/imx/dpu/Makefile | 10 + > > > drivers/gpu/drm/imx/dpu/dpu-constframe.c | 170 ++ > > > drivers/gpu/drm/imx/dpu/dpu-core.c| 881 > > > > > > drivers/gpu/drm/imx/dpu/dpu-crtc.c| 925 > > > ++ > > > drivers/gpu/drm/imx/dpu/dpu-crtc.h| 62 ++ > > > drivers/gpu/drm/imx/dpu/dpu-disengcfg.c | 114 > > > drivers/gpu/drm/imx/dpu/dpu-dprc.c| 721 +++ > > > drivers/gpu/drm/imx/dpu/dpu-dprc.h| 40 ++ > > > drivers/gpu/drm/imx/dpu/dpu-drv.c | 297 ++ > > > drivers/gpu/drm/imx/dpu/dpu-drv.h | 28 + > > > drivers/gpu/drm/imx/dpu/dpu-extdst.c | 296 ++ > > > drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c | 291 ++ > > > drivers/gpu/drm/imx/dpu/dpu-fetcheco.c| 221 +++ > > > drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c | 151 + > > > drivers/gpu/drm/imx/dpu/dpu-fetchunit.c | 609 > > > drivers/gpu/drm/imx/dpu/dpu-fetchunit.h | 191 ++ > > > drivers/gpu/drm/imx/dpu/dpu-fetchwarp.c | 247 > > > drivers/gpu/drm/imx/dpu/dpu-framegen.c| 392
[PATCH][next] drm/amd/display: Fix spelling mistake of function name
From: Colin Ian King
There are two spelling mistakes of the function name, fix this
by using __func__ instead of a hard coded name string.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index c16af3983fdb..91d4130cd2cb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1602,7 +1602,7 @@ static bool dc_link_construct(struct dc_link *link,
link->psr_settings.psr_version = DC_PSR_VERSION_UNSUPPORTED;
- DC_LOG_DC("BIOS object table - dc_link_contruct finished
successfully.\n");
+ DC_LOG_DC("BIOS object table - %s finished successfully.\n", __func__);
return true;
device_tag_fail:
link->link_enc->funcs->destroy(>link_enc);
@@ -1619,7 +1619,7 @@ static bool dc_link_construct(struct dc_link *link,
link->hpd_gpio = NULL;
}
- DC_LOG_DC("BIOS object table - dc_link_contruct failed.\n");
+ DC_LOG_DC("BIOS object table - %s failed.\n", __func__);
kfree(info);
return false;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
On Wed, Jan 20, 2021 at 03:48:28PM +0800, Chenyang Li wrote:
> This patch adds an initial DRM driver for the Loongson LS7A1000
> bridge chip(LS7A). The LS7A bridge chip contains two display
> controllers, support dual display output. The maximum support for
> each channel display is to 1920x1080@60Hz.
> At present, DC device detection and DRM driver registration are
> completed, the crtc/plane/encoder/connector objects has been
> implemented.
> On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use
> of dual screen, and support dual screen clone mode and expansion
> mode.
>
> v3:
> - Move the mode_valid function to the connector and optimize it.
I checked and in v2 it was on the crtc, which I think is the right place
for this. See the kerneldoc for the connector mode_valid function for why
this is usually not the right hook.
-Daniel
> - Fix num_crtc calculation method.
>
> v2:
> - Complete the case of 32-bit color in CRTC.
>
> Signed-off-by: Chenyang Li
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/loongson/Kconfig | 14 +
> drivers/gpu/drm/loongson/Makefile | 14 +
> drivers/gpu/drm/loongson/loongson_connector.c | 65 +
> drivers/gpu/drm/loongson/loongson_crtc.c | 227 +++
> drivers/gpu/drm/loongson/loongson_device.c| 54
> drivers/gpu/drm/loongson/loongson_drv.c | 269 ++
> drivers/gpu/drm/loongson/loongson_drv.h | 133 +
> drivers/gpu/drm/loongson/loongson_encoder.c | 37 +++
> drivers/gpu/drm/loongson/loongson_plane.c | 102 +++
> 11 files changed, 918 insertions(+)
> create mode 100644 drivers/gpu/drm/loongson/Kconfig
> create mode 100644 drivers/gpu/drm/loongson/Makefile
> create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_device.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h
> create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c
> create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 0973f408d75f..6ed1b6dc2f25 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -374,6 +374,8 @@ source "drivers/gpu/drm/xen/Kconfig"
>
> source "drivers/gpu/drm/vboxvideo/Kconfig"
>
> +source "drivers/gpu/drm/loongson/Kconfig"
> +
> source "drivers/gpu/drm/lima/Kconfig"
>
> source "drivers/gpu/drm/panfrost/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index fefaff4c832d..f87da730ea6d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/
> obj-$(CONFIG_DRM_TVE200) += tve200/
> obj-$(CONFIG_DRM_XEN) += xen/
> obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
> +obj-$(CONFIG_DRM_LOONGSON) += loongson/
> obj-$(CONFIG_DRM_LIMA) += lima/
> obj-$(CONFIG_DRM_PANFROST) += panfrost/
> obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> diff --git a/drivers/gpu/drm/loongson/Kconfig
> b/drivers/gpu/drm/loongson/Kconfig
> new file mode 100644
> index ..43eb0c80cc12
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config DRM_LOONGSON
> + tristate "DRM support for LS7A1000 bridge chipset"
> + depends on DRM && PCI
> + depends on CPU_LOONGSON64
> + select DRM_KMS_HELPER
> + select DRM_VRAM_HELPER
> + select DRM_TTM
> + select DRM_TTM_HELPER
> + default n
> + help
> + Support the display controllers found on the Loongson LS7A1000
> + bridge.
> diff --git a/drivers/gpu/drm/loongson/Makefile
> b/drivers/gpu/drm/loongson/Makefile
> new file mode 100644
> index ..22d063953b78
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Makefile for loongson drm drivers.
> +# This driver provides support for the
> +# Direct Rendering Infrastructure (DRI)
> +
> +ccflags-y := -Iinclude/drm
> +loongson-y := loongson_drv.o \
> + loongson_crtc.o \
> + loongson_plane.o \
> + loongson_device.o \
> + loongson_connector.o \
> + loongson_encoder.o
> +obj-$(CONFIG_DRM_LOONGSON) += loongson.o
> diff --git a/drivers/gpu/drm/loongson/loongson_connector.c
> b/drivers/gpu/drm/loongson/loongson_connector.c
> new file mode 100644
> index ..8cffabb62ebb
> --- /dev/null
> +++ b/drivers/gpu/drm/loongson/loongson_connector.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "loongson_drv.h"
> +
> +static int loongson_get_modes(struct drm_connector *connector)
> +{
> + int count;
> +
> + count = drm_add_modes_noedid(connector,
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > >
> > > On the success of virtio_gpu_object_create, add size of newly allocated
> > > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> > > bo lost its last refcount, subtract the bo size from the tracked
> > > total_mem if the original underlying memory allocation is successful.
> > >
> > > Signed-off-by: Yiwei Zhang
> >
> > Isn't this something that ideally we'd for everyone? Also tracepoint
> > for showing the total feels like tracepoint abuse, usually we show
> > totals somewhere in debugfs or similar, and tracepoint just for what's
> > happening (i.e. which object got deleted/created).
> >
> > What is this for exactly?
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/virtio/Kconfig | 1 +
> > > drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> > > drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> > > 3 files changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/virtio/Kconfig
> > > b/drivers/gpu/drm/virtio/Kconfig
> > > index b925b8b1da16..e103b7e883b1 100644
> > > --- a/drivers/gpu/drm/virtio/Kconfig
> > > +++ b/drivers/gpu/drm/virtio/Kconfig
> > > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > > select DRM_KMS_HELPER
> > > select DRM_GEM_SHMEM_HELPER
> > > select VIRTIO_DMA_SHARED_BUFFER
> > > + select TRACE_GPU_MEM
> > > help
> > >This is the virtual GPU driver for virtio. It can be used with
> > >QEMU based VMMs (like KVM or Xen).
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > index 6a232553c99b..7c60e7486bc4 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > > @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> > > spinlock_t resource_export_lock;
> > > /* protects map state and host_visible_mm */
> > > spinlock_t host_visible_lock;
> > > +
> > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > + atomic64_t total_mem;
> > > +#endif
> > > };
> > >
> > > struct virtio_gpu_fpriv {
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > index d69a5b6da553..1e16226cebbe 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > > @@ -25,12 +25,29 @@
> > >
> > > #include
> > > #include
> > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > +#include
> > > +#endif
> > >
> > > #include "virtgpu_drv.h"
> > >
> > > static int virtio_gpu_virglrenderer_workaround = 1;
> > > module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> > > 0400);
> > >
> > > +#ifdef CONFIG_TRACE_GPU_MEM
> > > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > > *vgdev,
> > > + s64 delta)
> > > +{
> > > + u64 total_mem = atomic64_add_return(delta, >total_mem);
> > > +
> > > + trace_gpu_mem_total(0, 0, total_mem);
> > > +}
> > > +#else
> > > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> > > *, s64)
> > > +{
> > > +}
> > > +#endif
> > > +
> > > int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
> > > *resid)
> > > {
> > > if (virtio_gpu_virglrenderer_workaround) {
> > > @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct
> > > drm_gem_object *obj)
> > > struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
> > >
> > > if (bo->created) {
> > > + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> > > virtio_gpu_cmd_unref_resource(vgdev, bo);
> > > virtio_gpu_notify(vgdev);
> > > /* completion handler calls virtio_gpu_cleanup_object() */
> > > @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> > > *vgdev,
> > > virtio_gpu_object_attach(vgdev, bo, ents, nents);
> > > }
> > >
> > > + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> > > *bo_ptr = bo;
> > > return 0;
> > >
> > > --
> > > 2.30.0.284.gd98b1dd5eaa7-goog
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> Thanks for your reply! Android Cuttlefish virtual platform is using
> the virtio-gpu driver, and we currently are carrying this small patch
> at the downstream side. This is essential for us because:
> (1) Android has deprecated debugfs on production devices already
> (2) Android GPU drivers are not DRM based, and this won't change in a
> short term.
>
> Android relies on this tracepoint + eBPF to make the GPU memory totals
> available at runtime on production devices, which has been enforced
> already. Not only game developers can
Re: [PATCH v4 00/14] RFC Support hot device unplug in amdgpu
On Tue, Jan 19, 2021 at 01:18:15PM -0500, Andrey Grodzovsky wrote: > > On 1/19/21 1:08 PM, Daniel Vetter wrote: > > On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky > > wrote: > > > > > > On 1/19/21 9:16 AM, Daniel Vetter wrote: > > > > On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote: > > > > > Until now extracting a card either by physical extraction (e.g. eGPU > > > > > with > > > > > thunderbolt connection or by emulation through syfs -> > > > > > /sys/bus/pci/devices/device_id/remove) > > > > > would cause random crashes in user apps. The random crashes in apps > > > > > were > > > > > mostly due to the app having mapped a device backed BO into its > > > > > address > > > > > space was still trying to access the BO while the backing device was > > > > > gone. > > > > > To answer this first problem Christian suggested to fix the handling > > > > > of mapped > > > > > memory in the clients when the device goes away by forcibly unmap all > > > > > buffers the > > > > > user processes has by clearing their respective VMAs mapping the > > > > > device BOs. > > > > > Then when the VMAs try to fill in the page tables again we check in > > > > > the fault > > > > > handlerif the device is removed and if so, return an error. This will > > > > > generate a > > > > > SIGBUS to the application which can then cleanly terminate.This > > > > > indeed was done > > > > > but this in turn created a problem of kernel OOPs were the OOPSes > > > > > were due to the > > > > > fact that while the app was terminating because of the SIGBUSit would > > > > > trigger use > > > > > after free in the driver by calling to accesses device structures > > > > > that were already > > > > > released from the pci remove sequence.This was handled by introducing > > > > > a 'flush' > > > > > sequence during device removal were we wait for drm file reference to > > > > > drop to 0 > > > > > meaning all user clients directly using this device terminated. > > > > > > > > > > v2: > > > > > Based on discussions in the mailing list with Daniel and Pekka [1] > > > > > and based on the document > > > > > produced by Pekka from those discussions [2] the whole approach with > > > > > returning SIGBUS and > > > > > waiting for all user clients having CPU mapping of device BOs to die > > > > > was dropped. > > > > > Instead as per the document suggestion the device structures are kept > > > > > alive until > > > > > the last reference to the device is dropped by user client and in the > > > > > meanwhile all existing and new CPU mappings of the BOs > > > > > belonging to the device directly or by dma-buf import are rerouted to > > > > > per user > > > > > process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' > > > > > section of [2] > > > > > since i am trying to get the minimal set of requirements that still > > > > > give useful solution > > > > > to work and this is the'Requirements for Render and Cross-Device > > > > > UAPI' section and so my > > > > > test case is removing a secondary device, which is render only and is > > > > > not involved > > > > > in KMS. > > > > > > > > > > v3: > > > > > More updates following comments from v2 such as removing loop to find > > > > > DRM file when rerouting > > > > > page faults to dummy page,getting rid of unnecessary sysfs handling > > > > > refactoring and moving > > > > > prevention of GPU recovery post device unplug from amdgpu to > > > > > scheduler layer. > > > > > On top of that added unplug support for the IOMMU enabled system. > > > > > > > > > > v4: > > > > > Drop last sysfs hack and use sysfs default attribute. > > > > > Guard against write accesses after device removal to avoid modifying > > > > > released memory. > > > > > Update dummy pages handling to on demand allocation and release > > > > > through drm managed framework. > > > > > Add return value to scheduler job TO handler (by Luben Tuikov) and > > > > > use this in amdgpu for prevention > > > > > of GPU recovery post device unplug > > > > > Also rebase on top of drm-misc-mext instead of amd-staging-drm-next > > > > > > > > > > With these patches I am able to gracefully remove the secondary card > > > > > using sysfs remove hook while glxgears > > > > > is running off of secondary card (DRI_PRIME=1) without kernel oopses > > > > > or hangs and keep working > > > > > with the primary card or soft reset the device without hangs or oopses > > > > > > > > > > TODOs for followup work: > > > > > Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff > > > > > and allocations) (Daniel) > > > > > Support plugging the secondary device back after unplug - currently > > > > > still experiencing HW error on plugging back. > > > > > Add support for 'Requirements for KMS UAPI' section of [2] - > > > > > unplugging primary, display connected card. > > > > > > > > > > [1] - Discussions during v3 of the patchset > > > > >
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting
On Tue, Jan 12, 2021 at 4:59 PM Xin Ji wrote:
>
> Hi Rob Herring, thanks for the comments.
>
> On Mon, Jan 11, 2021 at 04:14:35PM -0600, Rob Herring wrote:
> > On Thu, Dec 31, 2020 at 10:21:12AM +0800, Xin Ji wrote:
> > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> > > swing setting for adjusting DP tx PHY swing
> > >
> > > Signed-off-by: Xin Ji
> > > ---
> > > .../bindings/display/bridge/analogix,anx7625.yaml | 25
> > > --
> > > 1 file changed, 23 insertions(+), 2 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index 60585a4..4eb0ea3 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -34,6 +34,16 @@ properties:
> > > description: used for reset chip control, RESET_N pin B7.
> > > maxItems: 1
> > >
> > > + analogix,swing-setting:
> > > +type: uint8-array
> >
> > Humm, this should have be rejected by the meta-schema.
> We needs define an array to adjust DP tx PHY swing, the developer hopes these
> settings are changeable, so I moved the register data to DT. Can you
> give me some suggestion if it is rejected by the meta-schema?
> >
> > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> >
> > This is how types are defined other than boolean or nodes (object).
> >
> > > +description: an array of swing register setting for DP tx PHY
> > > +
> > > + analogix,mipi-dpi-in:
> > > +type: int
> > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > +description: indicate the MIPI rx signal type is DPI or DSI
> >
> > Why does this need to be in DT, you should be able to determine this
> > based on what you are connected to.
> As the anx7625 can receive MIPI DSI and DPI data (depends on hardware
> implement, we have a project which have two anx7625, one is DSI input,
> the other is DPI input), we needs to let driver know what kind of MIPI
> rx signal input. And there is no other way to tell driver the MIPI rx
> signal type, we needs define this flag.
> >
> > > +
> > >ports:
> > > type: object
> > >
> > > @@ -49,8 +59,8 @@ properties:
> > >Video port for panel or connector.
> > >
> > > required:
> > > -- port@0
> > > -- port@1
> > > + - port@0
> > > + - port@1
> > >
> > > required:
> > >- compatible
> > > @@ -72,6 +82,17 @@ examples:
> > > reg = <0x58>;
> > > enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> > > reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> > > +analogix,swing-setting = <0x00 0x14>, <0x01 0x54>,
> > > +<0x02 0x64>, <0x03 0x74>, <0x04 0x29>,
> > > +<0x05 0x7b>, <0x06 0x77>, <0x07 0x5b>,
> > > +<0x08 0x7f>, <0x0c 0x20>, <0x0d 0x60>,
> > > +<0x10 0x60>, <0x12 0x40>, <0x13 0x60>,
> > > +<0x14 0x14>, <0x15 0x54>, <0x16 0x64>,
> > > +<0x17 0x74>, <0x18 0x29>, <0x19 0x7b>,
> > > +<0x1a 0x77>, <0x1b 0x5b>, <0x1c 0x7f>,
> > > +<0x20 0x20>, <0x21 0x60>, <0x24 0x60>,
> > > +<0x26 0x40>, <0x27 0x60>;
> >
> > This is a matrix, which is different from an array type.
> OK, I'll change to array if this vendor define has been accepted.
I also wonder if we want to split the parameters per lane, and simply
have a flat array (instead of reg/value pairs like you have now).
Registers 0x00 to 0x13 have to do with Lane 0 (and 0x14 to 0x27 with
Lane 1): you can almost tell from the example values, they repeat. I'm
not sure if there's any value splitting those further (I don't think
anybody will be able to tune those without ANX's help).
So, maybe something like:
anx,swing-setting = <<[reg values for lane 0]>, <[reg values for lane 1]>>
where <[reg values for lane 0]> would be something like <0x14, 0x54,
0x64, ...> (that is, all the values between 0x00 and 0x13).
> >
> > > +analogix,mipi-dpi-in = <0>;
> > >
> > > ports {
> > > #address-cells = <1>;
> > > --
> > > 2.7.4
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 07/14] drm/amdgpu: Register IOMMU topology notifier per device.
On Wed, Jan 20, 2021 at 5:21 AM Andrey Grodzovsky
wrote:
>
>
> On 1/19/21 5:01 PM, Daniel Vetter wrote:
> > On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
> > wrote:
> >>
> >> On 1/19/21 8:45 AM, Daniel Vetter wrote:
> >>
> >> On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
> >>
> >> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
> >>
> >> Handle all DMA IOMMU gropup related dependencies before the
> >> group is removed.
> >>
> >> Signed-off-by: Andrey Grodzovsky
> >> ---
> >>drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5
> >>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 46
> >> ++
> >>drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +-
> >>drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 +
> >>drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++
> >>drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 ++
> >>6 files changed, 65 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> index 478a7d8..2953420 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> @@ -51,6 +51,7 @@
> >>#include
> >>#include
> >>#include
> >> +#include
> >>#include
> >>#include
> >> @@ -1041,6 +1042,10 @@ struct amdgpu_device {
> >>boolin_pci_err_recovery;
> >>struct pci_saved_state *pci_state;
> >> +
> >> + struct notifier_block nb;
> >> + struct blocking_notifier_head notifier;
> >> + struct list_head device_bo_list;
> >>};
> >>static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> index 45e23e3..e99f4f1 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> @@ -70,6 +70,8 @@
> >>#include
> >>#include
> >> +#include
> >> +
> >>MODULE_FIRMWARE("amdgpu/vega10_gpu_info.bin");
> >>MODULE_FIRMWARE("amdgpu/vega12_gpu_info.bin");
> >>MODULE_FIRMWARE("amdgpu/raven_gpu_info.bin");
> >> @@ -3200,6 +3202,39 @@ static const struct attribute
> >> *amdgpu_dev_attributes[] = {
> >>};
> >> +static int amdgpu_iommu_group_notifier(struct notifier_block *nb,
> >> + unsigned long action, void *data)
> >> +{
> >> + struct amdgpu_device *adev = container_of(nb, struct amdgpu_device, nb);
> >> + struct amdgpu_bo *bo = NULL;
> >> +
> >> + /*
> >> + * Following is a set of IOMMU group dependencies taken care of before
> >> + * device's IOMMU group is removed
> >> + */
> >> + if (action == IOMMU_GROUP_NOTIFY_DEL_DEVICE) {
> >> +
> >> + spin_lock(_bo_glob.lru_lock);
> >> + list_for_each_entry(bo, >device_bo_list, bo) {
> >> + if (bo->tbo.ttm)
> >> + ttm_tt_unpopulate(bo->tbo.bdev, bo->tbo.ttm);
> >> + }
> >> + spin_unlock(_bo_glob.lru_lock);
> >>
> >> That approach won't work. ttm_tt_unpopulate() might sleep on an IOMMU lock.
> >>
> >> You need to use a mutex here or even better make sure you can access the
> >> device_bo_list without a lock in this moment.
> >>
> >> I'd also be worried about the notifier mutex getting really badly in the
> >> way.
> >>
> >> Plus I'm worried why we even need this, it sounds a bit like papering over
> >> the iommu subsystem. Assuming we clean up all our iommu mappings in our
> >> device hotunplug/unload code, why do we still need to have an additional
> >> iommu notifier on top, with all kinds of additional headaches? The iommu
> >> shouldn't clean up before the devices in its group have cleaned up.
> >>
> >> I think we need more info here on what the exact problem is first.
> >> -Daniel
> >>
> >>
> >> Originally I experienced the crash bellow on IOMMU enabled device, it
> >> happens post device removal from PCI topology -
> >> during shutting down of user client holding last reference to drm device
> >> file (X in my case).
> >> The crash is because by the time I get to this point struct
> >> device->iommu_group pointer is NULL
> >> already since the IOMMU group for the device is unset during PCI removal.
> >> So this contradicts what you said above
> >> that the iommu shouldn't clean up before the devices in its group have
> >> cleaned up.
> >> So instead of guessing when is the right place to place all IOMMU related
> >> cleanups it makes sense
> >> to get notification from IOMMU subsystem in the form of event
> >> IOMMU_GROUP_NOTIFY_DEL_DEVICE
> >> and use that place to do all the relevant cleanups.
> > Yeah that goes boom, but you shouldn't need this special iommu cleanup
> > handler. Making sure that all the dma-api mappings are gone needs to
> > be done as part of the device hotunplug, you can't delay that to the
> > last drm_device cleanup.
> >
> > So I most of the patch here with pulling that out (should be outright
> > removed from the final release code even) is good, just not yet how
Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"
On Tue, 5 Jan 2021 at 17:23, Alex Deucher wrote: > > On Tue, Jan 5, 2021 at 8:05 AM Will Deacon wrote: > > > > On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote: > > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > > > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher > > > > > wrote: > > > > > > > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel > > > > > > wrote: > > > > > > > > > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > > > > > > > > > > > > > Simply disabling -mgeneral-regs-only left and right is risky, > > > > > > > given that > > > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers > > > > > > > anywhere, > > > > > > > and GCC is known to use SIMD registers for spilling, and may > > > > > > > invent > > > > > > > other uses of the FP/SIMD register file that have nothing to do > > > > > > > with the > > > > > > > floating point code in question. Note that putting > > > > > > > kernel_neon_begin() > > > > > > > and kernel_neon_end() around the code that does use FP is not > > > > > > > sufficient > > > > > > > here, the problem is in all the other code that may be emitted > > > > > > > with > > > > > > > references to SIMD registers in it. > > > > > > > > > > > > > > So the only way to do this properly is to put all floating point > > > > > > > code in > > > > > > > a separate compilation unit, and only compile that unit with > > > > > > > -mgeneral-regs-only. But perhaps the use of floating point here is > > > > > > > something that should be reconsidered entirely. > > > > > > > > > > > > > > Cc: Catalin Marinas > > > > > > > Cc: Will Deacon > > > > > > > Cc: Dave Martin > > > > > > > Cc: Rob Herring > > > > > > > Cc: Leo Li > > > > > > > Cc: Alex Deucher > > > > > > > Cc: "Christian König" > > > > > > > Cc: David Airlie > > > > > > > Cc: Daniel Vetter > > > > > > > Cc: Daniel Kolesa > > > > > > > Cc: amd-...@lists.freedesktop.org > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > > > > > Can rebase this on Linus' master branch? There were a number of new > > > > > > asics added which copy pasted the ARM64 support. > > > > > > > > > > > > > > > > Not sure what you are asking me here. Reverting commit c38d444e44badc5 > > > > > on top of mainline is not going to fix the other code that was added. > > > > > Or are you asking me to go and find the patches (how many?) that added > > > > > new ASICs and fix them for arm64? > > > > > > > > > > Note that this code is critically broken, as it may corrupt user > > > > > process state arbitrarily. So if new code was added that contains the > > > > > same bug, it should be reverted so that the respective authors can fix > > > > > it and resubmit. > > > > > > > > > > > > > Is this simply about dropping the newly added references to > > > > $(dml_rcflags) from the Makefile? Because that is quite trivial ... > > > > > > Yes, I was thinking something like the attached patch. > > > > > > Alex > > > > > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001 > > > From: Alex Deucher > > > Date: Mon, 4 Jan 2021 11:24:20 -0500 > > > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64 > > > > > > From Ard: > > > > > > "Simply disabling -mgeneral-regs-only left and right is risky, given that > > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, > > > and GCC is known to use SIMD registers for spilling, and may invent > > > other uses of the FP/SIMD register file that have nothing to do with the > > > floating point code in question. Note that putting kernel_neon_begin() > > > and kernel_neon_end() around the code that does use FP is not sufficient > > > here, the problem is in all the other code that may be emitted with > > > references to SIMD registers in it. > > > > > > So the only way to do this properly is to put all floating point code in > > > a separate compilation unit, and only compile that unit with > > > -mgeneral-regs-only." > > > > > > Disable support until the code can be properly refactored to support this > > > properly on aarch64. > > > > > > Reported-by: Ard Biesheuvel > > > Signed-off-by: Alex Deucher > > > --- > > > drivers/gpu/drm/amd/display/Kconfig | 2 +- > > > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 4 > > > .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 21 --- > > > drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 --- > > > .../drm/amd/display/dc/dcn10/dcn10_resource.c | 7 --- > > > drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 > > > drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 > > > drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 5 - > > > .../gpu/drm/amd/display/dc/dcn301/Makefile| 4 > > > .../gpu/drm/amd/display/dc/dcn302/Makefile| 4 > > >
Re: [PATCH 00/29] [Set 15] Finally rid W=1 warnings from GPU!
On Tue, 19 Jan 2021, Zack Rusin wrote: > > > > On Jan 19, 2021, at 03:29, Lee Jones wrote: > > > > On Mon, 18 Jan 2021, Daniel Vetter wrote: > > > >> On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote: > >>> On Mon, 18 Jan 2021, Daniel Vetter wrote: > >>> > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote: > > > >> On Jan 15, 2021, at 13:15, Lee Jones wrote: > >> > >> This set is part of a larger effort attempting to clean-up W=1 > >> kernel builds, which are currently overwhelmingly riddled with > >> niggly little warnings. > >> > >> Last set! All clean after this for; Arm, Arm64, PPC, MIPS and x86. > > > > Thanks! For all the vmwgfx bits: > > Reviewed-by: Zack Rusin > > Ok I merged everything except vmwgfx (that's for Zack) and i915/nouveau > (those generally go through other trees, pls holler if they're stuck). > >>> > >>> Thanks Daniel, you're a superstar! > >>> > >>> So Zack will take the vmwgfx parts? Despite providing a R-b? > >> > >> I only merge stuff that's defacto abandoned already. Everything else I try > >> to offload to whomever actually cares :-) > > > > Understood. Thanks for the explanation. > > > > Hopefully Zack actually cares. :D > > hah, I do. I just pushed all of the changes to drm-misc-next. Let me > know if I missed anything. Thanks! Perfect. Thank you Zack. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
