Re: [PATCH] drm/amd/pm: convert sysfs snprintf to sysfs_emit
On Wed, 7 Apr 2021 16:30:01 -0400 Alex Deucher wrote: > On Tue, Apr 6, 2021 at 10:13 AM Carlis wrote: > > > > From: Xuezhi Zhang > > > > Fix the following coccicheck warning: > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2022:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:294:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:154:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:496:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:512:9-17: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1740:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1667:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2074:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2047:9-17: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2768:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2738:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2442:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3246:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3253:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2458:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3047:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3133:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3209:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3216:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2410:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2496:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2470:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2426:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2965:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2972:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3006:8-16: > > WARNING: use scnprintf or sprintf > > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3013:8-16: > > WARNING: use scnprintf or sprintf > > > > Signed-off-by: Xuezhi Zhang > > I already applied a similar patch last week. > > Thanks, > > Alex > OK. Thanks, Xuezhi Zhang > > > --- > > drivers/gpu/drm/amd/pm/amdgpu_pm.c | 58 > > +++--- 1 file changed, 29 insertions(+), 29 > > deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index > > 5fa65f191a37..2777966ec1ca 100644 --- > > a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ > > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -151,7 +151,7 @@ static > > ssize_t amdgpu_get_power_dpm_state(struct device *dev, > > pm_runtime_mark_last_busy(ddev->dev); > > pm_runtime_put_autosuspend(ddev->dev); > > > > - return snprintf(buf, PAGE_SIZE, "%s\n", > > + return sysfs_emit(buf, "%s\n", > > (pm == POWER_STATE_TYPE_BATTERY) ? > > "battery" : (pm == POWER_STATE_TYPE_BALANCED) ? "balanced" : > > "performance"); } > > @@ -291,7 +291,7 @@ static ssize_t > > amdgpu_get_power_dpm_force_performance_level(struct device *dev, > > pm_runtime_mark_last_busy(ddev->dev); > > pm_runtime_put_autosuspend(ddev->dev); > > > > - return snprintf(buf, PAGE_SIZE, "%s\n", > > + return sysfs_emit(buf, "%s\n", > > (level == AMD_DPM_FORCED_LEVEL_AUTO) ? > > "auto" : (level == AMD_DPM_FORCED_LEVEL_LOW) ? "low" : > > (level == AMD_DPM_FORCED_LEVEL_HIGH) ? > > "high" : @@ -493,7 +493,7 @@ static ssize_t > > amdgpu_get_pp_cur_state(struct device *dev, if (i == data.nums) > > i = -EINVAL; > > > > - return snprintf(buf, PAGE_SIZE, "%d\n", i); > > + return sysfs_emit(buf, "%d\n", i); > > } > > > > static ssize_t amdgpu_get_pp_force_state(struct device *dev, > > @@ -509,7 +509,7 @@ static ssize_t amdgpu_get_pp_force_state(struct > > device *dev, if (adev->pp_force_state_enabled) > > return amdgpu_get_pp_cur_state(dev, attr, buf); > > else > > - return snprintf(buf, PAGE_SIZE, "\n"); > > + return sysfs_emit(buf, "\n"); > > } > > > > static ssize_t amdgpu_set_pp_force_state(struct device *dev, > > @@ -1664,7 +1664,7 @@ static ssize_t amdgpu_get_pp_sclk_od(struct > > device *dev,
[pull] amdgpu, radeon drm-fixes-5.12
Hi Dave, Daniel, Fixes for 5.12. The following changes since commit 6fdb8e5aba6a33fe5f1a0bd1bcf0cf2884437ead: Merge tag 'imx-drm-fixes-2021-04-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2021-04-02 04:53:16 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.12-2021-04-08 for you to fetch changes up to cdcc108a2aced5f9cbc45920e29bf49819e5477f: drm/amdgpu/smu7: fix CAC setting on TOPAZ (2021-04-08 00:36:40 -0400) amd-drm-fixes-5.12-2021-04-08: amdgpu: - DCN3 fix - Fix CAC setting regression for TOPAZ - Fix ttm regression radeon: - Fix ttm regression Alex Deucher (1): drm/amdgpu/smu7: fix CAC setting on TOPAZ Qingqing Zhuo (1): drm/amd/display: Add missing mask for DCN3 xinhui pan (2): drm/amdgpu: Fix size overflow drm/radeon: Fix size overflow drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.h | 1 + drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 4 files changed, 6 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi Am 07.04.21 um 21:49 schrieb Felix Kuehling: On 2021-04-07 3:34 p.m., Felix Kuehling wrote: On 2021-04-07 7:25 a.m., Christian König wrote: + /* + * Don't verify access for KFD BOs. They don't have a GEM + * object associated with them. + */ + if (bo->kfd_bo) + goto out; Who does the access verification now? This is somewhat confusing. I took this check as-is, including the comment, from amdgpu's verify_access function. The verify_access function was called by ttm_bo_mmap. It returned 0 and ttm_bo_mmap did the mapping. This is probably a left-over from when we mapped BOs using /dev/kfd. We changed this to use /dev/dri/renderD* a long time ago to fix CPU mapping invalidations on memory evictions. I think we can let GEM do the access check. Ok, good to know. Thomas can you remove the extra handling in a separate prerequisite patch? If anybody then bisects to this patch we at least know what to do to get it working again. FWIW, I ran KFDTest test with this shortcut removed on current amd-staging-drm-next + my HMM patch series, and it didn't seem to cause any issues. Wait, I celebrated too soon. I was running the wrong kernel. I do see some failures where access is being denied. I need to do more debugging to figure out what's causing that. OK, thanks for looking into this. I'll wait a bit before sending out the new patchset. Best regards Thomas Regards, Felix Regards, Felix Regards, Christian. -- 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 v5 03/21] gpu: host1x: Show number of pending waiters in debugfs
On Thu, Apr 08, 2021 at 06:13:44AM +0200, Michał Mirosław wrote:
> On Fri, Apr 02, 2021 at 07:02:32PM +0300, Dmitry Osipenko wrote:
> > 02.04.2021 00:19, Michał Mirosław пишет:
> > > On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote:
> > >> On 3/23/21 12:16 PM, Thierry Reding wrote:
> > >>> On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote:
> > Show the number of pending waiters in the debugfs status file.
> > This is useful for testing to verify that waiters do not leak
> > or accumulate incorrectly.
> >
> > Signed-off-by: Mikko Perttunen
> > ---
> > drivers/gpu/host1x/debug.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
> > index 1b4997bda1c7..8a14880c61bb 100644
> > --- a/drivers/gpu/host1x/debug.c
> > +++ b/drivers/gpu/host1x/debug.c
> > @@ -69,6 +69,7 @@ static int show_channel(struct host1x_channel *ch,
> > void *data, bool show_fifo)
> > static void show_syncpts(struct host1x *m, struct output *o)
> > {
> > + struct list_head *pos;
> > unsigned int i;
> > host1x_debug_output(o, " syncpts \n");
> > @@ -76,12 +77,19 @@ static void show_syncpts(struct host1x *m, struct
> > output *o)
> > for (i = 0; i < host1x_syncpt_nb_pts(m); i++) {
> > u32 max = host1x_syncpt_read_max(m->syncpt + i);
> > u32 min = host1x_syncpt_load(m->syncpt + i);
> > + unsigned int waiters = 0;
> > - if (!min && !max)
> > + spin_lock(>syncpt[i].intr.lock);
> > + list_for_each(pos, >syncpt[i].intr.wait_head)
> > + waiters++;
> > + spin_unlock(>syncpt[i].intr.lock);
> > >>>
> > >>> Would it make sense to keep a running count so that we don't have to
> > >>> compute it here?
> > >>
> > >> Considering this is just a debug facility, I think I prefer not adding a
> > >> new
> > >> field just for it.
> > >
> > > This looks like IRQ-disabled region, so unless only root can trigger
> > > this code, maybe the additional field could save a potential headache?
> > > How many waiters can there be in the worst case?
> >
> > The host1x's IRQ handler runs in a workqueue, so it should be okay.
>
> Why, then, this uses a spinlock (and it has 'intr' in its name)?
The critical sections are already O(n) in number of waiters, so this
patch doesn't make things worse as I previously thought. The questions
remain: What is the expected number and upper bound of workers?
Shouldn't this be a mutex instead?
Best Regards
Michał Mirosław
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 03/21] gpu: host1x: Show number of pending waiters in debugfs
On Fri, Apr 02, 2021 at 07:02:32PM +0300, Dmitry Osipenko wrote:
> 02.04.2021 00:19, Michał Mirosław пишет:
> > On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote:
> >> On 3/23/21 12:16 PM, Thierry Reding wrote:
> >>> On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote:
> Show the number of pending waiters in the debugfs status file.
> This is useful for testing to verify that waiters do not leak
> or accumulate incorrectly.
>
> Signed-off-by: Mikko Perttunen
> ---
> drivers/gpu/host1x/debug.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
> index 1b4997bda1c7..8a14880c61bb 100644
> --- a/drivers/gpu/host1x/debug.c
> +++ b/drivers/gpu/host1x/debug.c
> @@ -69,6 +69,7 @@ static int show_channel(struct host1x_channel *ch,
> void *data, bool show_fifo)
> static void show_syncpts(struct host1x *m, struct output *o)
> {
> +struct list_head *pos;
> unsigned int i;
> host1x_debug_output(o, " syncpts \n");
> @@ -76,12 +77,19 @@ static void show_syncpts(struct host1x *m, struct
> output *o)
> for (i = 0; i < host1x_syncpt_nb_pts(m); i++) {
> u32 max = host1x_syncpt_read_max(m->syncpt + i);
> u32 min = host1x_syncpt_load(m->syncpt + i);
> +unsigned int waiters = 0;
> -if (!min && !max)
> +spin_lock(>syncpt[i].intr.lock);
> +list_for_each(pos, >syncpt[i].intr.wait_head)
> +waiters++;
> +spin_unlock(>syncpt[i].intr.lock);
> >>>
> >>> Would it make sense to keep a running count so that we don't have to
> >>> compute it here?
> >>
> >> Considering this is just a debug facility, I think I prefer not adding a
> >> new
> >> field just for it.
> >
> > This looks like IRQ-disabled region, so unless only root can trigger
> > this code, maybe the additional field could save a potential headache?
> > How many waiters can there be in the worst case?
>
> The host1x's IRQ handler runs in a workqueue, so it should be okay.
Why, then, this uses a spinlock (and it has 'intr' in its name)?
Best Regards
Michał Mirosław
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next v2] drm/bridge: lt8912b: Add header file
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~ GPIOF_INIT_HIGH Signed-off-by: Zhang Jianhua --- v2: - add header file for lontium-lt8912b.c instead of add config dependence for CONFIG_DRM_LONTIUM_LT8912B --- drivers/gpu/drm/bridge/lontium-lt8912b.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c index 61491615bad0..79845b3b19e1 100644 --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c @@ -3,6 +3,7 @@ * Copyright (c) 2018, The Linux Foundation. All rights reserved. */ +#include #include #include #include -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: simplify devm_drm_panel_bridge_add_typed
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Tian Tao
Signed-off-by: Yicong Yang
---
drivers/gpu/drm/bridge/panel.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index c916f4b..e5ddefb 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -250,11 +250,9 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_panel_bridge_remove);
-static void devm_drm_panel_bridge_release(struct device *dev, void *res)
+static void devm_drm_panel_bridge_release(void *bridge)
{
- struct drm_bridge **bridge = res;
-
- drm_panel_bridge_remove(*bridge);
+ drm_panel_bridge_remove(bridge);
}
/**
@@ -295,20 +293,17 @@ struct drm_bridge *devm_drm_panel_bridge_add_typed(struct
device *dev,
struct drm_panel *panel,
u32 connector_type)
{
- struct drm_bridge **ptr, *bridge;
-
- ptr = devres_alloc(devm_drm_panel_bridge_release, sizeof(*ptr),
- GFP_KERNEL);
- if (!ptr)
- return ERR_PTR(-ENOMEM);
+ struct drm_bridge *bridge;
+ int ret;
bridge = drm_panel_bridge_add_typed(panel, connector_type);
- if (!IS_ERR(bridge)) {
- *ptr = bridge;
- devres_add(dev, ptr);
- } else {
- devres_free(ptr);
- }
+ if (IS_ERR(bridge))
+ return bridge;
+
+ ret = devm_add_action_or_reset(dev, devm_drm_panel_bridge_release,
+ bridge);
+ if (ret)
+ return ERR_PTR(ret);
return bridge;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
Quoting Dmitry Baryshkov (2021-04-07 15:57:01) > On Thu, 8 Apr 2021 at 01:41, Stephen Boyd wrote: > > > > Quoting Dmitry Baryshkov (2021-04-06 16:06:06) > > > devm_clk_hw_register_fixed_factor_release(), the release function for > > > the devm_clk_hw_register_fixed_factor(), calls > > > clk_hw_unregister_fixed_factor(), which will kfree() the clock. However > > > after that the devres functions will also kfree the allocated data, > > > resulting in double free/memory corruption. Just call > > > clk_hw_unregister() instead, leaving kfree() to devres code. > > > > > > Reported-by: Rob Clark > > > Cc: Daniel Palmer > > > Signed-off-by: Dmitry Baryshkov > > > --- > > > > > > Stephen, this fix affects the DSI PHY rework. Do we have a chance of > > > getting it into 5.12, otherwise there will be a cross-dependency between > > > msm-next and clk-next. > > > > Think I can get this into the last fixes PR. One question though, I > > think this follows the pattern that things like clk-divider.c use for > > devm. Are those also broken? > > It looks so. See e.g. the devres_release() function. It calls > (*release) callback, then it will kfree the resource. > Also see Documentation/driver-api/driver-model/devres.rst, which does > not kfree() in release functions. > > Do you wish for me to send all the fixes? > Yes please send more fixes. They're not high priority though so I'll probably leave them to bake in next for a week or so. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amdgpu: Remove verify_access shortcut for KFD BOs
This shortcut is no longer needed with access managed progerly by KFD.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 936b3cfdde55..4947dfe9aa70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -165,13 +165,6 @@ static int amdgpu_verify_access(struct ttm_buffer_object
*bo, struct file *filp)
{
struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
- /*
-* Don't verify access for KFD BOs. They don't have a GEM
-* object associated with them.
-*/
- if (abo->kfd_bo)
- return 0;
-
if (amdgpu_ttm_tt_get_usermm(bo->ttm))
return -EPERM;
return drm_vma_node_verify_access(>tbo.base.vma_node,
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpu
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 14 ++--
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 69 +++
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +-
3 files changed, 50 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 5ffb07b02810..0d59bebd92af 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -236,20 +236,20 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev
*dst, struct kgd_dev *s
/* GPUVM API */
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
- void **vm, void **process_info,
+ void **process_info,
struct dma_fence **ef);
-void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm);
-uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *vm);
+void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void
*drm_priv);
+uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *drm_priv);
int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
struct kgd_dev *kgd, uint64_t va, uint64_t size,
- void *vm, struct kgd_mem **mem,
+ void *drm_priv, struct kgd_mem **mem,
uint64_t *offset, uint32_t flags);
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, void *vm);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, void *vm);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_sync_memory(
struct kgd_dev *kgd, struct kgd_mem *mem, bool intr);
int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct kgd_dev *kgd,
@@ -260,7 +260,7 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct kgd_dev
*kgd,
struct kfd_vm_fault_info *info);
int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
struct dma_buf *dmabuf,
- uint64_t va, void *vm,
+ uint64_t va, void *drm_priv,
struct kgd_mem **mem, uint64_t *size,
uint64_t *mmap_offset);
int amdgpu_amdkfd_get_tile_config(struct kgd_dev *kgd,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 36012229ccc1..95442bcd60fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -951,6 +951,13 @@ static int process_update_pds(struct amdkfd_process_info
*process_info,
return 0;
}
+static struct amdgpu_vm *drm_priv_to_vm(struct drm_file *drm_priv)
+{
+ struct amdgpu_fpriv *fpriv = drm_priv->driver_priv;
+
+ return >vm;
+}
+
static int init_kfd_vm(struct amdgpu_vm *vm, void **process_info,
struct dma_fence **ef)
{
@@ -1039,15 +1046,19 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
**process_info,
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
- void **vm, void **process_info,
+ void **process_info,
struct dma_fence **ef)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct drm_file *drm_priv = filp->private_data;
- struct amdgpu_fpriv *drv_priv = drm_priv->driver_priv;
- struct amdgpu_vm *avm = _priv->vm;
+ struct amdgpu_fpriv *drv_priv;
+ struct amdgpu_vm *avm;
int ret;
+ ret = amdgpu_file_to_fpriv(filp, _priv);
+ if (ret)
+ return ret;
+ avm = _priv->vm;
+
/* Already a compute VM? */
if (avm->process_info)
return -EINVAL;
@@ -1062,7 +1073,7 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev
*kgd,
if (ret)
return ret;
- *vm = (void *)avm;
+ amdgpu_vm_set_task_info(avm);
return 0;
}
@@ -1103,15 +1114,17 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct
amdgpu_device *adev,
}
}
-void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm)
+void
[PATCH 3/4] drm/amdkfd: Allow access for mmapping KFD BOs
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 19 ++-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8 +---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 7 ---
4 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 0d59bebd92af..7c8c5e469707 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -245,7 +245,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
void *drm_priv, struct kgd_mem **mem,
uint64_t *offset, uint32_t flags);
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
+ uint64_t *size);
int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 95442bcd60fb..e7d61ec966b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1232,6 +1232,12 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
domain_string(alloc_domain), ret);
goto err_bo_create;
}
+ ret = drm_vma_node_allow(>vma_node, drm_priv);
+ if (ret) {
+ pr_debug("Failed to allow vma node access. ret %d\n",
+ret);
+ goto err_node_allow;
+ }
bo = gem_to_amdgpu_bo(gobj);
if (bo_type == ttm_bo_type_sg) {
bo->tbo.sg = sg;
@@ -1261,6 +1267,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
allocate_init_user_pages_failed:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
+ drm_vma_node_revoke(>vma_node, drm_priv);
+err_node_allow:
amdgpu_bo_unref();
/* Don't unreserve system mem limit twice */
goto err_reserve_limit;
@@ -1278,7 +1286,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
}
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size)
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
+ uint64_t *size)
{
struct amdkfd_process_info *process_info = mem->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
@@ -1355,6 +1364,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
}
/* Free the BO*/
+ drm_vma_node_revoke(>bo->tbo.base.vma_node, drm_priv);
drm_gem_object_put(>bo->tbo.base);
mutex_destroy(>lock);
kfree(mem);
@@ -1666,6 +1676,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
struct drm_gem_object *obj;
struct amdgpu_bo *bo;
+ int ret;
if (dma_buf->ops != _dmabuf_ops)
/* Can't handle non-graphics buffers */
@@ -1686,6 +1697,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev
*kgd,
if (!*mem)
return -ENOMEM;
+ ret = drm_vma_node_allow(>vma_node, drm_priv);
+ if (ret) {
+ kfree(mem);
+ return ret;
+ }
+
if (size)
*size = amdgpu_bo_size(bo);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 43de260b2230..8fc18de7cff4 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1328,7 +1328,8 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file
*filep,
return 0;
err_free:
- amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem,
NULL);
+ amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem,
+ pdd->vm, NULL);
err_unlock:
mutex_unlock(>mutex);
return err;
@@ -1365,7 +1366,7 @@ static int kfd_ioctl_free_memory_of_gpu(struct file
*filep,
}
ret = amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd,
- (struct kgd_mem *)mem, );
+ (struct kgd_mem *)mem, pdd->vm, );
/* If freeing the buffer failed, leave the handle in place for
* clean-up during process tear-down.
@@ -1721,7 +1722,8 @@ static int kfd_ioctl_import_dmabuf(struct file *filep,
return 0;
err_free:
- amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem
[PATCH 1/4] drm/amdkfd: Remove legacy code not acquiring VMs
ROCm user mode has acquired VMs from DRM file descriptors for as long
as it supported the upstream KFD. Legacy code to support older versions
of ROCm is not needed any more.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 --
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 50 ---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 27 --
3 files changed, 10 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..5ffb07b02810 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -234,14 +234,10 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev
*dst, struct kgd_dev *s
})
/* GPUVM API */
-int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
- void **vm, void **process_info,
- struct dma_fence **ef);
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
void **vm, void **process_info,
struct dma_fence **ef);
-void amdgpu_amdkfd_gpuvm_destroy_process_vm(struct kgd_dev *kgd, void *vm);
void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm);
uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *vm);
int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index e93850f2f3b1..36012229ccc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1037,41 +1037,6 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
**process_info,
return ret;
}
-int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
- void **vm, void **process_info,
- struct dma_fence **ef)
-{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct amdgpu_vm *new_vm;
- int ret;
-
- new_vm = kzalloc(sizeof(*new_vm), GFP_KERNEL);
- if (!new_vm)
- return -ENOMEM;
-
- /* Initialize AMDGPU part of the VM */
- ret = amdgpu_vm_init(adev, new_vm, AMDGPU_VM_CONTEXT_COMPUTE, pasid);
- if (ret) {
- pr_err("Failed init vm ret %d\n", ret);
- goto amdgpu_vm_init_fail;
- }
-
- /* Initialize KFD part of the VM and process info */
- ret = init_kfd_vm(new_vm, process_info, ef);
- if (ret)
- goto init_kfd_vm_fail;
-
- *vm = (void *) new_vm;
-
- return 0;
-
-init_kfd_vm_fail:
- amdgpu_vm_fini(adev, new_vm);
-amdgpu_vm_init_fail:
- kfree(new_vm);
- return ret;
-}
-
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
void **vm, void **process_info,
@@ -1138,21 +1103,6 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct amdgpu_device
*adev,
}
}
-void amdgpu_amdkfd_gpuvm_destroy_process_vm(struct kgd_dev *kgd, void *vm)
-{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct amdgpu_vm *avm = (struct amdgpu_vm *)vm;
-
- if (WARN_ON(!kgd || !vm))
- return;
-
- pr_debug("Destroying process vm %p\n", vm);
-
- /* Release the VM context */
- amdgpu_vm_fini(adev, avm);
- kfree(vm);
-}
-
void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index d4241d29ea94..d97e330a5022 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -935,9 +935,6 @@ static void kfd_process_destroy_pdds(struct kfd_process *p)
pdd->dev->kgd, pdd->vm);
fput(pdd->drm_file);
}
- else if (pdd->vm)
- amdgpu_amdkfd_gpuvm_destroy_process_vm(
- pdd->dev->kgd, pdd->vm);
if (pdd->qpd.cwsr_kaddr && !pdd->qpd.cwsr_base)
free_pages((unsigned long)pdd->qpd.cwsr_kaddr,
@@ -1375,19 +1372,18 @@ int kfd_process_device_init_vm(struct
kfd_process_device *pdd,
struct kfd_dev *dev;
int ret;
+ if (!drm_file)
+ return -EINVAL;
+
if (pdd->vm)
- return drm_file ? -EBUSY : 0;
+ return -EBUSY;
p = pdd->process;
dev = pdd->dev;
- if (drm_file)
- ret =
Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
Quoting Dmitry Baryshkov (2021-04-06 16:06:06)
> devm_clk_hw_register_fixed_factor_release(), the release function for
> the devm_clk_hw_register_fixed_factor(), calls
> clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> after that the devres functions will also kfree the allocated data,
> resulting in double free/memory corruption. Just call
> clk_hw_unregister() instead, leaving kfree() to devres code.
>
> Reported-by: Rob Clark
> Cc: Daniel Palmer
> Signed-off-by: Dmitry Baryshkov
> ---
Applied to clk-fixes. I also squashed this in to cleanup that ugly cast.
---8<
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 390c16f321a6..4e4b6d367612 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -66,12 +66,14 @@ EXPORT_SYMBOL_GPL(clk_fixed_factor_ops);
static void devm_clk_hw_register_fixed_factor_release(struct device *dev, void
*res)
{
+ struct clk_fixed_factor *fix = res;
+
/*
* We can not use clk_hw_unregister_fixed_factor, since it will kfree()
* the hw, resulting in double free. Just unregister the hw and let
* devres code kfree() it.
*/
- clk_hw_unregister(&((struct clk_fixed_factor *)res)->hw);
+ clk_hw_unregister(>hw);
}
static struct clk_hw *
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
On Thu, 8 Apr 2021 at 01:41, Stephen Boyd wrote: > > Quoting Dmitry Baryshkov (2021-04-06 16:06:06) > > devm_clk_hw_register_fixed_factor_release(), the release function for > > the devm_clk_hw_register_fixed_factor(), calls > > clk_hw_unregister_fixed_factor(), which will kfree() the clock. However > > after that the devres functions will also kfree the allocated data, > > resulting in double free/memory corruption. Just call > > clk_hw_unregister() instead, leaving kfree() to devres code. > > > > Reported-by: Rob Clark > > Cc: Daniel Palmer > > Signed-off-by: Dmitry Baryshkov > > --- > > > > Stephen, this fix affects the DSI PHY rework. Do we have a chance of > > getting it into 5.12, otherwise there will be a cross-dependency between > > msm-next and clk-next. > > Think I can get this into the last fixes PR. One question though, I > think this follows the pattern that things like clk-divider.c use for > devm. Are those also broken? It looks so. See e.g. the devres_release() function. It calls (*release) callback, then it will kfree the resource. Also see Documentation/driver-api/driver-model/devres.rst, which does not kfree() in release functions. Do you wish for me to send all the fixes? -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
Quoting Dmitry Baryshkov (2021-04-06 16:06:06) > devm_clk_hw_register_fixed_factor_release(), the release function for > the devm_clk_hw_register_fixed_factor(), calls > clk_hw_unregister_fixed_factor(), which will kfree() the clock. However > after that the devres functions will also kfree the allocated data, > resulting in double free/memory corruption. Just call > clk_hw_unregister() instead, leaving kfree() to devres code. > > Reported-by: Rob Clark > Cc: Daniel Palmer > Signed-off-by: Dmitry Baryshkov > --- > > Stephen, this fix affects the DSI PHY rework. Do we have a chance of > getting it into 5.12, otherwise there will be a cross-dependency between > msm-next and clk-next. Think I can get this into the last fixes PR. One question though, I think this follows the pattern that things like clk-divider.c use for devm. Are those also broken? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211875] CPU frequency scaling lost after "WARNING: CPU: 2 PID: 2358578 at smu8_send_msg_to_smc_with_parameter+0xfe/0x140 [amdgpu]"
https://bugzilla.kernel.org/show_bug.cgi?id=211875 --- Comment #8 from Erhard F. (erhar...@mailbox.org) --- Created attachment 296273 --> https://bugzilla.kernel.org/attachment.cgi?id=296273=edit dmesg (kernel 4.14.228, A10-9700E) Traced the issue back to kernel v4.14.228 which is still affected (v4.19.184 and v5.4.109 too). On v4.14.228 no stack trace like in recent kernels but these messages: [...] [28541.868617] amdgpu: [powerplay] min_core_set_clock not set [28542.483228] cz_send_msg_to_smc_async (0x0011) failed [28543.097905] cz_send_msg_to_smc_async (0x026e) failed [28543.712424] cz_send_msg_to_smc_async (0x002f) failed [28543.712719] amdgpu: [powerplay] min_core_set_clock not set [28544.330105] cz_send_msg_to_smc_async (0x0011) failed [28544.947054] cz_send_msg_to_smc_async (0x026e) failed [28545.564013] cz_send_msg_to_smc_async (0x002f) failed [28545.564251] amdgpu: [powerplay] min_core_set_clock not set [28546.179695] cz_send_msg_to_smc_async (0x0011) failed [28546.794880] cz_send_msg_to_smc_async (0x026e) failed [28547.409986] cz_send_msg_to_smc_async (0x002f) failed Apart from that the machine behaves the same after these "cz_send_msg_to_smc_async (0x002f) failed" - CPU permanently downclocked to 800 MHz, desktop 'freezing' issues with display going black after some time. Access via ssh still works. -- 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
Re: [PATCH] drm/amd/pm: convert sysfs snprintf to sysfs_emit
On Tue, Apr 6, 2021 at 10:13 AM Carlis wrote: > > From: Xuezhi Zhang > > Fix the following coccicheck warning: > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2022:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:294:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:154:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:496:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:512:9-17: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1740:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1667:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2074:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2047:9-17: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2768:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2738:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2442:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3246:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3253:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2458:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3047:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3133:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3209:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3216:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2410:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2496:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2470:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2426:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2965:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:2972:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3006:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/amd/pm//amdgpu_pm.c:3013:8-16: > WARNING: use scnprintf or sprintf > > Signed-off-by: Xuezhi Zhang I already applied a similar patch last week. Thanks, Alex > --- > drivers/gpu/drm/amd/pm/amdgpu_pm.c | 58 +++--- > 1 file changed, 29 insertions(+), 29 deletions(-) > > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > index 5fa65f191a37..2777966ec1ca 100644 > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > @@ -151,7 +151,7 @@ static ssize_t amdgpu_get_power_dpm_state(struct device > *dev, > pm_runtime_mark_last_busy(ddev->dev); > pm_runtime_put_autosuspend(ddev->dev); > > - return snprintf(buf, PAGE_SIZE, "%s\n", > + return sysfs_emit(buf, "%s\n", > (pm == POWER_STATE_TYPE_BATTERY) ? "battery" : > (pm == POWER_STATE_TYPE_BALANCED) ? "balanced" : > "performance"); > } > @@ -291,7 +291,7 @@ static ssize_t > amdgpu_get_power_dpm_force_performance_level(struct device *dev, > pm_runtime_mark_last_busy(ddev->dev); > pm_runtime_put_autosuspend(ddev->dev); > > - return snprintf(buf, PAGE_SIZE, "%s\n", > + return sysfs_emit(buf, "%s\n", > (level == AMD_DPM_FORCED_LEVEL_AUTO) ? "auto" : > (level == AMD_DPM_FORCED_LEVEL_LOW) ? "low" : > (level == AMD_DPM_FORCED_LEVEL_HIGH) ? "high" : > @@ -493,7 +493,7 @@ static ssize_t amdgpu_get_pp_cur_state(struct device *dev, > if (i == data.nums) > i = -EINVAL; > > - return snprintf(buf, PAGE_SIZE, "%d\n", i); > + return sysfs_emit(buf, "%d\n", i); > } > > static ssize_t amdgpu_get_pp_force_state(struct device *dev, > @@ -509,7 +509,7 @@ static ssize_t amdgpu_get_pp_force_state(struct device > *dev, > if (adev->pp_force_state_enabled) > return amdgpu_get_pp_cur_state(dev, attr, buf); > else > - return snprintf(buf, PAGE_SIZE, "\n"); > + return sysfs_emit(buf, "\n"); > } > > static ssize_t amdgpu_set_pp_force_state(struct device *dev, > @@ -1664,7 +1664,7 @@ static ssize_t amdgpu_get_pp_sclk_od(struct device *dev, > pm_runtime_mark_last_busy(ddev->dev); > pm_runtime_put_autosuspend(ddev->dev); > > - return snprintf(buf, PAGE_SIZE, "%d\n", value); > + return sysfs_emit(buf, "%d\n", value); > } > > static
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
On 2021-04-07 3:34 p.m., Felix Kuehling wrote: On 2021-04-07 7:25 a.m., Christian König wrote: + /* + * Don't verify access for KFD BOs. They don't have a GEM + * object associated with them. + */ + if (bo->kfd_bo) + goto out; Who does the access verification now? This is somewhat confusing. I took this check as-is, including the comment, from amdgpu's verify_access function. The verify_access function was called by ttm_bo_mmap. It returned 0 and ttm_bo_mmap did the mapping. This is probably a left-over from when we mapped BOs using /dev/kfd. We changed this to use /dev/dri/renderD* a long time ago to fix CPU mapping invalidations on memory evictions. I think we can let GEM do the access check. Ok, good to know. Thomas can you remove the extra handling in a separate prerequisite patch? If anybody then bisects to this patch we at least know what to do to get it working again. FWIW, I ran KFDTest test with this shortcut removed on current amd-staging-drm-next + my HMM patch series, and it didn't seem to cause any issues. Wait, I celebrated too soon. I was running the wrong kernel. I do see some failures where access is being denied. I need to do more debugging to figure out what's causing that. Regards, Felix Regards, Felix Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
On 2021-04-07 7:25 a.m., Christian König wrote: + /* + * Don't verify access for KFD BOs. They don't have a GEM + * object associated with them. + */ + if (bo->kfd_bo) + goto out; Who does the access verification now? This is somewhat confusing. I took this check as-is, including the comment, from amdgpu's verify_access function. The verify_access function was called by ttm_bo_mmap. It returned 0 and ttm_bo_mmap did the mapping. This is probably a left-over from when we mapped BOs using /dev/kfd. We changed this to use /dev/dri/renderD* a long time ago to fix CPU mapping invalidations on memory evictions. I think we can let GEM do the access check. Ok, good to know. Thomas can you remove the extra handling in a separate prerequisite patch? If anybody then bisects to this patch we at least know what to do to get it working again. FWIW, I ran KFDTest test with this shortcut removed on current amd-staging-drm-next + my HMM patch series, and it didn't seem to cause any issues. Regards, Felix Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote: > > On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote: > > > > On Fri, Apr 2, 2021 at 12:22 PM Christian König > > wrote: > > > > > > Hey Alex, > > > > > > the TTM and scheduler changes should already be in the drm-misc-next > > > branch (not 100% sure about the TTM patch, need to double check next > > > week). > > > > > > > The TTM change is not in drm-misc yet. > > > > > Could that cause problems when both are merged into drm-next? > > > > Dave, Daniel, how do you want to handle this? The duplicated patch is this > > one: > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac4eb83ab255de9c31184df51fd1534ba36fd212 > > amdgpu has changes which depend on it. The same patch is included in this > > PR. > > Ouch not sure how best to sync up here, maybe get misc-next into my > tree then rebase your tree on top of it? I can do that. Alex > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: remove unneeded variable ret
Quoting Bernard Zhao (2021-04-07 06:06:21) > This patch fix coccicheck warning: > drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret". Return > "0" on line 880 > Also remove unneeded function return value check. > > Signed-off-by: Bernard Zhao > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212077] AMD GPU discrete card memory at highest frequency even while not in use
https://bugzilla.kernel.org/show_bug.cgi?id=212077 Bat Malin (bat_ma...@abv.bg) changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |CODE_FIX --- Comment #15 from Bat Malin (bat_ma...@abv.bg) --- Issue fixed in 5.11.12 even now it consumes less power (~1,07W less). Before: amdgpu-pci-0100 Adapter: PCI adapter vddgfx: 756.00 mV edge: +35.0 C (crit = +94.0 C, hyst = -273.1 C) power1:8.14 W (cap = 60.00 W) After: amdgpu-pci-0100 Adapter: PCI adapter vddgfx: 756.00 mV edge: +38.0°C (crit = +94.0°C, hyst = -273.1°C) power1:7.07 W (cap = 60.00 W) Thank you! -- 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
Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal
Hi Marijn On 2021-04-06 14:47, Marijn Suijten wrote: Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up. In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq. The reason the CONFIG_HEIGHT was at such a high value is to make sure that we always get the TE only from the panel vsync and not false positives coming from the tear check logic itself. When you say that disp-te gpio is not hooked up, is it something incorrect with the schematic OR panel is not generating the TE correctly? Suggested-by: AngeloGioacchino Del Regno Signed-off-by: Marijn Suijten Reviewed-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index ff2c1d583c79..2d5ac03dbc17 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); mdp5_write(mdp5_kms, - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); mdp5_write(mdp5_kms, REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/msm/dpu: remove unused local variable 'cmd_enc'
On 2021-04-07 01:33, Zhen Lei wrote:
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning:
variable ‘cmd_enc’ set but not used [-Wunused-but-set-variable]
Fixes: fe286893ed34 ("drm/msm/dpu: Remove unused call in
wait_for_commit_done")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b2be39b9144e449..088900841bf8baa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -685,10 +685,6 @@ static int
dpu_encoder_phys_cmd_wait_for_tx_complete(
static int dpu_encoder_phys_cmd_wait_for_commit_done(
struct dpu_encoder_phys *phys_enc)
{
- struct dpu_encoder_phys_cmd *cmd_enc;
-
- cmd_enc = to_dpu_encoder_phys_cmd(phys_enc);
-
/* only required for master controller */
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm: remove unneeded variable ret
On 2021-04-07 06:06, Bernard Zhao wrote:
This patch fix coccicheck warning:
drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret".
Return "0" on line 880
Also remove unneeded function return value check.
Signed-off-by: Bernard Zhao
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_link.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c
b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da78c4a..3395b08155a6 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -843,10 +843,8 @@ bool dp_link_send_edid_checksum(struct dp_link
*dp_link, u8 checksum)
return ret == 1;
}
-static int dp_link_parse_vx_px(struct dp_link_private *link)
+static void dp_link_parse_vx_px(struct dp_link_private *link)
{
- int ret = 0;
-
DRM_DEBUG_DP("vx: 0=%d, 1=%d, 2=%d, 3=%d\n",
drm_dp_get_adjust_request_voltage(link->link_status, 0),
drm_dp_get_adjust_request_voltage(link->link_status, 1),
@@ -876,8 +874,6 @@ static int dp_link_parse_vx_px(struct
dp_link_private *link)
DRM_DEBUG_DP("Requested: v_level = 0x%x, p_level = 0x%x\n",
link->dp_link.phy_params.v_level,
link->dp_link.phy_params.p_level);
-
- return ret;
}
/**
@@ -891,8 +887,6 @@ static int dp_link_parse_vx_px(struct
dp_link_private *link)
static int dp_link_process_phy_test_pattern_request(
struct dp_link_private *link)
{
- int ret = 0;
-
if (!(link->request.test_requested & DP_TEST_LINK_PHY_TEST_PATTERN))
{
DRM_DEBUG_DP("no phy test\n");
return -EINVAL;
@@ -918,12 +912,9 @@ static int
dp_link_process_phy_test_pattern_request(
link->dp_link.link_params.rate =
drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
- ret = dp_link_parse_vx_px(link);
-
- if (ret)
- DRM_ERROR("parse_vx_px failed. ret=%d\n", ret);
+ dp_link_parse_vx_px(link);
- return ret;
+ return 0;
}
static u8 get_link_status(const u8 link_status[DP_LINK_STATUS_SIZE],
int r)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 1/1] drm/msm/dpu: remove unused local variable 'cmd_enc'
On 2021-04-07 01:33, Zhen Lei wrote:
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning:
variable ‘cmd_enc’ set but not used [-Wunused-but-set-variable]
Fixes: fe286893ed34 ("drm/msm/dpu: Remove unused call in
wait_for_commit_done")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b2be39b9144e449..088900841bf8baa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -685,10 +685,6 @@ static int
dpu_encoder_phys_cmd_wait_for_tx_complete(
static int dpu_encoder_phys_cmd_wait_for_commit_done(
struct dpu_encoder_phys *phys_enc)
{
- struct dpu_encoder_phys_cmd *cmd_enc;
-
- cmd_enc = to_dpu_encoder_phys_cmd(phys_enc);
-
/* only required for master controller */
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/msm/dp: remove unused local variable 'hpd'
On 2021-04-07 01:23, Zhen Lei wrote:
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’
set but not used [-Wunused-but-set-variable]
Fixes: c58eb1b54fee ("drm/msm/dp: fix connect/disconnect handled at
irq_hpd")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6e1eaf277..31bf2a40a9eb2c9 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -493,7 +493,6 @@ static int dp_display_usbpd_attention_cb(struct
device *dev)
int rc = 0;
u32 sink_request;
struct dp_display_private *dp;
- struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -507,8 +506,6 @@ static int dp_display_usbpd_attention_cb(struct
device *dev)
return -ENODEV;
}
- hpd = dp->usbpd;
-
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
if (!rc) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/8] drm/vmwgfx: Inline vmw_verify_access()
On 4/6/21 5:09 AM, Thomas Zimmermann wrote:
Vmwgfx is the only user of the TTM's verify_access callback. Inline
the call and avoid the indirection through the function pointer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 7 ++-
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 2dc031fe4a90..a079734f9d68 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -658,14 +658,6 @@ static void vmw_evict_flags(struct ttm_buffer_object *bo,
*placement = vmw_sys_placement;
}
-static int vmw_verify_access(struct ttm_buffer_object *bo, struct file *filp)
-{
- struct ttm_object_file *tfile =
- vmw_fpriv((struct drm_file *)filp->private_data)->tfile;
-
- return vmw_user_bo_verify_access(bo, tfile);
-}
-
static int vmw_ttm_io_mem_reserve(struct ttm_device *bdev, struct
ttm_resource *mem)
{
struct vmw_private *dev_priv = container_of(bdev, struct vmw_private,
bdev);
@@ -768,7 +760,6 @@ struct ttm_device_funcs vmw_bo_driver = {
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vmw_evict_flags,
.move = vmw_move,
- .verify_access = vmw_verify_access,
.swap_notify = vmw_swap_notify,
.io_mem_reserve = _ttm_io_mem_reserve,
};
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index 3eaad00668f2..2574d4707407 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -65,6 +65,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
};
struct drm_file *file_priv = filp->private_data;
struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
+ struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
struct ttm_device *bdev = _priv->bdev;
struct ttm_buffer_object *bo;
int ret;
@@ -76,11 +77,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
if (unlikely(!bo))
return -EINVAL;
- if (unlikely(!bo->bdev->funcs->verify_access)) {
- ret = -EPERM;
- goto out_unref;
- }
- ret = bo->bdev->funcs->verify_access(bo, filp);
+ ret = vmw_user_bo_verify_access(bo, tfile);
if (unlikely(ret != 0))
goto out_unref;
Looks great.
Reviewed-by: Zack Rusin
z
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver
On 4/6/21 5:09 AM, Thomas Zimmermann wrote:
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 54 ++--
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index cb9975889e2f..3eaad00668f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -27,6 +27,30 @@
#include "vmwgfx_drv.h"
+static struct ttm_buffer_object *vmw_bo_vm_lookup(struct ttm_device *bdev,
+ unsigned long offset,
+ unsigned long pages)
+{
+ struct drm_vma_offset_node *node;
+ struct ttm_buffer_object *bo = NULL;
+
+ drm_vma_offset_lock_lookup(bdev->vma_manager);
+
+ node = drm_vma_offset_lookup_locked(bdev->vma_manager, offset, pages);
+ if (likely(node)) {
+ bo = container_of(node, struct ttm_buffer_object,
+ base.vma_node);
+ bo = ttm_bo_get_unless_zero(bo);
+ }
+
+ drm_vma_offset_unlock_lookup(bdev->vma_manager);
+
+ if (!bo)
+ pr_err("Could not find buffer object to map\n");
It's not a big deal and I know it's been in the original, but since
you're already in there if you could change this to DRM_ERR that'd be
great. Either way:
Reviewed-by: Zack Rusin
z
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 00/25] Rid W=1 warnings from HID
On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote: > > On Fri, 26 Mar 2021, 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. > > > > Lee Jones (25): > > HID: intel-ish-hid: Remove unused variable 'err' > > HID: ishtp-hid-client: Move variable to where it's actually used > > HID: intel-ish-hid: pci-ish: Remove unused variable 'ret' > > HID: intel-ish: Supply some missing param descriptions > > HID: intel-ish: Fix a naming disparity and a formatting error > > HID: usbhid: Repair a formatting issue in a struct description > > HID: intel-ish-hid: Fix a little doc-rot > > HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses > > HID: hid-alps: Correct struct misnaming > > HID: intel-ish-hid: Fix potential copy/paste error > > HID: hid-core: Fix incorrect function name in header > > HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in > > header > > HID: ishtp-hid-client: Fix incorrect function name report_bad_packet() > > HID: hid-kye: Fix incorrect function name for kye_tablet_enable() > > HID: hid-picolcd_core: Remove unused variable 'ret' > > HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote > > abuses > > HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs > > HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses > > HID: hid-uclogic-params: Ensure function names are present and correct > > in kernel-doc headers > > HID: hid-sensor-custom: Remove unused variable 'ret' > > HID: wacom_sys: Demote kernel-doc abuse > > HID: hid-sensor-hub: Remove unused struct member 'quirks' > > HID: hid-sensor-hub: Move 'hsdev' description to correct struct > > definition > > HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues > > HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning > > These have been on the list for a couple of weeks now. > > Is there anything I can do to help expedite their merge? > > I'm concerned since -rc6 has just been released. Sorry for the delay. I am currently queuing them locally and running a few tests on them. I don't expect anything to happen, but better be safe than anything. FWIW, I am splitting the series in 3: - 11 patches for intel ish are going to be queued in for-5.13/intel-ish - the thrustmaster one in for-5.13/thrustmaster - the rest (13 patches) will be sent in for-5.13/warnings. Cheers, Benjamin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: force hsa hsa hfp packets multiple of line num to avoid screen shift
Hi, Jitao:
Jitao Shi 於 2021年4月7日 週三 下午10:37寫道：
>
> The bridge chip ANX7625 require the line packets ending at the sametime
> or ANX7625 will shift the screen.
>
> Change-Id: Ia324ad28fbff54140feedb9a1d6bfb2b246d0447
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a1ff152ef468..e825a80862de 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -194,6 +194,8 @@ struct mtk_dsi {
> struct clk *hs_clk;
>
> u32 data_rate;
> + /* force dsi line end without dsi_null data */
> + bool force_dsi_end_without_null;
>
> unsigned long mode_flags;
> enum mipi_dsi_pixel_format format;
> @@ -495,6 +497,13 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi
> *dsi)
> DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
> }
>
> + if (dsi->force_dsi_end_without_null) {
> + horizontal_sync_active_byte =
> roundup(horizontal_sync_active_byte, dsi->lanes) - 2;
> + horizontal_frontporch_byte =
> roundup(horizontal_frontporch_byte, dsi->lanes) - 2;
> + horizontal_backporch_byte =
> roundup(horizontal_backporch_byte, dsi->lanes) - 2;
> + horizontal_backporch_byte -= (vm->hactive * dsi_tmp_buf_bpp +
> 2) % dsi->lanes;
> + }
> +
> writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
> writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> @@ -1091,6 +1100,9 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> dsi->bridge.of_node = dev->of_node;
> dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
>
> + dsi->force_dsi_end_without_null = of_property_read_bool(dev->of_node,
> +
> "force_dsi_end_without_null");
If force_dsi_end_without_null is caused by ANX7625, I think we should
get this information from ANX7625.
Regards,
Chun-Kuang.
> +
> drm_bridge_add(>bridge);
>
> ret = component_add(>dev, _dsi_component_ops);
> --
> 2.25.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/scheduler: Change scheduled fence track
+ dri-devel since GPU scheduler is a shared component.
On Wed, Apr 7, 2021 at 9:31 AM Roy Sun wrote:
>
> Update the timestamp of scheduled fence on HW
> completion of the previous fences
>
> This allow more accurate tracking of the fence
> execution in HW
>
> Signed-off-by: David M Nieto
> Signed-off-by: Roy Sun
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 92d8de24d0a1..4e5d8d4af010 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -515,7 +515,7 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler
> *sched)
> EXPORT_SYMBOL(drm_sched_resubmit_jobs);
>
> /**
> - * drm_sched_resubmit_jobs_ext - helper to relunch certain number of jobs
> from mirror ring list
> + * drm_sched_resubmit_jobs_ext - helper to relunch certain number of jobs
> from pending list
> *
> * @sched: scheduler instance
> * @max: job numbers to relaunch
> @@ -671,7 +671,7 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
> static struct drm_sched_job *
> drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
> {
> - struct drm_sched_job *job;
> + struct drm_sched_job *job, *next;
>
> /*
> * Don't destroy jobs while the timeout worker is running OR thread
> @@ -690,6 +690,13 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler
> *sched)
> if (job && dma_fence_is_signaled(>s_fence->finished)) {
> /* remove job from pending_list */
> list_del_init(>list);
> + /* account for the next fence in the queue */
> + next = list_first_entry_or_null(>pending_list,
> + struct drm_sched_job, list);
> + if (next) {
> + next->s_fence->scheduled.timestamp =
> + job->s_fence->finished.timestamp;
> + }
> } else {
> job = NULL;
> /* queue timeout for next job */
> --
> 2.31.1
>
> ___
> 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: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
Hi
On 06.04.21 14:40, Laurent Pinchart wrote:
Hi Dafna,
Thank you for the patch.
On Tue, Mar 30, 2021 at 01:52:00PM +0200, Dafna Hirschfeld wrote:
drm_bridge_funcs has a function called 'hpd_notify'.
The function drm_bridge_hpd_notify does not call
'hpd_notify' but it calls 'hpd_cb'. This is rather
confusing. Rename the function to fix this confusion.
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
drivers/gpu/drm/bridge/display-connector.c | 2 +-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
drivers/gpu/drm/drm_bridge.c| 8
include/drm/drm_bridge.h| 8
8 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 76555ae64e9c..748f82910f4f 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
cec_phys_addr_invalidate(adv7511->cec_adap);
drm_kms_helper_hotplug_event(adv7511->connector.dev);
} else {
- drm_bridge_hpd_notify(>bridge, status);
+ drm_bridge_hpd_cb(>bridge, status);
}
}
}
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d0c65610ebb5..682da288ff6d 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw, void
*context)
if (mhdp->connector.dev)
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
else
- drm_bridge_hpd_notify(>bridge,
cdns_mhdp_detect(mhdp));
+ drm_bridge_hpd_cb(>bridge,
cdns_mhdp_detect(mhdp));
}
}
@@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void *data)
else
drm_kms_helper_hotplug_event(mhdp->bridge.dev);
} else {
- drm_bridge_hpd_notify(>bridge,
cdns_mhdp_detect(mhdp));
+ drm_bridge_hpd_cb(>bridge,
cdns_mhdp_detect(mhdp));
}
}
diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c
index 05eb759da6fc..8ccd69d7fe34 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq, void
*arg)
struct display_connector *conn = arg;
struct drm_bridge *bridge = >bridge;
- drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
+ drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index fee27952ec6d..58f61b5da605 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work)
connected = lt9611uxc->hdmi_connected;
mutex_unlock(>ocm_lock);
- drm_bridge_hpd_notify(>bridge,
- connected ?
- connector_status_connected :
- connector_status_disconnected);
+ drm_bridge_hpd_cb(>bridge,
+ connected ?
+ connector_status_connected :
+ connector_status_disconnected);
}
}
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..984ab5c4bc71 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3026,7 +3026,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (hdmi->bridge.dev) {
drm_helper_hpd_irq_event(hdmi->bridge.dev);
- drm_bridge_hpd_notify(>bridge, status);
+ drm_bridge_hpd_cb(>bridge, status);
}
}
diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c b/drivers/gpu/drm/bridge/ti-tpd12s015.c
index e0e015243a60..2f079b6f51bc 100644
--- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
+++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
@@ -103,7 +103,7 @@ static irqreturn_t
[PATCH v2 0/4] drm/msm/dpu: always use mdp device to scale bandwidth
Currently DPU driver scales bandwidth and core clock for sc7180 only, while the rest of chips get static bandwidth votes. Make all chipsets scale bandwidth and clock per composition requirements like sc7180 does. Drop old voting path completely. Changes since v1: - Add dts changes as requested by Kalyan Thota ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] arm64: dts: sm8250: move bus clock to mdp node for sm8250 target
Move the bus clock to mdp device node,in order to facilitate bus band
width scaling on sm8250 target.
The parent device MDSS will not vote for bus bw, instead the vote will
be triggered by mdp device node. Since a minimum vote is required to
turn on bus clock, move the clock node to mdp device from where the
votes are requested.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 394973e778f7..60fe2eaf06c5 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2294,10 +2294,9 @@ mdss: mdss@ae0 {
power-domains = < MDSS_GDSC>;
clocks = < DISP_CC_MDSS_AHB_CLK>,
-< GCC_DISP_HF_AXI_CLK>,
< GCC_DISP_SF_AXI_CLK>,
< DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface", "bus", "nrt_bus", "core";
+ clock-names = "iface", "nrt_bus", "core";
assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
assigned-clock-rates = <46000>;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/msm/dpu: fill missing details in hw catalog for sdm845 and sm8[12]50
Fill clk_inefficiency_factor, bw_inefficiency_factor and
min_prefill_lines in hw catalog data for sdm845 and sm8[12]50.
Efficiency factors are blindly copied from sc7180 data, while
min_prefill_lines is based on downstream display driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 189f3533525c..a9f74c1177dd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -817,6 +817,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
{.rd_enable = 1, .wr_enable = 1},
{.rd_enable = 1, .wr_enable = 0}
},
+ .clk_inefficiency_factor = 105,
+ .bw_inefficiency_factor = 120,
};
static const struct dpu_perf_cfg sc7180_perf_data = {
@@ -852,6 +854,7 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
.min_core_ib = 240,
.min_llcc_ib = 80,
.min_dram_ib = 80,
+ .min_prefill_lines = 24,
.danger_lut_tbl = {0xf, 0x, 0x0},
.qos_lut_tbl = {
{.nentry = ARRAY_SIZE(sm8150_qos_linear),
@@ -869,6 +872,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
{.rd_enable = 1, .wr_enable = 1},
{.rd_enable = 1, .wr_enable = 0}
},
+ .clk_inefficiency_factor = 105,
+ .bw_inefficiency_factor = 120,
};
static const struct dpu_perf_cfg sm8250_perf_data = {
@@ -877,6 +882,7 @@ static const struct dpu_perf_cfg sm8250_perf_data = {
.min_core_ib = 480,
.min_llcc_ib = 0,
.min_dram_ib = 80,
+ .min_prefill_lines = 35,
.danger_lut_tbl = {0xf, 0x, 0x0},
.qos_lut_tbl = {
{.nentry = ARRAY_SIZE(sc7180_qos_linear),
@@ -894,6 +900,8 @@ static const struct dpu_perf_cfg sm8250_perf_data = {
{.rd_enable = 1, .wr_enable = 1},
{.rd_enable = 1, .wr_enable = 0}
},
+ .clk_inefficiency_factor = 105,
+ .bw_inefficiency_factor = 120,
};
/*
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/msm/dpu: always use mdp device to scale bandwidth
Currently DPU driver scales bandwidth and core clock for sc7180 only,
while the rest of chips get static bandwidth votes. Make all chipsets
scale bandwidth and clock per composition requirements like sc7180 does.
Drop old voting path completely.
Tested on RB3 (SDM845) and RB5 (SM8250).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 51 +---
2 files changed, 2 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 85f2c3564c96..fb061e666faa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -933,8 +933,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
DPU_DEBUG("REG_DMA is not defined");
}
- if (of_device_is_compatible(dev->dev->of_node, "qcom,sc7180-mdss"))
- dpu_kms_parse_data_bus_icc_path(dpu_kms);
+ dpu_kms_parse_data_bus_icc_path(dpu_kms);
pm_runtime_get_sync(_kms->pdev->dev);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index cd4078807db1..3416e9617ee9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -31,40 +31,8 @@ struct dpu_mdss {
void __iomem *mmio;
struct dss_module_power mp;
struct dpu_irq_controller irq_controller;
- struct icc_path *path[2];
- u32 num_paths;
};
-static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
- struct dpu_mdss *dpu_mdss)
-{
- struct icc_path *path0 = of_icc_get(dev->dev, "mdp0-mem");
- struct icc_path *path1 = of_icc_get(dev->dev, "mdp1-mem");
-
- if (IS_ERR_OR_NULL(path0))
- return PTR_ERR_OR_ZERO(path0);
-
- dpu_mdss->path[0] = path0;
- dpu_mdss->num_paths = 1;
-
- if (!IS_ERR_OR_NULL(path1)) {
- dpu_mdss->path[1] = path1;
- dpu_mdss->num_paths++;
- }
-
- return 0;
-}
-
-static void dpu_mdss_icc_request_bw(struct msm_mdss *mdss)
-{
- struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
- int i;
- u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
-
- for (i = 0; i < dpu_mdss->num_paths; i++)
- icc_set_bw(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
-}
-
static void dpu_mdss_irq(struct irq_desc *desc)
{
struct dpu_mdss *dpu_mdss = irq_desc_get_handler_data(desc);
@@ -178,8 +146,6 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
struct dss_module_power *mp = _mdss->mp;
int ret;
- dpu_mdss_icc_request_bw(mdss);
-
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
if (ret) {
DPU_ERROR("clock enable failed, ret:%d\n", ret);
@@ -213,15 +179,12 @@ static int dpu_mdss_disable(struct msm_mdss *mdss)
{
struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
struct dss_module_power *mp = _mdss->mp;
- int ret, i;
+ int ret;
ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (ret)
DPU_ERROR("clock disable failed, ret:%d\n", ret);
- for (i = 0; i < dpu_mdss->num_paths; i++)
- icc_set_bw(dpu_mdss->path[i], 0, 0);
-
return ret;
}
@@ -232,7 +195,6 @@ static void dpu_mdss_destroy(struct drm_device *dev)
struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
struct dss_module_power *mp = _mdss->mp;
int irq;
- int i;
pm_runtime_suspend(dev->dev);
pm_runtime_disable(dev->dev);
@@ -242,9 +204,6 @@ static void dpu_mdss_destroy(struct drm_device *dev)
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
- for (i = 0; i < dpu_mdss->num_paths; i++)
- icc_put(dpu_mdss->path[i]);
-
if (dpu_mdss->mmio)
devm_iounmap(>dev, dpu_mdss->mmio);
dpu_mdss->mmio = NULL;
@@ -276,12 +235,6 @@ int dpu_mdss_init(struct drm_device *dev)
DRM_DEBUG("mapped mdss address space @%pK\n", dpu_mdss->mmio);
- if (!of_device_is_compatible(dev->dev->of_node, "qcom,sc7180-mdss")) {
- ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss);
- if (ret)
- return ret;
- }
-
mp = _mdss->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
@@ -307,8 +260,6 @@ int dpu_mdss_init(struct drm_device *dev)
pm_runtime_enable(dev->dev);
- dpu_mdss_icc_request_bw(priv->mdss);
-
return ret;
irq_error:
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] arm64: dts: sdm845: move bus clock to mdp node for sdm845 target
Move the bus clock to mdp device node,in order to facilitate bus band
width scaling on sdm845 target.
The parent device MDSS will not vote for bus bw, instead the vote will
be triggered by mdp device node. Since a minimum vote is required to
turn on bus clock, move the clock node to mdp device from where the
votes are requested.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7395ef20b90e..55704804c2ca 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4136,9 +4136,8 @@ mdss: mdss@ae0 {
power-domains = < MDSS_GDSC>;
clocks = < GCC_DISP_AHB_CLK>,
-< GCC_DISP_AXI_CLK>,
< DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface", "bus", "core";
+ clock-names = "iface", "core";
assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
assigned-clock-rates = <3>;
@@ -4166,11 +4165,12 @@ mdss_mdp: mdp@ae01000 {
<0 0x0aeb 0 0x2008>;
reg-names = "mdp", "vbif";
- clocks = < DISP_CC_MDSS_AHB_CLK>,
+ clocks = < GCC_DISP_AXI_CLK>,
+< DISP_CC_MDSS_AHB_CLK>,
< DISP_CC_MDSS_AXI_CLK>,
< DISP_CC_MDSS_MDP_CLK>,
< DISP_CC_MDSS_VSYNC_CLK>;
- clock-names = "iface", "bus", "core", "vsync";
+ clock-names = "gcc-bus", "iface", "bus",
"core", "vsync";
assigned-clocks = <
DISP_CC_MDSS_MDP_CLK>,
<
DISP_CC_MDSS_VSYNC_CLK>;
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mediatek: force hsa hsa hfp packets multiple of line num to avoid screen shift
The bridge chip ANX7625 require the line packets ending at the sametime
or ANX7625 will shift the screen.
Change-Id: Ia324ad28fbff54140feedb9a1d6bfb2b246d0447
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index a1ff152ef468..e825a80862de 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -194,6 +194,8 @@ struct mtk_dsi {
struct clk *hs_clk;
u32 data_rate;
+ /* force dsi line end without dsi_null data */
+ bool force_dsi_end_without_null;
unsigned long mode_flags;
enum mipi_dsi_pixel_format format;
@@ -495,6 +497,13 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
}
+ if (dsi->force_dsi_end_without_null) {
+ horizontal_sync_active_byte =
roundup(horizontal_sync_active_byte, dsi->lanes) - 2;
+ horizontal_frontporch_byte =
roundup(horizontal_frontporch_byte, dsi->lanes) - 2;
+ horizontal_backporch_byte = roundup(horizontal_backporch_byte,
dsi->lanes) - 2;
+ horizontal_backporch_byte -= (vm->hactive * dsi_tmp_buf_bpp +
2) % dsi->lanes;
+ }
+
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
@@ -1091,6 +1100,9 @@ static int mtk_dsi_probe(struct platform_device *pdev)
dsi->bridge.of_node = dev->of_node;
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
+ dsi->force_dsi_end_without_null = of_property_read_bool(dev->of_node,
+
"force_dsi_end_without_null");
+
drm_bridge_add(>bridge);
ret = component_add(>dev, _dsi_component_ops);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.105
Alex Deucher (1): amdgpu: update marketing names Alistair Delva (1): xf86drm: fix null pointer deref in drmGetBufInfo Ashutosh Dixit (1): intel: Keep libdrm working without pread/pwrite ioctls Emil Velikov (3): xf86drm: cap number of reported devices by drmGetDevice(2) Revert "xf86drm: cap number of reported devices by drmGetDevice(2)" xf86drm: cap number of reported devices by drmGetDevice(2) Fabio Estevam (1): tests/util: Add mxsfb-drm driver Fang Tan (1): meson: use library() instead of shared_library(). Heiko Becker (1): meson: Also search for rst2man.py James Zhu (1): tests/amdgpu: add vcn test support for dimgrey_cavefish Jinzhou Su (1): test/amdgpu: remove static varible in Syncobj test Lang Yu (2): drm/tests/amdgpu: fix Metadata test failed issue tests/amdgpu: fix bo eviction test issue Leo Liu (4): amdgpu_drm: sync up with the latest amdgpu_drm.h based on drm-next (https://cgit.freedesktop.org/drm/drm) amdgpu: sync up amdgpu_drm.h with latest from kernel amdgpu: add function of INFO ioctl for querying video caps Bump version to 2.4.105 Simon Ser (4): xf86drmMode: add drmIsKMS xf86drm: warn about GEM handle reference counting xf86drmMode: introduce drmModeGetPropertyType xf86drmMode: set FB_MODIFIERS flag when modifiers are supplied Sonny Jiang (1): tests/amdgpu/vcn: clean abundant codes Tao Zhou (1): tests/amdgpu: add vcn test support for navy_flounder Tejas Upadhyay (3): intel: sync i915_pciids.h with kernel intel: add INTEL_ADLS_IDS to the pciids list intel: Add support for JSL Valentin Churavy (1): Use dep_rt in amdgpu/meson.build Victor Hugo Vianna Silva (1): Avoid some compiler errors for tests/util/pattern.c git tag: libdrm-2.4.105 https://dri.freedesktop.org/libdrm/libdrm-2.4.105.tar.xz SHA256: 1d1d024b7cadc63e2b59cddaca94f78864940ab440843841113fbac6afaf2a46 libdrm-2.4.105.tar.xz SHA512: 083a04af7208e58be21b89c6ebdbe2db3ba00cd29f0d271bd38bfe97dfca741edafddaaf9b5b95c20fac2c9b700434ea5b21397de26f7073169ad6f5b090f715 libdrm-2.4.105.tar.xz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.105.tar.xz.sig ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
On Wed, Apr 07, 2021 at 03:50:35PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/7/21 2:34 PM, Ville Syrjälä wrote:
> > On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/25/21 12:48 PM, Hans de Goede wrote:
> >>> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> >>> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> >>> Predia Basic tablet would no longer properly light up after reboot.
> >>>
> >>> I've managed to reproduce this without rebooting by doing:
> >>> chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
> >>> echo 0 > /sys/class/graphics/fb0/blank
> >>>
> >>> Which rapidly turns the panel off and back on again.
> >>>
> >>> The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various
> >>> delays
> >>> used for panel on/off, since starting with MIPI-sequences version >= 3 the
> >>> delays are already included inside the MIPI-sequences.
> >>>
> >>> The problems exposed by the "Shut down displays gracefully on reboot"
> >>> change, show that using this helper for the panel_pwr_cycle_delay is
> >>> not the right thing to do. This has not been noticed until now because
> >>> normally the panel never is cycled off and directly on again in quick
> >>> succession.
> >>>
> >>> Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
> >>> call to avoid the panel staying black after a quick off + on cycle.
> >>>
> >>> Cc: Ville Syrjälä
> >>> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
> >>> Signed-off-by: Hans de Goede
> >>
> >> Ping? Ville AFAICT this is ready for merging, can you review this please
> >> so that I can push it to drm-intel-next ?
> >
> > Didn't get the original mail, but lgtm.
>
> Yeah, these bounced I mentioned that in a p.s. in one of the emails
> in our private threads about the mail issues, with patchwork links,
> but I guess the p.s. was hidden in all the other stuff in that thread.
> Anyways this is solved now.
>
> > Reviewed-by: Ville Syrjälä
>
> Thank you, note this is patch 1/2 does the Reviewed-by apply to
> both? Patch 2/2 is here:
>
> https://patchwork.freedesktop.org/patch/425983/
That one looks good as well.
Reviewed-by: Ville Syrjälä
>
> Regards,
>
> Hans
>
>
>
>
> >>> ---
> >>> drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >>> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >>> index d5a3f69c5df3..38d5a1f3ded5 100644
> >>> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >>> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >>> @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct
> >>> intel_atomic_state *state,
> >>>* FIXME As we do with eDP, just make a note of the time here
> >>>* and perform the wait before the next panel power on.
> >>>*/
> >>> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> >>> + msleep(intel_dsi->panel_pwr_cycle_delay);
> >>> }
> >>>
> >>> static void intel_dsi_shutdown(struct intel_encoder *encoder)
> >>> {
> >>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> >>>
> >>> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> >>> + msleep(intel_dsi->panel_pwr_cycle_delay);
> >>> }
> >>>
> >>> static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
> >>>
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/doc: emphasize difference between plane formats and IN_FORMATS blob
On Tue, Apr 06, 2021 at 04:21:18PM -0300, Leandro Ribeiro wrote:
> Emphasize how userspace should use the plane format list
> (format_type_ptr) and the IN_FORMATS blob property.
>
> Formats exposed in the plane format list (format_type_ptr) do not
> require modifiers, and formats that are present in the IN_FORMATS blob
> property support modifiers.
>
> Note that these are not disjoint sets. If a format supports modifiers
> but the driver can also handle it without a modifier, it should be
> present in both the IN_FORMATS blob property and the plane format list.
>
> Signed-off-by: Leandro Ribeiro
> ---
> drivers/gpu/drm/drm_plane.c | 4
> include/uapi/drm/drm_mode.h | 3 +++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..b48d9bd81a59 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,10 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * To find out the list of buffer formats which are supported without a
> + * modifier, userspace should not look at this blob property, but at the
> + * formats list of the plane: _mode_get_plane.format_type_ptr.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 96fc9a6da608..4293800ec095 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -340,6 +340,9 @@ struct drm_mode_get_plane {
> /**
>* @format_type_ptr: Pointer to ``__u32`` array of formats that are
>* supported by the plane. These formats do not require modifiers.
> + *
> + * To find out the list of formats that support modifiers, userspace
> + * must use the plane IN_FORMATS blob property.
>*/
Addfb2+modifiers predates the IN_FORMATS blob, so this doesn't
match reality.
> __u64 format_type_ptr;
> };
> --
> 2.31.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
Hi,
On 4/7/21 2:34 PM, Ville Syrjälä wrote:
> On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 3/25/21 12:48 PM, Hans de Goede wrote:
>>> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
>>> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
>>> Predia Basic tablet would no longer properly light up after reboot.
>>>
>>> I've managed to reproduce this without rebooting by doing:
>>> chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
>>> echo 0 > /sys/class/graphics/fb0/blank
>>>
>>> Which rapidly turns the panel off and back on again.
>>>
>>> The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
>>> used for panel on/off, since starting with MIPI-sequences version >= 3 the
>>> delays are already included inside the MIPI-sequences.
>>>
>>> The problems exposed by the "Shut down displays gracefully on reboot"
>>> change, show that using this helper for the panel_pwr_cycle_delay is
>>> not the right thing to do. This has not been noticed until now because
>>> normally the panel never is cycled off and directly on again in quick
>>> succession.
>>>
>>> Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
>>> call to avoid the panel staying black after a quick off + on cycle.
>>>
>>> Cc: Ville Syrjälä
>>> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
>>> Signed-off-by: Hans de Goede
>>
>> Ping? Ville AFAICT this is ready for merging, can you review this please so
>> that I can push it to drm-intel-next ?
>
> Didn't get the original mail, but lgtm.
Yeah, these bounced I mentioned that in a p.s. in one of the emails
in our private threads about the mail issues, with patchwork links,
but I guess the p.s. was hidden in all the other stuff in that thread.
Anyways this is solved now.
> Reviewed-by: Ville Syrjälä
Thank you, note this is patch 1/2 does the Reviewed-by apply to
both? Patch 2/2 is here:
https://patchwork.freedesktop.org/patch/425983/
Regards,
Hans
>>> ---
>>> drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
>>> b/drivers/gpu/drm/i915/display/vlv_dsi.c
>>> index d5a3f69c5df3..38d5a1f3ded5 100644
>>> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
>>> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
>>> @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct
>>> intel_atomic_state *state,
>>> * FIXME As we do with eDP, just make a note of the time here
>>> * and perform the wait before the next panel power on.
>>> */
>>> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
>>> + msleep(intel_dsi->panel_pwr_cycle_delay);
>>> }
>>>
>>> static void intel_dsi_shutdown(struct intel_encoder *encoder)
>>> {
>>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>>>
>>> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
>>> + msleep(intel_dsi->panel_pwr_cycle_delay);
>>> }
>>>
>>> static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
>>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/doc: document drm_mode_get_plane
On Tue, Apr 06, 2021 at 04:21:17PM -0300, Leandro Ribeiro wrote:
> Add a small description and document struct fields of
> drm_mode_get_plane.
>
> Signed-off-by: Leandro Ribeiro
> ---
> include/uapi/drm/drm_mode.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index d1a93d2a85f9..96fc9a6da608 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -312,16 +312,35 @@ struct drm_mode_set_plane {
> __u32 src_w;
> };
>
> +/**
> + * struct drm_mode_get_plane - Get plane metadata.
> + *
> + * Userspace can perform a GETPLANE ioctl to retrieve information about a
> + * plane.
> + */
> struct drm_mode_get_plane {
> + /** @plane_id: Object ID of the plane. */
> __u32 plane_id;
>
> + /** @crtc_id: Object ID of the current CRTC. */
> __u32 crtc_id;
> + /** @fb_id: Object ID of the current fb. */
> __u32 fb_id;
>
> + /**
> + * @possible_crtcs: Pointer to ``__u32`` array of CRTC's that are
> + * compatible with the plane.
> + */
It's a bitmask.
> __u32 possible_crtcs;
> + /** @gamma_size: Size of the legacy gamma table. */
> __u32 gamma_size;
>
> + /** @count_format_types: Number of formats. */
> __u32 count_format_types;
> + /**
> + * @format_type_ptr: Pointer to ``__u32`` array of formats that are
> + * supported by the plane. These formats do not require modifiers.
> + */
> __u64 format_type_ptr;
> };
>
> --
> 2.31.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: remove unneeded variable ret
This patch fix coccicheck warning:
drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret". Return "0"
on line 880
Also remove unneeded function return value check.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/msm/dp/dp_link.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da78c4a..3395b08155a6 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -843,10 +843,8 @@ bool dp_link_send_edid_checksum(struct dp_link *dp_link,
u8 checksum)
return ret == 1;
}
-static int dp_link_parse_vx_px(struct dp_link_private *link)
+static void dp_link_parse_vx_px(struct dp_link_private *link)
{
- int ret = 0;
-
DRM_DEBUG_DP("vx: 0=%d, 1=%d, 2=%d, 3=%d\n",
drm_dp_get_adjust_request_voltage(link->link_status, 0),
drm_dp_get_adjust_request_voltage(link->link_status, 1),
@@ -876,8 +874,6 @@ static int dp_link_parse_vx_px(struct dp_link_private *link)
DRM_DEBUG_DP("Requested: v_level = 0x%x, p_level = 0x%x\n",
link->dp_link.phy_params.v_level,
link->dp_link.phy_params.p_level);
-
- return ret;
}
/**
@@ -891,8 +887,6 @@ static int dp_link_parse_vx_px(struct dp_link_private *link)
static int dp_link_process_phy_test_pattern_request(
struct dp_link_private *link)
{
- int ret = 0;
-
if (!(link->request.test_requested & DP_TEST_LINK_PHY_TEST_PATTERN)) {
DRM_DEBUG_DP("no phy test\n");
return -EINVAL;
@@ -918,12 +912,9 @@ static int dp_link_process_phy_test_pattern_request(
link->dp_link.link_params.rate =
drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
- ret = dp_link_parse_vx_px(link);
-
- if (ret)
- DRM_ERROR("parse_vx_px failed. ret=%d\n", ret);
+ dp_link_parse_vx_px(link);
- return ret;
+ return 0;
}
static u8 get_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Call for an EDID parsing library
On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote: > FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd > definitely be interested in using such as library. A C API with no > dependencies is pretty important from my point-of-view. > > I'd prefer if C++ was not used at all (and could almost be baited into > doing the work if that were the case), but it seems that ship has > sailed already. The same for Mutter / GNOME, not having to maintain a EDID parser would be great. Though personally I don't care if it's implemented in C++, C or whatever, as long as there is a C API to use. Jonas > > Simon > ___ > wayland-devel mailing list > wayland-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND -next] drm: kirin: Remove redundant dev_err call in ade_hw_ctx_alloc()
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reported-by: Hulk Robot
Signed-off-by: Wei Li
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 6dcf9ec05eec..78a792048c42 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -857,10 +857,8 @@ static void *ade_hw_ctx_alloc(struct platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ctx->base = devm_ioremap_resource(dev, res);
- if (IS_ERR(ctx->base)) {
- DRM_ERROR("failed to remap ade io base\n");
+ if (IS_ERR(ctx->base))
return ERR_PTR(-EIO);
- }
ctx->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(ctx->reset))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
Hi Dmitry, On Wed, 7 Apr 2021 at 08:06, Dmitry Baryshkov wrote: > > devm_clk_hw_register_fixed_factor_release(), the release function for > the devm_clk_hw_register_fixed_factor(), calls > clk_hw_unregister_fixed_factor(), which will kfree() the clock. However > after that the devres functions will also kfree the allocated data, > resulting in double free/memory corruption. Just call > clk_hw_unregister() instead, leaving kfree() to devres code. Doh. Sorry for not spotting this when I wrote the patch. Thank you for cleaning up after me. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: xlnx: zynqmp: fix a memset in zynqmp_dp_train()
On 3/30/21 11:31 AM, Dan Carpenter wrote:
> The dp->train_set[] for this driver is only two characters, not four so
> this memsets too much. Fortunately, this ends up corrupting a struct
> hole and not anything important.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 99158ee67d02..59d1fb017da0 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -866,7 +866,7 @@ static int zynqmp_dp_train(struct zynqmp_dp *dp)
> return ret;
>
> zynqmp_dp_write(dp, ZYNQMP_DP_SCRAMBLING_DISABLE, 1);
> - memset(dp->train_set, 0, 4);
> + memset(dp->train_set, 0, sizeof(dp->train_set));
> ret = zynqmp_dp_link_train_cr(dp);
> if (ret)
> return ret;
>
Reviewed-by: Michal Simek
Thanks,
Michal
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
> Hi,
>
> On 3/25/21 12:48 PM, Hans de Goede wrote:
> > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> > displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> > Predia Basic tablet would no longer properly light up after reboot.
> >
> > I've managed to reproduce this without rebooting by doing:
> > chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
> > echo 0 > /sys/class/graphics/fb0/blank
> >
> > Which rapidly turns the panel off and back on again.
> >
> > The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
> > used for panel on/off, since starting with MIPI-sequences version >= 3 the
> > delays are already included inside the MIPI-sequences.
> >
> > The problems exposed by the "Shut down displays gracefully on reboot"
> > change, show that using this helper for the panel_pwr_cycle_delay is
> > not the right thing to do. This has not been noticed until now because
> > normally the panel never is cycled off and directly on again in quick
> > succession.
> >
> > Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
> > call to avoid the panel staying black after a quick off + on cycle.
> >
> > Cc: Ville Syrjälä
> > Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
> > Signed-off-by: Hans de Goede
>
> Ping? Ville AFAICT this is ready for merging, can you review this please so
> that I can push it to drm-intel-next ?
Didn't get the original mail, but lgtm.
Reviewed-by: Ville Syrjälä
>
> Regards,
>
> Hans
>
>
> > ---
> > drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> > b/drivers/gpu/drm/i915/display/vlv_dsi.c
> > index d5a3f69c5df3..38d5a1f3ded5 100644
> > --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> > @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct
> > intel_atomic_state *state,
> > * FIXME As we do with eDP, just make a note of the time here
> > * and perform the wait before the next panel power on.
> > */
> > - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> > + msleep(intel_dsi->panel_pwr_cycle_delay);
> > }
> >
> > static void intel_dsi_shutdown(struct intel_encoder *encoder)
> > {
> > struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> >
> > - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> > + msleep(intel_dsi->panel_pwr_cycle_delay);
> > }
> >
> > static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi,
Am 06.04.21 um 17:27 schrieb Felix Kuehling:
Am 2021-04-06 um 6:38 a.m. schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
This change resolves several inconsistencies between regular mmap and
prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
areas. Previously it way only set for regular mmap calls, prime-based
mmap used TTM's default vm_ops. The check for kfd_bo has been taken
from amdgpu_verify_access(), which is not called any longer and has
been removed.
As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
implemented in amdgpu's GEM code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 46 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 64 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 71
-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
6 files changed, 66 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e0c4f7c7f1b9..19c5ab08d9ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -42,52 +42,6 @@
#include
#include
-/**
- * amdgpu_gem_prime_mmap - _driver.gem_prime_mmap implementation
- * @obj: GEM BO
- * @vma: Virtual memory area
- *
- * Sets up a userspace mapping of the BO's memory in the given
- * virtual memory area.
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- */
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
- unsigned asize = amdgpu_bo_size(bo);
- int ret;
-
- if (!vma->vm_file)
- return -ENODEV;
-
- if (adev == NULL)
- return -ENODEV;
-
- /* Check for valid size. */
- if (asize < vma->vm_end - vma->vm_start)
- return -EINVAL;
-
- if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
- (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)) {
- return -EPERM;
- }
- vma->vm_pgoff += amdgpu_bo_mmap_offset(bo) >> PAGE_SHIFT;
-
- /* prime mmap does not need to check access, so allow here */
- ret = drm_vma_node_allow(>vma_node,
vma->vm_file->private_data);
- if (ret)
- return ret;
-
- ret = ttm_bo_mmap(vma->vm_file, vma, >mman.bdev);
- drm_vma_node_revoke(>vma_node, vma->vm_file->private_data);
-
- return ret;
-}
-
static int
__dma_resv_make_exclusive(struct dma_resv *obj)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index 39b5b9616fd8..3e93b9b407a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -31,8 +31,6 @@ struct drm_gem_object
*amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf);
bool amdgpu_dmabuf_is_xgmi_accessible(struct amdgpu_device *adev,
struct amdgpu_bo *bo);
-int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
extern const struct dma_buf_ops amdgpu_dmabuf_ops;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 76f48f79c70b..e96d2758f4bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1656,7 +1656,7 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
.flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
- .mmap = amdgpu_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#ifdef CONFIG_COMPAT
@@ -1719,7 +1719,7 @@ static const struct drm_driver
amdgpu_kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = amdgpu_gem_prime_import,
- .gem_prime_mmap = amdgpu_gem_prime_mmap,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fb7171e5507c..fe93faad05f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -41,6 +41,36 @@
static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
Please name that function amdgpu_gem_fault or amdgpu_gem_object_fault
+{
+ struct ttm_buffer_object *bo =
Re: Call for an EDID parsing library
On 07/04/2021 12:31, Jani Nikula wrote: > On Wed, 07 Apr 2021, Hans Verkuil wrote: >> It is the most complete EDID parser I know based on the various standards. > > Does it support pure DisplayID in addition to DisplayID blocks embedded > to EDID extension blocks? I think we'll be needing that sometime in the > near future. (We don't yet support that in the kernel either.) It doesn't, but that shouldn't be too hard to implement. Do you have examples of that? If I had some, then I could implement support for it in edid-decode. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Call for an EDID parsing library
FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd definitely be interested in using such as library. A C API with no dependencies is pretty important from my point-of-view. I'd prefer if C++ was not used at all (and could almost be baited into doing the work if that were the case), but it seems that ship has sailed already. Simon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/pm: convert sysfs snprintf to sysfs_emit
Am 06.04.21 um 16:11 schrieb Carlis: From: Xuezhi Zhang Fix the following coccicheck warning: drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2022:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:294:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:154:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:496:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:512:9-17: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:1740:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:1667:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2074:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2047:9-17: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2768:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2738:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2442:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3246:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3253:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2458:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3047:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3133:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3209:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3216:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2410:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2496:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2470:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2426:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2965:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:2972:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3006:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/amd/pm//amdgpu_pm.c:3013:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Xuezhi Zhang Acked-by: Christian König --- drivers/gpu/drm/amd/pm/amdgpu_pm.c | 58 +++--- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index 5fa65f191a37..2777966ec1ca 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -151,7 +151,7 @@ static ssize_t amdgpu_get_power_dpm_state(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", (pm == POWER_STATE_TYPE_BATTERY) ? "battery" : (pm == POWER_STATE_TYPE_BALANCED) ? "balanced" : "performance"); } @@ -291,7 +291,7 @@ static ssize_t amdgpu_get_power_dpm_force_performance_level(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", (level == AMD_DPM_FORCED_LEVEL_AUTO) ? "auto" : (level == AMD_DPM_FORCED_LEVEL_LOW) ? "low" : (level == AMD_DPM_FORCED_LEVEL_HIGH) ? "high" : @@ -493,7 +493,7 @@ static ssize_t amdgpu_get_pp_cur_state(struct device *dev, if (i == data.nums) i = -EINVAL; - return snprintf(buf, PAGE_SIZE, "%d\n", i); + return sysfs_emit(buf, "%d\n", i); } static ssize_t amdgpu_get_pp_force_state(struct device *dev, @@ -509,7 +509,7 @@ static ssize_t amdgpu_get_pp_force_state(struct device *dev, if (adev->pp_force_state_enabled) return amdgpu_get_pp_cur_state(dev, attr, buf); else - return snprintf(buf, PAGE_SIZE, "\n"); + return sysfs_emit(buf, "\n"); } static ssize_t amdgpu_set_pp_force_state(struct device *dev, @@ -1664,7 +1664,7 @@ static ssize_t amdgpu_get_pp_sclk_od(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%d\n", value); + return sysfs_emit(buf, "%d\n", value); } static ssize_t amdgpu_set_pp_sclk_od(struct device *dev, @@ -1737,7 +1737,7 @@ static ssize_t amdgpu_get_pp_mclk_od(struct device *dev, pm_runtime_mark_last_busy(ddev->dev); pm_runtime_put_autosuspend(ddev->dev); - return snprintf(buf, PAGE_SIZE, "%d\n", value);
Re: [PATCH v4 6/6] drm/sprd: add Unisoc's drm mipi dsi driver
On Wed, Mar 31, 2021 at 09:47:12AM +0800, Kevin Tang wrote: > > > diff --git a/drivers/gpu/drm/sprd/Makefile > > b/drivers/gpu/drm/sprd/Makefile > > > index 6c25bfa99..d49f4977b 100644 > > > --- a/drivers/gpu/drm/sprd/Makefile > > > +++ b/drivers/gpu/drm/sprd/Makefile > > > @@ -1,5 +1,8 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > obj-y := sprd_drm.o \ > > > - sprd_dpu.o > > > - > > > + sprd_dpu.o \ > > > + sprd_dsi.o \ > > > + dw_dsi_ctrl.o \ > > > + dw_dsi_ctrl_ppi.o \ > > > > So it's a designware IP? There's a driver for it already that seems > > fairly similar: > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > > > Our dw dsi controller is not a standard synopsys ip, we have updated a lot > on the basic ip version, > the entire control register is different, i have cc to drm/bridge reviewers > and maintainers. You should make it more obvious then in a comment or in the name of the driver. If it's fairly different from the original IP from Synopsys, maybe you should just drop the reference to the name? Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/6] dt-bindings: display: add Unisoc's mipi dsi controller bindings
On Wed, Mar 31, 2021 at 09:49:14AM +0800, Kevin Tang wrote: > Hi Maxime, > > Maxime Ripard 于2021年3月24日周三 下午7:13写道： > > > On Mon, Feb 22, 2021 at 09:28:21PM +0800, Kevin Tang wrote: > > > From: Kevin Tang > > > > > > Adds MIPI DSI Controller > > > support for Unisoc's display subsystem. > > > > > > Cc: Orson Zhai > > > Cc: Chunyan Zhang > > > Signed-off-by: Kevin Tang > > > Reviewed-by: Rob Herring > > > --- > > > .../display/sprd/sprd,sharkl3-dsi-host.yaml | 102 ++ > > > 1 file changed, 102 insertions(+) > > > create mode 100644 > > Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > > > > > diff --git > > a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > > new file mode 100644 > > > index 0..d439f688f > > > --- /dev/null > > > +++ > > b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml > > > @@ -0,0 +1,102 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Unisoc MIPI DSI Controller > > > + > > > +maintainers: > > > + - Kevin Tang > > > + > > > +properties: > > > + compatible: > > > +const: sprd,sharkl3-dsi-host > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + interrupts: > > > +maxItems: 2 > > > + > > > + clocks: > > > +minItems: 1 > > > + > > > + clock-names: > > > +items: > > > + - const: clk_src_96m > > > + > > > + power-domains: > > > +maxItems: 1 > > > + > > > + ports: > > > +type: object > > > + > > > +properties: > > > + "#address-cells": > > > +const: 1 > > > + > > > + "#size-cells": > > > +const: 0 > > > + > > > + port@0: > > > +type: object > > > +description: > > > + A port node with endpoint definitions as defined in > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. > > > + That port should be the input endpoint, usually coming from > > > + the associated DPU. > > > + port@1: > > > +type: object > > > +description: > > > + A port node with endpoint definitions as defined in > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. > > > + That port should be the output endpoint, usually output to > > > + the associated panel. > > > > The DSI generic binding asks that peripherals that are controlled > > through a DCS be a subnode of the MIPI-DSI bus, not through a port > > endpoint. > > > Our DSI controller don't support DCS now... I'm not sure I follow you, you mentionned in the patch 4 that you were testing for a device to be in command mode, how would that work without DCS support? Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/6] drm/sprd: add Unisoc's drm display controller driver
Hi,
Adding Jörg, Will and Robin,
On Wed, Mar 31, 2021 at 09:21:19AM +0800, Kevin Tang wrote:
> > > +static u32 check_mmu_isr(struct sprd_dpu *dpu, u32 reg_val)
> > > +{
> > > + struct dpu_context *ctx = >ctx;
> > > + u32 mmu_mask = BIT_DPU_INT_MMU_VAOR_RD |
> > > + BIT_DPU_INT_MMU_VAOR_WR |
> > > + BIT_DPU_INT_MMU_INV_RD |
> > > + BIT_DPU_INT_MMU_INV_WR;
> > > + u32 val = reg_val & mmu_mask;
> > > + int i;
> > > +
> > > + if (val) {
> > > + drm_err(dpu->drm, "--- iommu interrupt err: 0x%04x ---\n",
> > val);
> > > +
> > > + if (val & BIT_DPU_INT_MMU_INV_RD)
> > > + drm_err(dpu->drm, "iommu invalid read error, addr:
> > 0x%08x\n",
> > > + readl(ctx->base + REG_MMU_INV_ADDR_RD));
> > > + if (val & BIT_DPU_INT_MMU_INV_WR)
> > > + drm_err(dpu->drm, "iommu invalid write error,
> > addr: 0x%08x\n",
> > > + readl(ctx->base + REG_MMU_INV_ADDR_WR));
> > > + if (val & BIT_DPU_INT_MMU_VAOR_RD)
> > > + drm_err(dpu->drm, "iommu va out of range read
> > error, addr: 0x%08x\n",
> > > + readl(ctx->base + REG_MMU_VAOR_ADDR_RD));
> > > + if (val & BIT_DPU_INT_MMU_VAOR_WR)
> > > + drm_err(dpu->drm, "iommu va out of range write
> > error, addr: 0x%08x\n",
> > > + readl(ctx->base + REG_MMU_VAOR_ADDR_WR));
> >
> > Is that the IOMMU page fault interrupt? I would expect it to be in the
> > iommu driver.
>
> Our iommu driver is indeed an separate driver, and also in upstreaming,
> but iommu fault interrupts reporting by display controller, not iommu
> itself,
> if use iommu_set_fault_handler() to hook in our reporting function, there
> must be cross-module access to h/w registers.
Can you explain a bit more the design of the hardware then? Each device
connected to the IOMMU has a status register (and an interrupt) that
reports when there's a fault?
I'd like to get an ack at least from the IOMMU maintainers and
reviewers.
> > > +static void sprd_dpi_init(struct sprd_dpu *dpu)
> > > +{
> > > + struct dpu_context *ctx = >ctx;
> > > + u32 int_mask = 0;
> > > + u32 reg_val;
> > > +
> > > + if (ctx->if_type == SPRD_DPU_IF_DPI) {
> > > + /* use dpi as interface */
> > > + dpu_reg_clr(ctx, REG_DPU_CFG0, BIT_DPU_IF_EDPI);
> > > + /* disable Halt function for SPRD DSI */
> > > + dpu_reg_clr(ctx, REG_DPI_CTRL, BIT_DPU_DPI_HALT_EN);
> > > + /* select te from external pad */
> > > + dpu_reg_set(ctx, REG_DPI_CTRL,
> > BIT_DPU_EDPI_FROM_EXTERNAL_PAD);
> > > +
> > > + /* set dpi timing */
> > > + reg_val = ctx->vm.hsync_len << 0 |
> > > + ctx->vm.hback_porch << 8 |
> > > + ctx->vm.hfront_porch << 20;
> > > + writel(reg_val, ctx->base + REG_DPI_H_TIMING);
> > > +
> > > + reg_val = ctx->vm.vsync_len << 0 |
> > > + ctx->vm.vback_porch << 8 |
> > > + ctx->vm.vfront_porch << 20;
> > > + writel(reg_val, ctx->base + REG_DPI_V_TIMING);
> > > +
> > > + if (ctx->vm.vsync_len + ctx->vm.vback_porch < 32)
> > > + drm_warn(dpu->drm, "Warning: (vsync + vbp) < 32, "
> > > + "underflow risk!\n");
> >
> > I don't think a warning is appropriate here. Maybe we should just
> > outright reject any mode that uses it?
> >
> This issue has been fixed on the new soc, maybe I should remove it.
If it still requires a workaround on older SoC, you can definitely add
it but we should prevent any situation where the underflow might occur
instead of reporting it once we're there.
> > > +static enum drm_mode_status sprd_crtc_mode_valid(struct drm_crtc *crtc,
> > > + const struct drm_display_mode
> > *mode)
> > > +{
> > > + struct sprd_dpu *dpu = to_sprd_crtc(crtc);
> > > +
> > > + drm_dbg(dpu->drm, "%s() mode: "DRM_MODE_FMT"\n", __func__,
> > DRM_MODE_ARG(mode));
> > > +
> > > + if (mode->type & DRM_MODE_TYPE_PREFERRED) {
> > > + drm_display_mode_to_videomode(mode, >ctx.vm);
> >
> > You don't seem to use that anywhere else? And that's a bit fragile,
> > nothing really guarantees that it's the mode you're going to use, and
> > even then it can be adjusted.
> >
> drm_mode convert to video_mode is been use in "sprd_dpu_init" and
> "sprd_dpi_init "
> Preferred mode should be fixed mode, we generally don’t adjust it.
That's not really the assumption DRM is built upon though. The userspace
is even allowed to setup its own mode and try to configure it, and your
driver should take that into account.
I'd just drop that mode_valid hook, and retrieve the videomode if you
need it in atomic_enable or
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
Yes, that was the one I was talking about. Ok, good to know that this is fixed. Regards, Christian. Am 07.04.21 um 10:50 schrieb Chen, Guchun: [AMD Public Use] Hi Felix and Christian, If the regression you are talking about is the NULL pointer problem when running KFD tests, it should fixed by below patch in this series. drm/amdgpu: fix NULL pointer dereference Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Wednesday, April 7, 2021 2:57 PM To: Kuehling, Felix ; Deucher, Alexander ; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; airl...@gmail.com; daniel.vet...@ffwll.ch Subject: Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13 Am 06.04.21 um 17:42 schrieb Felix Kuehling: Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher: Hi Dave, Daniel, New stuff for 5.13. There are two small patches for ttm and scheduler that were dependencies for amdgpu changes. The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: Merge tag 'amd-drm-next-5.13-2021-03-23' of https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit lab.freedesktop.org%2Fagd5f%2Flinuxdata=04%7C01%7Cguchun.chen%40 amd.com%7C51d1cbcf7ccc43854abb08d8f99250d8%7C3dd8961fe4884e608e11a82d 994e183d%7C0%7C0%7C637533754128113017%7CUnknown%7CTWFpbGZsb3d8eyJWIjo iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 p;sdata=FcdoL9w5LhBZ849ctXPudr%2BBQnnm7Oiq3pz5X7LGGk4%3Dreserved =0 into drm-next (2021-03-26 15:53:21 +0100) are available in the Git repository at: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit lab.freedesktop.org%2Fagd5f%2Flinux.gitdata=04%7C01%7Cguchun.che n%40amd.com%7C51d1cbcf7ccc43854abb08d8f99250d8%7C3dd8961fe4884e608e11 a82d994e183d%7C0%7C0%7C637533754128113017%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 0sdata=N4JIk%2BEgzleaKYaxvdtT7TR1ZsS6FGsIGpDDUqiQiLw%3Drese rved=0 tags/amd-drm-next-5.13-2021-04-01 for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 -0400) amd-drm-next-5.13-2021-04-01: amdgpu: - Re-enable GPU reset on VanGogh - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME - Disentangle HG from vga_switcheroo - S0ix fixes - W=1 fixes - Resource iterator fixes - DMCUB updates - UBSAN fixes - More PM API cleanup - Aldebaran updates - Modifier fixes - Enable VCN load balancing with asymmetric engines - Rework BO structs - Aldebaran reset support - Initial LTTPR display work - Display MALL fixes - Fall back to YCbCr420 when YCbCr444 fails - SR-IOV fixes - Misc cleanups and fixes radeon: - Typo fixes ttm: - Handle cached requests (required for Aldebaran) scheduler: - Fix runqueue selection when changing priorities (required to fix VCN load balancing) Alex Deucher (20): drm/amdgpu/display/dm: add missing parameter documentation drm/amdgpu: Add additional Sienna Cichlid PCI ID drm/amdgpu: add a dev_pm_ops prepare callback (v2) drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags (v2) drm/amdgpu: disentangle HG systems from vgaswitcheroo drm/amdgpu: rework S3/S4/S0ix state handling drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) drm/amdgpu: clean up non-DC suspend/resume handling drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) drm/amdgpu: re-enable suspend phase 2 for S0ix drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend drm/amdgpu: update comments about s0ix suspend/resume drm/amdgpu: drop S0ix checks around CG/PG in suspend drm/amdgpu: skip kfd suspend/resume for S0ix drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x drm/amdgpu/display: fix memory leak for dimgrey cavefish drm/amdgpu/pm: mark pcie link/speed arrays as const drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend drm/amdgpu/display: fix warning on 32 bit in dmub Alex Sierra (2): drm/amdgpu: replace per_device_list by array drm/amdgpu: ih reroute for newer asics than vega20 Alvin Lee (1): drm/amd/display: Change input parameter for set_drr Anson Jacob (2): drm/amd/display: Fix UBSAN: shift-out-of-bounds warning drm/amd/display: Removing unused code from dmub_cmd.h Anthony Koo (2): drm/amd/display: [FW Promotion] Release 0.0.57 drm/amd/display: [FW Promotion] Release 0.0.58 Aric Cyr (2): drm/amd/display: 3.2.128 drm/amd/display: 3.2.129 Arnd Bergmann (3): amdgpu: avoid incorrect %hu format string amdgpu: fix gcc
Re: Call for an EDID parsing library
On Wed, 07 Apr 2021, Hans Verkuil wrote: > It is the most complete EDID parser I know based on the various standards. Does it support pure DisplayID in addition to DisplayID blocks embedded to EDID extension blocks? I think we'll be needing that sometime in the near future. (We don't yet support that in the kernel either.) BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for SN65DSI83/84/85
Hi again, On Wed, Mar 24, 2021 at 02:56:37PM +0100, Claudius Heine wrote: > Hi Jagan, > > On 2021-02-14 18:44, Jagan Teki wrote: > > SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge > > controller IC's from Texas Instruments. > > > > SN65DSI83 - Single Channel DSI to Single-link LVDS bridge > > SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge > > SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge > > > > Right now the bridge driver is supporting Channel A with single > > link, so dt-bindings documented according to it. > > Do you know when we can expect a v4 for this? > > I am currently working on top of your patch set to setup a dual-link LVDS > bridge of SN65DSI84. Ping ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
On 3/22/21 11:29 AM, Marek Vasut wrote: On 3/22/21 2:14 AM, Laurent Pinchart wrote: Hi Marek, Hi, [...] diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index e5e3c72630cf..399a6528780a 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -74,6 +74,13 @@ properties: additionalProperties: false + pixelclk-active: + description: | + Data sampling on rising or falling edge. + Use 0 to sample pixel data on rising edge and + Use 1 to sample pixel data on falling edge and + enum: [0, 1] The idea is good, but instead of adding a custom property, how about reusing the pclk-sample property defined in ../../media/video-interfaces.yaml ? Repeating myself from V1 discussion ... Either is fine by me, but I think pixelclk-active, which comes from panel-timings.yaml is closer to the video than multimedia bindings. Was there ever any reply from Rob on this ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Thanks, I will do that. 在 2021/4/7 16:03, Robert Foss 写道: Yes, you are right, there are many files reference gpiod_set_value_cansleep() and devm_gpiod_get_optional(). How about add config dependencies for all releated I think this is the way to go and roughly half of the drm bridge drivers seem to need this change. Do you mind submitting a series of patches adding this fix for all of the relevant bridge drivers? configs or only add config dependencies for the top level config? . ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/nouveau/kms: remove unused local variable 'width'
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/nouveau/nouveau_display.c: In function
‘nouveau_framebuffer_new’:
drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable ‘width’ set
but not used [-Wunused-but-set-variable]
Fixes: 4f5746c863db ("drm/nouveau/kms: Check framebuffer size against bo")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/nouveau/nouveau_display.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 17831ee897ea46d..7d3b1f8de300784 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -306,7 +306,7 @@
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct drm_framebuffer *fb;
const struct drm_format_info *info;
- unsigned int width, height, i;
+ unsigned int height, i;
uint32_t tile_mode;
uint8_t kind;
int ret;
@@ -346,9 +346,6 @@
info = drm_get_format_info(dev, mode_cmd);
for (i = 0; i < info->num_planes; i++) {
- width = drm_format_info_plane_width(info,
- mode_cmd->width,
- i);
height = drm_format_info_plane_height(info,
mode_cmd->height,
i);
--
1.8.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Call for an EDID parsing library
Hi Pekka, On 07/04/2021 10:44, Pekka Paalanen wrote: > Hi all, > > with display servers proliferating thanks to Wayland, and the Linux > kernel exposing only a very limited set of information based on EDID > (rightfully so!), the need to interpret EDID blobs is spreading even > more. I would like to start the discussion about starting a project to > develop a shared library for parsing EDID blobs. This is not the first > time either, other people have suggested it years and years ago already, > but apparently it didn't quite materialise as far as I know. > > Right now, it seems that more or less every display server and other > KMS application is hand-rolling its own EDID parsing code, even for the > most trivial information (monitor make, model, and serial number). With > HDR and color management support coming to Wayland, the need to parse > more things out of EDID will only increase. These things are not > exposed by the kernel, and most of these things have no use for the > kernel either. > > My personal motivation for this is that I don't want to be developing > or reviewing yet another partial EDID parser implementation in Weston. > > I recall ponderings about sharing the same EDID parsing code between > the kernel and userspace, but I got the feeling that it would be a > hindrance in process more than a benefit from sharing code. It would > need to live in the kernel tree, to be managed with the kernel > development process, use the kernel "standard libraries", and adhere to > kernel programming style - all which are good and fine, but maybe also > more restricting than useful in this case. Therefore I would suggest a > userspace-only library. > > Everyone hand-rolling their own parsing code has the obvious > disadvantages. In the opposite, I would expect a new shared EDID > parsing library and project to: > - be hosted under gitlab.freedesktop.org > - be MIT licensed > - offer at least a C ABI > - employ mandatory Gitlab CI to ensure with sample EDID blobs that it > cannot regress > > Prior art can be found in various places. I believe Xorg xserver has > its battle-tested EDID parsing code. Ajax once played with the idea in > https://cgit.freedesktop.org/~ajax/libminitru/ . Then we have > https://git.linuxtv.org/edid-decode.git too which has code and test > data but not a C ABI (right?). Correct, I moved it to C++. It was never designed to be a library, it was primarily meant to turn an EDID into a human readable format. And these days it is also a very powerful tool to verify EDIDs. It is the most complete EDID parser I know based on the various standards. > It does not necessarily need to be a new project. Would edid-decode > project be open to adding a C library ABI? I would be open to that. The best way would be to create a C library that turns the EDID blocks into C structures, while edid-decode itself remains C++ and uses the C library to do the parsing. While edid-decode supports a large range of Extension Blocks, a C library could probably limit itself to the base block, CTA-861 blocks and DisplayID blocks. > > edid-decode is already MIT licensed and seems to have a lot of code, > too, but that's all I know for now. It is as far as I know the most complete parser. > > Would there be anyone interested to take lead or work on a project like > this? I can assist/advice and do code reviews, but I don't have the time myself to do the actual work. > > Personally I don't think I'd be working on it, but I would be really > happy to use it in Weston. > > Should it be a new project, or grow inside edid-decode or something > else? I think it would make sense if it is grown as a library used by edid-decode. The edid-decode utility is under active maintenance and follows the latest EDID standards, so that will probably help the quality of the library. My main requirement would be that the edid-decode functionality is not affected, especially the conformity checks are still performed. And that support for new/updated EDID standards can easily be implemented, but that's exactly what you would want in an edid library. > > I believe MIT license is important to have wide adoption of it. C ABI > similarly. Also that it would be a "small" library without heavy > dependencies. It shouldn't need any dependencies. edid-decode doesn't need any either except for -lm, which is probably not needed for the library part. > What do you think? Could anyone spare their time for this? Didn't you just volunteer? :-) :-) Regards, Hans > > Who would be interested in using it if this library appeared? > > > Thanks, > pq > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages
Am 07.04.21 um 09:47 schrieb Daniel Gomez: On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote: On Mon, Mar 22, 2021 at 6:34 AM Christian König wrote: Hi Daniel, Am 22.03.21 um 10:38 schrieb Daniel Gomez: On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote: This caused a regression in kfdtest in a large-buffer stress test after memory allocation for user pages fails: I'm sorry to hear that. BTW, I guess you meant amdgpu leak patch and not this one. Just some background for the mem leak patch if helps to understand this: The leak was introduce here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D0b988ca1c7c4c73983b4ea96ef7c2af2263c87ebdata=04%7C01%7CChristian.Koenig%40amd.com%7C65d21b6f02da409ac7b508d8f9997367%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533784761980218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2FeOQf12NBkC3YGZ7QW66%2FT%2FpyM3DjEb9IMbqUvISMfo%3Dreserved=0 where the bound status was introduced for all drm drivers including radeon and amdgpu. So this patch just reverts the logic to the original code but keeping the bound status. In my case, the binding code allocates the user pages memory and returns without bounding (at amdgpu_gtt_mgr_has_gart_addr). So, when the unbinding happens, the memory needs to be cleared to prevent the leak. Ah, now I understand what's happening here. Daniel your patch is not really correct. The problem is rather that we don't set the tt object to bound if it doesn't have a GTT address. Going to provide a patch for this. Did this patch ever land? I don't think so but I might send a v2 following Christian's comment if you guys agree. Somebody else already provided a patch which I reviewed, but I'm not sure if that landed either. Also, the patch here is for radeon but the pagefault issue reported by Felix is affected by the amdgpu one: radeon patch: drm/radeon/ttm: Fix memory leak userptr pages https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F20210318083236.43578-1-daniel%40qtec.com%2Fdata=04%7C01%7CChristian.Koenig%40amd.com%7C65d21b6f02da409ac7b508d8f9997367%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533784761980218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HSMK%2FqYz%2Bzz9qbKc%2FITUWluBDeaW9YrgyH8p0L640%2F0%3Dreserved=0 amdgpu patch: drm/amdgpu/ttm: Fix memory leak userptr pages https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F20210317160840.36019-1-daniel%40qtec.com%2Fdata=04%7C01%7CChristian.Koenig%40amd.com%7C65d21b6f02da409ac7b508d8f9997367%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533784761980218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UsUZ4YjCSjHmzlPB07oTaGrsntTrQSwlGk%2BxUjwDiag%3Dreserved=0 I assume both need to be fixed with the same approach. Yes correct. Let me double check where that fix went. Thanks, Christian. Daniel Alex Regards, Christian. [17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16 [17359.543746] BUG: kernel NULL pointer dereference, address: [17359.551494] #PF: supervisor read access in kernel mode [17359.557375] #PF: error_code(0x) - not-present page [17359.563247] PGD 0 P4D 0 [17359.566514] Oops: [#1] SMP PTI [17359.570728] CPU: 8 PID: 5944 Comm: kfdtest Not tainted 5.11.0-kfd-fkuehlin #193 [17359.578760] Hardware name: ASUS All Series/X99-E WS/USB 3.1, BIOS 3201 06/17/2016 [17359.586971] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 [amdgpu] [17359.594075] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 24 62 00 00 85 c0 0f 85 ab 00 00 00 c6 43 54 00 5b 5d c3 48 8b 46 10 8b 4e 50 <48> 8b 30 48 85 f6 74 ba 8b 50 0c 48 8b bf 80 a1 ff ff 83 e1 01 45 [17359.614340] RSP: 0018:a4764971fc98 EFLAGS: 00010206 [17359.620315] RAX: RBX: 950e8d4edf00 RCX: [17359.628204] RDX: RSI: 950e8d4edf00 RDI: 950eadec5e80 [17359.636084] RBP: 950eadec5e80 R08: R09: [17359.643958] R10: 0246 R11: 0001 R12: 950c03377800 [17359.651833] R13: 950eadec5e80 R14: 950c03377858 R15: [17359.659701] FS: 7febb20cb740() GS:950ebfc0() knlGS: [17359.668528] CS: 0010 DS: ES: CR0: 80050033 [17359.675012] CR2: CR3: 0006d700e005 CR4: 001706e0 [17359.682883] Call Trace: [17359.686063] amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu] [17359.692349] ttm_bo_cleanup_memtype_use+0x37/0x60 [ttm] [17359.698307] ttm_bo_release+0x278/0x5e0 [ttm] [17359.703385] amdgpu_bo_unref+0x1a/0x30 [amdgpu] [17359.708701]
Re: your mail
Thanks Ray for pointing this out. Looks like the mail ended up in my
spam folder otherwise.
Apart from that this patch is a really really big NAK. I can't count how
often I had to reject stuff like this!
Using the page reference for TTM pages is illegal and can lead to struct
page corruption.
Can you please describe why you need that?
Regards,
Christian.
Am 07.04.21 um 10:25 schrieb Huang Rui:
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
Signed-off-by: songqiang
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 14660f723f71..f3698f0ad4d7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned
npages, int flags,
if (++p != pages[i + j])
break;
-if (j == HPAGE_PMD_NR)
+ if (j == HPAGE_PMD_NR) {
order = HPAGE_PMD_ORDER;
+ for (j = 1; j < HPAGE_PMD_NR; ++j)
+ page_ref_dec(pages[i+j]);
+ }
}
#endif
@@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
if (!p)
break;
-
- for (j = 0; j < HPAGE_PMD_NR; ++j)
+ for (j = 0; j < HPAGE_PMD_NR; ++j) {
pages[i++] = p++;
-
+ if (j > 0)
+ page_ref_inc(pages[i-1]);
+ }
npages -= HPAGE_PMD_NR;
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Call for an EDID parsing library
On Wed, 7 Apr 2021 11:44:04 +0300 Pekka Paalanen said: > Hi all, > > with display servers proliferating thanks to Wayland, and the Linux > kernel exposing only a very limited set of information based on EDID > (rightfully so!), the need to interpret EDID blobs is spreading even > more. I would like to start the discussion about starting a project to > develop a shared library for parsing EDID blobs. This is not the first > time either, other people have suggested it years and years ago already, > but apparently it didn't quite materialise as far as I know. > > Right now, it seems that more or less every display server and other > KMS application is hand-rolling its own EDID parsing code, even for the > most trivial information (monitor make, model, and serial number). With > HDR and color management support coming to Wayland, the need to parse > more things out of EDID will only increase. These things are not > exposed by the kernel, and most of these things have no use for the > kernel either. > > My personal motivation for this is that I don't want to be developing > or reviewing yet another partial EDID parser implementation in Weston. > > I recall ponderings about sharing the same EDID parsing code between > the kernel and userspace, but I got the feeling that it would be a > hindrance in process more than a benefit from sharing code. It would > need to live in the kernel tree, to be managed with the kernel > development process, use the kernel "standard libraries", and adhere to > kernel programming style - all which are good and fine, but maybe also > more restricting than useful in this case. Therefore I would suggest a > userspace-only library. > > Everyone hand-rolling their own parsing code has the obvious > disadvantages. In the opposite, I would expect a new shared EDID > parsing library and project to: > - be hosted under gitlab.freedesktop.org > - be MIT licensed > - offer at least a C ABI > - employ mandatory Gitlab CI to ensure with sample EDID blobs that it > cannot regress > > Prior art can be found in various places. I believe Xorg xserver has > its battle-tested EDID parsing code. Ajax once played with the idea in > https://cgit.freedesktop.org/~ajax/libminitru/ . Then we have > https://git.linuxtv.org/edid-decode.git too which has code and test > data but not a C ABI (right?). > > It does not necessarily need to be a new project. Would edid-decode > project be open to adding a C library ABI? > > edid-decode is already MIT licensed and seems to have a lot of code, > too, but that's all I know for now. > > Would there be anyone interested to take lead or work on a project like > this? > > Personally I don't think I'd be working on it, but I would be really > happy to use it in Weston. > > Should it be a new project, or grow inside edid-decode or something > else? > > I believe MIT license is important to have wide adoption of it. C ABI > similarly. Also that it would be a "small" library without heavy > dependencies. I'd say it needs nothing more than libc - I can't see the justification for more than that. If this is the case along with the above you have given, then I see no reason for it to not be used by everyone other than the usual user complaint of "too many dependencies (of a compositor)". :) I'd definitely consider using it. > What do you think? Could anyone spare their time for this? > > Who would be interested in using it if this library appeared? > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] clk: fixed: fix double free in resource managed fixed-factor clock
On Wed, 7 Apr 2021 at 02:06, Dmitry Baryshkov
wrote:
>
> devm_clk_hw_register_fixed_factor_release(), the release function for
> the devm_clk_hw_register_fixed_factor(), calls
> clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> after that the devres functions will also kfree the allocated data,
> resulting in double free/memory corruption. Just call
> clk_hw_unregister() instead, leaving kfree() to devres code.
>
> Reported-by: Rob Clark
> Cc: Daniel Palmer
Forgot:
Fixes: 0b9266d295ce ("clk: fixed: add devm helper for
clk_hw_register_fixed_factor()")
> Signed-off-by: Dmitry Baryshkov
> ---
>
> Stephen, this fix affects the DSI PHY rework. Do we have a chance of
> getting it into 5.12, otherwise there will be a cross-dependency between
> msm-next and clk-next.
>
> ---
> drivers/clk/clk-fixed-factor.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
--
With best wishes
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Convert sysfs sprintf/snprintf family to sysfs_emit
On 3/30/21 2:25 AM, Tian Tao wrote:
Fix the following coccicheck warning:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING:
use scnprintf or sprintf
Signed-off-by: Tian Tao
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index ca891ae..cc7664c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -62,7 +62,7 @@ core_id_show(struct device *dev, struct device_attribute
*attr, char *buf)
{
struct komeda_dev *mdev = dev_to_mdev(dev);
- return snprintf(buf, PAGE_SIZE, "0x%08x\n", mdev->chip.core_id);
+ return sysfs_emit(buf, "0x%08x\n", mdev->chip.core_id);
}
static DEVICE_ATTR_RO(core_id);
@@ -85,7 +85,7 @@ config_id_show(struct device *dev, struct device_attribute *attr, char *buf)
if (pipe->layers[i]->layer_type == KOMEDA_FMT_RICH_LAYER)
config_id.n_richs++;
}
- return snprintf(buf, PAGE_SIZE, "0x%08x\n", config_id.value);
+ return sysfs_emit(buf, "0x%08x\n", config_id.value);
}
static DEVICE_ATTR_RO(config_id);
@@ -94,7 +94,7 @@ aclk_hz_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct komeda_dev *mdev = dev_to_mdev(dev);
- return snprintf(buf, PAGE_SIZE, "%lu\n", clk_get_rate(mdev->aclk));
+ return sysfs_emit(buf, "%lu\n", clk_get_rate(mdev->aclk));
}
static DEVICE_ATTR_RO(aclk_hz);
Looks OK to me.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver v3
On Thu, Apr 01, 2021 at 05:52:36PM +0200, Christoph Hellwig wrote: > Diffstat: > arch/powerpc/include/asm/fsl_pamu_stash.h | 12 > drivers/gpu/drm/msm/adreno/adreno_gpu.c |5 > drivers/iommu/amd/iommu.c | 23 > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75 --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |1 > drivers/iommu/arm/arm-smmu/arm-smmu.c | 111 +--- > drivers/iommu/arm/arm-smmu/arm-smmu.h |2 > drivers/iommu/dma-iommu.c |9 > drivers/iommu/fsl_pamu.c| 293 --- > drivers/iommu/fsl_pamu.h| 12 > drivers/iommu/fsl_pamu_domain.c | 688 > ++-- > drivers/iommu/fsl_pamu_domain.h | 46 - > drivers/iommu/intel/iommu.c | 95 --- > drivers/iommu/iommu.c | 118 +--- > drivers/soc/fsl/qbman/qman_portal.c | 55 -- > drivers/vfio/vfio_iommu_type1.c | 31 - > drivers/vhost/vdpa.c| 10 > include/linux/io-pgtable.h |4 > include/linux/iommu.h | 76 --- > 19 files changed, 203 insertions(+), 1463 deletions(-) Applied, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/msm/dpu: remove unused local variable 'cmd_enc'
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning: variable
‘cmd_enc’ set but not used [-Wunused-but-set-variable]
Fixes: fe286893ed34 ("drm/msm/dpu: Remove unused call in wait_for_commit_done")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b2be39b9144e449..088900841bf8baa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -685,10 +685,6 @@ static int dpu_encoder_phys_cmd_wait_for_tx_complete(
static int dpu_encoder_phys_cmd_wait_for_commit_done(
struct dpu_encoder_phys *phys_enc)
{
- struct dpu_encoder_phys_cmd *cmd_enc;
-
- cmd_enc = to_dpu_encoder_phys_cmd(phys_enc);
-
/* only required for master controller */
if (!dpu_encoder_phys_cmd_is_master(phys_enc))
return 0;
--
1.8.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
[AMD Public Use] Hi Felix and Christian, If the regression you are talking about is the NULL pointer problem when running KFD tests, it should fixed by below patch in this series. drm/amdgpu: fix NULL pointer dereference Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Wednesday, April 7, 2021 2:57 PM To: Kuehling, Felix ; Deucher, Alexander ; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; airl...@gmail.com; daniel.vet...@ffwll.ch Subject: Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13 Am 06.04.21 um 17:42 schrieb Felix Kuehling: > Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher: >> Hi Dave, Daniel, >> >> New stuff for 5.13. There are two small patches for ttm and >> scheduler that were dependencies for amdgpu changes. >> >> The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: >> >>Merge tag 'amd-drm-next-5.13-2021-03-23' of >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit >> lab.freedesktop.org%2Fagd5f%2Flinuxdata=04%7C01%7Cguchun.chen%40 >> amd.com%7C51d1cbcf7ccc43854abb08d8f99250d8%7C3dd8961fe4884e608e11a82d >> 994e183d%7C0%7C0%7C637533754128113017%7CUnknown%7CTWFpbGZsb3d8eyJWIjo >> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 >> p;sdata=FcdoL9w5LhBZ849ctXPudr%2BBQnnm7Oiq3pz5X7LGGk4%3Dreserved >> =0 into drm-next (2021-03-26 15:53:21 +0100) >> >> are available in the Git repository at: >> >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit >> lab.freedesktop.org%2Fagd5f%2Flinux.gitdata=04%7C01%7Cguchun.che >> n%40amd.com%7C51d1cbcf7ccc43854abb08d8f99250d8%7C3dd8961fe4884e608e11 >> a82d994e183d%7C0%7C0%7C637533754128113017%7CUnknown%7CTWFpbGZsb3d8eyJ >> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 >> 0sdata=N4JIk%2BEgzleaKYaxvdtT7TR1ZsS6FGsIGpDDUqiQiLw%3Drese >> rved=0 tags/amd-drm-next-5.13-2021-04-01 >> >> for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: >> >>drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 >> 17:32:32 -0400) >> >> >> amd-drm-next-5.13-2021-04-01: >> >> amdgpu: >> - Re-enable GPU reset on VanGogh >> - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME >> - Disentangle HG from vga_switcheroo >> - S0ix fixes >> - W=1 fixes >> - Resource iterator fixes >> - DMCUB updates >> - UBSAN fixes >> - More PM API cleanup >> - Aldebaran updates >> - Modifier fixes >> - Enable VCN load balancing with asymmetric engines >> - Rework BO structs >> - Aldebaran reset support >> - Initial LTTPR display work >> - Display MALL fixes >> - Fall back to YCbCr420 when YCbCr444 fails >> - SR-IOV fixes >> - Misc cleanups and fixes >> >> radeon: >> - Typo fixes >> >> ttm: >> - Handle cached requests (required for Aldebaran) >> >> scheduler: >> - Fix runqueue selection when changing priorities (required to fix VCN >>load balancing) >> >> >> Alex Deucher (20): >>drm/amdgpu/display/dm: add missing parameter documentation >>drm/amdgpu: Add additional Sienna Cichlid PCI ID >>drm/amdgpu: add a dev_pm_ops prepare callback (v2) >>drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and >> DPM_FLAG_SMART_SUSPEND flags (v2) >>drm/amdgpu: disentangle HG systems from vgaswitcheroo >>drm/amdgpu: rework S3/S4/S0ix state handling >>drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) >>drm/amdgpu: clean up non-DC suspend/resume handling >>drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) >>drm/amdgpu: re-enable suspend phase 2 for S0ix >>drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend >>drm/amdgpu: update comments about s0ix suspend/resume >>drm/amdgpu: drop S0ix checks around CG/PG in suspend >>drm/amdgpu: skip kfd suspend/resume for S0ix >>drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x >>drm/amdgpu/display: fix memory leak for dimgrey cavefish >>drm/amdgpu/pm: mark pcie link/speed arrays as const >>drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend >>drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in >> suspend >>drm/amdgpu/display: fix warning on 32 bit in dmub >> >> Alex Sierra (2): >>drm/amdgpu: replace per_device_list by array >>drm/amdgpu: ih reroute for newer asics than vega20 >> >> Alvin Lee (1): >>drm/amd/display: Change input parameter for set_drr >> >> Anson Jacob (2): >>drm/amd/display: Fix UBSAN: shift-out-of-bounds warning >>drm/amd/display: Removing unused code from dmub_cmd.h >> >> Anthony Koo (2): >>drm/amd/display: [FW Promotion] Release 0.0.57 >>drm/amd/display: [FW Promotion] Release 0.0.58 >> >> Aric Cyr (2): >>drm/amd/display: 3.2.128 >>
[PATCH v2 2/2] drm/panel: simple: Add support for EDT ETM0350G0DH6 panel
From: Stefan Riedmueller
This patch adds support for the EDT ETM0350G0DH6 3.5" (320x240) lcd
panel to DRM simple panel driver.
Signed-off-by: Stefan Riedmueller
Signed-off-by: Yunus Bas
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 283c17a75376..70c25f6e642b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1847,6 +1847,32 @@ static const struct panel_desc edt_et035012dm6 = {
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
};
+static const struct drm_display_mode edt_etm0350g0dh6_mode = {
+ .clock = 6520,
+ .hdisplay = 320,
+ .hsync_start = 320 + 20,
+ .hsync_end = 320 + 20 + 68,
+ .htotal = 320 + 20 + 68,
+ .vdisplay = 240,
+ .vsync_start = 240 + 4,
+ .vsync_end = 240 + 4 + 18,
+ .vtotal = 240 + 4 + 18,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc edt_etm0350g0dh6 = {
+ .modes = _etm0350g0dh6_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 70,
+ .height = 53,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode edt_etm043080dh6gp_mode = {
.clock = 10870,
.hdisplay = 480,
@@ -4243,6 +4269,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "edt,et035012dm6",
.data = _et035012dm6,
+ }, {
+ .compatible = "edt,etm0350g0dh6",
+ .data = _etm0350g0dh6,
}, {
.compatible = "edt,etm043080dh6gp",
.data = _etm043080dh6gp,
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/panel: simple: Add support for EDT ETMV570G2DHU panel
From: Stefan Riedmueller
This patch adds support for the EDT ETMV570G2DHU 5.7" (640x480) lcd panel
to DRM simple panel driver.
Signed-off-by: Stefan Riedmueller
Signed-off-by: Yunus Bas
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..283c17a75376 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1926,6 +1926,32 @@ static const struct panel_desc edt_et057090dhu = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct drm_display_mode edt_etmv570g2dhu_mode = {
+ .clock = 25175,
+ .hdisplay = 640,
+ .hsync_start = 640,
+ .hsync_end = 640 + 16,
+ .htotal = 640 + 16 + 30 + 114,
+ .vdisplay = 480,
+ .vsync_start = 480 + 10,
+ .vsync_end = 480 + 10 + 3,
+ .vtotal = 480 + 10 + 3 + 35,
+ .flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC,
+};
+
+static const struct panel_desc edt_etmv570g2dhu = {
+ .modes = _etmv570g2dhu_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 115,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode edt_etm0700g0dh6_mode = {
.clock = 33260,
.hdisplay = 800,
@@ -4226,6 +4252,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "edt,et057090dhu",
.data = _et057090dhu,
+ }, {
+ .compatible = "edt,etmv570g2dhu",
+ .data = _etmv570g2dhu,
}, {
.compatible = "edt,et070080dh6",
.data = _etm0700g0dh6,
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Call for an EDID parsing library
Hi all, with display servers proliferating thanks to Wayland, and the Linux kernel exposing only a very limited set of information based on EDID (rightfully so!), the need to interpret EDID blobs is spreading even more. I would like to start the discussion about starting a project to develop a shared library for parsing EDID blobs. This is not the first time either, other people have suggested it years and years ago already, but apparently it didn't quite materialise as far as I know. Right now, it seems that more or less every display server and other KMS application is hand-rolling its own EDID parsing code, even for the most trivial information (monitor make, model, and serial number). With HDR and color management support coming to Wayland, the need to parse more things out of EDID will only increase. These things are not exposed by the kernel, and most of these things have no use for the kernel either. My personal motivation for this is that I don't want to be developing or reviewing yet another partial EDID parser implementation in Weston. I recall ponderings about sharing the same EDID parsing code between the kernel and userspace, but I got the feeling that it would be a hindrance in process more than a benefit from sharing code. It would need to live in the kernel tree, to be managed with the kernel development process, use the kernel "standard libraries", and adhere to kernel programming style - all which are good and fine, but maybe also more restricting than useful in this case. Therefore I would suggest a userspace-only library. Everyone hand-rolling their own parsing code has the obvious disadvantages. In the opposite, I would expect a new shared EDID parsing library and project to: - be hosted under gitlab.freedesktop.org - be MIT licensed - offer at least a C ABI - employ mandatory Gitlab CI to ensure with sample EDID blobs that it cannot regress Prior art can be found in various places. I believe Xorg xserver has its battle-tested EDID parsing code. Ajax once played with the idea in https://cgit.freedesktop.org/~ajax/libminitru/ . Then we have https://git.linuxtv.org/edid-decode.git too which has code and test data but not a C ABI (right?). It does not necessarily need to be a new project. Would edid-decode project be open to adding a C library ABI? edid-decode is already MIT licensed and seems to have a lot of code, too, but that's all I know for now. Would there be anyone interested to take lead or work on a project like this? Personally I don't think I'd be working on it, but I would be really happy to use it in Weston. Should it be a new project, or grow inside edid-decode or something else? I believe MIT license is important to have wide adoption of it. C ABI similarly. Also that it would be a "small" library without heavy dependencies. What do you think? Could anyone spare their time for this? Who would be interested in using it if this library appeared? Thanks, pq pgpUHq4NK0tqc.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 5/8] mm: Device exclusive memory access
Some devices require exclusive write access to shared virtual memory (SVM) ranges to perform atomic operations on that memory. This requires CPU page tables to be updated to deny access whilst atomic operations are occurring. In order to do this introduce a new swap entry type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for exclusive access by a device all page table mappings for the particular range are replaced with device exclusive swap entries. This causes any CPU access to the page to result in a fault. Faults are resovled by replacing the faulting entry with the original mapping. This results in MMU notifiers being called which a driver uses to update access permissions such as revoking atomic access. After notifiers have been called the device will no longer have exclusive access to the region. Signed-off-by: Alistair Popple Reviewed-by: Christoph Hellwig --- v8: * Remove device exclusive entries on fork rather than copy them. v7: * Added Christoph's Reviewed-by. * Minor cosmetic cleanups suggested by Christoph. * Replace mmu_notifier_range_init_migrate/exclusive with mmu_notifier_range_init_owner as suggested by Christoph. * Replaced lock_page() with lock_page_retry() when handling faults. * Restrict to anonymous pages for now. v6: * Fixed a bisectablity issue due to incorrectly applying the rename of migrate_pgmap_owner to the wrong patches for Nouveau and hmm_test. v5: * Renamed range->migrate_pgmap_owner to range->owner. * Added MMU_NOTIFY_EXCLUSIVE to allow passing of a driver cookie which allows notifiers called as a result of make_device_exclusive_range() to be ignored. * Added a check to try_to_protect_one() to detect if the pages originally returned from get_user_pages() have been unmapped or not. * Removed check_device_exclusive_range() as it is no longer required with the other changes. * Documentation update. v4: * Add function to check that mappings are still valid and exclusive. * s/long/unsigned long/ in make_device_exclusive_entry(). --- Documentation/vm/hmm.rst | 19 ++- drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +- include/linux/mmu_notifier.h | 26 ++-- include/linux/rmap.h | 4 + include/linux/swap.h | 4 +- include/linux/swapops.h | 44 +- lib/test_hmm.c| 2 +- mm/hmm.c | 5 + mm/memory.c | 176 +++-- mm/migrate.c | 10 +- mm/mprotect.c | 8 + mm/page_vma_mapped.c | 9 +- mm/rmap.c | 210 ++ 13 files changed, 487 insertions(+), 32 deletions(-) diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index 09e28507f5b2..a14c2938e7af 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -332,7 +332,7 @@ between device driver specific code and shared common code: walks to fill in the ``args->src`` array with PFNs to be migrated. The ``invalidate_range_start()`` callback is passed a ``struct mmu_notifier_range`` with the ``event`` field set to - ``MMU_NOTIFY_MIGRATE`` and the ``migrate_pgmap_owner`` field set to + ``MMU_NOTIFY_MIGRATE`` and the ``owner`` field set to the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This is allows the device driver to skip the invalidation callback and only invalidate device private MMU mappings that are actually migrating. @@ -405,6 +405,23 @@ between device driver specific code and shared common code: The lock can now be released. +Exclusive access memory +=== + +Some devices have features such as atomic PTE bits that can be used to implement +atomic access to system memory. To support atomic operations to a shared virtual +memory page such a device needs access to that page which is exclusive of any +userspace access from the CPU. The ``make_device_exclusive_range()`` function +can be used to make a memory range inaccessible from userspace. + +This replaces all mappings for pages in the given range with special swap +entries. Any attempt to access the swap entry results in a fault which is +resovled by replacing the entry with the original mapping. A driver gets +notified that the mapping has been changed by MMU notifiers, after which point +it will no longer have exclusive access to the page. Exclusive access is +guranteed to last until the driver drops the page lock and page reference, at +which point any CPU faults on the page may proceed as described. + Memory cgroup (memcg) and rss accounting diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c b/drivers/gpu/drm/nouveau/nouveau_svm.c index f18bd53da052..94f841026c3b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_svm.c +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c @@ -265,7 +265,7 @@
[PATCH v8 8/8] nouveau/svm: Implement atomic SVM access
Some NVIDIA GPUs do not support direct atomic access to system memory
via PCIe. Instead this must be emulated by granting the GPU exclusive
access to the memory. This is achieved by replacing CPU page table
entries with special swap entries that fault on userspace access.
The driver then grants the GPU permission to update the page undergoing
atomic access via the GPU page tables. When CPU access to the page is
required a CPU fault is raised which calls into the device driver via
MMU notifiers to revoke the atomic access. The original page table
entries are then restored allowing CPU access to proceed.
Signed-off-by: Alistair Popple
---
v7:
* Removed magic values for fault access levels
* Improved readability of fault comparison code
v4:
* Check that page table entries haven't changed before mapping on the
device
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 126 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 +
4 files changed, 123 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index d6dd40f21eed..9c7ff56831c5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -77,6 +77,7 @@ struct nvif_vmm_pfnmap_v0 {
#define NVIF_VMM_PFNMAP_V0_APER 0x00f0ULL
#define NVIF_VMM_PFNMAP_V0_HOST 0xULL
#define NVIF_VMM_PFNMAP_V0_VRAM 0x0010ULL
+#define NVIF_VMM_PFNMAP_V0_A 0x0004ULL
#define NVIF_VMM_PFNMAP_V0_W 0x0002ULL
#define NVIF_VMM_PFNMAP_V0_V 0x0001ULL
#define NVIF_VMM_PFNMAP_V0_NONE 0xULL
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index a195e48c9aee..81526d65b4e2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
struct nouveau_svm {
struct nouveau_drm *drm;
@@ -67,6 +68,11 @@ struct nouveau_svm {
} buffer[1];
};
+#define FAULT_ACCESS_READ 0
+#define FAULT_ACCESS_WRITE 1
+#define FAULT_ACCESS_ATOMIC 2
+#define FAULT_ACCESS_PREFETCH 3
+
#define SVM_DBG(s,f,a...) NV_DEBUG((s)->drm, "svm: "f"\n", ##a)
#define SVM_ERR(s,f,a...) NV_WARN((s)->drm, "svm: "f"\n", ##a)
@@ -411,6 +417,24 @@ nouveau_svm_fault_cancel_fault(struct nouveau_svm *svm,
fault->client);
}
+static int
+nouveau_svm_fault_priority(u8 fault)
+{
+ switch (fault) {
+ case FAULT_ACCESS_PREFETCH:
+ return 0;
+ case FAULT_ACCESS_READ:
+ return 1;
+ case FAULT_ACCESS_WRITE:
+ return 2;
+ case FAULT_ACCESS_ATOMIC:
+ return 3;
+ default:
+ WARN_ON_ONCE(1);
+ return -1;
+ }
+}
+
static int
nouveau_svm_fault_cmp(const void *a, const void *b)
{
@@ -421,9 +445,8 @@ nouveau_svm_fault_cmp(const void *a, const void *b)
return ret;
if ((ret = (s64)fa->addr - fb->addr))
return ret;
- /*XXX: atomic? */
- return (fa->access == 0 || fa->access == 3) -
- (fb->access == 0 || fb->access == 3);
+ return nouveau_svm_fault_priority(fa->access) -
+ nouveau_svm_fault_priority(fb->access);
}
static void
@@ -487,6 +510,10 @@ static bool nouveau_svm_range_invalidate(struct
mmu_interval_notifier *mni,
struct svm_notifier *sn =
container_of(mni, struct svm_notifier, notifier);
+ if (range->event == MMU_NOTIFY_EXCLUSIVE &&
+ range->owner == sn->svmm->vmm->cli->drm->dev)
+ return true;
+
/*
* serializes the update to mni->invalidate_seq done by caller and
* prevents invalidation of the PTE from progressing while HW is being
@@ -555,6 +582,71 @@ static void nouveau_hmm_convert_pfn(struct nouveau_drm
*drm,
args->p.phys[0] |= NVIF_VMM_PFNMAP_V0_W;
}
+static int nouveau_atomic_range_fault(struct nouveau_svmm *svmm,
+ struct nouveau_drm *drm,
+ struct nouveau_pfnmap_args *args, u32 size,
+ struct svm_notifier *notifier)
+{
+ unsigned long timeout =
+ jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
+ struct mm_struct *mm = svmm->notifier.mm;
+ struct page *page;
+ unsigned long start = args->p.addr;
+ unsigned long notifier_seq;
+ int ret = 0;
+
+ ret = mmu_interval_notifier_insert(>notifier, mm,
+
[PATCH v8 7/8] nouveau/svm: Refactor nouveau_range_fault
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 34 ---
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 94f841026c3b..a195e48c9aee 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -567,18 +567,27 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
unsigned long hmm_pfns[1];
struct hmm_range range = {
.notifier = >notifier,
- .start = notifier->notifier.interval_tree.start,
- .end = notifier->notifier.interval_tree.last + 1,
.default_flags = hmm_flags,
.hmm_pfns = hmm_pfns,
.dev_private_owner = drm->dev,
};
- struct mm_struct *mm = notifier->notifier.mm;
+ struct mm_struct *mm = svmm->notifier.mm;
int ret;
+ ret = mmu_interval_notifier_insert(>notifier, mm,
+ args->p.addr, args->p.size,
+ _svm_mni_ops);
+ if (ret)
+ return ret;
+
+ range.start = notifier->notifier.interval_tree.start;
+ range.end = notifier->notifier.interval_tree.last + 1;
+
while (true) {
- if (time_after(jiffies, timeout))
- return -EBUSY;
+ if (time_after(jiffies, timeout)) {
+ ret = -EBUSY;
+ goto out;
+ }
range.notifier_seq = mmu_interval_read_begin(range.notifier);
mmap_read_lock(mm);
@@ -587,7 +596,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
if (ret) {
if (ret == -EBUSY)
continue;
- return ret;
+ goto out;
}
mutex_lock(>mutex);
@@ -606,6 +615,9 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(>mutex);
+out:
+ mmu_interval_notifier_remove(>notifier);
+
return ret;
}
@@ -727,14 +739,8 @@ nouveau_svm_fault(struct nvif_notify *notify)
}
notifier.svmm = svmm;
- ret = mmu_interval_notifier_insert(, mm,
- args.i.p.addr, args.i.p.size,
- _svm_mni_ops);
- if (!ret) {
- ret = nouveau_range_fault(svmm, svm->drm, ,
- sizeof(args), hmm_flags, );
- mmu_interval_notifier_remove();
- }
+ ret = nouveau_range_fault(svmm, svm->drm, ,
+ sizeof(args), hmm_flags, );
mmput(mm);
limit = args.i.p.addr + args.i.p.size;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 6/8] mm: Selftests for exclusive device memory
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 124 +++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 158 +
3 files changed, 284 insertions(+)
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 5c9f5a020c1d..305a9d9e2b4c 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "test_hmm_uapi.h"
@@ -46,6 +47,7 @@ struct dmirror_bounce {
unsigned long cpages;
};
+#define DPT_XA_TAG_ATOMIC 1UL
#define DPT_XA_TAG_WRITE 3UL
/*
@@ -619,6 +621,54 @@ static void dmirror_migrate_alloc_and_copy(struct
migrate_vma *args,
}
}
+static int dmirror_check_atomic(struct dmirror *dmirror, unsigned long start,
+unsigned long end)
+{
+ unsigned long pfn;
+
+ for (pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT); pfn++) {
+ void *entry;
+ struct page *page;
+
+ entry = xa_load(>pt, pfn);
+ page = xa_untag_pointer(entry);
+ if (xa_pointer_tag(entry) == DPT_XA_TAG_ATOMIC)
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+static int dmirror_atomic_map(unsigned long start, unsigned long end,
+ struct page **pages, struct dmirror *dmirror)
+{
+ unsigned long pfn, mapped = 0;
+ int i;
+
+ /* Map the migrated pages into the device's page tables. */
+ mutex_lock(>mutex);
+
+ for (i = 0, pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT);
pfn++, i++) {
+ void *entry;
+
+ if (!pages[i])
+ continue;
+
+ entry = pages[i];
+ entry = xa_tag_pointer(entry, DPT_XA_TAG_ATOMIC);
+ entry = xa_store(>pt, pfn, entry, GFP_ATOMIC);
+ if (xa_is_err(entry)) {
+ mutex_unlock(>mutex);
+ return xa_err(entry);
+ }
+
+ mapped++;
+ }
+
+ mutex_unlock(>mutex);
+ return mapped;
+}
+
static int dmirror_migrate_finalize_and_map(struct migrate_vma *args,
struct dmirror *dmirror)
{
@@ -661,6 +711,71 @@ static int dmirror_migrate_finalize_and_map(struct
migrate_vma *args,
return 0;
}
+static int dmirror_exclusive(struct dmirror *dmirror,
+struct hmm_dmirror_cmd *cmd)
+{
+ unsigned long start, end, addr;
+ unsigned long size = cmd->npages << PAGE_SHIFT;
+ struct mm_struct *mm = dmirror->notifier.mm;
+ struct page *pages[64];
+ struct dmirror_bounce bounce;
+ unsigned long next;
+ int ret;
+
+ start = cmd->addr;
+ end = start + size;
+ if (end < start)
+ return -EINVAL;
+
+ /* Since the mm is for the mirrored process, get a reference first. */
+ if (!mmget_not_zero(mm))
+ return -EINVAL;
+
+ mmap_read_lock(mm);
+ for (addr = start; addr < end; addr = next) {
+ int i, mapped;
+
+ if (end < addr + (ARRAY_SIZE(pages) << PAGE_SHIFT))
+ next = end;
+ else
+ next = addr + (ARRAY_SIZE(pages) << PAGE_SHIFT);
+
+ ret = make_device_exclusive_range(mm, addr, next, pages, NULL);
+ mapped = dmirror_atomic_map(addr, next, pages, dmirror);
+ for (i = 0; i < ret; i++) {
+ if (pages[i]) {
+ unlock_page(pages[i]);
+ put_page(pages[i]);
+ }
+ }
+
+ if (addr + (mapped << PAGE_SHIFT) < next) {
+ mmap_read_unlock(mm);
+ mmput(mm);
+ return -EBUSY;
+ }
+ }
+ mmap_read_unlock(mm);
+ mmput(mm);
+
+ /* Return the migrated data for verification. */
+ ret = dmirror_bounce_init(, start, size);
+ if (ret)
+ return ret;
+ mutex_lock(>mutex);
+ ret = dmirror_do_read(dmirror, start, end, );
+ mutex_unlock(>mutex);
+ if (ret == 0) {
+ if (copy_to_user(u64_to_user_ptr(cmd->ptr), bounce.ptr,
+bounce.size))
+ ret = -EFAULT;
+ }
+
+ cmd->cpages = bounce.cpages;
+ dmirror_bounce_fini();
+ return ret;
+}
+
static int dmirror_migrate(struct dmirror *dmirror,
struct hmm_dmirror_cmd *cmd)
{
@@ -949,6 +1064,15 @@ static long dmirror_fops_unlocked_ioctl(struct file *filp,
ret = dmirror_migrate(dmirror, );
break;
+
[PATCH v8 4/8] mm/rmap: Split migration into its own function
Migration is currently implemented as a mode of operation for
try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
However it does not have much in common with the rest of the unmap
functionality of try_to_unmap_one() and thus splitting it into a
separate function reduces the complexity of try_to_unmap_one() making it
more readable.
Several simplifications can also be made in try_to_migrate_one() based
on the following observations:
- All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK.
- No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON.
- No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH.
TTU_SPLIT_FREEZE is a special case of migration used when splitting an
anonymous page. This is most easily dealt with by calling the correct
function from unmap_page() in mm/huge_memory.c - either
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
v5:
* Added comments about how PMD splitting works for migration vs.
unmapping
* Tightened up the flag check in try_to_migrate() to be explicit about
which TTU_XXX flags are supported.
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 15 +-
mm/migrate.c | 9 +-
mm/rmap.c| 358 ---
4 files changed, 280 insertions(+), 106 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 38a746787c2f..0e25d829f742 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -86,8 +86,6 @@ struct anon_vma_chain {
};
enum ttu_flags {
- TTU_MIGRATION = 0x1, /* migration mode */
-
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
TTU_IGNORE_HWPOISON = 0x20, /* corrupted page is recoverable */
@@ -96,7 +94,6 @@ enum ttu_flags {
* do a final flush if necessary */
TTU_RMAP_LOCKED = 0x80, /* do not grab rmap lock:
* caller holds it */
- TTU_SPLIT_FREEZE= 0x100,/* freeze pte under
splitting thp */
};
#ifdef CONFIG_MMU
@@ -193,6 +190,7 @@ static inline void page_dup_rmap(struct page *page, bool
compound)
int page_referenced(struct page *, int is_locked,
struct mem_cgroup *memcg, unsigned long *vm_flags);
+bool try_to_migrate(struct page *page, enum ttu_flags flags);
bool try_to_unmap(struct page *, enum ttu_flags flags);
/* Avoid racy checks */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 89af065cea5b..eab004331b97 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2357,16 +2357,21 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma,
static void unmap_page(struct page *page)
{
- enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
- TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
+ enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
bool unmap_success;
VM_BUG_ON_PAGE(!PageHead(page), page);
if (PageAnon(page))
- ttu_flags |= TTU_SPLIT_FREEZE;
-
- unmap_success = try_to_unmap(page, ttu_flags);
+ unmap_success = try_to_migrate(page, ttu_flags);
+ else
+ /*
+* Don't install migration entries for file backed pages. This
+* helps handle cases when i_size is in the middle of the page
+* as there is no need to unmap pages beyond i_size manually.
+*/
+ unmap_success = try_to_unmap(page, ttu_flags |
+ TTU_IGNORE_MLOCK);
VM_BUG_ON_PAGE(!unmap_success, page);
}
diff --git a/mm/migrate.c b/mm/migrate.c
index b752543adb64..cc4612e2a246 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1130,7 +1130,7 @@ static int __unmap_and_move(struct page *page, struct
page *newpage,
/* Establish migration ptes */
VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && !anon_vma,
page);
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK);
+ try_to_migrate(page, 0);
page_was_mapped = 1;
}
@@ -1332,7 +1332,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
if (page_mapped(hpage)) {
bool mapping_locked = false;
- enum ttu_flags ttu = TTU_MIGRATION|TTU_IGNORE_MLOCK;
+ enum ttu_flags ttu = 0;
if (!PageAnon(hpage)) {
/*
@@ -1349,7 +1349,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
ttu |= TTU_RMAP_LOCKED;
}
- try_to_unmap(hpage, ttu);
+ try_to_migrate(hpage, ttu);
page_was_mapped
[PATCH v8 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
The behaviour of try_to_unmap_one() is difficult to follow because it performs different operations based on a fairly large set of flags used in different combinations. TTU_MUNLOCK is one such flag. However it is exclusively used by try_to_munlock() which specifies no other flags. Therefore rather than overload try_to_unmap_one() with unrelated behaviour split this out into it's own function and remove the flag. Signed-off-by: Alistair Popple Reviewed-by: Ralph Campbell Reviewed-by: Christoph Hellwig --- v8: * Renamed try_to_munlock to page_mlock to better reflect what the function actually does. * Removed the TODO from the documentation that this patch addresses. v7: * Added Christoph's Reviewed-by v4: * Removed redundant check for VM_LOCKED --- Documentation/vm/unevictable-lru.rst | 33 --- include/linux/rmap.h | 3 +- mm/mlock.c | 10 +++--- mm/rmap.c| 48 +--- 4 files changed, 55 insertions(+), 39 deletions(-) diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst index 0e1490524f53..eae3af17f2d9 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/vm/unevictable-lru.rst @@ -389,14 +389,14 @@ mlocked, munlock_vma_page() updates that zone statistics for the number of mlocked pages. Note, however, that at this point we haven't checked whether the page is mapped by other VM_LOCKED VMAs. -We can't call try_to_munlock(), the function that walks the reverse map to +We can't call page_mlock(), the function that walks the reverse map to check for other VM_LOCKED VMAs, without first isolating the page from the LRU. -try_to_munlock() is a variant of try_to_unmap() and thus requires that the page +page_mlock() is a variant of try_to_unmap() and thus requires that the page not be on an LRU list [more on these below]. However, the call to -isolate_lru_page() could fail, in which case we couldn't try_to_munlock(). So, +isolate_lru_page() could fail, in which case we can't call page_mlock(). So, we go ahead and clear PG_mlocked up front, as this might be the only chance we -have. If we can successfully isolate the page, we go ahead and -try_to_munlock(), which will restore the PG_mlocked flag and update the zone +have. If we can successfully isolate the page, we go ahead and call +page_mlock(), which will restore the PG_mlocked flag and update the zone page statistics if it finds another VMA holding the page mlocked. If we fail to isolate the page, we'll have left a potentially mlocked page on the LRU. This is fine, because we'll catch it later if and if vmscan tries to reclaim @@ -545,31 +545,24 @@ munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, holepunching, and truncation of file pages and their anonymous COWed pages. -try_to_munlock() Reverse Map Scan +page_mlock() Reverse Map Scan - -.. warning:: - [!] TODO/FIXME: a better name might be page_mlocked() - analogous to the - page_referenced() reverse map walker. - When munlock_vma_page() [see section :ref:`munlock()/munlockall() System Call Handling ` above] tries to munlock a page, it needs to determine whether or not the page is mapped by any VM_LOCKED VMA without actually attempting to unmap all PTEs from the page. For this purpose, the unevictable/mlock infrastructure -introduced a variant of try_to_unmap() called try_to_munlock(). +introduced a variant of try_to_unmap() called page_mlock(). -try_to_munlock() calls the same functions as try_to_unmap() for anonymous and -mapped file and KSM pages with a flag argument specifying unlock versus unmap -processing. Again, these functions walk the respective reverse maps looking -for VM_LOCKED VMAs. When such a VMA is found, as in the try_to_unmap() case, -the functions mlock the page via mlock_vma_page() and return SWAP_MLOCK. This -undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page. +page_mlock() walks the respective reverse maps looking for VM_LOCKED VMAs. When +such a VMA is found the page is mlocked via mlock_vma_page(). This undoes the +pre-clearing of the page's PG_mlocked done by munlock_vma_page. -Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's +Note that page_mlock()'s reverse map walk must visit every VMA in a page's reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. However, the scan can terminate when it encounters a VM_LOCKED VMA. -Although try_to_munlock() might be called a great many times when munlocking a +Although page_mlock() might be called a great many times when munlocking a large region or tearing down a large address space that has been mlocked via mlockall(), overall this is a fairly rare event. @@ -602,7 +595,7 @@ inactive lists to the appropriate node's unevictable list. shrink_inactive_list() should only see SHM_LOCK'd pages
[PATCH v8 2/8] mm/swapops: Rework swap entry manipulation code
Both migration and device private pages use special swap entries that
are manipluated by a range of inline functions. The arguments to these
are somewhat inconsitent so rework them to remove flag type arguments
and to make the arguments similar for both read and write entry
creation.
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c| 10 +---
mm/memory.c | 10 +---
mm/migrate.c| 26 ++-
mm/mprotect.c | 10 +---
mm/rmap.c | 10 +---
9 files changed, 100 insertions(+), 62 deletions(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 139be8235ad2..4dfd807ae52a 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -100,35 +100,35 @@ static inline void *swp_to_radix_entry(swp_entry_t entry)
}
#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
- return swp_entry(write ? SWP_DEVICE_WRITE : SWP_DEVICE_READ,
-page_to_pfn(page));
+ return swp_entry(SWP_DEVICE_READ, offset);
}
-static inline bool is_device_private_entry(swp_entry_t entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
- int type = swp_type(entry);
- return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
+ return swp_entry(SWP_DEVICE_WRITE, offset);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline bool is_device_private_entry(swp_entry_t entry)
{
- *entry = swp_entry(SWP_DEVICE_READ, swp_offset(*entry));
+ int type = swp_type(entry);
+ return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
}
#else /* CONFIG_DEVICE_PRIVATE */
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
return swp_entry(0, 0);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
+ return swp_entry(0, 0);
}
static inline bool is_device_private_entry(swp_entry_t entry)
@@ -136,35 +136,32 @@ static inline bool is_device_private_entry(swp_entry_t
entry)
return false;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return false;
}
#endif /* CONFIG_DEVICE_PRIVATE */
#ifdef CONFIG_MIGRATION
-static inline swp_entry_t make_migration_entry(struct page *page, int write)
-{
- BUG_ON(!PageLocked(compound_head(page)));
-
- return swp_entry(write ? SWP_MIGRATION_WRITE : SWP_MIGRATION_READ,
- page_to_pfn(page));
-}
-
static inline int is_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_READ ||
swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline int is_write_migration_entry(swp_entry_t entry)
+static inline int is_writable_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline void make_migration_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
{
- *entry = swp_entry(SWP_MIGRATION_READ, swp_offset(*entry));
+ return swp_entry(SWP_MIGRATION_READ, offset);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_MIGRATION_WRITE, offset);
}
extern void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
@@ -174,21 +171,28 @@ extern void migration_entry_wait(struct mm_struct *mm,
pmd_t *pmd,
extern void migration_entry_wait_huge(struct vm_area_struct *vma,
struct mm_struct *mm, pte_t *pte);
#else
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
-#define make_migration_entry(page, write) swp_entry(0, 0)
static inline int is_migration_entry(swp_entry_t swp)
{
return 0;
}
-static inline void make_migration_entry_read(swp_entry_t *entryp) { }
static inline void __migration_entry_wait(struct mm_struct *mm,
[PATCH v8 1/8] mm: Remove special swap entry functions
Remove multiple similar inline functions for dealing with different
types of special swap entries.
Both migration and device private swap entries use the swap offset to
store a pfn. Instead of multiple inline functions to obtain a struct
page for each swap entry type use a common function
pfn_swap_entry_to_page(). Also open-code the various entry_to_pfn()
functions as this results is shorter code that is easier to understand.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
---
v7:
* Reworded commit message to include pfn_swap_entry_to_page()
* Added Christoph's Reviewed-by
v6:
* Removed redundant compound_page() call from inside PageLocked()
* Fixed a minor build issue for s390 reported by kernel test bot
v4:
* Added pfn_swap_entry_to_page()
* Reinstated check that migration entries point to locked pages
* Removed #define swapcache_prepare which isn't needed for CONFIG_SWAP=0
builds
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23 +-
include/linux/swap.h| 4 +--
include/linux/swapops.h | 69 ++---
mm/hmm.c| 5 ++-
mm/huge_memory.c| 4 +--
mm/memcontrol.c | 2 +-
mm/memory.c | 10 +++---
mm/migrate.c| 6 ++--
mm/page_vma_mapped.c| 6 ++--
10 files changed, 50 insertions(+), 81 deletions(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 18205f851c24..eec3a9d7176e 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -691,7 +691,7 @@ static void ptep_zap_swap_entry(struct mm_struct *mm,
swp_entry_t entry)
if (!non_swap_entry(entry))
dec_mm_counter(mm, MM_SWAPENTS);
else if (is_migration_entry(entry)) {
- struct page *page = migration_entry_to_page(entry);
+ struct page *page = pfn_swap_entry_to_page(entry);
dec_mm_counter(mm, mm_counter(page));
}
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 3cec6fbef725..08ee59d945c0 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -514,10 +514,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
} else {
mss->swap_pss += (u64)PAGE_SIZE << PSS_SHIFT;
}
- } else if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ } else if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
} else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
&& pte_none(*pte))) {
page = xa_load(>vm_file->f_mapping->i_pages,
@@ -549,7 +547,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
swp_entry_t entry = pmd_to_swp_entry(*pmd);
if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
if (IS_ERR_OR_NULL(page))
return;
@@ -691,10 +689,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long
hmask,
} else if (is_swap_pte(*pte)) {
swp_entry_t swpent = pte_to_swp_entry(*pte);
- if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
}
if (page) {
int mapcount = page_mapcount(page);
@@ -1383,11 +1379,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct
pagemapread *pm,
frame = swp_type(entry) |
(swp_offset(entry) << MAX_SWAPFILES_SHIFT);
flags |= PM_SWAP;
- if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
-
- if (is_device_private_entry(entry))
- page = device_private_entry_to_page(entry);
+ if (is_pfn_swap_entry(entry))
+ page = pfn_swap_entry_to_page(entry);
}
if (page && !PageAnon(page))
@@ -1444,7 +1437,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long
addr, unsigned long end,
if (pmd_swp_soft_dirty(pmd))
flags |= PM_SOFT_DIRTY;
VM_BUG_ON(!is_pmd_migration_entry(pmd));
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
#endif
[PATCH v8 0/8] Add support for SVM atomics in Nouveau
This is the eighth version of a series to add support to Nouveau for atomic memory operations on OpenCL shared virtual memory (SVM) regions. The main change for this version is a simplification of device exclusive entry handling. Instead of copying entries for copy-on-write mappings during fork they are removed instead. This is safer because there could be unique corner cases when copying, particularly for pinned pages which should follow the same logic as copy_present_page(). Removing entries avoids this possiblity by treating them as normal ptes. Exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches 1 & 2 refactor existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). These should not change any functionality, but any help testing would be much appreciated as I have not been able to test every usage of try_to_unmap_one(). Patch 5 contains the bulk of the implementation for device exclusive memory. Patch 6 contains some additions to the HMM selftests to ensure everything works as expected. Patch 7 is a cleanup for the Nouveau SVM implementation. Patch 8 contains the implementation of atomic access for the Nouveau driver. This has been tested using the latest upstream Mesa userspace with a simple OpenCL test program which checks the results of atomic GPU operations on a SVM buffer whilst also writing to the same buffer from the CPU. Alistair Popple (8): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 19 +- Documentation/vm/unevictable-lru.rst | 33 +- arch/s390/mm/pgtable.c| 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 156 - drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 + fs/proc/task_mmu.c| 23 +- include/linux/mmu_notifier.h | 26 +- include/linux/rmap.h | 11 +- include/linux/swap.h | 8 +- include/linux/swapops.h | 123 ++-- lib/test_hmm.c| 126 +++- lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 45 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 196 +- mm/migrate.c | 51 +- mm/mlock.c| 10 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 612 +++--- tools/testing/selftests/vm/hmm-tests.c| 158 + 26 files changed, 1366 insertions(+), 312 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms/nv50-: remove unused variable
Fix the following gcc warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1389:6: warning: variable ‘ret’
set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1c9c0cd..b75ede1 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1386,12 +1386,10 @@ struct nouveau_encoder *nv50_real_outp(struct
drm_encoder *encoder)
{
struct nouveau_drm *drm = nouveau_drm(mstm->outp->base.base.dev);
struct drm_encoder *encoder;
- int ret;
NV_ATOMIC(drm, "%s: mstm cleanup\n", mstm->outp->base.base.name);
- ret = drm_dp_check_act_status(>mgr);
-
- ret = drm_dp_update_payload_part2(>mgr);
+ drm_dp_check_act_status(>mgr);
+ drm_dp_update_payload_part2(>mgr);
drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: your mail
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
> Signed-off-by: songqiang
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 14660f723f71..f3698f0ad4d7 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned
> npages, int flags,
> if (++p != pages[i + j])
> break;
>
> - if (j == HPAGE_PMD_NR)
> + if (j == HPAGE_PMD_NR) {
> order = HPAGE_PMD_ORDER;
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> + page_ref_dec(pages[i+j]);
> + }
> }
> #endif
>
> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned
> npages, int flags,
> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
> if (!p)
> break;
> -
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
> pages[i++] = p++;
> -
> + if (j > 0)
> + page_ref_inc(pages[i-1]);
> + }
> npages -= HPAGE_PMD_NR;
> }
> }
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/msm/dp: remove unused local variable 'hpd'
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’ set but not
used [-Wunused-but-set-variable]
Fixes: c58eb1b54fee ("drm/msm/dp: fix connect/disconnect handled at irq_hpd")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6e1eaf277..31bf2a40a9eb2c9 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -493,7 +493,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
int rc = 0;
u32 sink_request;
struct dp_display_private *dp;
- struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -507,8 +506,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
return -ENODEV;
}
- hpd = dp->usbpd;
-
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
if (!rc) {
--
1.8.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/19] dt-bindings: iommu: mediatek: update mediatek, iommu.yaml references
Changeset bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT
schema")
renamed: Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
to: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml.
Update the cross-references accordingly.
Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
Signed-off-by: Mauro Carvalho Chehab
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
.../devicetree/bindings/media/mediatek-jpeg-decoder.txt | 2 +-
.../devicetree/bindings/media/mediatek-jpeg-encoder.txt | 2 +-
Documentation/devicetree/bindings/media/mediatek-mdp.txt| 2 +-
Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 93b160df3eec..fbb59c9ddda6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -64,7 +64,7 @@ Required properties (DMA function blocks):
- larb: Should contain a phandle pointing to the local arbiter device as
defined
in
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Optional properties (RDMA function blocks):
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index cf60c5acc0e4..39c1028b2dfb 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -19,7 +19,7 @@ Required properties:
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
index acfb50375b8a..5e53c6ab52d0 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -17,7 +17,7 @@ Required properties:
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index f4798d04e925..caa24943da33 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -25,7 +25,7 @@ Required properties (DMA function blocks, child node):
"mediatek,mt8173-mdp-wdma"
"mediatek,mt8173-mdp-wrot"
- iommus: should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
- mediatek,larb: must contain the local arbiters in the current Socs, see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8217424fd4bd..a83ebc1a1c7f 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -18,7 +18,7 @@ Required properties:
"univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
"venc_lt_sel", "vdec_bus_clk_src".
- iommus : should point to the respective IOMMU block with master port as
- argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+ argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
One of the two following nodes:
- mediatek,vpu : the node of the video processor unit, if using VPU.
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/19] Fix broken documentation file references
Hi Jon, As files keep being moved around and DT bindings are converted and renamed to yaml, their doc references get outdated, pointing to an invalid places. This series address those. It is based on the top of docs-next tree, and most patches here are independent from the other ones. v2: - Dropped patches that were already applied, Most of those will be following via Jonathan Cameron's iio tree; - Dropped patches that don't apply on the top of docs next. - Added some new patches fixing other breakages. PS.: I placed the dropped patches on a separate branch. I'll track them and re-submit any missing ones after -rc1. Mauro Carvalho Chehab (19): MAINTAINERS: update ste,mcde.yaml reference MAINTAINERS: update brcm,bcm-v3d.yaml reference MAINTAINERS: update fsl,dpaa2-console.yaml reference MAINTAINERS: update mtk-sd.yaml reference MAINTAINERS: update snps,dw-axi-dmac.yaml reference dt-bindings: don't use ../dir for doc references dt-bindings: fix references for iio-bindings.txt dt-bindings: iommu: mediatek: update mediatek,iommu.yaml references dt-bindings: i3c: update i3c.yaml references dt-bindings:iio:adc: update motorola,cpcap-adc.yaml reference dt-bindings:iio:adc: update dlg,da9150-gpadc.yaml reference dt-bindings: power: supply: da9150: update da9150-charger.txt reference dt-bindings: power: supply: da9150: update da9150-fg.txt reference docs: update sysfs-platform_profile.rst reference docs: update rcu_dereference.rst reference docs: vcpu-requests.rst: fix reference for atomic ops docs: replace transation references for reporting-bugs.rst docs: translations/zh_CN: fix a typo at 8.Conclusion.rst docs: sched-bwc.rst: fix a typo on a doc name .../bindings/display/mediatek/mediatek,disp.txt | 2 +- .../devicetree/bindings/hwmon/ntc_thermistor.txt | 2 +- .../devicetree/bindings/i3c/cdns,i3c-master.txt | 6 +++--- .../bindings/i3c/snps,dw-i3c-master.txt | 6 +++--- .../devicetree/bindings/iio/adc/ingenic,adc.yaml | 5 +++-- .../devicetree/bindings/input/adc-joystick.yaml | 4 +++- .../input/touchscreen/resistive-adc-touch.txt| 5 - .../bindings/media/mediatek-jpeg-decoder.txt | 2 +- .../bindings/media/mediatek-jpeg-encoder.txt | 2 +- .../devicetree/bindings/media/mediatek-mdp.txt | 2 +- .../bindings/media/mediatek-vcodec.txt | 2 +- Documentation/devicetree/bindings/mfd/ab8500.txt | 4 +++- Documentation/devicetree/bindings/mfd/da9150.txt | 8 .../devicetree/bindings/mfd/motorola-cpcap.txt | 16 .../bindings/power/supply/da9150-charger.txt | 2 +- Documentation/scheduler/sched-bwc.rst| 2 +- .../translations/it_IT/process/howto.rst | 2 +- Documentation/translations/ja_JP/howto.rst | 2 +- Documentation/translations/zh_CN/SecurityBugs| 2 +- .../zh_CN/admin-guide/reporting-issues.rst | 4 ++-- .../translations/zh_CN/process/8.Conclusion.rst | 2 +- .../translations/zh_CN/process/howto.rst | 2 +- Documentation/virt/kvm/vcpu-requests.rst | 2 +- MAINTAINERS | 10 +- include/linux/platform_profile.h | 2 +- tools/memory-model/Documentation/glossary.txt| 2 +- 26 files changed, 54 insertions(+), 46 deletions(-) -- 2.30.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
> Yes, you are right, there are many files reference > gpiod_set_value_cansleep() and > > devm_gpiod_get_optional(). How about add config dependencies for all > releated I think this is the way to go and roughly half of the drm bridge drivers seem to need this change. Do you mind submitting a series of patches adding this fix for all of the relevant bridge drivers? > > configs or only add config dependencies for the top level config? > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Hi Robert Yes, you are right, there are many files reference gpiod_set_value_cansleep() and devm_gpiod_get_optional(). How about add config dependencies for all releated configs or only add config dependencies for the top level config? Best regards Zhang Jianhua 在 2021/4/6 18:21, Robert Foss 写道: Hey Zhang On Tue, 6 Apr 2021 at 11:07, Zhang Jianhua wrote: If CONFIG_DRM_LONTIUM_LT8912B=y, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~ GPIOF_INIT_HIGH Signed-off-by: Zhang Jianhua --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index dba62f92d051..caa9658ec933 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -67,6 +67,7 @@ config DRM_LONTIUM_LT8912B select DRM_PANEL_BRIDGE select DRM_KMS_HELPER select REGMAP_I2C + select GPIOLIB This appears like the right fix for this problem. However, a number of drm/bridge drivers seem to call both gpio_set_value_cansleep() and devm_gpiod_get_optional() without having the GPIOLIB kconfig option selected so this can't be a new issue. Maybe some more investigation is in order. . ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote: > > On Mon, Mar 22, 2021 at 6:34 AM Christian König > wrote: > > > > Hi Daniel, > > > > Am 22.03.21 um 10:38 schrieb Daniel Gomez: > > > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling > > > wrote: > > >> This caused a regression in kfdtest in a large-buffer stress test after > > >> memory allocation for user pages fails: > > > I'm sorry to hear that. BTW, I guess you meant amdgpu leak patch and > > > not this one. > > > Just some background for the mem leak patch if helps to understand this: > > > The leak was introduce here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b988ca1c7c4c73983b4ea96ef7c2af2263c87eb > > > where the bound status was introduced for all drm drivers including > > > radeon and amdgpu. So this patch just reverts the logic to the > > > original code but keeping the bound status. In my case, the binding > > > code allocates the user pages memory and returns without bounding (at > > > amdgpu_gtt_mgr_has_gart_addr). So, > > > when the unbinding happens, the memory needs to be cleared to prevent the > > > leak. > > > > Ah, now I understand what's happening here. Daniel your patch is not > > really correct. > > > > The problem is rather that we don't set the tt object to bound if it > > doesn't have a GTT address. > > > > Going to provide a patch for this. > > Did this patch ever land? I don't think so but I might send a v2 following Christian's comment if you guys agree. Also, the patch here is for radeon but the pagefault issue reported by Felix is affected by the amdgpu one: radeon patch: drm/radeon/ttm: Fix memory leak userptr pages https://patchwork.kernel.org/project/dri-devel/patch/20210318083236.43578-1-dan...@qtec.com/ amdgpu patch: drm/amdgpu/ttm: Fix memory leak userptr pages https://patchwork.kernel.org/project/dri-devel/patch/20210317160840.36019-1-dan...@qtec.com/ I assume both need to be fixed with the same approach. Daniel > > Alex > > > > > Regards, > > Christian. > > > > > > > >> [17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16 > > >> [17359.543746] BUG: kernel NULL pointer dereference, address: > > >> > > >> [17359.551494] #PF: supervisor read access in kernel mode > > >> [17359.557375] #PF: error_code(0x) - not-present page > > >> [17359.563247] PGD 0 P4D 0 > > >> [17359.566514] Oops: [#1] SMP PTI > > >> [17359.570728] CPU: 8 PID: 5944 Comm: kfdtest Not tainted > > >> 5.11.0-kfd-fkuehlin #193 > > >> [17359.578760] Hardware name: ASUS All Series/X99-E WS/USB 3.1, BIOS > > >> 3201 06/17/2016 > > >> [17359.586971] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 [amdgpu] > > >> [17359.594075] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 24 > > >> 62 00 00 85 c0 0f 85 ab 00 00 00 c6 43 54 00 5b 5d c3 48 8b 46 10 8b 4e > > >> 50 <48> 8b 30 48 85 f6 74 ba 8b 50 0c 48 8b bf 80 a1 ff ff 83 e1 01 45 > > >> [17359.614340] RSP: 0018:a4764971fc98 EFLAGS: 00010206 > > >> [17359.620315] RAX: RBX: 950e8d4edf00 RCX: > > >> > > >> [17359.628204] RDX: RSI: 950e8d4edf00 RDI: > > >> 950eadec5e80 > > >> [17359.636084] RBP: 950eadec5e80 R08: R09: > > >> > > >> [17359.643958] R10: 0246 R11: 0001 R12: > > >> 950c03377800 > > >> [17359.651833] R13: 950eadec5e80 R14: 950c03377858 R15: > > >> > > >> [17359.659701] FS: 7febb20cb740() GS:950ebfc0() > > >> knlGS: > > >> [17359.668528] CS: 0010 DS: ES: CR0: 80050033 > > >> [17359.675012] CR2: CR3: 0006d700e005 CR4: > > >> 001706e0 > > >> [17359.682883] Call Trace: > > >> [17359.686063] amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu] > > >> [17359.692349] ttm_bo_cleanup_memtype_use+0x37/0x60 [ttm] > > >> [17359.698307] ttm_bo_release+0x278/0x5e0 [ttm] > > >> [17359.703385] amdgpu_bo_unref+0x1a/0x30 [amdgpu] > > >> [17359.708701] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7e5/0x910 > > >> [amdgpu] > > >> [17359.716307] kfd_ioctl_alloc_memory_of_gpu+0x11a/0x220 [amdgpu] > > >> [17359.723036] kfd_ioctl+0x223/0x400 [amdgpu] > > >> [17359.728017] ? kfd_dev_is_large_bar+0x90/0x90 [amdgpu] > > >> [17359.734152] __x64_sys_ioctl+0x8b/0xd0 > > >> [17359.738796] do_syscall_64+0x2d/0x40 > > >> [17359.743259] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > >> [17359.749205] RIP: 0033:0x7febb083b6d7 > > >> [17359.753681] Code: b3 66 90 48 8b 05 b1 47 2d 00 64 c7 00 26 00 00 00 > > >> 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f > > >> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 47 2d 00 f7 d8 64 89 01 48 > > >> [17359.774340] RSP: 002b:7ffdb5522cd8 EFLAGS: 0202 ORIG_RAX: > > >> 0010 > > >> [17359.782668] RAX: ffda RBX: 0001 RCX: > > >> 7febb083b6d7 > > >> [17359.790566] RDX:
Re: [PATCH] drm/connector: demote connector force-probes for non-master clients
On Wed, 07 Apr 2021 07:16:30 + Simon Ser wrote: > On Wednesday, April 7th, 2021 at 9:02 AM, Pekka Paalanen > wrote: > > > Btw. can force-probe be triggered via sysfs as well and does it require > > root privs? > > sysfs can force-probe like so: > > echo detect | sudo tee /sys/class/drm/card0-DP-1/status > > But this requires root, yes. Ah, all good then. Thanks, pq pgpkA4xLOGgyC.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote: > > On Fri, Apr 2, 2021 at 12:22 PM Christian König > wrote: > > > > Hey Alex, > > > > the TTM and scheduler changes should already be in the drm-misc-next > > branch (not 100% sure about the TTM patch, need to double check next week). > > > > The TTM change is not in drm-misc yet. > > > Could that cause problems when both are merged into drm-next? > > Dave, Daniel, how do you want to handle this? The duplicated patch is this > one: > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac4eb83ab255de9c31184df51fd1534ba36fd212 > amdgpu has changes which depend on it. The same patch is included in this PR. Ouch not sure how best to sync up here, maybe get misc-next into my tree then rebase your tree on top of it? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/connector: demote connector force-probes for non-master clients
On Wednesday, April 7th, 2021 at 9:02 AM, Pekka Paalanen wrote: > Btw. can force-probe be triggered via sysfs as well and does it require > root privs? sysfs can force-probe like so: echo detect | sudo tee /sys/class/drm/card0-DP-1/status But this requires root, yes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 0/2] Add virtual hardware module
On Mon, 5 Apr 2021 11:41:50 +0530 Sumera Priyadarsini wrote: > This patchset adds support for emulating virtual hardware with VKMS. > The virtual hardware mode can be enabled by using the following command > while loading the module: > sudo modprobe vkms enable_virtual_hw=1 Hi, every time I see this cover letter subject, I start wondering "what is this virtual hardware module, yet another one?" and then I read the cover letter and realise it is about adding an option to VKMS. The next time you revise this series, could you perhaps clarify the subject? The idea of having a mode where VKMS behaves like a virtual hardware driver is good, IMO. I do think "vblank-less mode" describes it better though, because I would assume things like USB display drivers to work like this too, and VKMS is already a virtual driver anyway. To clarify, as a userspace programmer what I would expect "vblank-less mode" to be is that the DRM driver completes pageflips and modesets at arbitrary times, perhaps always immediately or perhaps with a variable delay that depends on how much processing is needed for the update. Also vblank events do not fire and vblank counters do not advance. Is this correct? Thanks, pq > > The first patch is prep work for adding virtual_hw mode and refactors > the plane composition in vkms by adding a helper function > vkms_composer_common() > which can be used for both vblank mode and virtual mode. > > The second patch adds virtual hardware support as a module option. It > adds new atomic helper functions for the virtual mode > and modifies the existing atomic helpers for usage by the vblank mode > This gives us two sets of drm_crtc_helper_funcs struct for both modes, > making the code flow cleaner and easier to debug. > > This patchset has been tested with the igt tests- kms_writeback, kms_atomic, > kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for > subtests related to crc reads and skips tests that rely on vertical > blanking. This patchset must be tested after incorporating the > igt-tests patch: > https://lists.freedesktop.org/archives/igt-dev/2021-February/029355.html > > Sumera Priyadarsini (2): > drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode > drm/vkms: Add support for virtual hardware mode > > drivers/gpu/drm/vkms/vkms_composer.c | 88 +--- > drivers/gpu/drm/vkms/vkms_crtc.c | 51 +++- > drivers/gpu/drm/vkms/vkms_drv.c | 18 -- > drivers/gpu/drm/vkms/vkms_drv.h | 4 ++ > 4 files changed, 109 insertions(+), 52 deletions(-) > pgpc66oKMobEJ.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/connector: demote connector force-probes for non-master clients
On Fri, 2 Apr 2021 13:22:12 +0200
Simon Ser wrote:
> Force-probing a connector can be slow and cause flickering. As this
> affects the global KMS state, let's make it so only the DRM master
> can force-probe a connector.
>
> Non-master DRM clients won't be able to force-probe a connector
> anymore. Instead, KMS will perform a regular read-only connector
> query.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
Hi,
seems like a good idea to me.
Acked-by: Pekka Paalanen
Btw. can force-probe be triggered via sysfs as well and does it require
root privs?
Thanks,
pq
> ---
> drivers/gpu/drm/drm_connector.c | 11 ---
> include/uapi/drm/drm_mode.h | 7 ---
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..2f70a52a892b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -20,6 +20,7 @@
> * OF THIS SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -2374,9 +2375,13 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
>
> mutex_lock(>mode_config.mutex);
> if (out_resp->count_modes == 0) {
> - connector->funcs->fill_modes(connector,
> - dev->mode_config.max_width,
> - dev->mode_config.max_height);
> + if (drm_is_current_master(file_priv))
> + connector->funcs->fill_modes(connector,
> + dev->mode_config.max_width,
> +
> dev->mode_config.max_height);
> + else
> + drm_dbg_kms(dev, "User-space requested a forced probe
> on [CONNECTOR:%d:%s] but is not the DRM master, demoting to read-only probe",
> + connector->base.id, connector->name);
> }
>
> out_resp->mm_width = connector->display_info.width_mm;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index a5e76aa06ad5..3efa2e38d89b 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -413,9 +413,10 @@ enum drm_mode_subconnector {
> *
> * **Force-probing a connector**
> *
> - * If the @count_modes field is set to zero, the kernel will perform a forced
> - * probe on the connector to refresh the connector status, modes and EDID.
> - * A forced-probe can be slow, might cause flickering and the ioctl will
> block.
> + * If the @count_modes field is set to zero and the DRM client is the DRM
> + * master, the kernel will perform a forced probe on the connector to refresh
> + * the connector status, modes and EDID. A forced-probe can be slow, might
> + * cause flickering and the ioctl will block.
> *
> * User-space needs to force-probe connectors to ensure their metadata is
> * up-to-date at startup and after receiving a hot-plug event. User-space
pgpAZLgd9Lz4t.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13
Am 06.04.21 um 17:42 schrieb Felix Kuehling: Am 2021-04-01 um 6:29 p.m. schrieb Alex Deucher: Hi Dave, Daniel, New stuff for 5.13. There are two small patches for ttm and scheduler that were dependencies for amdgpu changes. The following changes since commit 2cbcb78c9ee5520c8d836c7ff57d1b60ebe8e9b7: Merge tag 'amd-drm-next-5.13-2021-03-23' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-03-26 15:53:21 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.13-2021-04-01 for you to fetch changes up to ef95d2a98d642a537190d73c45ae3c308afee890: drm/amdgpu/display: fix warning on 32 bit in dmub (2021-04-01 17:32:32 -0400) amd-drm-next-5.13-2021-04-01: amdgpu: - Re-enable GPU reset on VanGogh - Enable DPM flags for SMART_SUSPEND and MAY_SKIP_RESUME - Disentangle HG from vga_switcheroo - S0ix fixes - W=1 fixes - Resource iterator fixes - DMCUB updates - UBSAN fixes - More PM API cleanup - Aldebaran updates - Modifier fixes - Enable VCN load balancing with asymmetric engines - Rework BO structs - Aldebaran reset support - Initial LTTPR display work - Display MALL fixes - Fall back to YCbCr420 when YCbCr444 fails - SR-IOV fixes - Misc cleanups and fixes radeon: - Typo fixes ttm: - Handle cached requests (required for Aldebaran) scheduler: - Fix runqueue selection when changing priorities (required to fix VCN load balancing) Alex Deucher (20): drm/amdgpu/display/dm: add missing parameter documentation drm/amdgpu: Add additional Sienna Cichlid PCI ID drm/amdgpu: add a dev_pm_ops prepare callback (v2) drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and DPM_FLAG_SMART_SUSPEND flags (v2) drm/amdgpu: disentangle HG systems from vgaswitcheroo drm/amdgpu: rework S3/S4/S0ix state handling drm/amdgpu: don't evict vram on APUs for suspend to ram (v4) drm/amdgpu: clean up non-DC suspend/resume handling drm/amdgpu: move s0ix check into amdgpu_device_ip_suspend_phase2 (v3) drm/amdgpu: re-enable suspend phase 2 for S0ix drm/amdgpu/swsmu: skip gfx cgpg on s0ix suspend drm/amdgpu: update comments about s0ix suspend/resume drm/amdgpu: drop S0ix checks around CG/PG in suspend drm/amdgpu: skip kfd suspend/resume for S0ix drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.x drm/amdgpu/display: fix memory leak for dimgrey cavefish drm/amdgpu/pm: mark pcie link/speed arrays as const drm/amdgpu/pm: bail on sysfs/debugfs queries during platform suspend drm/amdgpu/vangogh: don't check for dpm in is_dpm_running when in suspend drm/amdgpu/display: fix warning on 32 bit in dmub Alex Sierra (2): drm/amdgpu: replace per_device_list by array drm/amdgpu: ih reroute for newer asics than vega20 Alvin Lee (1): drm/amd/display: Change input parameter for set_drr Anson Jacob (2): drm/amd/display: Fix UBSAN: shift-out-of-bounds warning drm/amd/display: Removing unused code from dmub_cmd.h Anthony Koo (2): drm/amd/display: [FW Promotion] Release 0.0.57 drm/amd/display: [FW Promotion] Release 0.0.58 Aric Cyr (2): drm/amd/display: 3.2.128 drm/amd/display: 3.2.129 Arnd Bergmann (3): amdgpu: avoid incorrect %hu format string amdgpu: fix gcc -Wrestrict warning amdgpu: securedisplay: simplify i2c hexdump output Bhaskar Chowdhury (6): drm/amdgpu: Fix a typo drm/amdgpu: Fix a typo drm/atomic: Couple of typo fixes drm/radeon/r600_cs: Few typo fixes drm/amd/amdgpu/gfx_v7_0: Trivial typo fixes drm/amd: Fix a typo in two different sentences Bindu Ramamurthy (1): drm/amd/display: Allow idle optimization based on vblank. Chengming Gui (1): drm/amd/amdgpu: set MP1 state to UNLOAD before reload its FW for vega20/ALDEBARAN Chris Park (1): drm/amd/display: Disable MALL when SMU not present Christian König (5): drm/amdgpu: remove irq_src->data handling drm/amdgpu: add the sched_score to amdgpu_ring_init drm/amdgpu: share scheduler score on VCN3 instances drm/sched: select new rq even if there is only one v3 drm/amdgpu: load balance VCN3 decode as well v8 Daniel Gomez (2): drm/amdgpu/ttm: Fix memory leak userptr pages This introduced a regression for KFD, which I pointed out at the time. Was there ever a fix for that. This was fixed recently by somebody else. I've reviewed the patch, but I'm not sure if it landed inside the branch. Regards, Christian. Regards, Felix drm/radeon/ttm: Fix memory leak userptr pages David Galiffi (1): drm/amd/display: Fixed Clock Recovery Sequence Dennis Li (1): drm/amdgpu: add codes to capture invalid hardware access when recovery
[PATCH v1] drm/radeon: Fix a missing check bug in radeon_dp_mst_detect()
From: Yingjie Wang
In radeon_dp_mst_detect(), We should check whether or not @connector
has been unregistered from userspace. If the connector is unregistered,
we should return disconnected status.
Fixes: 9843ead08f18 ("drm/radeon: add DisplayPort MST support (v2)")
Signed-off-by: Yingjie Wang
---
drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 2c32186c4acd..4e4c937c36c6 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -242,6 +242,9 @@ radeon_dp_mst_detect(struct drm_connector *connector,
to_radeon_connector(connector);
struct radeon_connector *master = radeon_connector->mst_port;
+ if (drm_connector_is_unregistered(connector))
+ return connector_status_disconnected;
+
return drm_dp_mst_detect_port(connector, ctx, >mst_mgr,
radeon_connector->port);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-P
Signed-off-by: songqiang
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 14660f723f71..f3698f0ad4d7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned
npages, int flags,
if (++p != pages[i + j])
break;
- if (j == HPAGE_PMD_NR)
+ if (j == HPAGE_PMD_NR) {
order = HPAGE_PMD_ORDER;
+ for (j = 1; j < HPAGE_PMD_NR; ++j)
+ page_ref_dec(pages[i+j]);
+ }
}
#endif
@@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned
npages, int flags,
p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
if (!p)
break;
-
- for (j = 0; j < HPAGE_PMD_NR; ++j)
+ for (j = 0; j < HPAGE_PMD_NR; ++j) {
pages[i++] = p++;
-
+ if (j > 0)
+ page_ref_inc(pages[i-1]);
+ }
npages -= HPAGE_PMD_NR;
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
