[git pull] drm fixes for 5.4-rc6
Hi Linus, This is the regular drm fixes pull request for 5.4-rc6. It's a bit larger than I'd like but then last week was quieter than usual. The main fixes are amdgpu, and the two bigger area are navi fixes which are the newest GPU range so still getting actively fixed up, but also a bunch of clang stack alignment fixes (as amdgpu uses double in some places). Otherwise it's all fairly run of the mill fixes, i915, panfrost, etnaviv, v3d and radeon, along with a core scheduler fix. Dave. drm-fixes-2019-11-01: drm fixes for 5.4-rc6 amdgpu: - clang alignment fixes - Updated golden settings - navi: gpuvm, sdma and display fixes - Freesync fix - Gamma fix for DCN - DP dongle detection fix - vega10: Fix for undervolting radeon: - reenable kexec fix for ppc scheduler: - set an error if hw job failed i915: - fix PCH reference clock for HSW/BDW - TGL display PLL doc fix panfrost: - warning fix - runtime pm fix - bad pointer dereference fix v3d: - memleak fix etnaviv: - memory corruption fix - deadlock fix - reintroduce lost debug message The following changes since commit d6d5df1db6e9d7f8f76d2911707f7d5877251b02: Linux 5.4-rc5 (2019-10-27 13:19:19 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-11-01 for you to fetch changes up to e54de91a24753da713b9bcf9fcd93eec246e45e7: Merge tag 'drm-fixes-5.4-2019-10-30' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2019-11-01 11:27:39 +1000) drm fixes for 5.4-rc6 amdgpu: - clang alignment fixes - Updated golden settings - navi: gpuvm, sdma and display fixes - Freesync fix - Gamma fix for DCN - DP dongle detection fix - vega10: Fix for undervolting radeon: - reenable kexec fix for ppc scheduler: - set an error if hw job failed i915: - fix PCH reference clock for HSW/BDW - TGL display PLL doc fix panfrost: - warning fix - runtime pm fix - bad pointer dereference fix v3d: - memleak fix etnaviv: - memory corruption fix - deadlock fix - reintroduce lost debug message Aidan Yang (1): drm/amd/display: Allow inverted gamma Alex Deucher (1): drm/amdgpu/gmc10: properly set BANK_SELECT and FRAGMENT_SIZE Andrey Grodzovsky (2): drm/sched: Set error to s_fence if HW job submission failed. drm/amdgpu: If amdgpu_ib_schedule fails return back the error. Anna Karas (1): drm/i915/tgl: Fix doc not corresponding to code Christian Gmeiner (1): drm/etnaviv: fix dumping of iommuv2 Dave Airlie (4): Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-10-30-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2019-10-31' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-fixes-5.4-2019-10-30' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Jun Lei (2): drm/amd/display: do not synchronize "drr" displays drm/amd/display: add 50us buffer as WA for pstate switch in active Kyle Mahlkuch (1): drm/radeon: Fix EEH during kexec Lucas Stach (2): drm/etnaviv: fix deadlock in GPU coredump drm/etnaviv: reinstate MMUv1 command buffer window check Michael Strauss (1): drm/amd/display: Passive DP->HDMI dongle detection fix Navid Emamdoost (1): drm/v3d: Fix memory leak in v3d_submit_cl_ioctl Nick Desaulniers (3): drm/amdgpu: fix stack alignment ABI mismatch for Clang drm/amdgpu: fix stack alignment ABI mismatch for GCC 7.1+ drm/amdgpu: enable -msse2 for GCC 7.1+ users Pelle van Gils (1): drm/amdgpu/powerplay/vega10: allow undervolting in p7 Pierre-Eric Pelloux-Prayer (1): drm/amdgpu/sdma5: do not execute 0-sized IBs (v2) Robin Murphy (1): drm/panfrost: Don't dereference bogus MMU pointers Tianci.Yin (3): drm/amdgpu/gfx10: update gfx golden settings drm/amdgpu/gfx10: update gfx golden settings for navi14 drm/amdgpu/gfx10: update gfx golden settings for navi12 Tomeu Vizoso (1): panfrost: Properly undo pm_runtime_enable when deferring a probe Ville Syrjälä (1): drm/i915: Fix PCH reference clock for FDI on HSW/BDW Yi Wang (1): drm/panfrost: fix -Wmissing-prototypes warnings Zhan liu (2): drm/amd/display: Change Navi14's DWB flag to 1 drm/amd/display: setting the DIG_MODE to the correct value. chen gong (1): drm/amdgpu: Fix SDMA hang when performing VKexample test zhongshiqi (1): dc.c:use kzalloc without test drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 4 +++- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 9 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 + drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c| 9
[PATCH] drm/doc: Adding VKMS module description and use to "Testing and Validation"
Add a description on VKMS module and the cases in which it should be used. There's a brief explanation on how to set it and use it in a VM, along with an example of running an igt-test. Signed-off-by: Gabriela Bittencourt --- Hi DRM-community, this is my first (of many, I hope) patch in this subsystem. I hope to have a lot of learning (and fun :)) working with you guys. I'm starting by documenting the VKMS driver in "Userland interfaces", if I have been inaccurate in my description or if I misunderstood some concept, please let me know. --- Documentation/gpu/drm-uapi.rst | 38 ++ 1 file changed, 38 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 94f90521f58c..7d6c86b7af76 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -285,6 +285,44 @@ run-tests.sh is a wrapper around piglit that will execute the tests matching the -t options. A report in HTML format will be available in ./results/html/index.html. Results can be compared with piglit. +Using VKMS to test DRM API +-- + +VKMS is a software-only model of a KMS driver that is useful for testing +and for running compositors. VKMS aims to enable a virtual display without +the need for a hardware display capability. These characteristics made VKMS +a perfect tool for validating the DRM core behavior and also support the +compositor developer. VKMS helps us to test DRM core function in a virtual +machine, which makes it easy to test some of the core changes. + +To Validate changes in DRM API with VKMS, start setting the kernel. The +VKMS module is not enabled by defaut, so enable it in the menuconfig:: + + $ make menuconfig + +Compile the kernel with the VKMS enabled and install it in the target +machine. VKMS can be run in a Virtual Machine (QEMU, virtme or similar). +It's recommended the use of KVM with the minimum of 1GB of RAM and four +cores. + +It's possible to run the IGT-tests in a VM in two ways: +1. Use IGT inside a VM +2. Use IGT from the host machine and write the results in a shared directory. + +As follow, there is an example of using a VM with a shared directory with +the host machine to run igt-tests. As example it's used virtme:: + + $ virtme-run --rwdir /path/for/shared_dir --kdir=path/for/kernel/directory --mods=auto + +Run the igt-tests, as example it's ran the 'kms_flip' tests:: + + $ /path/for/igt-gpu-tools/scripts/run-tests.sh -p -s -t "kms_flip.*" -v + +In this example instead of build the igt_runner it's used Piglit +(-p option); it's created html summary of the tests results and it's saved +in the folder "igt-gpu-tools/results"; it's executed only the igt-tests +matching the -t option. + Display CRC Support --- -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: update cursors by using async atomic update
Hi, Bibby:
On Fri, 2019-10-25 at 13:38 +0800, Bibby Hsieh wrote:
> Support to async updates of cursors by using the new atomic
> interface for that.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 32 +
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 ++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 44
> 3 files changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index b07dc9b59ca3..3c96178bd559 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -395,6 +395,38 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> }
> }
>
> +void mtk_drm_crtc_cursor_update(struct drm_crtc *crtc, struct drm_plane
> *plane,
> + struct drm_plane_state *new_state)
> +{
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + const struct drm_plane_helper_funcs *plane_helper_funcs =
> + plane->helper_private;
> + int i;
> +
> + if (!mtk_crtc->enabled)
> + return;
> +
> + plane_helper_funcs->atomic_update(plane, new_state);
> +
> + for (i = 0; i < mtk_crtc->layer_nr; i++) {
> + struct drm_plane *plane = _crtc->planes[i];
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> + if (plane_state->pending.dirty) {
> + plane_state->pending.config = true;
> + plane_state->pending.dirty = false;
You do this for all plane but I think you should only do this for this
plane. Other plane should do this only when atomic_flush.
Regards,
CK
> + }
> + }
> + mtk_crtc->pending_planes = true;
> + if (priv->data->shadow_register) {
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
> +}
> +
> static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index fcc134eb00c9..e65d58db201d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -20,4 +20,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> const enum mtk_ddp_comp_id *path,
> unsigned int path_len);
>
> +void mtk_drm_crtc_cursor_update(struct drm_crtc *crtc, struct drm_plane
> *plane,
> + struct drm_plane_state *plane_state);
> +
> #endif /* MTK_DRM_CRTC_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 584a9ecadce6..f0e91ecb3b4c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -70,6 +71,47 @@ static void mtk_drm_plane_destroy_state(struct drm_plane
> *plane,
> kfree(to_mtk_plane_state(state));
> }
>
> +static int mtk_plane_atomic_async_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> +
> + if (plane != state->crtc->cursor)
> + return -EINVAL;
> +
> + if (!plane->state)
> + return -EINVAL;
> +
> + if (!plane->state->fb)
> + return -EINVAL;
> +
> + if (state->state)
> + crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> + state->crtc);
> + else /* Special case for asynchronous cursor updates. */
> + crtc_state = state->crtc->state;
> +
> + return drm_atomic_helper_check_plane_state(plane->state, crtc_state,
> +DRM_PLANE_HELPER_NO_SCALING,
> +DRM_PLANE_HELPER_NO_SCALING,
> +true, true);
> +}
> +
> +static void mtk_plane_atomic_async_update(struct drm_plane *plane,
> + struct drm_plane_state *new_state)
> +{
> + plane->state->crtc_x = new_state->crtc_x;
> + plane->state->crtc_y = new_state->crtc_y;
> + plane->state->crtc_h = new_state->crtc_h;
> + plane->state->crtc_w = new_state->crtc_w;
> + plane->state->src_x = new_state->src_x;
> + plane->state->src_y = new_state->src_y;
> + plane->state->src_h = new_state->src_h;
> + plane->state->src_w = new_state->src_w;
> +
> + mtk_drm_crtc_cursor_update(new_state->crtc, plane, new_state);
> +}
>
Re: [PATCH] drm/mediatek: update cursors by using async atomic update
Hi, Bibby:
On Fri, 2019-10-25 at 13:38 +0800, Bibby Hsieh wrote:
> Support to async updates of cursors by using the new atomic
> interface for that.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 32 +
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 ++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 44
> 3 files changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index b07dc9b59ca3..3c96178bd559 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -395,6 +395,38 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> }
> }
>
> +void mtk_drm_crtc_cursor_update(struct drm_crtc *crtc, struct drm_plane
> *plane,
> + struct drm_plane_state *new_state)
> +{
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + const struct drm_plane_helper_funcs *plane_helper_funcs =
> + plane->helper_private;
> + int i;
> +
> + if (!mtk_crtc->enabled)
> + return;
> +
> + plane_helper_funcs->atomic_update(plane, new_state);
Why do you not call mtk_plane_atomic_update() directly?
> +
> + for (i = 0; i < mtk_crtc->layer_nr; i++) {
> + struct drm_plane *plane = _crtc->planes[i];
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> + if (plane_state->pending.dirty) {
> + plane_state->pending.config = true;
> + plane_state->pending.dirty = false;
> + }
> + }
> + mtk_crtc->pending_planes = true;
> + if (priv->data->shadow_register) {
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
This part is the same as the part in mtk_drm_crtc_atomic_flush. Separate
the common part to an independent function.
Regards,
CK
> +}
> +
> static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index fcc134eb00c9..e65d58db201d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -20,4 +20,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> const enum mtk_ddp_comp_id *path,
> unsigned int path_len);
>
> +void mtk_drm_crtc_cursor_update(struct drm_crtc *crtc, struct drm_plane
> *plane,
> + struct drm_plane_state *plane_state);
> +
> #endif /* MTK_DRM_CRTC_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 584a9ecadce6..f0e91ecb3b4c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -70,6 +71,47 @@ static void mtk_drm_plane_destroy_state(struct drm_plane
> *plane,
> kfree(to_mtk_plane_state(state));
> }
>
> +static int mtk_plane_atomic_async_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> +
> + if (plane != state->crtc->cursor)
> + return -EINVAL;
> +
> + if (!plane->state)
> + return -EINVAL;
> +
> + if (!plane->state->fb)
> + return -EINVAL;
> +
> + if (state->state)
> + crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> + state->crtc);
> + else /* Special case for asynchronous cursor updates. */
> + crtc_state = state->crtc->state;
> +
> + return drm_atomic_helper_check_plane_state(plane->state, crtc_state,
> +DRM_PLANE_HELPER_NO_SCALING,
> +DRM_PLANE_HELPER_NO_SCALING,
> +true, true);
> +}
> +
> +static void mtk_plane_atomic_async_update(struct drm_plane *plane,
> + struct drm_plane_state *new_state)
> +{
> + plane->state->crtc_x = new_state->crtc_x;
> + plane->state->crtc_y = new_state->crtc_y;
> + plane->state->crtc_h = new_state->crtc_h;
> + plane->state->crtc_w = new_state->crtc_w;
> + plane->state->src_x = new_state->src_x;
> + plane->state->src_y = new_state->src_y;
> + plane->state->src_h = new_state->src_h;
> + plane->state->src_w = new_state->src_w;
> +
> +
[Bug 111482] Sapphire Pulse RX 5700 XT power consumption
https://bugs.freedesktop.org/show_bug.cgi?id=111482 --- Comment #29 from Shmerl --- (In reply to Andrew Sheldon from comment #27) > A bit of a hacky workaround to 144hz (and multi-monitor issues) on Navi: > > - Bootup to X > - Suspend to ram > - Notice that clocks have dropped (even in multi-monitor configuration) > - I get flickering in the auto profile after doing this (maybe similar to > the Polaris issues) > - To remove the flickering, set power_dpm_force_performance_level to "low" > Which one exactly did you set it at? I have 2560x1440 / 144 Hz monitor (LG 27GL850) and Sapphire Pulse RX 5700 XT (hardware switch set to higher performance BIOS) and in general I noticed a similar thing. During normal idle KDE operation, power stays at around 32 W or so. If I suspend and resume, power drops to 11 W and the monitor starts flickering wildly. I tried to do: echo "low" > /sys/class/drm/card0/device/power_dpm_force_performance_level But that didn't really help with flickering. Can anyone from AMD please comment, whether 32 W is expected power consumption for light desktop usage at 2560x1440 / 144 Hz for Sapphire Pulse RX 5700 XT? And clearly, after resume things are now broken regardless of what's the normal level is supposed to be. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: covert to helper nonblocking atomic commit
Hi, Bibby:
On Fri, 2019-10-25 at 13:38 +0800, Bibby Hsieh wrote:
> In order to commit state asynchronously, we change
> .atomic_commit to drm_atomic_helper_commit().
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 11
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 ++---
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 --
> 3 files changed, 16 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index b97eb5f58483..b07dc9b59ca3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -317,6 +317,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
> {
> struct drm_device *drm = mtk_crtc->base.dev;
> + struct drm_crtc *crtc = _crtc->base;
> int i;
>
> DRM_DEBUG_DRIVER("%s\n", __func__);
> @@ -340,6 +341,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> mtk_disp_mutex_unprepare(mtk_crtc->mutex);
>
> pm_runtime_put(drm->dev);
> +
> + if (crtc->state->event && !crtc->state->active) {
> + spin_lock_irq(>dev->event_lock);
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + crtc->state->event = NULL;
> + spin_unlock_irq(>dev->event_lock);
> + }
This part looks like a bug fix. When the power is off, the latest event
may not process yet. So just send it here. But in
mtk_drm_crtc_atomic_disable(), it already wait for a vblank, why the
latest event has not processed yet?
> }
>
> static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> @@ -456,12 +464,15 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc
> *crtc,
> if (mtk_crtc->event && state->base.event)
> DRM_ERROR("new event while there is still a pending event\n");
>
> + spin_lock_irq(>dev->event_lock);
> if (state->base.event) {
> state->base.event->pipe = drm_crtc_index(crtc);
> WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> + WARN_ON(mtk_crtc->event);
> mtk_crtc->event = state->base.event;
> state->base.event = NULL;
> }
> + spin_unlock_irq(>dev->event_lock);
This part is a bug fix. The 'event' variable would be access by thread
context in mtk_drm_crtc_atomic_begin() or by interrupt context in
mtk_drm_crtc_finish_page_flip(), so each part should be a critical
section. Move this to an independent patch.
> }
>
> static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 6588dc6dd5e3..16e5771d182e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -36,89 +36,14 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -static void mtk_atomic_schedule(struct mtk_drm_private *private,
> - struct drm_atomic_state *state)
> -{
> - private->commit.state = state;
> - schedule_work(>commit.work);
> -}
> -
> -static void mtk_atomic_complete(struct mtk_drm_private *private,
> - struct drm_atomic_state *state)
> -{
> - struct drm_device *drm = private->drm;
> -
> - drm_atomic_helper_wait_for_fences(drm, state, false);
> -
> - /*
> - * Mediatek drm supports runtime PM, so plane registers cannot be
> - * written when their crtc is disabled.
> - *
> - * The comment for drm_atomic_helper_commit states:
> - * For drivers supporting runtime PM the recommended sequence is
> - *
> - * drm_atomic_helper_commit_modeset_disables(dev, state);
> - * drm_atomic_helper_commit_modeset_enables(dev, state);
> - * drm_atomic_helper_commit_planes(dev, state,
> - * DRM_PLANE_COMMIT_ACTIVE_ONLY);
> - *
> - * See the kerneldoc entries for these three functions for more details.
> - */
> - drm_atomic_helper_commit_modeset_disables(drm, state);
> - drm_atomic_helper_commit_modeset_enables(drm, state);
> - drm_atomic_helper_commit_planes(drm, state,
> - DRM_PLANE_COMMIT_ACTIVE_ONLY);
> -
> - drm_atomic_helper_wait_for_vblanks(drm, state);
> -
> - drm_atomic_helper_cleanup_planes(drm, state);
> - drm_atomic_state_put(state);
> -}
> -
> -static void mtk_atomic_work(struct work_struct *work)
> -{
> - struct mtk_drm_private *private = container_of(work,
> - struct mtk_drm_private, commit.work);
> -
> - mtk_atomic_complete(private, private->commit.state);
> -}
> -
> -static int mtk_atomic_commit(struct drm_device *drm,
> - struct drm_atomic_state *state,
> - bool async)
> -{
> - struct
[Bug 112138] [kernel 5.4-rc4][amdgpu][CIK]: [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
https://bugs.freedesktop.org/show_bug.cgi?id=112138 --- Comment #2 from MasterCATZ --- also noticed same issue , causing fan control on my R9 290's to stop and GPU's hitting thermal limits @ 96 Deg because powerplay can not talk to the cards BIOS Oct 26 08:08:28 aio kernel: [drm] add ip block number 5 Oct 26 08:08:28 aio kernel: amdgpu: [powerplay] hwmgr_sw_init smu backed is ci_smu amdgpu: [powerplay] failed to send message 282 ret is 254 Linux 5.3.8-050308-generic OpenGL Information GL_VENDOR: X.Org GL_RENDERER: AMD Radeon R9 200 Series (HAWAII, DRM 3.33.0, 5.3.8-050308-generic, LLVM 9.0.0) GL_VERSION:4.5 (Compatibility Profile) Mesa 19.3.0-devel (git-ff6e148 2019-10-29 bionic-oibaf-ppa) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111869] Navi "divide error" hang
https://bugs.freedesktop.org/show_bug.cgi?id=111869 --- Comment #3 from Andrew Sheldon --- I also get this error frequently with amd-staging-drm-next, but not with 5.4-rcX (at least I can't remember getting one with the latter). Not sure if that suggests there is a regression, or something to do with the 5.3 kernel specifically (I don't remember having the error when amd-staging-drm-next was using 5.2 kernel). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #16 from Andrew Sheldon --- (In reply to wychuchol from comment #14) > RX 5700 XT Pop OS 19.10 latest Oibaf mesa not sure what llvm > Anomaly 1.5.0 update 3 standalone 64 bit mod for S.T.A.L.K.E.R. Call of > Pripyat running under wine d3dx11_43->dxvk (winetricks dxvk d3dcompiler_43 > d3dx11_43) > > Oct 30 02:49:30 pop-os kernel: [ 4864.627343] > [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for > fences timed out! > Oct 30 02:49:30 pop-os kernel: [ 4869.231450] [drm:amdgpu_job_timedout > [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=2626284, emitted > seq=2626286 > Oct 30 02:49:30 pop-os kernel: [ 4869.231486] [drm:amdgpu_job_timedout > [amdgpu]] *ERROR* Process information: process AnomalyDX11.exe pid 5791 > thread AnomalyDX11.exe pid 5791 > Oct 30 02:49:30 pop-os kernel: [ 4869.231487] [drm] GPU recovery disabled. > > Happens at random. Sometimes hangs straight away, sometimes can go over an > hour without crash. Complete crash, no option available besides hard reset. > Not even mouse pointer would move (as with sdma0 hang). > > I'm sorry if it's not the right place to report this, I'm somewhat new to > all of this. Ring gfx type hangs tend to be in Mesa. Report here: https://gitlab.freedesktop.org/mesa/mesa/issues Also I'm not sure how up to date the Oibaf repo is, but Mesa git landed ACO recently for Navi cards. You can try with RADV_PERFTEST=aco environment variable set if your Mesa is new enough, and you might have better luck with hangs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/19] Documentation/vm: add pin_user_pages.rst
On Wed, Oct 30, 2019 at 03:49:30PM -0700, John Hubbard wrote:
> Document the new pin_user_pages() and related calls
> and behavior.
>
> Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
> in this documentation. (I've reworded it and expanded on it slightly.)
As I said before I think this may be better in a previous patch where you
reference it.
Ira
>
> Cc: Jonathan Corbet
> Signed-off-by: John Hubbard
> ---
> Documentation/vm/index.rst | 1 +
> Documentation/vm/pin_user_pages.rst | 213
> 2 files changed, 214 insertions(+)
> create mode 100644 Documentation/vm/pin_user_pages.rst
>
> diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst
> index e8d943b21cf9..7194efa3554a 100644
> --- a/Documentation/vm/index.rst
> +++ b/Documentation/vm/index.rst
> @@ -44,6 +44,7 @@ descriptions of data structures and algorithms.
> page_migration
> page_frags
> page_owner
> + pin_user_pages
> remap_file_pages
> slub
> split_page_table_lock
> diff --git a/Documentation/vm/pin_user_pages.rst
> b/Documentation/vm/pin_user_pages.rst
> new file mode 100644
> index ..7110bca3f188
> --- /dev/null
> +++ b/Documentation/vm/pin_user_pages.rst
> @@ -0,0 +1,213 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +
> +pin_user_pages() and related calls
> +
> +
> +.. contents:: :local:
> +
> +Overview
> +
> +
> +This document describes the following functions: ::
> +
> + pin_user_pages
> + pin_user_pages_fast
> + pin_user_pages_remote
> +
> + pin_longterm_pages
> + pin_longterm_pages_fast
> + pin_longterm_pages_remote
> +
> +Basic description of FOLL_PIN
> +=
> +
> +A new flag for get_user_pages ("gup") has been added: FOLL_PIN. FOLL_PIN has
> +significant interactions and interdependencies with FOLL_LONGTERM, so both
> are
> +covered here.
> +
> +Both FOLL_PIN and FOLL_LONGTERM are "internal" to gup, meaning that neither
> +FOLL_PIN nor FOLL_LONGTERM should not appear at the gup call sites. This
> allows
> +the associated wrapper functions (pin_user_pages and others) to set the
> correct
> +combination of these flags, and to check for problems as well.
> +
> +FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,
> +multiple threads and call sites are free to pin the same struct pages, via
> both
> +FOLL_PIN and FOLL_GET. It's just the call site that needs to choose one or
> the
> +other, not the struct page(s).
> +
> +The FOLL_PIN implementation is nearly the same as FOLL_GET, except that
> FOLL_PIN
> +uses a different reference counting technique.
> +
> +FOLL_PIN is a prerequisite to FOLL_LONGTGERM. Another way of saying that is,
> +FOLL_LONGTERM is a specific case, more restrictive case of FOLL_PIN.
> +
> +Which flags are set by each wrapper
> +===
> +
> +Only FOLL_PIN and FOLL_LONGTERM are covered here. These flags are added to
> +whatever flags the caller provides::
> +
> + Functiongup flags (FOLL_PIN or FOLL_LONGTERM only)
> + --
> + pin_user_pages FOLL_PIN
> + pin_user_pages_fast FOLL_PIN
> + pin_user_pages_remote FOLL_PIN
> +
> + pin_longterm_pages FOLL_PIN | FOLL_LONGTERM
> + pin_longterm_pages_fast FOLL_PIN | FOLL_LONGTERM
> + pin_longterm_pages_remote FOLL_PIN | FOLL_LONGTERM
> +
> +Tracking dma-pinned pages
> +=
> +
> +Some of the key design constraints, and solutions, for tracking dma-pinned
> +pages:
> +
> +* An actual reference count, per struct page, is required. This is because
> + multiple processes may pin and unpin a page.
> +
> +* False positives (reporting that a page is dma-pinned, when in fact it is
> not)
> + are acceptable, but false negatives are not.
> +
> +* struct page may not be increased in size for this, and all fields are
> already
> + used.
> +
> +* Given the above, we can overload the page->_refcount field by using, sort
> of,
> + the upper bits in that field for a dma-pinned count. "Sort of", means that,
> + rather than dividing page->_refcount into bit fields, we simple add a
> medium-
> + large value (GUP_PIN_COUNTING_BIAS, initially chosen to be 1024: 10 bits)
> to
> + page->_refcount. This provides fuzzy behavior: if a page has get_page()
> called
> + on it 1024 times, then it will appear to have a single dma-pinned count.
> + And again, that's acceptable.
> +
> +This also leads to limitations: there are only 32-10==22 bits available for a
> +counter that increments 10 bits at a time.
> +
> +TODO: for 1GB and larger huge pages, this is cutting it close. That's because
> +when pin_user_pages() follows such pages, it increments the head page by "1"
> +(where "1" used to mean "+1" for get_user_pages(), but now means
Re: [PATCH 13/19] media/v4l2-core: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
On Wed, Oct 30, 2019 at 03:49:24PM -0700, John Hubbard wrote:
> 1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
> pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
>
> 2. Because all FOLL_PIN-acquired pages must be released via
> put_user_page(), also convert the put_page() call over to
> put_user_pages_dirty_lock().
>
Reviewed-by: Ira Weiny
> Cc: Mauro Carvalho Chehab
> Signed-off-by: John Hubbard
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
> b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index 28262190c3ab..9b9c5b37bf59 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -183,12 +183,12 @@ static int videobuf_dma_init_user_locked(struct
> videobuf_dmabuf *dma,
> dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
> data, size, dma->nr_pages);
>
> - err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
> - flags | FOLL_LONGTERM, dma->pages, NULL);
> + err = pin_longterm_pages(data & PAGE_MASK, dma->nr_pages,
> + flags, dma->pages, NULL);
>
> if (err != dma->nr_pages) {
> dma->nr_pages = (err >= 0) ? err : 0;
> - dprintk(1, "get_user_pages: err=%d [%d]\n", err,
> + dprintk(1, "pin_longterm_pages: err=%d [%d]\n", err,
> dma->nr_pages);
> return err < 0 ? err : -EINVAL;
> }
> @@ -349,11 +349,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
> BUG_ON(dma->sglen);
>
> if (dma->pages) {
> - for (i = 0; i < dma->nr_pages; i++) {
> - if (dma->direction == DMA_FROM_DEVICE)
> - set_page_dirty_lock(dma->pages[i]);
> - put_page(dma->pages[i]);
> - }
> + put_user_pages_dirty_lock(dma->pages, dma->nr_pages,
> + dma->direction == DMA_FROM_DEVICE);
> kfree(dma->pages);
> dma->pages = NULL;
> }
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/19] net/xdp: set FOLL_PIN via pin_user_pages()
On Wed, Oct 30, 2019 at 03:49:22PM -0700, John Hubbard wrote:
> Convert net/xdp to use the new pin_longterm_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages.
>
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> net/xdp/xdp_umem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 16d5f353163a..4d56dfb1139a 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -285,8 +285,8 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
> return -ENOMEM;
>
> down_read(>mm->mmap_sem);
> - npgs = get_user_pages(umem->address, umem->npgs,
> - gup_flags | FOLL_LONGTERM, >pgs[0], NULL);
> + npgs = pin_longterm_pages(umem->address, umem->npgs, gup_flags,
> + >pgs[0], NULL);
> up_read(>mm->mmap_sem);
>
> if (npgs != umem->npgs) {
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/19] fs/io_uring: set FOLL_PIN via pin_user_pages()
On Wed, Oct 30, 2019 at 03:49:21PM -0700, John Hubbard wrote:
> Convert fs/io_uring to use the new pin_user_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
>
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> fs/io_uring.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index a30c4f622cb3..d3924b1760eb 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3431,9 +3431,8 @@ static int io_sqe_buffer_register(struct io_ring_ctx
> *ctx, void __user *arg,
>
> ret = 0;
> down_read(>mm->mmap_sem);
> - pret = get_user_pages(ubuf, nr_pages,
> - FOLL_WRITE | FOLL_LONGTERM,
> - pages, vmas);
> + pret = pin_longterm_pages(ubuf, nr_pages, FOLL_WRITE, pages,
> + vmas);
> if (pret == nr_pages) {
> /* don't support file backed memory */
> for (j = 0; j < nr_pages; j++) {
> --
> 2.23.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/19] drm/via: set FOLL_PIN via pin_user_pages_fast()
On Wed, Oct 30, 2019 at 03:49:20PM -0700, John Hubbard wrote: > Convert drm/via to use the new pin_user_pages_fast() call, which sets > FOLL_PIN. Setting FOLL_PIN is now required for code that requires > tracking of pinned pages, and therefore for any code that calls > put_user_page(). > Reviewed-by: Ira Weiny > Signed-off-by: John Hubbard > --- > drivers/gpu/drm/via/via_dmablit.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/via/via_dmablit.c > b/drivers/gpu/drm/via/via_dmablit.c > index 3db000aacd26..37c5e572993a 100644 > --- a/drivers/gpu/drm/via/via_dmablit.c > +++ b/drivers/gpu/drm/via/via_dmablit.c > @@ -239,7 +239,7 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg, > drm_via_dmablit_t *xfer) > vsg->pages = vzalloc(array_size(sizeof(struct page *), vsg->num_pages)); > if (NULL == vsg->pages) > return -ENOMEM; > - ret = get_user_pages_fast((unsigned long)xfer->mem_addr, > + ret = pin_user_pages_fast((unsigned long)xfer->mem_addr, > vsg->num_pages, > vsg->direction == DMA_FROM_DEVICE ? FOLL_WRITE : 0, > vsg->pages); > -- > 2.23.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/19] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()
On Wed, Oct 30, 2019 at 03:49:19PM -0700, John Hubbard wrote:
> Convert process_vm_access to use the new pin_user_pages_remote()
> call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
> code that requires tracking of pinned pages.
>
> Also, release the pages via put_user_page*().
>
> Also, rename "pages" to "pinned_pages", as this makes for
> easier reading of process_vm_rw_single_vec().
Ok... but it made review a bit harder...
Reviewed-by: Ira Weiny
>
> Signed-off-by: John Hubbard
> ---
> mm/process_vm_access.c | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
> index 357aa7bef6c0..fd20ab675b85 100644
> --- a/mm/process_vm_access.c
> +++ b/mm/process_vm_access.c
> @@ -42,12 +42,11 @@ static int process_vm_rw_pages(struct page **pages,
> if (copy > len)
> copy = len;
>
> - if (vm_write) {
> + if (vm_write)
> copied = copy_page_from_iter(page, offset, copy, iter);
> - set_page_dirty_lock(page);
> - } else {
> + else
> copied = copy_page_to_iter(page, offset, copy, iter);
> - }
> +
> len -= copied;
> if (copied < copy && iov_iter_count(iter))
> return -EFAULT;
> @@ -96,7 +95,7 @@ static int process_vm_rw_single_vec(unsigned long addr,
> flags |= FOLL_WRITE;
>
> while (!rc && nr_pages && iov_iter_count(iter)) {
> - int pages = min(nr_pages, max_pages_per_loop);
> + int pinned_pages = min(nr_pages, max_pages_per_loop);
> int locked = 1;
> size_t bytes;
>
> @@ -106,14 +105,15 @@ static int process_vm_rw_single_vec(unsigned long addr,
>* current/current->mm
>*/
> down_read(>mmap_sem);
> - pages = get_user_pages_remote(task, mm, pa, pages, flags,
> - process_pages, NULL, );
> + pinned_pages = pin_user_pages_remote(task, mm, pa, pinned_pages,
> + flags, process_pages,
> + NULL, );
> if (locked)
> up_read(>mmap_sem);
> - if (pages <= 0)
> + if (pinned_pages <= 0)
> return -EFAULT;
>
> - bytes = pages * PAGE_SIZE - start_offset;
> + bytes = pinned_pages * PAGE_SIZE - start_offset;
> if (bytes > len)
> bytes = len;
>
> @@ -122,10 +122,12 @@ static int process_vm_rw_single_vec(unsigned long addr,
>vm_write);
> len -= bytes;
> start_offset = 0;
> - nr_pages -= pages;
> - pa += pages * PAGE_SIZE;
> - while (pages)
> - put_page(process_pages[--pages]);
> + nr_pages -= pinned_pages;
> + pa += pinned_pages * PAGE_SIZE;
> +
> + /* If vm_write is set, the pages need to be made dirty: */
> + put_user_pages_dirty_lock(process_pages, pinned_pages,
> + vm_write);
> }
>
> return rc;
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/19] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()
On Wed, Oct 30, 2019 at 03:49:18PM -0700, John Hubbard wrote:
> Convert infiniband to use the new wrapper calls, and stop
> explicitly setting FOLL_LONGTERM at the call sites.
>
> The new pin_longterm_*() calls replace get_user_pages*()
> calls, and set both FOLL_LONGTERM and a new FOLL_PIN
> flag. The FOLL_PIN flag requires that the caller must
> return the pages via put_user_page*() calls, but
> infiniband was already doing that as part of an earlier
> commit.
>
NOTE: I'm not 100% convinced that mixing the flags and new calls like this is
good. I think we are going to need a lot more documentation on which flags are
"user" accessible vs not...
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> drivers/infiniband/core/umem.c | 5 ++---
> drivers/infiniband/core/umem_odp.c | 10 +-
> drivers/infiniband/hw/hfi1/user_pages.c | 4 ++--
> drivers/infiniband/hw/mthca/mthca_memfree.c | 3 +--
> drivers/infiniband/hw/qib/qib_user_pages.c | 8
> drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
> drivers/infiniband/hw/usnic/usnic_uiom.c| 9 -
> drivers/infiniband/sw/siw/siw_mem.c | 5 ++---
> 8 files changed, 21 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 24244a2f68cc..c5a78d3e674b 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -272,11 +272,10 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
> unsigned long addr,
>
> while (npages) {
> down_read(>mmap_sem);
> - ret = get_user_pages(cur_base,
> + ret = pin_longterm_pages(cur_base,
>min_t(unsigned long, npages,
> PAGE_SIZE / sizeof (struct page *)),
> - gup_flags | FOLL_LONGTERM,
> - page_list, NULL);
> + gup_flags, page_list, NULL);
> if (ret < 0) {
> up_read(>mmap_sem);
> goto umem_release;
> diff --git a/drivers/infiniband/core/umem_odp.c
> b/drivers/infiniband/core/umem_odp.c
> index 163ff7ba92b7..a38b67b83db5 100644
> --- a/drivers/infiniband/core/umem_odp.c
> +++ b/drivers/infiniband/core/umem_odp.c
> @@ -534,7 +534,7 @@ static int ib_umem_odp_map_dma_single_page(
> } else if (umem_odp->page_list[page_index] == page) {
> umem_odp->dma_list[page_index] |= access_mask;
> } else {
> - pr_err("error: got different pages in IB device and from
> get_user_pages. IB device page: %p, gup page: %p\n",
> + pr_err("error: got different pages in IB device and from
> pin_longterm_pages. IB device page: %p, gup page: %p\n",
> umem_odp->page_list[page_index], page);
> /* Better remove the mapping now, to prevent any further
>* damage. */
> @@ -639,11 +639,11 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
> *umem_odp, u64 user_virt,
> /*
>* Note: this might result in redundent page getting. We can
>* avoid this by checking dma_list to be 0 before calling
> - * get_user_pages. However, this make the code much more
> - * complex (and doesn't gain us much performance in most use
> - * cases).
> + * pin_longterm_pages. However, this makes the code much
> + * more complex (and doesn't gain us much performance in most
> + * use cases).
>*/
> - npages = get_user_pages_remote(owning_process, owning_mm,
> + npages = pin_longterm_pages_remote(owning_process, owning_mm,
> user_virt, gup_num_pages,
> flags, local_page_list, NULL, NULL);
> up_read(_mm->mmap_sem);
> diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
> b/drivers/infiniband/hw/hfi1/user_pages.c
> index 469acb961fbd..9b55b0a73e29 100644
> --- a/drivers/infiniband/hw/hfi1/user_pages.c
> +++ b/drivers/infiniband/hw/hfi1/user_pages.c
> @@ -104,9 +104,9 @@ int hfi1_acquire_user_pages(struct mm_struct *mm,
> unsigned long vaddr, size_t np
> bool writable, struct page **pages)
> {
> int ret;
> - unsigned int gup_flags = FOLL_LONGTERM | (writable ? FOLL_WRITE : 0);
> + unsigned int gup_flags = (writable ? FOLL_WRITE : 0);
>
> - ret = get_user_pages_fast(vaddr, npages, gup_flags, pages);
> + ret = pin_longterm_pages_fast(vaddr, npages, gup_flags, pages);
> if (ret < 0)
> return ret;
>
> diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c
> b/drivers/infiniband/hw/mthca/mthca_memfree.c
> index edccfd6e178f..beec7e4b8a96 100644
> --- a/drivers/infiniband/hw/mthca/mthca_memfree.c
> +++
Re: [PATCH 05/19] mm/gup: introduce pin_user_pages*() and FOLL_PIN
On Wed, Oct 30, 2019 at 03:49:16PM -0700, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> basically documented. (An upcoming patch provides more extensive
> documentation.) The second set (pin_longterm*) also sets
> FOLL_LONGTERM:
>
> pin_user_pages()
> pin_user_pages_remote()
> pin_user_pages_fast()
>
> pin_longterm_pages()
> pin_longterm_pages_remote()
> pin_longterm_pages_fast()
>
> All pages that are pinned via the above calls, must be unpinned via
> put_user_page().
>
> The underlying rules are:
>
> * These are gup-internal flags, so the call sites should not directly
> set FOLL_PIN nor FOLL_LONGTERM. That behavior is enforced with
> assertions, for the new FOLL_PIN flag. However, for the pre-existing
> FOLL_LONGTERM flag, which has some call sites that still directly
> set FOLL_LONGTERM, there is no assertion yet.
>
> * Call sites that want to indicate that they are going to do DirectIO
> ("DIO") or something with similar characteristics, should call a
> get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
> will:
> * Start with "pin_user_pages" instead of "get_user_pages". That
> makes it easy to find and audit the call sites.
> * Set FOLL_PIN
>
> * For pages that are received via FOLL_PIN, those pages must be returned
> via put_user_page().
>
> Signed-off-by: John Hubbard
> ---
> include/linux/mm.h | 53 -
> mm/gup.c | 284 +
> 2 files changed, 311 insertions(+), 26 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index cc292273e6ba..62c838a3e6c7 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1526,9 +1526,23 @@ long get_user_pages_remote(struct task_struct *tsk,
> struct mm_struct *mm,
> unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas, int *locked);
> +long pin_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> +unsigned long start, unsigned long nr_pages,
> +unsigned int gup_flags, struct page **pages,
> +struct vm_area_struct **vmas, int *locked);
> +long pin_longterm_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
> +unsigned long start, unsigned long nr_pages,
> +unsigned int gup_flags, struct page **pages,
> +struct vm_area_struct **vmas, int *locked);
> long get_user_pages(unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages,
> struct vm_area_struct **vmas);
> +long pin_user_pages(unsigned long start, unsigned long nr_pages,
> + unsigned int gup_flags, struct page **pages,
> + struct vm_area_struct **vmas);
> +long pin_longterm_pages(unsigned long start, unsigned long nr_pages,
> + unsigned int gup_flags, struct page **pages,
> + struct vm_area_struct **vmas);
> long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages, int *locked);
> long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
> @@ -1536,6 +1550,10 @@ long get_user_pages_unlocked(unsigned long start,
> unsigned long nr_pages,
>
> int get_user_pages_fast(unsigned long start, int nr_pages,
> unsigned int gup_flags, struct page **pages);
> +int pin_user_pages_fast(unsigned long start, int nr_pages,
> + unsigned int gup_flags, struct page **pages);
> +int pin_longterm_pages_fast(unsigned long start, int nr_pages,
> + unsigned int gup_flags, struct page **pages);
>
> int account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc);
> int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
> @@ -2594,13 +2612,15 @@ struct page *follow_page(struct vm_area_struct *vma,
> unsigned long address,
> #define FOLL_ANON0x8000 /* don't do file mappings */
> #define FOLL_LONGTERM0x1 /* mapping lifetime is indefinite: see
> below */
> #define FOLL_SPLIT_PMD 0x2 /* split huge pmd before returning */
> +#define FOLL_PIN 0x4 /* pages must be released via put_user_page() */
>
> /*
> - * NOTE on FOLL_LONGTERM:
> + * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
> + * other. Here is what they mean, and how to use them:
> *
> * FOLL_LONGTERM indicates that the page will be held for an indefinite time
> - * period _often_ under userspace control.
[PATCH] drm/atomic: swap_state should stall on cleanup_done
From: Rob Clark
Stalling on cleanup_done ensures that any atomic state related to a
nonblock commit no longer has dangling references to per-object state
that can be freed.
Otherwise, if a !nonblock commit completes after a nonblock commit has
swapped state (ie. the synchronous part of the nonblock commit comes
before the !nonblock commit), but before the asynchronous part of the
nonblock commit completes, what was the new per-object state in the
nonblock commit can be freed.
This shows up with the new self-refresh helper, as _update_avg_times()
dereferences the original old and new crtc_state.
Fixes: d4da4e33341c ("drm: Measure Self Refresh Entry/Exit times to avoid
thrashing")
Cc: Sean Paul
Signed-off-by: Rob Clark
---
Other possibilities:
1) maybe block later before freeing atomic state?
2) refcount individual per-object state
drivers/gpu/drm/drm_atomic_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3ef2ac52ce94..a5d95429f91b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2711,7 +2711,7 @@ int drm_atomic_helper_swap_state(struct drm_atomic_state
*state,
if (!commit)
continue;
- ret =
wait_for_completion_interruptible(>hw_done);
+ ret =
wait_for_completion_interruptible(>cleanup_done);
if (ret)
return ret;
}
@@ -2722,7 +2722,7 @@ int drm_atomic_helper_swap_state(struct drm_atomic_state
*state,
if (!commit)
continue;
- ret =
wait_for_completion_interruptible(>hw_done);
+ ret =
wait_for_completion_interruptible(>cleanup_done);
if (ret)
return ret;
}
@@ -2733,7 +2733,7 @@ int drm_atomic_helper_swap_state(struct drm_atomic_state
*state,
if (!commit)
continue;
- ret =
wait_for_completion_interruptible(>hw_done);
+ ret =
wait_for_completion_interruptible(>cleanup_done);
if (ret)
return ret;
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH RESEND] drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence
Hi Rob, On Tue, Oct 15, 2019 at 11:19 AM Jeffrey Hugo wrote: > > On Tue, Oct 15, 2019 at 7:40 AM Fabio Estevam wrote: > > > > Booting the adreno driver on a imx53 board leads to the following > > error message: > > > > adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU > > powerlevels > > > > As the "qcom,gpu-pwrlevels" property is optional and never present on > > i.MX5, turn the message into debug level instead. > > > > Signed-off-by: Fabio Estevam > > Seems reasonable. Reviewed-by: Jeffrey Hugo Any comments, please? Just wanted to get rid of this misleading error message on i.MX5. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
In case of tiled displays, if we hotplug just one connector,
fbcon currently just selects the preferred mode and if it is
tiled mode then that becomes a problem if rest of the tiles are
not present.
So in the fbdev driver on hotplug when we probe the client modeset,
we we dont find all the connectors for all tiles, then on a connector
with one tile, just fallback to the first available non tiled mode
to display over a single connector.
Suggested-by: Ville Syrjälä
Suggested-by: Dave Airlie
Cc: Ville Syrjälä
Cc: Dave Airlie
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_client_modeset.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 895b73f23079..e28a723587db 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -114,6 +114,20 @@ drm_client_find_modeset(struct drm_client_dev *client,
struct drm_crtc *crtc)
return NULL;
}
+static struct drm_display_mode *
+drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
+{
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(mode, >modes, head) {
+ if (mode->hdisplay == connector->tile_h_size &&
+ mode->vdisplay == connector->tile_v_size)
+ continue;
+ return mode;
+ }
+ return NULL;
+}
+
static struct drm_display_mode *
drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
int height)
{
@@ -348,8 +362,17 @@ static bool drm_client_target_preferred(struct
drm_connector **connectors,
struct drm_connector *connector;
u64 conn_configured = 0;
int tile_pass = 0;
+ int num_tiled_conns = 0;
int i;
+ for (i = 0; i < connector_count; i++) {
+ connector = connectors[i];
+ if (!connector->has_tile)
+ continue;
+
+ num_tiled_conns ++;
+ }
+
retry:
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
@@ -394,6 +417,12 @@ static bool drm_client_target_preferred(struct
drm_connector **connectors,
connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
modes[i] = drm_connector_has_preferred_mode(connector,
width, height);
}
+ if (connector->has_tile &&
+ num_tiled_conns < connector->num_h_tile *
connector->num_v_tile) {
+ DRM_DEBUG_KMS("Falling back to non tiled mode on
Connector %d\n",
+ connector->base.id);
+ modes[i] =
drm_connector_fallback_non_tiled_mode(connector);
+ }
/* No preferred modes, pick one off the list */
if (!modes[i] && !list_empty(>modes)) {
list_for_each_entry(modes[i], >modes, head)
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/19] mm/gup: factor out duplicate code from four routines
On Thu, Oct 31, 2019 at 11:43:37AM -0700, John Hubbard wrote:
> On 10/31/19 11:35 AM, Ira Weiny wrote:
> > On Wed, Oct 30, 2019 at 03:49:13PM -0700, John Hubbard wrote:
> ...
> >> +
> >> +static void __remove_refs_from_head(struct page *page, int refs)
> >> +{
> >> + /* Do a get_page() first, in case refs == page->_refcount */
> >> + get_page(page);
> >> + page_ref_sub(page, refs);
> >> + put_page(page);
> >> +}
> >
> > I wonder if this is better implemented as "put_compound_head()"? To match
> > the
> > try_get_compound_head() call below?
>
> Hi Ira,
>
> Good idea, I'll rename it to that.
>
> >
> >> +
> >> +static int __huge_pt_done(struct page *head, int nr_recorded_pages, int
> >> *nr)
> >> +{
> >> + *nr += nr_recorded_pages;
> >> + SetPageReferenced(head);
> >> + return 1;
> >
> > When will this return anything but 1?
> >
>
> Never, but it saves a line at all four call sites, by having it return like
> that.
>
> I could see how maybe people would prefer to just have it be a void function,
> and return 1 directly at the call sites. Since this was a lower line count I
> thought maybe it would be slightly better, but it's hard to say really.
It is a NIT perhaps but I feel like the signature of a function should stand on
it's own. What this does is mix the meaning of this function with those
calling it. Which IMO is not good style.
We can see what others say.
Ira
>
> thanks,
>
> John Hubbard
> NVIDIA
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/dp: Increase link status size
Whoops, replied to the wrong one
Reviewed-by: Lyude Paul
On Tue, 2019-10-29 at 15:03 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The current link status contains bytes 0x202 through 0x207, but we also
> want to make sure to include the DP_ADJUST_REQUEST_POST_CURSOR2 (0x20c)
> so that the post-cursor adjustment can be queried during link training.
>
> Reported-by: coverity-bot
> Addresses-Coverity-ID: 1487366 ("Memory - corruptions")
> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> Signed-off-by: Thierry Reding
> ---
> include/drm/drm_dp_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 51ecb5112ef8..9581dec900ba 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1121,7 +1121,7 @@
> #define DP_MST_PHYSICAL_PORT_0 0
> #define DP_MST_LOGICAL_PORT_0 8
>
> -#define DP_LINK_STATUS_SIZE 6
> +#define DP_LINK_STATUS_SIZE 11
> bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count);
> bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp: Increase link status size
Reviewed-by: Lyude Paul
On Tue, 2019-10-29 at 12:10 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The current link status contains bytes 0x202 through 0x207, but we also
> want to make sure to include the DP_ADJUST_REQUEST_POST_CURSOR2 (0x20c)
> so that the post-cursor adjustment can be queried during link training.
>
> Reported-by: coverity-bot
> Addresses-Coverity-ID: 1487366 ("Memory - corruptions")
> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
> Signed-off-by: Thierry Reding
> ---
> I vaguely recall once carrying a patch to do this, but I can't find any
> trace of it.
>
> include/drm/drm_dp_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 51ecb5112ef8..9581dec900ba 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1121,7 +1121,7 @@
> #define DP_MST_PHYSICAL_PORT_0 0
> #define DP_MST_LOGICAL_PORT_0 8
>
> -#define DP_LINK_STATUS_SIZE 6
> +#define DP_LINK_STATUS_SIZE 11
> bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
> int lane_count);
> bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave & Daniel, Here's the last -misc-next pull request for 5.5. Lots of refactoring going on this week which results in a negative diffstat. Only thing to highlight is the dma-buf heap introduction and revert, which you are already aware of, so hopefully no other surprises here. drm-misc-next-2019-10-31: drm-misc-next for 5.5: UAPI Changes: -dma-buf: Introduce and revert dma-buf heap (Andrew/John/Sean) Cross-subsystem Changes: - None Core Changes: -dma-buf: add dynamic mapping to allow exporters to choose dma_resv lock state on mmap/munmap (Christian) -vram: add prepare/cleanup fb helpers to vram helpers (Thomas) -ttm: always keep bo's on the lru + ttm cleanups (Christian) -sched: allow a free_job routine to sleep (Steven) -fb_helper: remove unused drm_fb_helper_defio_init() (Thomas) Driver Changes: -bochs/hibmc/vboxvideo: Use new vram helpers for prepare/cleanup fb (Thomas) -amdgpu: Implement dma-buf import/export without drm helpers (Christian) -panfrost: Simplify devfreq integration in driver (Steven) Cc: Christian König Cc: Thomas Zimmermann Cc: Steven Price Cc: Andrew F. Davis Cc: John Stultz Cc: Sean Paul Cheers, Sean The following changes since commit 9a42c7c647a9ad0f7ebb147a52eda3dcb7c84292: drm/tegra: Move drm_dp_link helpers to Tegra DRM (2019-10-23 18:22:10 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-10-31 for you to fetch changes up to fae7d7d5f374eadbb0b5dd31b39162e7176e9c3d: Revert "dma-buf: Add dma-buf heaps framework" (2019-10-30 16:41:49 -0400) drm-misc-next for 5.5: UAPI Changes: -dma-buf: Introduce and revert dma-buf heap (Andrew/John/Sean) Cross-subsystem Changes: - None Core Changes: -dma-buf: add dynamic mapping to allow exporters to choose dma_resv lock state on mmap/munmap (Christian) -vram: add prepare/cleanup fb helpers to vram helpers (Thomas) -ttm: always keep bo's on the lru + ttm cleanups (Christian) -sched: allow a free_job routine to sleep (Steven) -fb_helper: remove unused drm_fb_helper_defio_init() (Thomas) Driver Changes: -bochs/hibmc/vboxvideo: Use new vram helpers for prepare/cleanup fb (Thomas) -amdgpu: Implement dma-buf import/export without drm helpers (Christian) -panfrost: Simplify devfreq integration in driver (Steven) Cc: Christian König Cc: Thomas Zimmermann Cc: Steven Price Cc: Andrew F. Davis Cc: John Stultz Cc: Sean Paul Andrew F. Davis (1): dma-buf: Add dma-buf heaps framework Anna Karas (1): doc: drm: Update references to previously renamed files Bhanusree (3): drm/gpu: Add comment for memory barrier drm/gpu: Fix Missing blank line after declarations drm/gpu: Fix Memory barrier without comment Issue Christian König (10): dma-buf: change DMA-buf locking convention v3 dma-buf: stop using the dmabuf->lock so much v2 drm/ttm, drm/vmwgfx: move cpu_writers handling into vmwgfx drm/ttm: always keep BOs on the LRU drm/ttm: remove pointers to globals drm/ttm: use the parent resv for ghost objects v3 drm/qxl: stop using TTM to call driver internal functions drm/ttm: stop exporting ttm_mem_io_* functions drm/amdgpu: add independent DMA-buf export v8 drm/amdgpu: add independent DMA-buf import v9 Daniel Vetter (1): drm/simple-kms: Standardize arguments for callbacks Geert Uytterhoeven (1): drm: Spelling s/connet/connect/ Hans de Goede (1): drm/vboxvideo: Use drm_gem_fb_create_with_dirty instead of drm_gem_fb_create John Stultz (4): dma-buf: heaps: Add heap helpers dma-buf: heaps: Add system heap to dmabuf heaps dma-buf: heaps: Add CMA heap to dmabuf heaps kselftests: Add dma-heap test Rob Herring (1): drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap Sean Paul (5): Revert "kselftests: Add dma-heap test" Revert "dma-buf: heaps: Add CMA heap to dmabuf heaps" Revert "dma-buf: heaps: Add system heap to dmabuf heaps" Revert "dma-buf: heaps: Add heap helpers" Revert "dma-buf: Add dma-buf heaps framework" Steven Price (3): drm: Don't free jobs in wait_event_interruptible() drm/panfrost: Use generic code for devfreq drm/panfrost: Simplify devfreq utilisation tracking Thomas Zimmermann (6): drm/vram-helpers: Add helpers for prepare_fb() and cleanup_fb() drm/bochs: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpers drm/hisilicon/hibmc: Use GEM VRAM's prepare_fb() and cleanup_fb() helpers drm/vboxvideo: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpers drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs drm/todo: Clarify situation around fbdev and defio Wambui Karuga (1): drm/mediatek: remove cast to pointers passed to kfree
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #187 from Konstantin Pereiaslov --- As recommended here I added AMD_DEBUG="nongg,nodma" to /etc/environment and additionally added export AMD_DEBUG="nongg,nodma" to ~/.profile just to be sure and for 5 days since that I only had one system freeze and it had a different journalctl message, so it did help me help with sdma0 timeout issue! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] Genericize DW MIPI DSI bridge and add i.MX 6 driver
On Thu, 31 Oct 2019, Emil Velikov wrote: Hi Adrian, Hi Emil! On Thu, 31 Oct 2019 at 14:26, Adrian Ratiu wrote: Having a generic Synopsis DesignWare MIPI-DSI host controller bridge driver is a very good idea, however the current implementation has hardcoded quite a lot of the register layouts used by the two supported SoC vendors, STM and Rockchip, which use IP cores v1.30 and v1.31. This makes it hard to support other SoC vendors like the FSL/NXP i.MX 6 which use older v1.01 cores or future versions because, based on history, layout changes should also be expected in new DSI versions / SoCs. This patch series converts the bridge and platform drivers to access registers via generic regmap APIs and allows each platform driver to configure its register layout via struct reg_fields, then adds support for the host controller found on i.MX 6. Have you considered keeping the difference internal to the dw-mipi-dsi driver? Say having the iMX6 module "request" the v1.01 regmap from the bridge driver, while rockchip/others doing the equivalent. No, I haven't. It sounds like a good idea though and I think it's doable. Thank you! .../bindings/display/imx/mipi-dsi.txt | 56 ++ drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 518 +- drivers/gpu/drm/imx/Kconfig | 7 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 502 + .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 154 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 160 +- include/drm/bridge/dw_mipi_dsi.h | 60 +- 8 files changed, 1185 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c This should make the delta a lot smaller, avoiding the unnecessary copy of register fields and regmap. Plus plugging future users will be dead trivial. Agreed. I'll do this in v2 unless someone objects or proposes a better alternative. I'll let this series sit a little more on review so others have a chance to see and review; will address all feedback in v2. -Emil ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/19] goldish_pipe: rename local pin_user_pages() routine
On Wed, Oct 30, 2019 at 03:49:14PM -0700, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
>
> An upcoming patch will introduce a global pin_user_pages()
> function.
>
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> drivers/platform/goldfish/goldfish_pipe.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c
> b/drivers/platform/goldfish/goldfish_pipe.c
> index cef0133aa47a..7ed2a21a0bac 100644
> --- a/drivers/platform/goldfish/goldfish_pipe.c
> +++ b/drivers/platform/goldfish/goldfish_pipe.c
> @@ -257,12 +257,12 @@ static int goldfish_pipe_error_convert(int status)
> }
> }
>
> -static int pin_user_pages(unsigned long first_page,
> - unsigned long last_page,
> - unsigned int last_page_size,
> - int is_write,
> - struct page *pages[MAX_BUFFERS_PER_COMMAND],
> - unsigned int *iter_last_page_size)
> +static int pin_goldfish_pages(unsigned long first_page,
> + unsigned long last_page,
> + unsigned int last_page_size,
> + int is_write,
> + struct page *pages[MAX_BUFFERS_PER_COMMAND],
> + unsigned int *iter_last_page_size)
> {
> int ret;
> int requested_pages = ((last_page - first_page) >> PAGE_SHIFT) + 1;
> @@ -354,9 +354,9 @@ static int transfer_max_buffers(struct goldfish_pipe
> *pipe,
> if (mutex_lock_interruptible(>lock))
> return -ERESTARTSYS;
>
> - pages_count = pin_user_pages(first_page, last_page,
> - last_page_size, is_write,
> - pipe->pages, _last_page_size);
> + pages_count = pin_goldfish_pages(first_page, last_page,
> + last_page_size, is_write,
> + pipe->pages, _last_page_size);
> if (pages_count < 0) {
> mutex_unlock(>lock);
> return pages_count;
> --
> 2.23.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/19] mm/gup: factor out duplicate code from four routines
On Wed, Oct 30, 2019 at 03:49:13PM -0700, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there are subtle differences.
>
> Factor out the common code into static functions, thus reducing the
> overall line count and the code's complexity.
>
> Also, take the opportunity to slightly improve the efficiency of the
> error cases, by doing a mass subtraction of the refcount, surrounded
> by get_page()/put_page().
>
> Also, further simplify (slightly), by waiting until the the successful
> end of each routine, to increment *nr.
Overall it seems like a pretty good clean up. It did take a bit of review but
I _think_ it is correct. A couple of comments below.
>
> Cc: Christoph Hellwig
> Cc: Aneesh Kumar K.V
> Signed-off-by: John Hubbard
> ---
> mm/gup.c | 113 ++-
> 1 file changed, 46 insertions(+), 67 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 85caf76b3012..8fb0d9cdfaf5 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1969,6 +1969,35 @@ static int __gup_device_huge_pud(pud_t pud, pud_t
> *pudp, unsigned long addr,
> }
> #endif
>
> +static int __record_subpages(struct page *page, unsigned long addr,
> + unsigned long end, struct page **pages, int nr)
> +{
> + int nr_recorded_pages = 0;
> +
> + do {
> + pages[nr] = page;
> + nr++;
> + page++;
> + nr_recorded_pages++;
> + } while (addr += PAGE_SIZE, addr != end);
> + return nr_recorded_pages;
> +}
> +
> +static void __remove_refs_from_head(struct page *page, int refs)
> +{
> + /* Do a get_page() first, in case refs == page->_refcount */
> + get_page(page);
> + page_ref_sub(page, refs);
> + put_page(page);
> +}
I wonder if this is better implemented as "put_compound_head()"? To match the
try_get_compound_head() call below?
> +
> +static int __huge_pt_done(struct page *head, int nr_recorded_pages, int *nr)
> +{
> + *nr += nr_recorded_pages;
> + SetPageReferenced(head);
> + return 1;
When will this return anything but 1?
Ira
> +}
> +
> #ifdef CONFIG_ARCH_HAS_HUGEPD
> static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
> unsigned long sz)
> @@ -1998,34 +2027,19 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz,
> unsigned long addr,
> /* hugepages are never "special" */
> VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
>
> - refs = 0;
> head = pte_page(pte);
> -
> page = head + ((addr & (sz-1)) >> PAGE_SHIFT);
> - do {
> - VM_BUG_ON(compound_head(page) != head);
> - pages[*nr] = page;
> - (*nr)++;
> - page++;
> - refs++;
> - } while (addr += PAGE_SIZE, addr != end);
> + refs = __record_subpages(page, addr, end, pages, *nr);
>
> head = try_get_compound_head(head, refs);
> - if (!head) {
> - *nr -= refs;
> + if (!head)
> return 0;
> - }
>
> if (unlikely(pte_val(pte) != pte_val(*ptep))) {
> - /* Could be optimized better */
> - *nr -= refs;
> - while (refs--)
> - put_page(head);
> + __remove_refs_from_head(head, refs);
> return 0;
> }
> -
> - SetPageReferenced(head);
> - return 1;
> + return __huge_pt_done(head, refs, nr);
> }
>
> static int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
> @@ -2071,30 +2085,18 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
> unsigned long addr,
>pages, nr);
> }
>
> - refs = 0;
> page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
> - do {
> - pages[*nr] = page;
> - (*nr)++;
> - page++;
> - refs++;
> - } while (addr += PAGE_SIZE, addr != end);
> + refs = __record_subpages(page, addr, end, pages, *nr);
>
> head = try_get_compound_head(pmd_page(orig), refs);
> - if (!head) {
> - *nr -= refs;
> + if (!head)
> return 0;
> - }
>
> if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
> - *nr -= refs;
> - while (refs--)
> - put_page(head);
> + __remove_refs_from_head(head, refs);
> return 0;
> }
> -
> - SetPageReferenced(head);
> - return 1;
> + return __huge_pt_done(head, refs, nr);
> }
>
> static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
> @@ -2114,30 +2116,18 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp,
> unsigned long addr,
>pages, nr);
> }
>
> - refs = 0;
> page =
Re: [PATCH 01/19] mm/gup: pass flags arg to __gup_device_* functions
On Wed, Oct 30, 2019 at 03:49:12PM -0700, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
Reviewed-by: Ira Weiny
> Cc: Kirill A. Shutemov
> Signed-off-by: John Hubbard
> ---
> mm/gup.c | 28 ++--
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 8f236a335ae9..85caf76b3012 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1890,7 +1890,8 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
> unsigned long end,
>
> #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) &&
> defined(CONFIG_TRANSPARENT_HUGEPAGE)
> static int __gup_device_huge(unsigned long pfn, unsigned long addr,
> - unsigned long end, struct page **pages, int *nr)
> + unsigned long end, unsigned int flags,
> + struct page **pages, int *nr)
> {
> int nr_start = *nr;
> struct dev_pagemap *pgmap = NULL;
> @@ -1916,13 +1917,14 @@ static int __gup_device_huge(unsigned long pfn,
> unsigned long addr,
> }
>
> static int __gup_device_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
> - unsigned long end, struct page **pages, int *nr)
> + unsigned long end, unsigned int flags,
> + struct page **pages, int *nr)
> {
> unsigned long fault_pfn;
> int nr_start = *nr;
>
> fault_pfn = pmd_pfn(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
> - if (!__gup_device_huge(fault_pfn, addr, end, pages, nr))
> + if (!__gup_device_huge(fault_pfn, addr, end, flags, pages, nr))
> return 0;
>
> if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
> @@ -1933,13 +1935,14 @@ static int __gup_device_huge_pmd(pmd_t orig, pmd_t
> *pmdp, unsigned long addr,
> }
>
> static int __gup_device_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
> - unsigned long end, struct page **pages, int *nr)
> + unsigned long end, unsigned int flags,
> + struct page **pages, int *nr)
> {
> unsigned long fault_pfn;
> int nr_start = *nr;
>
> fault_pfn = pud_pfn(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
> - if (!__gup_device_huge(fault_pfn, addr, end, pages, nr))
> + if (!__gup_device_huge(fault_pfn, addr, end, flags, pages, nr))
> return 0;
>
> if (unlikely(pud_val(orig) != pud_val(*pudp))) {
> @@ -1950,14 +1953,16 @@ static int __gup_device_huge_pud(pud_t orig, pud_t
> *pudp, unsigned long addr,
> }
> #else
> static int __gup_device_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
> - unsigned long end, struct page **pages, int *nr)
> + unsigned long end, unsigned int flags,
> + struct page **pages, int *nr)
> {
> BUILD_BUG();
> return 0;
> }
>
> static int __gup_device_huge_pud(pud_t pud, pud_t *pudp, unsigned long addr,
> - unsigned long end, struct page **pages, int *nr)
> + unsigned long end, unsigned int flags,
> + struct page **pages, int *nr)
> {
> BUILD_BUG();
> return 0;
> @@ -2062,7 +2067,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
> unsigned long addr,
> if (pmd_devmap(orig)) {
> if (unlikely(flags & FOLL_LONGTERM))
> return 0;
> - return __gup_device_huge_pmd(orig, pmdp, addr, end, pages, nr);
> + return __gup_device_huge_pmd(orig, pmdp, addr, end, flags,
> + pages, nr);
> }
>
> refs = 0;
> @@ -2092,7 +2098,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
> unsigned long addr,
> }
>
> static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
> - unsigned long end, unsigned int flags, struct page **pages, int
> *nr)
> + unsigned long end, unsigned int flags,
> + struct page **pages, int *nr)
> {
> struct page *head, *page;
> int refs;
> @@ -2103,7 +2110,8 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp,
> unsigned long addr,
> if (pud_devmap(orig)) {
> if (unlikely(flags & FOLL_LONGTERM))
> return 0;
> - return __gup_device_huge_pud(orig, pudp, addr, end, pages, nr);
> + return __gup_device_huge_pud(orig, pudp, addr, end, flags,
> + pages, nr);
> }
>
> refs = 0;
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: potential information leak in do_fb_ioctl()
On Wed, 2019-10-30 at 21:12 +0100, Andrea Righi wrote: > Then memset() + memcpy() is probably the best option, > since copying all those fields one by one looks quite ugly to me... A memset of an automatic before a memcpy to the same automatic is unnecessary. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
Hi Yiwei, This is the latest series: https://patchwork.kernel.org/cover/11120371/ (I still need to reply some of the feedback.) Regards, Kenny On Thu, Oct 31, 2019 at 12:59 PM Yiwei Zhang wrote: > > Hi Kenny, > > Thanks for the info. Do you mind forwarding the existing discussion to me or > have me cc'ed in that thread? > > Best, > Yiwei > > On Wed, Oct 30, 2019 at 10:23 PM Kenny Ho wrote: >> >> Hi Yiwei, >> >> I am not sure if you are aware, there is an ongoing RFC on adding drm >> support in cgroup for the purpose of resource tracking. One of the >> resource is GPU memory. It's not exactly the same as what you are >> proposing (it doesn't track API usage, but it tracks the type of GPU >> memory from kmd perspective) but perhaps it would be of interest to >> you. There are no consensus on it at this point. >> >> (sorry for being late to the discussion. I only noticed this thread >> when one of the email got lucky and escape the spam folder.) >> >> Regards, >> Kenny >> >> On Wed, Oct 30, 2019 at 4:14 AM Yiwei Zhang wrote: >> > >> > Hi Jerome and all folks, >> > >> > In addition to my last reply, I just wanna get some more information >> > regarding this on the upstream side. >> > >> > 1. Do you think this(standardize a way to report GPU private allocations) >> > is going to be a useful thing on the upstream as well? It grants a lot >> > benefits for Android, but I'd like to get an idea for the non-Android >> > world. >> > >> > 2. There might be some worries that upstream kernel driver has no idea >> > regarding the API. However, to achieve good fidelity around memory >> > reporting, we'd have to pass down certain metadata which is known only by >> > the userland. Consider this use case: on the upstream side, freedreno for >> > example, some memory buffer object(BO) during its own lifecycle could >> > represent totally different things, and kmd is not aware of that. When >> > we'd like to take memory snapshots at certain granularity, we have to know >> > what that buffer represents so that the snapshot can be meaningful and >> > useful. >> > >> > If we just keep this Android specific, I'd worry some day the upstream has >> > standardized a way to report this and Android vendors have to take extra >> > efforts to migrate over. This is one of the main reasons we'd like to do >> > this on the upstream side. >> > >> > Timeline wise, Android has explicit deadlines for the next release and we >> > have to push hard towards those. Any prompt responses are very much >> > appreciated! >> > >> > Best regards, >> > Yiwei >> > >> > On Mon, Oct 28, 2019 at 11:33 AM Yiwei Zhang wrote: >> >> >> >> On Mon, Oct 28, 2019 at 8:26 AM Jerome Glisse wrote: >> >>> >> >>> On Fri, Oct 25, 2019 at 11:35:32AM -0700, Yiwei Zhang wrote: >> >>> > Hi folks, >> >>> > >> >>> > This is the plain text version of the previous email in case that was >> >>> > considered as spam. >> >>> > >> >>> > --- Background --- >> >>> > On the downstream Android, vendors used to report GPU private memory >> >>> > allocations with debugfs nodes in their own formats. However, debugfs >> >>> > nodes >> >>> > are getting deprecated in the next Android release. >> >>> >> >>> Maybe explain why it is useful first ? >> >> >> >> >> >> Memory is precious on Android mobile platforms. Apps using a large amount >> >> of >> >> memory, games, tend to maintain a table for the memory on different >> >> devices with >> >> different prediction models. Private gpu memory allocations is currently >> >> semi-blind >> >> to the apps and the platform as well. >> >> >> >> By having the data, the platform can do: >> >> (1) GPU memory profiling as part of the huge Android profiler in progress. >> >> (2) Android system health team can enrich the performance test coverage. >> >> (3) We can collect filed metrics to detect any regression on the gpu >> >> private memory >> >> allocations in the production population. >> >> (4) Shell user can easily dump the allocations in a uniform way across >> >> vendors. >> >> (5) Platform can feed the data to the apps so that apps can do memory >> >> allocations >> >> in a more predictable way. >> >> >> >>> >> >>> > >> >>> > --- Proposal --- >> >>> > We are taking the chance to unify all the vendors to migrate their >> >>> > existing >> >>> > debugfs nodes into a standardized sysfs node structure. Then the >> >>> > platform >> >>> > is able to do a bunch of useful things: memory profiling, system health >> >>> > coverage, field metrics, local shell dump, in-app api, etc. This >> >>> > proposal >> >>> > is better served upstream as all GPU vendors can standardize a gpu >> >>> > memory >> >>> > structure and reduce fragmentation across Android and Linux that >> >>> > clients >> >>> > can rely on. >> >>> > >> >>> > --- Detailed design --- >> >>> > The sysfs node structure looks like below: >> >>> > /sys/devices/// >> >>> > e.g. "/sys/devices/mali0/gpu_mem/606/gl_buffer" and the gl_buffer is a >> >>> > node >>
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2019-10-31: - Fix PCH reference clock for FDI on HSW/BDW which was causing users blank screen - Small documentation fix for TGL display PLLs Thanks, Rodrigo. The following changes since commit d6d5df1db6e9d7f8f76d2911707f7d5877251b02: Linux 5.4-rc5 (2019-10-27 13:19:19 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-10-31 for you to fetch changes up to 59cd826fb5e7889515bf5771e295e0624c348571: drm/i915: Fix PCH reference clock for FDI on HSW/BDW (2019-10-29 21:50:24 -0700) - Fix PCH reference clock for FDI on HSW/BDW which was causing users blank screen - Small documentation fix for TGL display PLLs Anna Karas (1): drm/i915/tgl: Fix doc not corresponding to code Ville Syrjälä (1): drm/i915: Fix PCH reference clock for FDI on HSW/BDW drivers/gpu/drm/i915/display/intel_display.c | 11 ++- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 15 +++ drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 2 ++ 4 files changed, 25 insertions(+), 7 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Hi Adrian, On Thu, 31 Oct 2019 at 14:26, Adrian Ratiu wrote: > > Having a generic Synopsis DesignWare MIPI-DSI host controller bridge > driver is a very good idea, however the current implementation has > hardcoded quite a lot of the register layouts used by the two supported > SoC vendors, STM and Rockchip, which use IP cores v1.30 and v1.31. > > This makes it hard to support other SoC vendors like the FSL/NXP i.MX 6 > which use older v1.01 cores or future versions because, based on history, > layout changes should also be expected in new DSI versions / SoCs. > > This patch series converts the bridge and platform drivers to access > registers via generic regmap APIs and allows each platform driver to > configure its register layout via struct reg_fields, then adds support > for the host controller found on i.MX 6. > Have you considered keeping the difference internal to the dw-mipi-dsi driver? Say having the iMX6 module "request" the v1.01 regmap from the bridge driver, while rockchip/others doing the equivalent. > .../bindings/display/imx/mipi-dsi.txt | 56 ++ > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 518 +- > drivers/gpu/drm/imx/Kconfig | 7 + > drivers/gpu/drm/imx/Makefile | 1 + > drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 502 + > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 154 +- > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 160 +- > include/drm/bridge/dw_mipi_dsi.h | 60 +- > 8 files changed, 1185 insertions(+), 273 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt > create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c > This should make the delta a lot smaller, avoiding the unnecessary copy of register fields and regmap. Plus plugging future users will be dead trivial. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Handle workqueue allocation failure
On Fri, Oct 25, 2019 at 06:20:01PM +0200, Michel Dänzer wrote:
> On 2019-10-25 6:18 p.m., Will Deacon wrote:
> > On Fri, Oct 25, 2019 at 06:06:26PM +0200, Michel Dänzer wrote:
> >> On 2019-10-25 1:04 p.m., Will Deacon wrote:
> >>> In the highly unlikely event that we fail to allocate the "radeon-crtc"
> >>> workqueue, we should bail cleanly rather than blindly march on with a
> >>> NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
> >>> structure.
> >>>
> >>> This was reported previously by Nicolas, but I don't think his fix was
> >>> correct:
> >>
> >> Neither is this one I'm afraid. See my feedback on
> >> https://patchwork.freedesktop.org/patch/331534/ .
> >
> > Thanks. Although I agree with you wrt the original patch, I don't think
> > the workqueue allocation failure is distinguishable from the CRTC allocation
> > failure with my patch. Are you saying that the error path there is broken
> > too?
>
> The driver won't actually work if radeon_crtc_init bails silently, it'll
> just fall over at some later point.
Ok, so how about fleshing it out as per below?
Will
--->8
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index e81b01f8db90..177acee06620 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -668,21 +668,29 @@ static const struct drm_crtc_funcs radeon_crtc_funcs = {
.page_flip_target = radeon_crtc_page_flip_target,
};
-static void radeon_crtc_init(struct drm_device *dev, int index)
+static int radeon_crtc_init(struct drm_device *dev, int index)
{
struct radeon_device *rdev = dev->dev_private;
struct radeon_crtc *radeon_crtc;
+ struct workqueue_struct *wq;
int i;
radeon_crtc = kzalloc(sizeof(struct radeon_crtc) + (RADEONFB_CONN_LIMIT
* sizeof(struct drm_connector *)), GFP_KERNEL);
if (radeon_crtc == NULL)
- return;
+ return -ENOMEM;
+
+ wq = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
+ if (unlikely(!wq)) {
+ kfree(radeon_crtc);
+ return - ENOMEM;
+ }
drm_crtc_init(dev, _crtc->base, _crtc_funcs);
drm_mode_crtc_set_gamma_size(_crtc->base, 256);
radeon_crtc->crtc_id = index;
- radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
+ radeon_crtc->flip_queue = wq;
+
rdev->mode_info.crtcs[index] = radeon_crtc;
if (rdev->family >= CHIP_BONAIRE) {
@@ -711,6 +719,8 @@ static void radeon_crtc_init(struct drm_device *dev, int
index)
radeon_atombios_init_crtc(dev, radeon_crtc);
else
radeon_legacy_init_crtc(dev, radeon_crtc);
+
+ return 0;
}
static const char *encoder_names[38] = {
@@ -1602,9 +1612,8 @@ int radeon_modeset_init(struct radeon_device *rdev)
rdev->ddev->mode_config.fb_base = rdev->mc.aper_base;
ret = radeon_modeset_create_props(rdev);
- if (ret) {
- return ret;
- }
+ if (ret)
+ goto err_drm_mode_config_cleanup;
/* init i2c buses */
radeon_i2c_init(rdev);
@@ -1617,7 +1626,9 @@ int radeon_modeset_init(struct radeon_device *rdev)
/* allocate crtcs */
for (i = 0; i < rdev->num_crtc; i++) {
- radeon_crtc_init(rdev->ddev, i);
+ ret = radeon_crtc_init(rdev->ddev, i);
+ if (ret)
+ goto err_drm_mode_config_cleanup;
}
/* okay we should have all the bios connectors */
@@ -1645,6 +1656,10 @@ int radeon_modeset_init(struct radeon_device *rdev)
ret = radeon_pm_late_init(rdev);
return 0;
+
+err_drm_mode_config_cleanup:
+ drm_mode_config_cleanup(rdev->ddev);
+ return ret;
}
void radeon_modeset_fini(struct radeon_device *rdev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112188] OpenGL stuttering in some cases on AMD Navi cards (RX 5700XT in my case)
https://bugs.freedesktop.org/show_bug.cgi?id=112188 --- Comment #4 from Marko Popovic --- I just spoke to another user that has different model of the RX 5700 XT and he doesn't seem to be having this issue. My setup: OS: Pop!_OS 19.10 CPU/RAM: Intel i5-6600 / 16 GB DDR4 GPU: Sapphire Pulse RX 5700 XT Kernel: 5.4.0-999-generic (Ubuntu daily) MESA: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.0-devel (git-ff6e148 2019-10-29 eoan-oibaf-ppa) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112188] OpenGL stuttering in some cases on AMD Navi cards (RX 5700XT in my case)
https://bugs.freedesktop.org/show_bug.cgi?id=112188 --- Comment #3 from Marko Popovic --- Created attachment 145859 --> https://bugs.freedesktop.org/attachment.cgi?id=145859=edit Video showcase #2 in 60fps, much more obvious I add a capture in 60fps so the issue is much more noticable by the bare eye -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112188] OpenGL stuttering in some cases on AMD Navi cards (RX 5700XT in my case)
https://bugs.freedesktop.org/show_bug.cgi?id=112188 --- Comment #2 from Marko Popovic --- PS to any of the developers: If you guys think that I should post this bug somewhere else (etc. MESA bug tracker) plz let me know with a response. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112188] OpenGL stuttering in some cases on AMD Navi cards (RX 5700XT in my case)
https://bugs.freedesktop.org/show_bug.cgi?id=112188 --- Comment #1 from Marko Popovic --- Created attachment 145857 --> https://bugs.freedesktop.org/attachment.cgi?id=145857=edit Trace file from Feral launcher -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112188] OpenGL stuttering in some cases on AMD Navi cards (RX 5700XT in my case)
https://bugs.freedesktop.org/show_bug.cgi?id=112188 Bug ID: 112188 Summary: OpenGL stuttering in some cases on AMD Navi cards (RX 5700XT in my case) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: popovic.ma...@protonmail.com Created attachment 145856 --> https://bugs.freedesktop.org/attachment.cgi?id=145856=edit Video showcase of the bug Here is a trace file and a video showcase of stuttering in Feral game launcher (OpenGL) that happens in many cases, but not reproducable in all GL apps/desktops (mGBA emulator, Godot game engine, Feral launcher) I'd like to see one of AMD OpenGL developers take a look at the trace file and a video for proof that stuttering actually occurs and try to figure out what might be causing the issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: bridge: dw_mipi_dsi: access registers via a regmap
Convert the common bridge code and the two rockchip & stm drivers
which currently use it to the regmap API in anticipation for further
changes to make it more generic and add older DSI host controller
support as found on i.mx6 based devices.
No functional changes other than requiring the platform drivers to
provide a regmap via their plat_data. Going further each platform
driver can also add its own regmap configuration like for maximum
write offsets, r/w callbacks or different register layouts.
Suggested-by: Boris Brezillon
Signed-off-by: Adrian Ratiu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 189 +-
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 36 +++-
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 44 ++--
include/drm/bridge/dw_mipi_dsi.h | 2 +-
4 files changed, 155 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index b6e793bb653c..4ef3e9038cc2 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -226,7 +227,7 @@ struct dw_mipi_dsi {
struct mipi_dsi_host dsi_host;
struct drm_bridge *panel_bridge;
struct device *dev;
- void __iomem *base;
+ struct regmap *regs;
struct clk *pclk;
@@ -280,16 +281,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct
drm_bridge *bridge)
return container_of(bridge, struct dw_mipi_dsi, bridge);
}
-static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
-{
- writel(val, dsi->base + reg);
-}
-
-static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
-{
- return readl(dsi->base + reg);
-}
-
static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
@@ -366,29 +357,29 @@ static void dw_mipi_message_config(struct dw_mipi_dsi
*dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
- dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
- dsi_write(dsi, DSI_CMD_MODE_CFG, val);
+ regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
+ regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
}
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
{
int ret;
- u32 val, mask;
+ u32 val = 0, mask;
- ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_CMD_FULL), 1000,
-CMD_PKT_STATUS_TIMEOUT_US);
+ ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+ val, !(val & GEN_CMD_FULL), 1000,
+ CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
}
- dsi_write(dsi, DSI_GEN_HDR, hdr_val);
+ regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
- ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, (val & mask) == mask,
-1000, CMD_PKT_STATUS_TIMEOUT_US);
+ ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+ val, (val & mask) == mask,
+ 1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
@@ -403,24 +394,26 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
const u8 *tx_buf = packet->payload;
int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
__le32 word;
- u32 val;
+ u32 val = 0;
while (len) {
if (len < pld_data_bytes) {
word = 0;
memcpy(, tx_buf, len);
- dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
+ regmap_write(dsi->regs, DSI_GEN_PLD_DATA,
+le32_to_cpu(word));
len = 0;
} else {
memcpy(, tx_buf, pld_data_bytes);
- dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
+ regmap_write(dsi->regs, DSI_GEN_PLD_DATA,
+le32_to_cpu(word));
tx_buf += pld_data_bytes;
len -= pld_data_bytes;
}
- ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_PLD_W_FULL), 1000,
-CMD_PKT_STATUS_TIMEOUT_US);
+
[PATCH 2/4] drm: bridge: dw_mipi_dsi: abstract register access using reg_fields
Register existence, address/offsets, field layouts, reserved bits and so on differ between MIPI-DSI versions and between SoC vendor boards. Despite these differences the hw IP and protocols are mostly the same so the generic driver can be made to compensate these differences. The existing Rockchip and STM drivers hardcoded a lot of their common definitions in the bridge code because they're based on DSI v1.30 and 1.31 which are relatively close, but in order to support older/future versions with more diverging layouts like the v1.01 present on imx6, we abstract some of the register accesses via the regmap_field APIs. This enables each platform driver to supply its own specific register layout making the common bridge driver more generic as well as removing a lot of the bit-shifting and masking boilerplate which is now handled automatically by the regmap subsystem. Not all register accesses have been converted: only the minimum difference between the versions supplied by the current 3 rockchip, stm and imx host controller cores, moore can be moved in the future as needed. Suggested-by: Boris Brezillon Signed-off-by: Adrian Ratiu --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 470 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 118 + drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 116 + include/drm/bridge/dw_mipi_dsi.h | 58 +++ 4 files changed, 529 insertions(+), 233 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 4ef3e9038cc2..f88690d04494 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -43,11 +43,8 @@ #define TO_CLK_DIVISION(div) (((div) & 0xff) << 8) #define TX_ESC_CLK_DIVISION(div) ((div) & 0xff) -#define DSI_DPI_VCID 0x0c #define DPI_VCID(vcid) ((vcid) & 0x3) -#define DSI_DPI_COLOR_CODING 0x10 -#define LOOSELY18_EN BIT(8) #define DPI_COLOR_CODING_16BIT_1 0x0 #define DPI_COLOR_CODING_16BIT_2 0x1 #define DPI_COLOR_CODING_16BIT_3 0x2 @@ -55,13 +52,6 @@ #define DPI_COLOR_CODING_18BIT_2 0x4 #define DPI_COLOR_CODING_24BIT 0x5 -#define DSI_DPI_CFG_POL0x14 -#define COLORM_ACTIVE_LOW BIT(4) -#define SHUTD_ACTIVE_LOW BIT(3) -#define HSYNC_ACTIVE_LOW BIT(2) -#define VSYNC_ACTIVE_LOW BIT(1) -#define DATAEN_ACTIVE_LOW BIT(0) - #define DSI_DPI_LP_CMD_TIM 0x18 #define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) #define INVACT_LPCMD_TIME(p) ((p) & 0xff) @@ -71,7 +61,6 @@ #define DSI_DBI_PARTITIONING_EN0x24 #define DSI_DBI_CMDSIZE0x28 -#define DSI_PCKHDL_CFG 0x2c #define CRC_RX_EN BIT(4) #define ECC_RX_EN BIT(3) #define BTA_EN BIT(2) @@ -81,70 +70,13 @@ #define DSI_GEN_VCID 0x30 #define DSI_MODE_CFG 0x34 -#define ENABLE_VIDEO_MODE 0 -#define ENABLE_CMD_MODEBIT(0) -#define DSI_VID_MODE_CFG 0x38 -#define ENABLE_LOW_POWER (0x3f << 8) -#define ENABLE_LOW_POWER_MASK (0x3f << 8) +#define ENABLE_LOW_POWER 0x3f + #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0 #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1 #define VID_MODE_TYPE_BURST0x2 -#define VID_MODE_TYPE_MASK 0x3 -#define VID_MODE_VPG_ENABLEBIT(16) -#define VID_MODE_VPG_HORIZONTALBIT(24) - -#define DSI_VID_PKT_SIZE 0x3c -#define VID_PKT_SIZE(p)((p) & 0x3fff) - -#define DSI_VID_NUM_CHUNKS 0x40 -#define VID_NUM_CHUNKS(c) ((c) & 0x1fff) - -#define DSI_VID_NULL_SIZE 0x44 -#define VID_NULL_SIZE(b) ((b) & 0x1fff) - -#define DSI_VID_HSA_TIME 0x48 -#define DSI_VID_HBP_TIME 0x4c -#define DSI_VID_HLINE_TIME 0x50 -#define DSI_VID_VSA_LINES 0x54 -#define DSI_VID_VBP_LINES 0x58 -#define DSI_VID_VFP_LINES 0x5c -#define DSI_VID_VACTIVE_LINES 0x60 -#define DSI_EDPI_CMD_SIZE 0x64 - -#define DSI_CMD_MODE_CFG 0x68 -#define MAX_RD_PKT_SIZE_LP BIT(24) -#define DCS_LW_TX_LP BIT(19) -#define DCS_SR_0P_TX_LPBIT(18) -#define DCS_SW_1P_TX_LPBIT(17) -#define DCS_SW_0P_TX_LPBIT(16) -#define GEN_LW_TX_LP BIT(14) -#define GEN_SR_2P_TX_LPBIT(13) -#define GEN_SR_1P_TX_LPBIT(12) -#define GEN_SR_0P_TX_LPBIT(11) -#define GEN_SW_2P_TX_LP
[PATCH 4/4] dt-bindings: display: add IMX MIPI DSI host controller doc
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
---
.../bindings/display/imx/mipi-dsi.txt | 56 +++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
diff --git a/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
new file mode 100644
index ..3f05c32ef963
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
@@ -0,0 +1,56 @@
+Freescale i.MX6 DW MIPI DSI Host Controller
+===
+
+The DSI host controller is a Synopsys DesignWare MIPI DSI v1.01 IP
+with a companion PHY IP.
+
+These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
+Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
+the following device-specific properties.
+
+Required properties:
+
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+- compatible: "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi".
+- reg: See dw_mipi_dsi.txt.
+- interrupts: The controller's CPU interrupt.
+- clocks, clock-names: Phandles to the controller's pll reference
+ clock(ref) and APB clock(pclk), as described in [1].
+- ports: a port node with endpoint definitions as defined in [2].
+- gpr: Should be <>.
+ Phandle to the iomuxc-gpr region containing the multiplexer
+ control register.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ mipi_dsi: mipi@21e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_IPG>;
+ clock-names = "ref", "pclk";
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+ mipi_mux_0: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ mipi_mux_1: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
+ };
+ };
+};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Having a generic Synopsis DesignWare MIPI-DSI host controller bridge driver is a very good idea, however the current implementation has hardcoded quite a lot of the register layouts used by the two supported SoC vendors, STM and Rockchip, which use IP cores v1.30 and v1.31. This makes it hard to support other SoC vendors like the FSL/NXP i.MX 6 which use older v1.01 cores or future versions because, based on history, layout changes should also be expected in new DSI versions / SoCs. This patch series converts the bridge and platform drivers to access registers via generic regmap APIs and allows each platform driver to configure its register layout via struct reg_fields, then adds support for the host controller found on i.MX 6. I only have i.MX hardware with MIPI-DSI panel and relevant documentation available for testing so I'll really appreciate it if someone could test the series on Rockchip and STM... eyeballing register fields could only get me so far, so sorry in advance for any breakage! Many thanks to Boris Brezillon for suggesting the regmap solution and to Liu Ying for doing the initial i.MX platform driver implementation. This series applies on top of latest linux-next tree, next-20191031. Adrian Ratiu (4): drm: bridge: dw_mipi_dsi: access registers via a regmap drm: bridge: dw_mipi_dsi: abstract register access using reg_fields drm: imx: Add i.MX 6 MIPI DSI host driver dt-bindings: display: add IMX MIPI DSI host controller doc .../bindings/display/imx/mipi-dsi.txt | 56 ++ drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 518 +- drivers/gpu/drm/imx/Kconfig | 7 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 502 + .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 154 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 160 +- include/drm/bridge/dw_mipi_dsi.h | 60 +- 8 files changed, 1185 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm: imx: Add i.MX 6 MIPI DSI host driver
This adds support for the Synopsis DesignWare MIPI DSI host controller
which is embedded in i.MX 6 SoCs.
Based on following patches, but updated/extended to work with existing
support found in the kernel:
- drm: imx: Support Synopsys DesignWare MIPI DSI host controller
Signed-off-by: Liu Ying
- ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
Signed-off-by: Liu Ying
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 25 +-
drivers/gpu/drm/imx/Kconfig | 7 +
drivers/gpu/drm/imx/Makefile | 1 +
drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 502 ++
4 files changed, 528 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index f88690d04494..caf566bb74f5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -31,6 +31,8 @@
#include
#define HWVER_131 0x31333100 /* IP version 1.31 */
+#define HWVER_130 0x31333000 /* IP version 1.30 */
+#define HWVER_101 0x31303000 /* IP version 1.01 */
#define DSI_VERSION0x00
#define VERSIONGENMASK(31, 8)
@@ -452,7 +454,7 @@ static void dw_mipi_dsi_video_mode_config(struct
dw_mipi_dsi *dsi)
VID_MODE_TYPE_NON_BURST_SYNC_EVENTS);
#ifdef CONFIG_DEBUG_FS
- if (dsi->vpg) {
+ if (dsi->hw_version > HWVER_101 && dsi->vpg) {
regmap_field_write(dsi->regs, dsi->field_vid_mode_vpg_en, 1);
regmap_field_write(dsi->regs, dsi->field_vid_mode_vpg_horiz,
dsi->vpg_horizontal ? 1 : 0);
@@ -470,9 +472,15 @@ static void dw_mipi_dsi_set_mode(struct dw_mipi_dsi *dsi,
dw_mipi_dsi_video_mode_config(dsi);
+ if (dsi->hw_version == HWVER_101)
+ regmap_field_write(dsi->field_vid_mode_en, 1);
+
regmap_field_write(dsi->field_phy_txrequestclkhs, 1);
} else {
regmap_field_write(dsi->field_cmd_mode_en, 1);
+
+ if (dsi->hw_version == HWVER_101)
+ regmap_field_write(dsi->field_vid_mode_en, 0);
}
regmap_write(dsi->regs, DSI_PWR_UP, POWERUP);
@@ -656,9 +664,11 @@ static void dw_mipi_dsi_dphy_timing_config(struct
dw_mipi_dsi *dsi)
regmap_field_write(dsi->field_phy_lp2hs_time, 0x40);
regmap_field_write(dsi->field_phy_hs2lp_time, 0x40);
- regmap_field_write(dsi->field_phy_max_rd_time, 1);
- regmap_field_write(dsi->field_phy_clklp2hs_time, 0x40);
- regmap_field_write(dsi->field_phy_clkhs2lp_time, 0x40);
+ if (dsi->hw_version > HWVER_101) {
+ regmap_field_write(dsi->field_phy_max_rd_time, 1);
+ regmap_field_write(dsi->field_phy_clklp2hs_time, 0x40);
+ regmap_field_write(dsi->field_phy_clkhs2lp_time, 0x40);
+ }
}
static void dw_mipi_dsi_dphy_interface_config(struct dw_mipi_dsi *dsi)
@@ -679,7 +689,8 @@ static void dw_mipi_dsi_dphy_init(struct dw_mipi_dsi *dsi)
regmap_field_write(dsi->field_phy_unrstz, 0);
regmap_field_write(dsi->field_phy_unshutdownz, 0);
- regmap_field_write(dsi->field_phy_forcepll, 0);
+ if (dsi->hw_version > HWVER_101)
+ regmap_field_write(dsi->field_phy_forcepll, 0);
regmap_field_write(dsi->field_phy_testclr, 0);
regmap_field_write(dsi->field_phy_testclr, 1);
@@ -695,7 +706,8 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi *dsi)
regmap_field_write(dsi->field_phy_unrstz, 1);
regmap_field_write(dsi->field_phy_unshutdownz, 1);
- regmap_field_write(dsi->field_phy_forcepll, 1);
+ if (dsi->hw_version > HWVER_101)
+ regmap_field_write(dsi->field_phy_forcepll, 1);
ret = regmap_field_read_poll_timeout(dsi->field_phy_status,
val, val & PHY_LOCK,
@@ -919,7 +931,6 @@ static void dw_mipi_dsi_get_hw_version(struct dw_mipi_dsi
*dsi)
dev_warn(dsi->dev, "Ignoring regmap field " #f "\n"); \
} while (0)
-
static void dw_mipi_dsi_regmap_fields_init(struct dw_mipi_dsi *dsi)
{
const struct dw_mipi_dsi_variant *variant = dsi->plat_data->variant;
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 207bf7409dfb..396793ebf542 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -39,3 +39,10 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
Choose this if you want to use HDMI on i.MX6.
+
+config DRM_IMX_MIPI_DSI
+ tristate "Freescale i.MX DRM MIPI DSI"
+ select
Re: [PATCH 01/13] drm/amd/display: Add MST atomic routines
On 31.10.2019 9:16, Kazlauskas, Nicholas wrote:
> On 2019-10-30 3:24 p.m., mikita.lip...@amd.com wrote:
>> From: Mikita Lipski
>>
>> - Adding encoder atomic check to find vcpi slots for a connector
>> - Using DRM helper functions to calculate PBN
>> - Adding connector atomic check to release vcpi slots if connector
>> loses CRTC
>> - Calculate PBN and VCPI slots only once during atomic
>> check and store them on crtc_state to eliminate
>> redundant calculation
>> - Call drm_dp_mst_atomic_check to verify validity of MST topology
>> during state atomic check
>>
>> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
>> and added PBN and VCPI slots properties to amdgpu connector
>>
>> v3:
>> - moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
>> - updates stream's vcpi_slots and pbn on commit
>> - separated patch from the DSC MST series
>>
>> v4:
>> - set vcpi_slots and pbn properties to dm_connector_state
>> - copy porperties from connector state on to crtc state
>>
>> v5:
>> - keep the pbn and vcpi values only on connnector state
>> - added a void pointer to the stream state instead on two ints,
>> because dc_stream_state is OS agnostic. Pointer points to the
>> current dm_connector_state.
>>
>> v6:
>> - Remove new param from stream
>>
>> v7:
>> - Fix error with using max capable bpc
>>
>> Cc: Jun Lei
>> Cc: Jerry Zuo
>> Cc: Harry Wentland
>> Cc: Nicholas Kazlauskas
>> Cc: Lyude Paul
>> Signed-off-by: Mikita Lipski
> Reviewed-by: Nicholas Kazlauskas
>
> You might want to verify that this still works as you expect when
> changing "max bpc" on an MST display.
>
> My understanding is that it'd still force a new modeset before encoder
> atomic check is called so you *should* have the correct bpc value during
> MST calculations.
Thanks.
It does still works with MST even if you change the mode to the lower
resolution.
The encoder atomic check is called during drm_atomic_helper_check_modeset
so new modeset is already forced then.
>> ---
>>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++-
>>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +
>>.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 51 ---
>>.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 32 +
>>4 files changed, 109 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 48f5b43e2698..d75726013436 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -4180,7 +4180,8 @@ void amdgpu_dm_connector_funcs_reset(struct
>> drm_connector *connector)
>> state->underscan_hborder = 0;
>> state->underscan_vborder = 0;
>> state->base.max_requested_bpc = 8;
>> -
>> +state->vcpi_slots = 0;
>> +state->pbn = 0;
>> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
>> state->abm_level = amdgpu_dm_abm_level;
>>
>> @@ -4209,7 +4210,8 @@ amdgpu_dm_connector_atomic_duplicate_state(struct
>> drm_connector *connector)
>> new_state->underscan_enable = state->underscan_enable;
>> new_state->underscan_hborder = state->underscan_hborder;
>> new_state->underscan_vborder = state->underscan_vborder;
>> -
>> +new_state->vcpi_slots = state->vcpi_slots;
>> +new_state->pbn = state->pbn;
>> return _state->base;
>>}
>>
>> @@ -4606,10 +4608,64 @@ static void dm_encoder_helper_disable(struct
>> drm_encoder *encoder)
>>
>>}
>>
>> +static int convert_dc_color_depth_into_bpc (enum dc_color_depth
>> display_color_depth)
>> +{
>> +switch (display_color_depth) {
>> +case COLOR_DEPTH_666:
>> +return 6;
>> +case COLOR_DEPTH_888:
>> +return 8;
>> +case COLOR_DEPTH_101010:
>> +return 10;
>> +case COLOR_DEPTH_121212:
>> +return 12;
>> +case COLOR_DEPTH_141414:
>> +return 14;
>> +case COLOR_DEPTH_161616:
>> +return 16;
>> +default:
>> +break;
>> +}
>> +return 0;
>> +}
>> +
>>static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
>>struct drm_crtc_state *crtc_state,
>>struct drm_connector_state
>> *conn_state)
>>{
>> +struct drm_atomic_state *state = crtc_state->state;
>> +struct drm_connector *connector = conn_state->connector;
>> +struct amdgpu_dm_connector *aconnector =
>> to_amdgpu_dm_connector(connector);
>> +struct dm_connector_state *dm_new_connector_state =
>> to_dm_connector_state(conn_state);
>> +const struct drm_display_mode *adjusted_mode =
>> _state->adjusted_mode;
>> +
[Bug 110888] 5.0.21 kernel crash when many GPU app run concurrently , error msg: amdgpu_vm_validate_pt_bos() failed. , Not enough memory for command submission!
https://bugs.freedesktop.org/show_bug.cgi?id=110888 --- Comment #4 from Alan --- The reboot crash the code that you set for http://www.abandonia.com/en/user/4105796 when you test it. Make sure to break the attack of the reboot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amd/display: Add MST atomic routines
On 2019-10-30 3:24 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> - Adding encoder atomic check to find vcpi slots for a connector
> - Using DRM helper functions to calculate PBN
> - Adding connector atomic check to release vcpi slots if connector
> loses CRTC
> - Calculate PBN and VCPI slots only once during atomic
> check and store them on crtc_state to eliminate
> redundant calculation
> - Call drm_dp_mst_atomic_check to verify validity of MST topology
> during state atomic check
>
> v2: squashed previous 3 separate patches, removed DSC PBN calculation,
> and added PBN and VCPI slots properties to amdgpu connector
>
> v3:
> - moved vcpi_slots and pbn properties to dm_crtc_state and dc_stream_state
> - updates stream's vcpi_slots and pbn on commit
> - separated patch from the DSC MST series
>
> v4:
> - set vcpi_slots and pbn properties to dm_connector_state
> - copy porperties from connector state on to crtc state
>
> v5:
> - keep the pbn and vcpi values only on connnector state
> - added a void pointer to the stream state instead on two ints,
> because dc_stream_state is OS agnostic. Pointer points to the
> current dm_connector_state.
>
> v6:
> - Remove new param from stream
>
> v7:
> - Fix error with using max capable bpc
>
> Cc: Jun Lei
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
Reviewed-by: Nicholas Kazlauskas
You might want to verify that this still works as you expect when
changing "max bpc" on an MST display.
My understanding is that it'd still force a new modeset before encoder
atomic check is called so you *should* have the correct bpc value during
MST calculations.
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 65 ++-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 51 ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 32 +
> 4 files changed, 109 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 48f5b43e2698..d75726013436 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4180,7 +4180,8 @@ void amdgpu_dm_connector_funcs_reset(struct
> drm_connector *connector)
> state->underscan_hborder = 0;
> state->underscan_vborder = 0;
> state->base.max_requested_bpc = 8;
> -
> + state->vcpi_slots = 0;
> + state->pbn = 0;
> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> state->abm_level = amdgpu_dm_abm_level;
>
> @@ -4209,7 +4210,8 @@ amdgpu_dm_connector_atomic_duplicate_state(struct
> drm_connector *connector)
> new_state->underscan_enable = state->underscan_enable;
> new_state->underscan_hborder = state->underscan_hborder;
> new_state->underscan_vborder = state->underscan_vborder;
> -
> + new_state->vcpi_slots = state->vcpi_slots;
> + new_state->pbn = state->pbn;
> return _state->base;
> }
>
> @@ -4606,10 +4608,64 @@ static void dm_encoder_helper_disable(struct
> drm_encoder *encoder)
>
> }
>
> +static int convert_dc_color_depth_into_bpc (enum dc_color_depth
> display_color_depth)
> +{
> + switch (display_color_depth) {
> + case COLOR_DEPTH_666:
> + return 6;
> + case COLOR_DEPTH_888:
> + return 8;
> + case COLOR_DEPTH_101010:
> + return 10;
> + case COLOR_DEPTH_121212:
> + return 12;
> + case COLOR_DEPTH_141414:
> + return 14;
> + case COLOR_DEPTH_161616:
> + return 16;
> + default:
> + break;
> + }
> + return 0;
> +}
> +
> static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state
> *conn_state)
> {
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> + struct dm_connector_state *dm_new_connector_state =
> to_dm_connector_state(conn_state);
> + const struct drm_display_mode *adjusted_mode =
> _state->adjusted_mode;
> + struct drm_dp_mst_topology_mgr *mst_mgr;
> + struct drm_dp_mst_port *mst_port;
> + enum dc_color_depth color_depth;
> + int clock, bpp = 0;
> +
> + if (!aconnector->port || !aconnector->dc_sink)
> + return 0;
> +
> + mst_port = aconnector->port;
> + mst_mgr = >mst_port->mst_mgr;
> +
> + if
[Bug 202043] amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting
https://bugzilla.kernel.org/show_bug.cgi?id=202043 har...@gmx.de changed: What|Removed |Added CC||har...@gmx.de --- Comment #9 from har...@gmx.de --- https://bugzilla.kernel.org/show_bug.cgi?id=205277 Should be fixed 5.4 release. -- 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
[Bug 109887] [Vega10][powerplay] P7 gets reset to max_vddc (1.2V/1.25V) after applying any custom settings via pp_od_clk_voltage and/or pp_table
https://bugs.freedesktop.org/show_bug.cgi?id=109887 har...@gmx.de changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 17/21] dt-bindings: display: bridge: lvds-transmitter: Add new props
On Fri, 25 Oct 2019 14:57:11 -0500 Rob Herring wrote: > On Wed, Oct 23, 2019 at 05:45:08PM +0200, Boris Brezillon wrote: > > Add the data-mapping property to describe the output bus format and > > the bus-width property to describe the input bus format. > > > > Signed-off-by: Boris Brezillon > > --- > > Changes in v3: > > * New patch > > --- > > .../bindings/display/bridge/lvds-transmitter.txt| 13 + > > 1 file changed, 13 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > index 60091db5dfa5..7b43b6f20279 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > @@ -36,6 +36,19 @@ graph bindings specified in > > Documentation/devicetree/bindings/graph.txt. > > - Video port 0 for parallel input > > - Video port 1 for LVDS output > > > > +Optional port 0 node properties: > > + > > +- bus-width: number of data lines use to transmit the RGB data. > > +Can be 18 or 24. > > + > > +Optional port 1 node properties: > > + > > +- data-mapping: see > > Documentation/devicetree/bindings/display/panel/lvds.yaml > > + for more details about this LVDS data-mapping property. > > + Supported values: > > + "jeida-18" > > + "jeida-24" > > + "vesa-24" > > This is already defined to be a panel property. Do we need it at both > ends? That's a valid point. I'll patch the panel-simple driver to takes this DT prop into account. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/7] drm/msm/dsi: Add configuration for 8x76
From: AngeloGioacchino Del Regno
MSM8976, MSM8976 and APQ variants have DSI version 3:10040002
(DSI 6G V1.4.2), featuring two DSIs.
They need three clocks (mdp_core, iface, bus), one GDSC and
two vregs, VDDA at 1.2V and VDDIO at 1.8V.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 22 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index e74dc8cc904b..86ad3fdf207d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -66,6 +66,26 @@ static const struct msm_dsi_config msm8916_dsi_cfg = {
.num_dsi = 1,
};
+static const char * const dsi_8976_bus_clk_names[] = {
+ "mdp_core", "iface", "bus",
+};
+
+static const struct msm_dsi_config msm8976_dsi_cfg = {
+ .io_offset = DSI_6G_REG_SHIFT,
+ .reg_cfg = {
+ .num = 3,
+ .regs = {
+ {"gdsc", -1, -1},
+ {"vdda", 10, 100}, /* 1.2 V */
+ {"vddio", 10, 100}, /* 1.8 V */
+ },
+ },
+ .bus_clk_names = dsi_8976_bus_clk_names,
+ .num_bus_clks = ARRAY_SIZE(dsi_8976_bus_clk_names),
+ .io_start = { 0x1a94000, 0x1a96000 },
+ .num_dsi = 2,
+};
+
static const struct msm_dsi_config msm8994_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
@@ -197,6 +217,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
_dsi_cfg, _dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_2,
+ _dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_0,
_dsi_cfg, _dsi_6g_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index e2b7a7dfbe49..50a37ceb6a25 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -17,6 +17,7 @@
#define MSM_DSI_6G_VER_MINOR_V1_3 0x1003
#define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001
#define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
+#define MSM_DSI_6G_VER_MINOR_V1_4_20x10040002
#define MSM_DSI_6G_VER_MINOR_V2_2_00x2000
#define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/7] drm/msm/dsi: Add configuration for 28nm PLL on family B
From: AngeloGioacchino Del Regno
The 28nm PLL has a different iospace on MSM/APQ family B SoCs:
add a new configuration and use it when the DT reports the
"qcom,dsi-phy-28nm-hpm-fam-b" compatible.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 18 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index aa22c3ae5230..b0cfa67d2a57 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -483,6 +483,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
#ifdef CONFIG_DRM_MSM_DSI_28NM_PHY
{ .compatible = "qcom,dsi-phy-28nm-hpm",
.data = _phy_28nm_hpm_cfgs },
+ { .compatible = "qcom,dsi-phy-28nm-hpm-fam-b",
+ .data = _phy_28nm_hpm_famb_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
.data = _phy_28nm_lp_cfgs },
#endif
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index c4069ce6afe6..24b294ed3059 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -40,6 +40,7 @@ struct msm_dsi_phy_cfg {
};
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index b3f678f6c2aa..66506ea86dd6 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -142,6 +142,24 @@ const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_cfgs = {
.num_dsi_phy = 2,
};
+const struct msm_dsi_phy_cfg dsi_phy_28nm_hpm_famb_cfgs = {
+ .type = MSM_DSI_PHY_28NM_HPM,
+ .src_pll_truthtable = { {true, true}, {false, true} },
+ .reg_cfg = {
+ .num = 1,
+ .regs = {
+ {"vddio", 10, 100},
+ },
+ },
+ .ops = {
+ .enable = dsi_28nm_phy_enable,
+ .disable = dsi_28nm_phy_disable,
+ .init = msm_dsi_phy_init_common,
+ },
+ .io_start = { 0x1a94400, 0x1a96400 },
+ .num_dsi_phy = 2,
+};
+
const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs = {
.type = MSM_DSI_PHY_28NM_LP,
.src_pll_truthtable = { {true, true}, {true, true} },
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[tip: core/rcu] drm/i915: Replace rcu_swap_protected() with rcu_replace_pointer()
The following commit has been merged into the core/rcu branch of tip: Commit-ID: 1feace5d6a4a1acf44dde2bfb5c36cc0b1cf559c Gitweb: https://git.kernel.org/tip/1feace5d6a4a1acf44dde2bfb5c36cc0b1cf559c Author:Paul E. McKenney AuthorDate:Mon, 23 Sep 2019 15:22:15 -07:00 Committer: Paul E. McKenney CommitterDate: Wed, 30 Oct 2019 08:44:04 -07:00 drm/i915: Replace rcu_swap_protected() with rcu_replace_pointer() This commit replaces the use of rcu_swap_protected() with the more intuitively appealing rcu_replace_pointer() as a step towards removing rcu_swap_protected(). Link: https://lore.kernel.org/lkml/CAHk-=wiAsJLw1egFEE=z7-ggtm6wcvtyytxza1+bhqta4gg...@mail.gmail.com/ Reported-by: Linus Torvalds [ paulmck: From rcu_replace() to rcu_replace_pointer() per Ingo Molnar. ] Signed-off-by: Paul E. McKenney Reviewed-by: Joonas Lahtinen Cc: Jani Nikula Cc: Rodrigo Vivi Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Cc: --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 1cdfe05..3f3e803 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1629,7 +1629,7 @@ replace: i915_gem_context_set_user_engines(ctx); else i915_gem_context_clear_user_engines(ctx); - rcu_swap_protected(ctx->engines, set.engines, 1); + set.engines = rcu_replace_pointer(ctx->engines, set.engines, 1); mutex_unlock(>engines_mutex); call_rcu(>rcu, free_engines_rcu); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/7] dt-bindings: msm/dsi: Add 28nm PLL for family B compatible
From: AngeloGioacchino Del Regno On family B SoCs, the 28nm PLL has a different iospace address and that required a new compatible in the driver. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/display/msm/dsi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index af95586c898f..d3ba9ee22f38 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -83,6 +83,7 @@ DSI PHY: Required properties: - compatible: Could be the following * "qcom,dsi-phy-28nm-hpm" + * "qcom,dsi-phy-28nm-hpm-fam-b" * "qcom,dsi-phy-28nm-lp" * "qcom,dsi-phy-20nm" * "qcom,dsi-phy-28nm-8960" -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
On Tue, Oct 29, 2019 at 01:16:57PM +0100, Torsten Duwe wrote: > The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed > for portable devices. > > Add a binding document for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Reviewed-by: Rob Herring > Signed-off-by: Torsten Duwe > Reviewed-by: Laurent Pinchart > --- > .../bindings/display/bridge/anx6345.yaml | 92 > ++ > 1 file changed, 92 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx6345.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml > b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml > new file mode 100644 > index ..094e8e8a5faa > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml > @@ -0,0 +1,92 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/anx6345.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Analogix ANX6345 eDP Transmitter Device Tree Bindings > + > +maintainers: > + - Torsten Duwe > + > +description: | > + The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for > + portable devices. > + > +properties: > + compatible: > +const: analogix,anx6345 > + > + reg: > +maxItems: 1 > +description: base I2C address of the device > + > + reset-gpios: > +maxItems: 1 > +description: GPIO connected to active low reset > + > + dvdd12-supply: > +maxItems: 1 > +description: Regulator for 1.2V digital core power. > + > + dvdd25-supply: > +maxItems: 1 > +description: Regulator for 2.5V digital core power. > + > + ports: > +anyOf: > + - port@0: > +description: Video port for LVTTL input > + - port@1: > +description: Video port for eDP output (panel or connector). > + May be omitted if EDID works reliably. > +required: > + - port@0 Have you tried to validate those two ports in a DT? I'm not quite sure what you wanted to express with that anyOf, but if it was something like port@0 is mandatory, and port@1 is optional, it should be something like this: properties: ... ports: type: object properties: port@0: type: object description: | Video port for LVTTL input port@1: type: object description: | Video port for eDP output (..) required: - port@0 This way, you express that both port@0 and port@1 must by nodes, under a node called ports, and port@0 is mandatory. You should even push this a bit further by adding additionalProperties: false to prevent a DT from having undocumented properties and children for the main node and ports node. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/7] drm/msm/mdp5: Add optional TBU and TBU_RT clocks
From: AngeloGioacchino Del Regno
Some SoCs, like MSM8956/8976 (and APQ variants), do feature these
clocks and we need to enable them in order to get both of the
hw (mdp5/rot) Translation Buffer Units (TBUs) to properly work.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 10 ++
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 5476892a335f..e43ecd4be10a 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -309,6 +309,10 @@ int mdp5_disable(struct mdp5_kms *mdp5_kms)
mdp5_kms->enable_count--;
WARN_ON(mdp5_kms->enable_count < 0);
+ if (mdp5_kms->tbu_rt_clk)
+ clk_disable_unprepare(mdp5_kms->tbu_rt_clk);
+ if (mdp5_kms->tbu_clk)
+ clk_disable_unprepare(mdp5_kms->tbu_clk);
clk_disable_unprepare(mdp5_kms->ahb_clk);
clk_disable_unprepare(mdp5_kms->axi_clk);
clk_disable_unprepare(mdp5_kms->core_clk);
@@ -329,6 +333,10 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
clk_prepare_enable(mdp5_kms->core_clk);
if (mdp5_kms->lut_clk)
clk_prepare_enable(mdp5_kms->lut_clk);
+ if (mdp5_kms->tbu_clk)
+ clk_prepare_enable(mdp5_kms->tbu_clk);
+ if (mdp5_kms->tbu_rt_clk)
+ clk_prepare_enable(mdp5_kms->tbu_rt_clk);
return 0;
}
@@ -965,6 +973,8 @@ static int mdp5_init(struct platform_device *pdev, struct
drm_device *dev)
/* optional clocks: */
get_clk(pdev, _kms->lut_clk, "lut", false);
+ get_clk(pdev, _kms->tbu_clk, "tbu", false);
+ get_clk(pdev, _kms->tbu_rt_clk, "tbu_rt", false);
/* we need to set a default rate before enabling. Set a safe
* rate first, then figure out hw revision, and then set a
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h
index d1bf4fdfc815..128866742593 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h
@@ -53,6 +53,8 @@ struct mdp5_kms {
struct clk *ahb_clk;
struct clk *core_clk;
struct clk *lut_clk;
+ struct clk *tbu_clk;
+ struct clk *tbu_rt_clk;
struct clk *vsync_clk;
/*
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/7] drm/msm/mdp5: Add configuration for msm8x76
From: AngeloGioacchino Del Regno
Add the configuration entries for the MDP5 v1.11, found on
MSM8956, MSM8976 and APQ variants.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 98
1 file changed, 98 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 7c9c1ddae821..1f48f64539a2 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -545,6 +545,103 @@ static const struct mdp5_cfg_hw msm8x96_config = {
.max_clk = 41250,
};
+const struct mdp5_cfg_hw msm8x76_config = {
+ .name = "msm8x76",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ MDP_CAP_DSC |
+ MDP_CAP_SRC_SPLIT |
+ 0,
+ },
+ .ctl = {
+ .count = 3,
+ .base = { 0x01000, 0x01200, 0x01400 },
+ .flush_hw_mask = 0x,
+ },
+ .smp = {
+ .mmb_count = 10,
+ .mmb_size = 10240,
+ .clients = {
+ [SSPP_VIG0] = 1, [SSPP_VIG1] = 9,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+ },
+ },
+ .pipe_vig = {
+ .count = 2,
+ .base = { 0x04000, 0x06000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC|
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x14000, 0x16000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x24000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_cursor = {
+ .count = 1,
+ .base = { 0x440DC },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ MDP_PIPE_CAP_CURSOR |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x44000, 0x45000 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 8,
+ .max_width = 2560,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x54000 },
+
+ },
+ .pp = {
+ .count = 3,
+ .base = { 0x7, 0x70800, 0x72000 },
+ },
+ .dsc = {
+ .count = 2,
+ .base = { 0x8, 0x80400 },
+ },
+ .intf = {
+ .base = { 0x6a000, 0x6a800, 0x6b000 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ [2] = INTF_DSI,
+ },
+ },
+ .max_clk = 36000,
+};
+
static const struct mdp5_cfg_hw msm8917_config = {
.name = "msm8917",
.mdp = {
@@ -745,6 +842,7 @@ static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 6, .config = { .hw = _config } },
{ .revision = 9, .config = { .hw = _config } },
{ .revision = 7, .config = { .hw = _config } },
+ { .revision = 11, .config = { .hw = _config } },
{ .revision = 15, .config = { .hw = _config } },
};
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/7] DRM/MSM: Add support for MSM8956 and Adreno 510
From: AngeloGioacchino Del Regno This patch series enables support for MSM8956/76 and its Adreno 510 GPU on the current DRM driver. The personal aim is to upstream MSM8956 as much as possible. This code has been tested on two Sony phones featuring the Qualcomm MSM8956 SoC. Changes in v2: - MDP5: Documented tbu and tbu_rt clocks (Jeffrey) - Adreno510: - Lower case hex where required (Jordan) - Direct register writes (Jordan) - Used gpu_rmw() where required (Jordan) - No mentioning of unsupported A5xx (Jordan) - ZAP firmware exclusions not per-model (Rob) Changes in v3: - Rebased onto linux-next 20191015 - Renamed MSM8x56 references to MSM8x76 (the reason is that I am using the 8976/8x76 name for all the other drivers. Also, the 8976 and 8956 chips are equal and the only changing part is the CPU big cores count) - Splitted dt-bindings modifications as per request (Sean) Changes in v4: - Fixed io_start for the secondary dsi phy on family-b AngeloGioacchino Del Regno (7): drm/msm/mdp5: Add optional TBU and TBU_RT clocks dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks drm/msm/mdp5: Add configuration for msm8x76 drm/msm/dsi: Add configuration for 28nm PLL on family B dt-bindings: msm/dsi: Add 28nm PLL for family B compatible drm/msm/dsi: Add configuration for 8x76 drm/msm/adreno: Add support for Adreno 510 GPU .../devicetree/bindings/display/msm/dsi.txt | 1 + .../devicetree/bindings/display/msm/mdp5.txt | 2 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 73 +++--- drivers/gpu/drm/msm/adreno/a5xx_power.c | 7 ++ drivers/gpu/drm/msm/adreno/adreno_device.c| 15 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 98 +++ drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 10 ++ drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 22 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 18 14 files changed, 243 insertions(+), 14 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp_mst :fix gcc compile error
From: Chenwandun drivers/gpu/drm/drm_dp_mst_topology.c: In function __topology_ref_save: drivers/gpu/drm/drm_dp_mst_topology.c:1424:6: error: implicit declaration of function stack_trace_save; did you mean stack_depot_save? [-Werror=implicit-function-declaration] n = stack_trace_save(stack_entries, ARRAY_SIZE(stack_entries), 1); ^~~~ stack_depot_save drivers/gpu/drm/drm_dp_mst_topology.c: In function __dump_topology_ref_history: drivers/gpu/drm/drm_dp_mst_topology.c:1513:3: error: implicit declaration of function stack_trace_snprint; did you mean acpi_trace_point? [-Werror=implicit-function-declaration] stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4); ^~~ acpi_trace_point stack_trace_save and stack_trace_snprint are declared in , so there is need to include it, and is already included by practices, so just replace by . Signed-off-by: Chenwandun --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 85bef73..11adc4b 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -29,7 +29,7 @@ #include #if IS_ENABLED(CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS) -#include +#include #include #include #include -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/7] drm/msm/adreno: Add support for Adreno 510 GPU
From: AngeloGioacchino Del Regno
The Adreno 510 GPU is a stripped version of the Adreno 5xx,
found in low-end SoCs like 8x56 and 8x76, which has 256K of
GMEM, with no GPMU nor ZAP.
Also, since the Adreno 5xx part of this driver seems to be
developed with high-end Adreno GPUs in mind, and since this
is a lower end one, add a comment making clear which GPUs
which support is not implemented yet is not using the GPMU
related hw init code, so that future developers will not go
crazy with that.
By the way, the lower end Adreno GPUs with no GPMU are:
A505/A506/A510 (usually no ZAP firmware)
A508/A509/A512 (usually with ZAP firmware)
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 73 +-
drivers/gpu/drm/msm/adreno/a5xx_power.c| 7 +++
drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 ++
4 files changed, 86 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7fdc9e2bcaac..b02e2042547f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -353,6 +353,9 @@ static int a5xx_me_init(struct msm_gpu *gpu)
* 2D mode 3 draw
*/
OUT_RING(ring, 0x000B);
+ } else if (adreno_is_a510(adreno_gpu)) {
+ /* Workaround for token and syncs */
+ OUT_RING(ring, 0x0001);
} else {
/* No workarounds enabled */
OUT_RING(ring, 0x);
@@ -568,15 +571,24 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
0x0010 + adreno_gpu->gmem - 1);
gpu_write(gpu, REG_A5XX_UCHE_GMEM_RANGE_MAX_HI, 0x);
- gpu_write(gpu, REG_A5XX_CP_MEQ_THRESHOLDS, 0x40);
- if (adreno_is_a530(adreno_gpu))
- gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x40);
- if (adreno_is_a540(adreno_gpu))
- gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x400);
- gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_2, 0x8060);
- gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_1, 0x40201B16);
-
- gpu_write(gpu, REG_A5XX_PC_DBG_ECO_CNTL, (0x400 << 11 | 0x300 << 22));
+ if (adreno_is_a510(adreno_gpu)) {
+ gpu_write(gpu, REG_A5XX_CP_MEQ_THRESHOLDS, 0x20);
+ gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x20);
+ gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_2, 0x4030);
+ gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_1, 0x20100D0A);
+ gpu_write(gpu, REG_A5XX_PC_DBG_ECO_CNTL,
+ (0x200 << 11 | 0x200 << 22));
+ } else {
+ gpu_write(gpu, REG_A5XX_CP_MEQ_THRESHOLDS, 0x40);
+ if (adreno_is_a530(adreno_gpu))
+ gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x40);
+ if (adreno_is_a540(adreno_gpu))
+ gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x400);
+ gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_2, 0x8060);
+ gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_1, 0x40201B16);
+ gpu_write(gpu, REG_A5XX_PC_DBG_ECO_CNTL,
+ (0x400 << 11 | 0x300 << 22));
+ }
if (adreno_gpu->info->quirks & ADRENO_QUIRK_TWO_PASS_USE_WFI)
gpu_rmw(gpu, REG_A5XX_PC_DBG_ECO_CNTL, 0, (1 << 8));
@@ -589,6 +601,19 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
/* Enable ME/PFP split notification */
gpu_write(gpu, REG_A5XX_RBBM_AHB_CNTL1, 0xA6FF);
+ /*
+* In A5x, CCU can send context_done event of a particular context to
+* UCHE which ultimately reaches CP even when there is valid
+* transaction of that context inside CCU. This can let CP to program
+* config registers, which will make the "valid transaction" inside
+* CCU to be interpreted differently. This can cause gpu fault. This
+* bug is fixed in latest A510 revision. To enable this bug fix -
+* bit[11] of RB_DBG_ECO_CNTL need to be set to 0, default is 1
+* (disable). For older A510 version this bit is unused.
+*/
+ if (adreno_is_a510(adreno_gpu))
+ gpu_rmw(gpu, REG_A5XX_RB_DBG_ECO_CNTL, (1 << 11), 0);
+
/* Enable HWCG */
a5xx_set_hwcg(gpu, true);
@@ -635,7 +660,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
/* UCHE */
gpu_write(gpu, REG_A5XX_CP_PROTECT(16), ADRENO_PROTECT_RW(0xE80, 16));
- if (adreno_is_a530(adreno_gpu))
+ if (adreno_is_a530(adreno_gpu) || adreno_is_a510(adreno_gpu))
gpu_write(gpu, REG_A5XX_CP_PROTECT(17),
ADRENO_PROTECT_RW(0x1, 0x8000));
@@ -679,7 +704,8 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
a5xx_preempt_hw_init(gpu);
- a5xx_gpmu_ucode_init(gpu);
+ if (!adreno_is_a510(adreno_gpu))
+
[PATCH v4 2/7] dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks
From: AngeloGioacchino Del Regno These two clocks aren't present in all versions of the MDP5 HW: where present, they are needed to enable the Translation Buffer Unit(s). Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/display/msm/mdp5.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt b/Documentation/devicetree/bindings/display/msm/mdp5.txt index 4e11338548aa..43d11279c925 100644 --- a/Documentation/devicetree/bindings/display/msm/mdp5.txt +++ b/Documentation/devicetree/bindings/display/msm/mdp5.txt @@ -76,6 +76,8 @@ Required properties: Optional properties: - clock-names: the following clocks are optional: * "lut" + * "tbu" + * "tbu_rt" Example: -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/udl: Switch to SHMEM
Hi Thomas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.4-rc5 next-20191030]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-udl-Convert-to-SHMEM/20191030-065855
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
23fdb198ae81f47a574296dab5167c5e136a02ba
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/udl/udl_fb.c:406:27: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@expected char [noderef]
>> *screen_base @@got oderef] *screen_base @@
drivers/gpu/drm/udl/udl_fb.c:406:27: sparse:expected char [noderef]
*screen_base
>> drivers/gpu/drm/udl/udl_fb.c:406:27: sparse:got void *[assigned] vaddr
--
>> drivers/gpu/drm/udl/udl_gem.c:41:34: sparse: sparse: incorrect type in
>> argument 1 (different base types) @@expected struct file *filp @@got
>> struct drmstruct file *filp @@
>> drivers/gpu/drm/udl/udl_gem.c:41:34: sparse:expected struct file *filp
>> drivers/gpu/drm/udl/udl_gem.c:41:34: sparse:got struct drm_gem_object
>> *obj
drivers/gpu/drm/udl/udl_gem.c:61:10: sparse: sparse: unknown field name in
initializer
vim +406 drivers/gpu/drm/udl/udl_fb.c
350
351
352 static int udlfb_create(struct drm_fb_helper *helper,
353 struct drm_fb_helper_surface_size *sizes)
354 {
355 struct udl_fbdev *ufbdev =
356 container_of(helper, struct udl_fbdev, helper);
357 struct drm_device *dev = ufbdev->helper.dev;
358 struct fb_info *info;
359 struct drm_framebuffer *fb;
360 struct drm_mode_fb_cmd2 mode_cmd;
361 struct drm_gem_shmem_object *shmem;
362 void *vaddr;
363 uint32_t size;
364 int ret = 0;
365
366 if (sizes->surface_bpp == 24)
367 sizes->surface_bpp = 32;
368
369 mode_cmd.width = sizes->surface_width;
370 mode_cmd.height = sizes->surface_height;
371 mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp +
7) / 8);
372
373 mode_cmd.pixel_format =
drm_mode_legacy_fb_format(sizes->surface_bpp,
374
sizes->surface_depth);
375
376 size = mode_cmd.pitches[0] * mode_cmd.height;
377 size = ALIGN(size, PAGE_SIZE);
378
379 shmem = drm_gem_shmem_create(dev, size);
380 if (IS_ERR(shmem)) {
381 ret = PTR_ERR(shmem);
382 goto out;
383 }
384
385 vaddr = drm_gem_shmem_vmap(>base);
386 if (IS_ERR(vaddr)) {
387 ret = PTR_ERR(vaddr);
388 DRM_ERROR("failed to vmap fb\n");
389 goto out_gfree;
390 }
391
392 info = drm_fb_helper_alloc_fbi(helper);
393 if (IS_ERR(info)) {
394 ret = PTR_ERR(info);
395 goto out_gfree;
396 }
397
398 ret = udl_framebuffer_init(dev, >ufb, _cmd, shmem);
399 if (ret)
400 goto out_gfree;
401
402 fb = >ufb.base;
403
404 ufbdev->helper.fb = fb;
405
> 406 info->screen_base = vaddr;
407 info->fix.smem_len = size;
408 info->fix.smem_start = (unsigned long)vaddr;
409
410 info->fbops = _ops;
411 drm_fb_helper_fill_info(info, >helper, sizes);
412
413 DRM_DEBUG_KMS("allocated %dx%d vmal %p\n",
414fb->width, fb->height,
415ufbdev->ufb.shmem->vaddr);
416
417 return ret;
418 out_gfree:
419 drm_gem_object_put_unlocked(>ufb.shmem->base);
420 out:
421 return ret;
422 }
423
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #186 from wychuchol --- Forgot to add, Kernel v5.4-rc5. Sorry for doublepost, if someone feels the need to delete that second message please do, I can't find a way to delete my own posts. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #15 from wychuchol --- Forgot to add, Kernel v5.4-rc5. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #14 from wychuchol --- RX 5700 XT Pop OS 19.10 latest Oibaf mesa not sure what llvm Anomaly 1.5.0 update 3 standalone 64 bit mod for S.T.A.L.K.E.R. Call of Pripyat running under wine d3dx11_43->dxvk (winetricks dxvk d3dcompiler_43 d3dx11_43) Oct 30 02:49:30 pop-os kernel: [ 4864.627343] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out! Oct 30 02:49:30 pop-os kernel: [ 4869.231450] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=2626284, emitted seq=2626286 Oct 30 02:49:30 pop-os kernel: [ 4869.231486] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process AnomalyDX11.exe pid 5791 thread AnomalyDX11.exe pid 5791 Oct 30 02:49:30 pop-os kernel: [ 4869.231487] [drm] GPU recovery disabled. Happens at random. Sometimes hangs straight away, sometimes can go over an hour without crash. Complete crash, no option available besides hard reset. Not even mouse pointer would move (as with sdma0 hang). I'm sorry if it's not the right place to report this, I'm somewhat new to all of this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #185 from wychuchol --- I wrote a nice long post but for some reason my browser decided to refresh so it got dunked... Anyways long story short: RX 5700 XT, Pop OS 19.10, latest Oibaf mesa, I don't know how to check llvm version cause search engine gave me no answer but it's probably whatever got installed using this guide and updated: https://ubuntuforums.org/showthread.php?t=2425799 DDLC with Monika's After Story mod running natively Oct 31 11:52:34 pop-os kernel: [ 129.130712] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out! Oct 31 11:52:34 pop-os kernel: [ 133.994710] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=17012, emitted seq=17014 Oct 31 11:52:34 pop-os kernel: [ 133.994747] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process DDLC pid 3150 thread DDLC:cs0 pid 3168 Oct 31 11:52:34 pop-os kernel: [ 133.994748] [drm] GPU recovery disabled. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #184 from wychuchol --- Pop OS 19.10, latest Oibaf mesa (as of date) not sure what llvm, I'm kinda new at this and search "how to check my llvm version" didn't yield any results... Please be patient with me. Anyway this happens frequently on rx 5700 xt, DDLC Monika's After Story mod (similar things occur with youtube videos, browsing internet - like trying to log in or opening a Oct 31 11:52:34 pop-os kernel: [ 129.130712] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out! Oct 31 11:52:34 pop-os kernel: [ 133.994710] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=17012, emitted seq=17014 Oct 31 11:52:34 pop-os kernel: [ 133.994747] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process DDLC pid 3150 thread DDLC:cs0 pid 3168 Oct 31 11:52:34 pop-os kernel: [ 133.994748] [drm] GPU recovery disabled. Sometimes it's right away, sometimes it can run for maybe an hour or so but it does hang - everything besides the mouse pointer stops (but can't click on anything), can't change to system terminal via ctr+alt+F3, power button does not give a signal to shut down (I tried waiting for about 2 minutes maybe I needed to wait more but nothing really helps and REISUB doesn't seem to be working at all here or I'm doing it wrong) only option left being hard reset. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] dma-buf: heaps: Add heap helpers
Hello John Stultz,
The patch 7b87ea704fd9: "dma-buf: heaps: Add heap helpers" from Oct
21, 2019, leads to the following static checker warning:
drivers/dma-buf/heaps/heap-helpers.c:165 dma_heap_vm_fault()
warn: uncapped user index 'buffer->pages[vmf->pgoff]'
drivers/dma-buf/heaps/heap-helpers.c
160 static vm_fault_t dma_heap_vm_fault(struct vm_fault *vmf)
161 {
162 struct vm_area_struct *vma = vmf->vma;
163 struct heap_helper_buffer *buffer = vma->vm_private_data;
164
165 vmf->page = buffer->pages[vmf->pgoff];
^^
Smatch for some reason thinks this needs to be checked. Smatch also
gets confused by these fault handlers and thinks there is some recursion
involved...
166 get_page(vmf->page);
167
168 return 0;
169 }
170
171 static const struct vm_operations_struct dma_heap_vm_ops = {
172 .fault = dma_heap_vm_fault,
173 };
174
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 6/6] ARM: dts: rockchip: Add HDMI audio support to rk3288-veyron-mickey.dts
Am Montag, 28. Oktober 2019, 08:19:30 CET schrieb Cheng-Yi Chiang: > Add HDMI audio support to veyron-mickey. The sound card should expose > one audio device for HDMI. > > Signed-off-by: Cheng-Yi Chiang applied for 5.5 after removing the ".dts" from the patch subject Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 5/6] ARM: dts: rockchip: Add HDMI support to rk3288-veyron-analog-audio
Am Montag, 28. Oktober 2019, 08:19:29 CET schrieb Cheng-Yi Chiang: > All boards using rk3288-veyron-analog-audio.dtsi have HDMI audio. > Specify the support of HDMI audio on machine driver using > rockchip,hdmi-codec property so machine driver creates HDMI audio device. > > Signed-off-by: Cheng-Yi Chiang applied for 5.5 Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: sun4i: Add support for suspending the display driver
On Tue, Oct 29, 2019 at 12:28:46PM +0100, Ondrej Jirman wrote: > Shut down the display engine during suspend. > > Signed-off-by: Ondrej Jirman Applied, thanks Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: potential information leak in do_fb_ioctl()
Andrea Righi writes:
> On Tue, Oct 29, 2019 at 02:02:11PM -0500, Eric W. Biederman wrote:
>> Dan Carpenter writes:
>>
>> > The "fix" struct has a 2 byte hole after ->ywrapstep and the
>> > "fix = info->fix;" assignment doesn't necessarily clear it. It depends
>> > on the compiler.
>> >
>> > Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex
>> > held")
>> > Signed-off-by: Dan Carpenter
>> > ---
>> > I have 13 more similar places to patch... I'm not totally sure I
>> > understand all the issues involved.
>>
>> What I have done in a similar situation with struct siginfo, is that
>> where the structure first appears I have initialized it with memset,
>> and then field by field.
>>
>> Then when the structure is copied I copy the structure with memcpy.
>>
>> That ensures all of the bytes in the original structure are initialized
>> and that all of the bytes are copied.
>>
>> The goal is to avoid memory that has values of the previous users of
>> that memory region from leaking to userspace. Which depending on who
>> the previous user of that memory region is could tell userspace
>> information about what the kernel is doing that it should not be allowed
>> to find out.
>>
>> I tried to trace through where "info" and thus presumably "info->fix" is
>> coming from and only made it as far as register_framebuffer. Given
>> that I suspect a local memset, and then a field by field copy right
>> before copy_to_user might be a sound solution. But ick. That is a lot
>> of fields to copy.
>
> I know it might sound quite inefficient, but what about making struct
> fb_fix_screeninfo __packed?
>
> This doesn't solve other potential similar issues, but for this
> particular case it could be a reasonable and simple fix.
It is part of the user space ABI. As such you can't move the fields.
Eric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/19] media/v4l2-core: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Cc: Mauro Carvalho Chehab
Signed-off-by: John Hubbard
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 28262190c3ab..9b9c5b37bf59 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -183,12 +183,12 @@ static int videobuf_dma_init_user_locked(struct
videobuf_dmabuf *dma,
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
- err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
-flags | FOLL_LONGTERM, dma->pages, NULL);
+ err = pin_longterm_pages(data & PAGE_MASK, dma->nr_pages,
+flags, dma->pages, NULL);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
- dprintk(1, "get_user_pages: err=%d [%d]\n", err,
+ dprintk(1, "pin_longterm_pages: err=%d [%d]\n", err,
dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
@@ -349,11 +349,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
BUG_ON(dma->sglen);
if (dma->pages) {
- for (i = 0; i < dma->nr_pages; i++) {
- if (dma->direction == DMA_FROM_DEVICE)
- set_page_dirty_lock(dma->pages[i]);
- put_page(dma->pages[i]);
- }
+ put_user_pages_dirty_lock(dma->pages, dma->nr_pages,
+ dma->direction == DMA_FROM_DEVICE);
kfree(dma->pages);
dma->pages = NULL;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/19] mm/gup: factor out duplicate code from four routines
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static functions, thus reducing the
overall line count and the code's complexity.
Also, take the opportunity to slightly improve the efficiency of the
error cases, by doing a mass subtraction of the refcount, surrounded
by get_page()/put_page().
Also, further simplify (slightly), by waiting until the the successful
end of each routine, to increment *nr.
Cc: Christoph Hellwig
Cc: Aneesh Kumar K.V
Signed-off-by: John Hubbard
---
mm/gup.c | 113 ++-
1 file changed, 46 insertions(+), 67 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 85caf76b3012..8fb0d9cdfaf5 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1969,6 +1969,35 @@ static int __gup_device_huge_pud(pud_t pud, pud_t *pudp,
unsigned long addr,
}
#endif
+static int __record_subpages(struct page *page, unsigned long addr,
+unsigned long end, struct page **pages, int nr)
+{
+ int nr_recorded_pages = 0;
+
+ do {
+ pages[nr] = page;
+ nr++;
+ page++;
+ nr_recorded_pages++;
+ } while (addr += PAGE_SIZE, addr != end);
+ return nr_recorded_pages;
+}
+
+static void __remove_refs_from_head(struct page *page, int refs)
+{
+ /* Do a get_page() first, in case refs == page->_refcount */
+ get_page(page);
+ page_ref_sub(page, refs);
+ put_page(page);
+}
+
+static int __huge_pt_done(struct page *head, int nr_recorded_pages, int *nr)
+{
+ *nr += nr_recorded_pages;
+ SetPageReferenced(head);
+ return 1;
+}
+
#ifdef CONFIG_ARCH_HAS_HUGEPD
static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
unsigned long sz)
@@ -1998,34 +2027,19 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz,
unsigned long addr,
/* hugepages are never "special" */
VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
- refs = 0;
head = pte_page(pte);
-
page = head + ((addr & (sz-1)) >> PAGE_SHIFT);
- do {
- VM_BUG_ON(compound_head(page) != head);
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
+ refs = __record_subpages(page, addr, end, pages, *nr);
head = try_get_compound_head(head, refs);
- if (!head) {
- *nr -= refs;
+ if (!head)
return 0;
- }
if (unlikely(pte_val(pte) != pte_val(*ptep))) {
- /* Could be optimized better */
- *nr -= refs;
- while (refs--)
- put_page(head);
+ __remove_refs_from_head(head, refs);
return 0;
}
-
- SetPageReferenced(head);
- return 1;
+ return __huge_pt_done(head, refs, nr);
}
static int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
@@ -2071,30 +2085,18 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
unsigned long addr,
pages, nr);
}
- refs = 0;
page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
- do {
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
+ refs = __record_subpages(page, addr, end, pages, *nr);
head = try_get_compound_head(pmd_page(orig), refs);
- if (!head) {
- *nr -= refs;
+ if (!head)
return 0;
- }
if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
- *nr -= refs;
- while (refs--)
- put_page(head);
+ __remove_refs_from_head(head, refs);
return 0;
}
-
- SetPageReferenced(head);
- return 1;
+ return __huge_pt_done(head, refs, nr);
}
static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
@@ -2114,30 +2116,18 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp,
unsigned long addr,
pages, nr);
}
- refs = 0;
page = pud_page(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
- do {
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
+ refs = __record_subpages(page, addr, end, pages, *nr);
head = try_get_compound_head(pud_page(orig), refs);
- if (!head) {
- *nr -= refs;
+ if (!head)
return 0;
- }
if (unlikely(pud_val(orig) !=
[PATCH 17/19] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage
It's good to have basic unit test coverage of the new FOLL_PIN behavior. Fortunately, the gup_benchmark unit test is extremely fast (a few milliseconds), so adding it the the run_vmtests suite is going to cause no noticeable change in running time. So, add two new invocations to run_vmtests: 1) Run gup_benchmark with normal get_user_pages(). 2) Run gup_benchmark with pin_user_pages(). This is much like the first call, except that it sets FOLL_PIN. Running these two in quick succession also provide a visual comparison of the running times, which is convenient. The new invocations are fairly early in the run_vmtests script, because with test suites, it's usually preferable to put the shorter, faster tests first, all other things being equal. Signed-off-by: John Hubbard --- tools/testing/selftests/vm/run_vmtests | 22 ++ 1 file changed, 22 insertions(+) diff --git a/tools/testing/selftests/vm/run_vmtests b/tools/testing/selftests/vm/run_vmtests index 951c507a27f7..93e8dc9a7cad 100755 --- a/tools/testing/selftests/vm/run_vmtests +++ b/tools/testing/selftests/vm/run_vmtests @@ -104,6 +104,28 @@ echo "NOTE: The above hugetlb tests provide minimal coverage. Use" echo " https://github.com/libhugetlbfs/libhugetlbfs.git for" echo " hugetlb regression testing." +echo "" +echo "running 'gup_benchmark -U' (normal/slow gup)" +echo "" +./gup_benchmark -U +if [ $? -ne 0 ]; then + echo "[FAIL]" + exitcode=1 +else + echo "[PASS]" +fi + +echo "--" +echo "running gup_benchmark -c (pin_user_pages)" +echo "--" +./gup_benchmark -c +if [ $? -ne 0 ]; then + echo "[FAIL]" + exitcode=1 +else + echo "[PASS]" +fi + echo "---" echo "running userfaultfd" echo "---" -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/19] goldish_pipe: rename local pin_user_pages() routine
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_pipe.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index cef0133aa47a..7ed2a21a0bac 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -257,12 +257,12 @@ static int goldfish_pipe_error_convert(int status)
}
}
-static int pin_user_pages(unsigned long first_page,
- unsigned long last_page,
- unsigned int last_page_size,
- int is_write,
- struct page *pages[MAX_BUFFERS_PER_COMMAND],
- unsigned int *iter_last_page_size)
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+ int is_write,
+ struct page *pages[MAX_BUFFERS_PER_COMMAND],
+ unsigned int *iter_last_page_size)
{
int ret;
int requested_pages = ((last_page - first_page) >> PAGE_SHIFT) + 1;
@@ -354,9 +354,9 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
- pages_count = pin_user_pages(first_page, last_page,
-last_page_size, is_write,
-pipe->pages, _last_page_size);
+ pages_count = pin_goldfish_pages(first_page, last_page,
+last_page_size, is_write,
+pipe->pages, _last_page_size);
if (pages_count < 0) {
mutex_unlock(>lock);
return pages_count;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/19] Documentation/vm: add pin_user_pages.rst
Document the new pin_user_pages() and related calls
and behavior.
Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
in this documentation. (I've reworded it and expanded on it slightly.)
Cc: Jonathan Corbet
Signed-off-by: John Hubbard
---
Documentation/vm/index.rst | 1 +
Documentation/vm/pin_user_pages.rst | 213
2 files changed, 214 insertions(+)
create mode 100644 Documentation/vm/pin_user_pages.rst
diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst
index e8d943b21cf9..7194efa3554a 100644
--- a/Documentation/vm/index.rst
+++ b/Documentation/vm/index.rst
@@ -44,6 +44,7 @@ descriptions of data structures and algorithms.
page_migration
page_frags
page_owner
+ pin_user_pages
remap_file_pages
slub
split_page_table_lock
diff --git a/Documentation/vm/pin_user_pages.rst
b/Documentation/vm/pin_user_pages.rst
new file mode 100644
index ..7110bca3f188
--- /dev/null
+++ b/Documentation/vm/pin_user_pages.rst
@@ -0,0 +1,213 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+pin_user_pages() and related calls
+
+
+.. contents:: :local:
+
+Overview
+
+
+This document describes the following functions: ::
+
+ pin_user_pages
+ pin_user_pages_fast
+ pin_user_pages_remote
+
+ pin_longterm_pages
+ pin_longterm_pages_fast
+ pin_longterm_pages_remote
+
+Basic description of FOLL_PIN
+=
+
+A new flag for get_user_pages ("gup") has been added: FOLL_PIN. FOLL_PIN has
+significant interactions and interdependencies with FOLL_LONGTERM, so both are
+covered here.
+
+Both FOLL_PIN and FOLL_LONGTERM are "internal" to gup, meaning that neither
+FOLL_PIN nor FOLL_LONGTERM should not appear at the gup call sites. This allows
+the associated wrapper functions (pin_user_pages and others) to set the
correct
+combination of these flags, and to check for problems as well.
+
+FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,
+multiple threads and call sites are free to pin the same struct pages, via both
+FOLL_PIN and FOLL_GET. It's just the call site that needs to choose one or the
+other, not the struct page(s).
+
+The FOLL_PIN implementation is nearly the same as FOLL_GET, except that
FOLL_PIN
+uses a different reference counting technique.
+
+FOLL_PIN is a prerequisite to FOLL_LONGTGERM. Another way of saying that is,
+FOLL_LONGTERM is a specific case, more restrictive case of FOLL_PIN.
+
+Which flags are set by each wrapper
+===
+
+Only FOLL_PIN and FOLL_LONGTERM are covered here. These flags are added to
+whatever flags the caller provides::
+
+ Functiongup flags (FOLL_PIN or FOLL_LONGTERM only)
+ --
+ pin_user_pages FOLL_PIN
+ pin_user_pages_fast FOLL_PIN
+ pin_user_pages_remote FOLL_PIN
+
+ pin_longterm_pages FOLL_PIN | FOLL_LONGTERM
+ pin_longterm_pages_fast FOLL_PIN | FOLL_LONGTERM
+ pin_longterm_pages_remote FOLL_PIN | FOLL_LONGTERM
+
+Tracking dma-pinned pages
+=
+
+Some of the key design constraints, and solutions, for tracking dma-pinned
+pages:
+
+* An actual reference count, per struct page, is required. This is because
+ multiple processes may pin and unpin a page.
+
+* False positives (reporting that a page is dma-pinned, when in fact it is not)
+ are acceptable, but false negatives are not.
+
+* struct page may not be increased in size for this, and all fields are already
+ used.
+
+* Given the above, we can overload the page->_refcount field by using, sort of,
+ the upper bits in that field for a dma-pinned count. "Sort of", means that,
+ rather than dividing page->_refcount into bit fields, we simple add a medium-
+ large value (GUP_PIN_COUNTING_BIAS, initially chosen to be 1024: 10 bits) to
+ page->_refcount. This provides fuzzy behavior: if a page has get_page()
called
+ on it 1024 times, then it will appear to have a single dma-pinned count.
+ And again, that's acceptable.
+
+This also leads to limitations: there are only 32-10==22 bits available for a
+counter that increments 10 bits at a time.
+
+TODO: for 1GB and larger huge pages, this is cutting it close. That's because
+when pin_user_pages() follows such pages, it increments the head page by "1"
+(where "1" used to mean "+1" for get_user_pages(), but now means "+1024" for
+pin_user_pages()) for each tail page. So if you have a 1GB huge page:
+
+* There are 256K (18 bits) worth of 4 KB tail pages.
+* There are 22 bits available to count up via GUP_PIN_COUNTING_BIAS (that is,
+ 10 bits at a time)
+* There are 22 - 18 == 4 bits available to count. Except that there aren't,
+ because you need to allow for a few normal get_page() calls on the head page,
+ as well. Fortunately, the approach of
Re: [PATCH v5 03/12] clk: mediatek: mt8173: switch mmsys to platform device probing
On Fri, Nov 16, 2018 at 12:54 PM wrote:
>
> From: Matthias Brugger
>
> Switch probing for the MMSYS to support invocation to a
> plain paltform device. The driver will be probed by the DRM subsystem.
>
> Signed-off-by: Matthias Brugger
> ---
> +
> +static struct platform_driver clk_mt8173_mm_drv = {
> + .probe = mtk_mmsys_probe,
> + .probe = mtk_mmsys_remove,
Should be .remove?
> + .driver = {
> + .name = "clk-mt8173-mm",
> + },
> +};
> +module_platform_driver(clk_mt8173_mm_drv);
>
> static void __init mtk_vdecsys_init(struct device_node *node)
> {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/19] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via put_user_page*() calls, but
infiniband was already doing that as part of an earlier
commit.
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 5 ++---
drivers/infiniband/core/umem_odp.c | 10 +-
drivers/infiniband/hw/hfi1/user_pages.c | 4 ++--
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 +--
drivers/infiniband/hw/qib/qib_user_pages.c | 8
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c| 9 -
drivers/infiniband/sw/siw/siw_mem.c | 5 ++---
8 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 24244a2f68cc..c5a78d3e674b 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -272,11 +272,10 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
unsigned long addr,
while (npages) {
down_read(>mmap_sem);
- ret = get_user_pages(cur_base,
+ ret = pin_longterm_pages(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
-gup_flags | FOLL_LONGTERM,
-page_list, NULL);
+gup_flags, page_list, NULL);
if (ret < 0) {
up_read(>mmap_sem);
goto umem_release;
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 163ff7ba92b7..a38b67b83db5 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -534,7 +534,7 @@ static int ib_umem_odp_map_dma_single_page(
} else if (umem_odp->page_list[page_index] == page) {
umem_odp->dma_list[page_index] |= access_mask;
} else {
- pr_err("error: got different pages in IB device and from
get_user_pages. IB device page: %p, gup page: %p\n",
+ pr_err("error: got different pages in IB device and from
pin_longterm_pages. IB device page: %p, gup page: %p\n",
umem_odp->page_list[page_index], page);
/* Better remove the mapping now, to prevent any further
* damage. */
@@ -639,11 +639,11 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
*umem_odp, u64 user_virt,
/*
* Note: this might result in redundent page getting. We can
* avoid this by checking dma_list to be 0 before calling
-* get_user_pages. However, this make the code much more
-* complex (and doesn't gain us much performance in most use
-* cases).
+* pin_longterm_pages. However, this makes the code much
+* more complex (and doesn't gain us much performance in most
+* use cases).
*/
- npages = get_user_pages_remote(owning_process, owning_mm,
+ npages = pin_longterm_pages_remote(owning_process, owning_mm,
user_virt, gup_num_pages,
flags, local_page_list, NULL, NULL);
up_read(_mm->mmap_sem);
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index 469acb961fbd..9b55b0a73e29 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -104,9 +104,9 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned
long vaddr, size_t np
bool writable, struct page **pages)
{
int ret;
- unsigned int gup_flags = FOLL_LONGTERM | (writable ? FOLL_WRITE : 0);
+ unsigned int gup_flags = (writable ? FOLL_WRITE : 0);
- ret = get_user_pages_fast(vaddr, npages, gup_flags, pages);
+ ret = pin_longterm_pages_fast(vaddr, npages, gup_flags, pages);
if (ret < 0)
return ret;
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index edccfd6e178f..beec7e4b8a96 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -472,8 +472,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct
mthca_uar *uar,
goto out;
}
- ret = get_user_pages_fast(uaddr & PAGE_MASK, 1,
- FOLL_WRITE | FOLL_LONGTERM, pages);
+ ret = pin_longterm_pages_fast(uaddr & PAGE_MASK, 1, FOLL_WRITE, pages);
if (ret < 0)
goto
[PATCH 01/19] mm/gup: pass flags arg to __gup_device_* functions
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
mm/gup.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 8f236a335ae9..85caf76b3012 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1890,7 +1890,8 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
#if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
static int __gup_device_huge(unsigned long pfn, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
int nr_start = *nr;
struct dev_pagemap *pgmap = NULL;
@@ -1916,13 +1917,14 @@ static int __gup_device_huge(unsigned long pfn,
unsigned long addr,
}
static int __gup_device_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
unsigned long fault_pfn;
int nr_start = *nr;
fault_pfn = pmd_pfn(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
- if (!__gup_device_huge(fault_pfn, addr, end, pages, nr))
+ if (!__gup_device_huge(fault_pfn, addr, end, flags, pages, nr))
return 0;
if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
@@ -1933,13 +1935,14 @@ static int __gup_device_huge_pmd(pmd_t orig, pmd_t
*pmdp, unsigned long addr,
}
static int __gup_device_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
unsigned long fault_pfn;
int nr_start = *nr;
fault_pfn = pud_pfn(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
- if (!__gup_device_huge(fault_pfn, addr, end, pages, nr))
+ if (!__gup_device_huge(fault_pfn, addr, end, flags, pages, nr))
return 0;
if (unlikely(pud_val(orig) != pud_val(*pudp))) {
@@ -1950,14 +1953,16 @@ static int __gup_device_huge_pud(pud_t orig, pud_t
*pudp, unsigned long addr,
}
#else
static int __gup_device_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
BUILD_BUG();
return 0;
}
static int __gup_device_huge_pud(pud_t pud, pud_t *pudp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
BUILD_BUG();
return 0;
@@ -2062,7 +2067,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned
long addr,
if (pmd_devmap(orig)) {
if (unlikely(flags & FOLL_LONGTERM))
return 0;
- return __gup_device_huge_pmd(orig, pmdp, addr, end, pages, nr);
+ return __gup_device_huge_pmd(orig, pmdp, addr, end, flags,
+pages, nr);
}
refs = 0;
@@ -2092,7 +2098,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned
long addr,
}
static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
- unsigned long end, unsigned int flags, struct page **pages, int
*nr)
+ unsigned long end, unsigned int flags,
+ struct page **pages, int *nr)
{
struct page *head, *page;
int refs;
@@ -2103,7 +2110,8 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned
long addr,
if (pud_devmap(orig)) {
if (unlikely(flags & FOLL_LONGTERM))
return 0;
- return __gup_device_huge_pud(orig, pudp, addr, end, pages, nr);
+ return __gup_device_huge_pud(orig, pudp, addr, end, flags,
+pages, nr);
}
refs = 0;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/19] goldish_pipe: convert to pin_user_pages() and put_user_page()
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
Another side effect is that the release code is simplified because
the page[] loop is now in gup.c instead of here, so just delete the
local release_user_pages() entirely, and call
put_user_pages_dirty_lock() directly, instead.
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_pipe.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 7ed2a21a0bac..635a8bc1b480 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -274,7 +274,7 @@ static int pin_goldfish_pages(unsigned long first_page,
*iter_last_page_size = last_page_size;
}
- ret = get_user_pages_fast(first_page, requested_pages,
+ ret = pin_user_pages_fast(first_page, requested_pages,
!is_write ? FOLL_WRITE : 0,
pages);
if (ret <= 0)
@@ -285,18 +285,6 @@ static int pin_goldfish_pages(unsigned long first_page,
return ret;
}
-static void release_user_pages(struct page **pages, int pages_count,
- int is_write, s32 consumed_size)
-{
- int i;
-
- for (i = 0; i < pages_count; i++) {
- if (!is_write && consumed_size > 0)
- set_page_dirty(pages[i]);
- put_page(pages[i]);
- }
-}
-
/* Populate the call parameters, merging adjacent pages together */
static void populate_rw_params(struct page **pages,
int pages_count,
@@ -372,7 +360,8 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
*consumed_size = pipe->command_buffer->rw_params.consumed_size;
- release_user_pages(pipe->pages, pages_count, is_write, *consumed_size);
+ put_user_pages_dirty_lock(pipe->pages, pages_count,
+ !is_write && *consumed_size > 0);
mutex_unlock(>lock);
return 0;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] ARM: shmobile_defconfig: Enable support for panels from EDT
The iwg20d comes with an LCD panel from Emerging Display Technologies Corporation (EDT), therefore enable what's required to support it. Signed-off-by: Fabrizio Castro --- arch/arm/configs/shmobile_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c6c7035..ab416a5 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=y @@ -125,7 +126,9 @@ CONFIG_VIDEO_ADV7604=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_DUMB_VGA_DAC=y +CONFIG_DRM_LVDS_CODEC=y CONFIG_DRM_SII902X=y CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_I2C_ADV7511_AUDIO=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/19] media/v4l2-core: set pages dirty upon releasing DMA buffers
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling set_page_dirty_lock() if the CPU pages
were potentially receiving data from the device.
Cc: Mauro Carvalho Chehab
Signed-off-by: John Hubbard
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 66a6c6c236a7..28262190c3ab 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -349,8 +349,11 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
BUG_ON(dma->sglen);
if (dma->pages) {
- for (i = 0; i < dma->nr_pages; i++)
+ for (i = 0; i < dma->nr_pages; i++) {
+ if (dma->direction == DMA_FROM_DEVICE)
+ set_page_dirty_lock(dma->pages[i]);
put_page(dma->pages[i]);
+ }
kfree(dma->pages);
dma->pages = NULL;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings
* H. Nikolaus Schaller [191018 18:47]: > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt > @@ -0,0 +1,76 @@ > +Imagination PVR/SGX GPU > + > +Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered by > this binding. > + > +Required properties: > +- compatible:Should be one of > + "img,sgx530-121", "img,sgx530", "ti,omap-omap3-sgx530-121"; > + - BeagleBoard ABC, OpenPandora 600MHz > + "img,sgx530-125", "img,sgx530", "ti,omap-omap3-sgx530-125"; > + - BeagleBoard XM, GTA04, OpenPandora 1GHz > + "img,sgx530-125", "img,sgx530", "ti,omap-am3517-sgx530-125"; > + "img,sgx530-125", "img,sgx530", "ti,omap-am335x-sgx530-125"; > + - BeagleBone Black > + "img,sgx540-120", "img,sgx540", "ti,omap-omap4-sgx540-120"; > + - Pandaboard (ES) > + "img,sgx544-112", "img,sgx544", "ti,omap-omap4-sgx544-112"; > + "img,sgx544-116", "img,sgx544", "ti,omap-omap5-sgx544-116"; > + - OMAP5 UEVM, Pyra Handheld > + "img,sgx544-116", "img,sgx544", "ti,omap-dra7-sgx544-116"; FYI, the compatible names above have unnecessary omap in them: "ti,omap-omap3-sgx530-121" should be "ti,omap3-sgx530-121" "ti,omap-am335x-sgx530-125" should be "ti,am335x-sgx530-125"; "ti,omap-dra7-sgx544-116" should be "ti,dra7-sgx544-116" And so on. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/19] vfio, mm: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
This also fixes one or two likely bugs.
1. Change vfio from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
Note that this is a change in behavior, because the
get_user_pages_remote() call was not setting FOLL_LONGTERM, but the
new pin_user_pages_remote() call that replaces it, *is* setting
FOLL_LONGTERM. It is important to set FOLL_LONGTERM, because the
DMA case requires it. Please see the FOLL_PIN documentation in
include/linux/mm.h, and Documentation/pin_user_pages.rst for details.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages().
Note that this effectively changes the code's behavior in
vfio_iommu_type1.c: put_pfn(): it now ultimately calls
set_page_dirty_lock(), instead of set_page_dirty(). This is
probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Cc: Alex Williamson
Signed-off-by: John Hubbard
---
drivers/vfio/vfio_iommu_type1.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index d864277ea16f..795e13f3ef08 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -327,9 +327,8 @@ static int put_pfn(unsigned long pfn, int prot)
{
if (!is_invalid_reserved_pfn(pfn)) {
struct page *page = pfn_to_page(pfn);
- if (prot & IOMMU_WRITE)
- SetPageDirty(page);
- put_page(page);
+
+ put_user_pages_dirty_lock(, 1, prot & IOMMU_WRITE);
return 1;
}
return 0;
@@ -349,11 +348,11 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
down_read(>mmap_sem);
if (mm == current->mm) {
- ret = get_user_pages(vaddr, 1, flags | FOLL_LONGTERM, page,
-vmas);
+ ret = pin_longterm_pages(vaddr, 1, flags, page, vmas);
} else {
- ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
- vmas, NULL);
+ ret = pin_longterm_pages_remote(NULL, mm, vaddr, 1,
+ flags, page, vmas,
+ NULL);
/*
* The lifetime of a vaddr_get_pfn() page pin is
* userspace-controlled. In the fs-dax case this could
@@ -363,7 +362,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
*/
if (ret > 0 && vma_is_fsdax(vmas[0])) {
ret = -EOPNOTSUPP;
- put_page(page[0]);
+ put_user_page(page[0]);
}
}
up_read(>mmap_sem);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/19] net/xdp: set FOLL_PIN via pin_user_pages()
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
Signed-off-by: John Hubbard
---
net/xdp/xdp_umem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 16d5f353163a..4d56dfb1139a 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -285,8 +285,8 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
return -ENOMEM;
down_read(>mm->mmap_sem);
- npgs = get_user_pages(umem->address, umem->npgs,
- gup_flags | FOLL_LONGTERM, >pgs[0], NULL);
+ npgs = pin_longterm_pages(umem->address, umem->npgs, gup_flags,
+ >pgs[0], NULL);
up_read(>mm->mmap_sem);
if (npgs != umem->npgs) {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Unexpected screen flicker during i915 initialization
Hi guys, We have 2 laptops, ASUS Z406MA and Acer TravelMate B118, both powered by the same Intel N5000 GemniLake CPU. On the Acer laptop, the panel will blink once during boot which never happens on the ASUS laptop. It caught my attention and I find the difference between them but I need help for more information, The major difference happens in bxt_sanitize_cdclk() on the following condition check. if (cdctl == expected) /* All well; nothing to sanitize */ return; On the problematic Acer laptop, the value of cdctl is 0x27a while the same cdctl is 0x278 on ASUS machine. Due to the 0x27a is not equal to the expected value 0x278 so it needs to be sanitized by assigning -1 to dev_priv->cdclk.hw.vco. Then the consequent bxt_set_cdclk() will force the full PLL disable and enable. And that's the flicker (blink) we observed during boot. Although I can't find the definition about the BIT(2) of CDCLK_CTL which cause this difference. Can anyone suggest what exactly the problem is and how should we deal with it? Thanks. Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 38/46] video: backlight: tosa: use gpio lookup table
Arnd Bergmann writes: > The driver should not require a machine specific header. Change > it to pass the gpio line through a lookup table, and move the > timing generator definitions into the drivers itself. > > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Bartlomiej Zolnierkiewicz > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Arnd Bergmann > > --- > I'm not overly confident that I got the correct device names > for the lookup table, it would be good if someone could > double-check. Ah the I2C and SPI devices querrying GPIOs ... unless someone does an actual test, this will probably be very regression prone ... Anyway : Acked-by: Robert Jarzmik Cheers. -- Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/19] vfio, mm: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
On 10/30/19 3:49 PM, John Hubbard wrote:
> This also fixes one or two likely bugs.
Well, actually just one...
>
> 1. Change vfio from get_user_pages(FOLL_LONGTERM), to
> pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
>
> Note that this is a change in behavior, because the
> get_user_pages_remote() call was not setting FOLL_LONGTERM, but the
> new pin_user_pages_remote() call that replaces it, *is* setting
> FOLL_LONGTERM. It is important to set FOLL_LONGTERM, because the
> DMA case requires it. Please see the FOLL_PIN documentation in
> include/linux/mm.h, and Documentation/pin_user_pages.rst for details.
Correction: the above comment is stale and wrong. I wrote it before
getting further into the details, and the patch doesn't do this.
Instead, it keeps exactly the old behavior: pin_longterm_pages_remote()
is careful to avoid setting FOLL_LONGTERM. Instead of setting that flag,
it drops in a "TODO" comment nearby. :)
I'll update the commit description in the next version of the series.
thanks,
John Hubbard
NVIDIA
>
> 2. Because all FOLL_PIN-acquired pages must be released via
> put_user_page(), also convert the put_page() call over to
> put_user_pages().
>
> Note that this effectively changes the code's behavior in
> vfio_iommu_type1.c: put_pfn(): it now ultimately calls
> set_page_dirty_lock(), instead of set_page_dirty(). This is
> probably more accurate.
>
> As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
> dealing with a file backed page where we have reference on the inode it
> hangs off." [1]
>
> [1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
>
> Cc: Alex Williamson
> Signed-off-by: John Hubbard
> ---
> drivers/vfio/vfio_iommu_type1.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index d864277ea16f..795e13f3ef08 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -327,9 +327,8 @@ static int put_pfn(unsigned long pfn, int prot)
> {
> if (!is_invalid_reserved_pfn(pfn)) {
> struct page *page = pfn_to_page(pfn);
> - if (prot & IOMMU_WRITE)
> - SetPageDirty(page);
> - put_page(page);
> +
> + put_user_pages_dirty_lock(, 1, prot & IOMMU_WRITE);
> return 1;
> }
> return 0;
> @@ -349,11 +348,11 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
>
> down_read(>mmap_sem);
> if (mm == current->mm) {
> - ret = get_user_pages(vaddr, 1, flags | FOLL_LONGTERM, page,
> - vmas);
> + ret = pin_longterm_pages(vaddr, 1, flags, page, vmas);
> } else {
> - ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
> - vmas, NULL);
> + ret = pin_longterm_pages_remote(NULL, mm, vaddr, 1,
> + flags, page, vmas,
> + NULL);
> /*
>* The lifetime of a vaddr_get_pfn() page pin is
>* userspace-controlled. In the fs-dax case this could
> @@ -363,7 +362,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
> long vaddr,
>*/
> if (ret > 0 && vma_is_fsdax(vmas[0])) {
> ret = -EOPNOTSUPP;
> - put_page(page[0]);
> + put_user_page(page[0]);
> }
> }
> up_read(>mmap_sem);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/19] fs/io_uring: set FOLL_PIN via pin_user_pages()
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
Signed-off-by: John Hubbard
---
fs/io_uring.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index a30c4f622cb3..d3924b1760eb 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -3431,9 +3431,8 @@ static int io_sqe_buffer_register(struct io_ring_ctx
*ctx, void __user *arg,
ret = 0;
down_read(>mm->mmap_sem);
- pret = get_user_pages(ubuf, nr_pages,
- FOLL_WRITE | FOLL_LONGTERM,
- pages, vmas);
+ pret = pin_longterm_pages(ubuf, nr_pages, FOLL_WRITE, pages,
+ vmas);
if (pret == nr_pages) {
/* don't support file backed memory */
for (j = 0; j < nr_pages; j++) {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
In an effort to repurpose lvds-encoder.c to also serve the
function of LVDS decoders, we ended up defining a new "generic"
compatible string, therefore adapt the dt-bindings to fit the
new purpose.
Signed-off-by: Fabrizio Castro
---
.../bindings/display/bridge/lvds-codec.txt | 100 +
.../bindings/display/bridge/lvds-transmitter.txt | 66 --
2 files changed, 100 insertions(+), 66 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
new file mode 100644
index 000..45fd81c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.txt
@@ -0,0 +1,100 @@
+Trasnparent LVDS encoders and LVDS decoders
+---
+
+This binding supports transparent LVDS encoders and LVDS decoders that don't
+require any configuration.
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This binding targets devices compatible with the following
+specifications only.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Those devices have been marketed under the FPD-Link and FlatLink brand names
+among others.
+
+
+Required properties:
+
+- compatible: Must be "lvds-encoder" for LVDS encoders or "lvds-decoder" for
+ LVDS decoders.
+
+ Any encoder compatible with this generic binding, but with additional
+ properties not listed here, must list a device specific compatible first
+ followed by the generic compatible.
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+For LVDS encoders:
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+For LVDS decoders:
+- Video port 0 for LVDS input
+- Video port 1 for parallel output
+
+
+LVDS encoder example
+
+
+lvds-encoder {
+ compatible = "lvds-encoder";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+ remote-endpoint = <_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
+
+LVDS decoder example
+
+
+lvds-decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+ remote-endpoint = <_out_lvds>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
+};
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
deleted file mode 100644
index 60091db..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Parallel to LVDS Encoder
-
-
-This binding supports the parallel to LVDS encoders that don't require any
-configuration.
-
-LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
-incompatible data link layers have been used over time to transmit image data
-to LVDS panels. This binding targets devices compatible with the following
-specifications only.
-
-[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
-1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
-[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
-Semiconductor
-[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
-Electronics Standards Association (VESA)
-
-Those devices have been marketed under the FPD-Link and FlatLink brand names
-among others.
-
-
-Required properties:
-
[PATCH 16/19] mm/gup_benchmark: support pin_user_pages() and related calls
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new corresponding pin_*() functions:
* pin_user_pages(): via the '-c' command line option
* pin_longterm_pages(): via the '-b' command line option
* pin_user_pages_fast(): via the '-a' command line option
Also, add an option for clarity: '-u' for what is now (still) the
default choice: get_user_pages_fast().
Also, for the three commands that set FOLL_PIN, verify that the pages
really are dma-pinned, via the new is_dma_pinned() routine.
Those commands are:
PIN_FAST_BENCHMARK : calls pin_user_pages_fast()
PIN_LONGTERM_BENCHMARK : calls pin_longterm_pages()
PIN_BENCHMARK : calls pin_user_pages()
In between the calls to pin_*() and put_user_pages(),
check each page: if page_dma_pinned() returns false, then
WARN and return.
Do this outside of the benchmark timestamps, so that it doesn't
affect reported times.
Signed-off-by: John Hubbard
---
mm/gup_benchmark.c | 74 --
tools/testing/selftests/vm/gup_benchmark.c | 23 ++-
2 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
index 7dd602d7f8db..2bb0f5df4803 100644
--- a/mm/gup_benchmark.c
+++ b/mm/gup_benchmark.c
@@ -8,6 +8,9 @@
#define GUP_FAST_BENCHMARK _IOWR('g', 1, struct gup_benchmark)
#define GUP_LONGTERM_BENCHMARK _IOWR('g', 2, struct gup_benchmark)
#define GUP_BENCHMARK _IOWR('g', 3, struct gup_benchmark)
+#define PIN_FAST_BENCHMARK _IOWR('g', 4, struct gup_benchmark)
+#define PIN_LONGTERM_BENCHMARK _IOWR('g', 5, struct gup_benchmark)
+#define PIN_BENCHMARK _IOWR('g', 6, struct gup_benchmark)
struct gup_benchmark {
__u64 get_delta_usec;
@@ -19,6 +22,44 @@ struct gup_benchmark {
__u64 expansion[10];/* For future use */
};
+static void put_back_pages(int cmd, struct page **pages, unsigned long
nr_pages)
+{
+ int i;
+
+ switch (cmd) {
+ case GUP_FAST_BENCHMARK:
+ case GUP_LONGTERM_BENCHMARK:
+ case GUP_BENCHMARK:
+ for (i = 0; i < nr_pages; i++)
+ put_page(pages[i]);
+ break;
+
+ case PIN_FAST_BENCHMARK:
+ case PIN_LONGTERM_BENCHMARK:
+ case PIN_BENCHMARK:
+ put_user_pages(pages, nr_pages);
+ break;
+ }
+}
+
+static void verify_dma_pinned(int cmd, struct page **pages,
+ unsigned long nr_pages)
+{
+ int i;
+
+ switch (cmd) {
+ case PIN_FAST_BENCHMARK:
+ case PIN_LONGTERM_BENCHMARK:
+ case PIN_BENCHMARK:
+ for (i = 0; i < nr_pages; i++) {
+ if (WARN(!page_dma_pinned(pages[i]),
+"pages[%d] is NOT dma-pinned\n", i))
+ break;
+ }
+ break;
+ }
+}
+
static int __gup_benchmark_ioctl(unsigned int cmd,
struct gup_benchmark *gup)
{
@@ -62,6 +103,19 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
nr = get_user_pages(addr, nr, gup->flags & 1, pages + i,
NULL);
break;
+ case PIN_FAST_BENCHMARK:
+ nr = pin_user_pages_fast(addr, nr, gup->flags & 1,
+pages + i);
+ break;
+ case PIN_LONGTERM_BENCHMARK:
+ nr = pin_longterm_pages(addr, nr,
+ (gup->flags & 1),
+ pages + i, NULL);
+ break;
+ case PIN_BENCHMARK:
+ nr = pin_user_pages(addr, nr, gup->flags & 1, pages + i,
+ NULL);
+ break;
default:
return -1;
}
@@ -72,15 +126,22 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
}
end_time = ktime_get();
+ /* Shifting the meaning of nr_pages: now it is actual number pinned: */
+ nr_pages = i;
+
gup->get_delta_usec = ktime_us_delta(end_time, start_time);
gup->size = addr - gup->addr;
+ /*
+* Take an un-benchmark-timed moment to verify DMA pinned
+* state: print a warning if any non-dma-pinned pages are found:
+*/
+ verify_dma_pinned(cmd, pages, nr_pages);
+
start_time = ktime_get();
- for (i = 0; i < nr_pages; i++) {
- if (!pages[i])
- break;
- put_page(pages[i]);
- }
+
+ put_back_pages(cmd, pages, nr_pages);
+
Re: [PATCH -next] gpu: host1x: Fix compile test failure
30.10.2019 16:54, YueHaibing пишет:
> If IOMMU_SUPPORT is not set, but IOMMU_IOVA is m and
> COMPILE_TEST is y, building fails:
>
> drivers/gpu/host1x/dev.o: In function `host1x_remove':
> dev.c:(.text+0x624): undefined reference to `put_iova_domain'
> dev.c:(.text+0x624): relocation truncated to fit: R_AARCH64_CALL26 against
> undefined symbol `put_iova_domain'
> dev.c:(.text+0x62c): undefined reference to `iova_cache_put'
> dev.c:(.text+0x62c): relocation truncated to fit: R_AARCH64_CALL26 against
> undefined symbol `iova_cache_put'
>
> Select IOMMU_IOVA while COMPILE_TEST is set to fix this.
>
> Reported-by: Hulk Robot
> Fixes: 52499a6ad2ae ("gpu: host1x: select IOMMU_IOVA")
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/host1x/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
> index cf987a3..354232d 100644
> --- a/drivers/gpu/host1x/Kconfig
> +++ b/drivers/gpu/host1x/Kconfig
> @@ -2,7 +2,7 @@
> config TEGRA_HOST1X
> tristate "NVIDIA Tegra host1x driver"
> depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
> - select IOMMU_IOVA if IOMMU_SUPPORT
> + select IOMMU_IOVA if (IOMMU_SUPPORT || COMPILE_TEST)
> help
> Driver for the NVIDIA Tegra host1x hardware.
>
>
It should be better to unconditionally select IOMMU_IOVA here.
The same could be done for drivers/staging/media/tegra-vde/ and
drivers/gpu/host1x/, please see [1].
[1] https://lore.kernel.org/linux-iommu/20190829154902.GC19842@ulmo/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] memory: tegra: Add gr2d and gr3d to DRM IOMMU group
28.10.2019 15:37, Thierry Reding пишет:
> From: Thierry Reding
>
> All of the devices making up the Tegra DRM device want to share a single
> IOMMU domain. Put them into a single group to allow them to do that.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/memory/tegra/tegra114.c | 10 ++
> drivers/memory/tegra/tegra124.c | 8 +---
> drivers/memory/tegra/tegra30.c | 11 +++
> 3 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/memory/tegra/tegra114.c b/drivers/memory/tegra/tegra114.c
> index ac8351b5beeb..48ef01c3ff90 100644
> --- a/drivers/memory/tegra/tegra114.c
> +++ b/drivers/memory/tegra/tegra114.c
> @@ -909,16 +909,18 @@ static const struct tegra_smmu_swgroup
> tegra114_swgroups[] = {
> { .name = "tsec", .swgroup = TEGRA_SWGROUP_TSEC, .reg = 0x294
> },
> };
>
> -static const unsigned int tegra114_group_display[] = {
> +static const unsigned int tegra114_group_drm[] = {
> TEGRA_SWGROUP_DC,
> TEGRA_SWGROUP_DCB,
> + TEGRA_SWGROUP_G2,
> + TEGRA_SWGROUP_NV,
> };
>
> static const struct tegra_smmu_group_soc tegra114_groups[] = {
> {
> - .name = "display",
> - .swgroups = tegra114_group_display,
> - .num_swgroups = ARRAY_SIZE(tegra114_group_display),
> + .name = "drm",
> + .swgroups = tegra114_group_drm,
> + .num_swgroups = ARRAY_SIZE(tegra114_group_drm),
> },
> };
>
> diff --git a/drivers/memory/tegra/tegra124.c b/drivers/memory/tegra/tegra124.c
> index 5d0ccb2be206..62b30b1b9677 100644
> --- a/drivers/memory/tegra/tegra124.c
> +++ b/drivers/memory/tegra/tegra124.c
> @@ -974,16 +974,18 @@ static const struct tegra_smmu_swgroup
> tegra124_swgroups[] = {
> { .name = "vi",.swgroup = TEGRA_SWGROUP_VI,.reg = 0x280
> },
> };
>
> -static const unsigned int tegra124_group_display[] = {
> +static const unsigned int tegra124_group_drm[] = {
> TEGRA_SWGROUP_DC,
> TEGRA_SWGROUP_DCB,
> + TEGRA_SWGROUP_GPU,
> + TEGRA_SWGROUP_VIC,
> };
>
> static const struct tegra_smmu_group_soc tegra124_groups[] = {
> {
> .name = "display",
> - .swgroups = tegra124_group_display,
> - .num_swgroups = ARRAY_SIZE(tegra124_group_display),
> + .swgroups = tegra124_group_drm,
> + .num_swgroups = ARRAY_SIZE(tegra124_group_drm),
> },
The "display" -> "drm" group's renaming is missed for T124.
[snip]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/19] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of process_vm_rw_single_vec().
Signed-off-by: John Hubbard
---
mm/process_vm_access.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index 357aa7bef6c0..fd20ab675b85 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -42,12 +42,11 @@ static int process_vm_rw_pages(struct page **pages,
if (copy > len)
copy = len;
- if (vm_write) {
+ if (vm_write)
copied = copy_page_from_iter(page, offset, copy, iter);
- set_page_dirty_lock(page);
- } else {
+ else
copied = copy_page_to_iter(page, offset, copy, iter);
- }
+
len -= copied;
if (copied < copy && iov_iter_count(iter))
return -EFAULT;
@@ -96,7 +95,7 @@ static int process_vm_rw_single_vec(unsigned long addr,
flags |= FOLL_WRITE;
while (!rc && nr_pages && iov_iter_count(iter)) {
- int pages = min(nr_pages, max_pages_per_loop);
+ int pinned_pages = min(nr_pages, max_pages_per_loop);
int locked = 1;
size_t bytes;
@@ -106,14 +105,15 @@ static int process_vm_rw_single_vec(unsigned long addr,
* current/current->mm
*/
down_read(>mmap_sem);
- pages = get_user_pages_remote(task, mm, pa, pages, flags,
- process_pages, NULL, );
+ pinned_pages = pin_user_pages_remote(task, mm, pa, pinned_pages,
+flags, process_pages,
+NULL, );
if (locked)
up_read(>mmap_sem);
- if (pages <= 0)
+ if (pinned_pages <= 0)
return -EFAULT;
- bytes = pages * PAGE_SIZE - start_offset;
+ bytes = pinned_pages * PAGE_SIZE - start_offset;
if (bytes > len)
bytes = len;
@@ -122,10 +122,12 @@ static int process_vm_rw_single_vec(unsigned long addr,
vm_write);
len -= bytes;
start_offset = 0;
- nr_pages -= pages;
- pa += pages * PAGE_SIZE;
- while (pages)
- put_page(process_pages[--pages]);
+ nr_pages -= pinned_pages;
+ pa += pinned_pages * PAGE_SIZE;
+
+ /* If vm_write is set, the pages need to be made dirty: */
+ put_user_pages_dirty_lock(process_pages, pinned_pages,
+ vm_write);
}
return rc;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings
Hi, > Am 30.10.2019 um 17:16 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [191018 18:47]: >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt >> @@ -0,0 +1,76 @@ >> +Imagination PVR/SGX GPU >> + >> +Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered >> by this binding. >> + >> +Required properties: >> +- compatible: Should be one of >> +"img,sgx530-121", "img,sgx530", "ti,omap-omap3-sgx530-121"; >> + - BeagleBoard ABC, OpenPandora 600MHz >> +"img,sgx530-125", "img,sgx530", "ti,omap-omap3-sgx530-125"; >> + - BeagleBoard XM, GTA04, OpenPandora 1GHz >> +"img,sgx530-125", "img,sgx530", "ti,omap-am3517-sgx530-125"; >> +"img,sgx530-125", "img,sgx530", "ti,omap-am335x-sgx530-125"; >> + - BeagleBone Black >> +"img,sgx540-120", "img,sgx540", "ti,omap-omap4-sgx540-120"; >> + - Pandaboard (ES) >> +"img,sgx544-112", "img,sgx544", "ti,omap-omap4-sgx544-112"; >> +"img,sgx544-116", "img,sgx544", "ti,omap-omap5-sgx544-116"; >> + - OMAP5 UEVM, Pyra Handheld >> +"img,sgx544-116", "img,sgx544", "ti,omap-dra7-sgx544-116"; > > FYI, the compatible names above have unnecessary omap in them: > > "ti,omap-omap3-sgx530-121" should be "ti,omap3-sgx530-121" > "ti,omap-am335x-sgx530-125" should be "ti,am335x-sgx530-125"; > "ti,omap-dra7-sgx544-116" should be "ti,dra7-sgx544-116" > > And so on. Yes, Rob already noted a while ago and our latest private code has it fixed. There is no progress towards a v2 since I am still fighting with the new yaml format he also requested... BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/19] mm/gup: introduce pin_user_pages*() and FOLL_PIN
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
basically documented. (An upcoming patch provides more extensive
documentation.) The second set (pin_longterm*) also sets
FOLL_LONGTERM:
pin_user_pages()
pin_user_pages_remote()
pin_user_pages_fast()
pin_longterm_pages()
pin_longterm_pages_remote()
pin_longterm_pages_fast()
All pages that are pinned via the above calls, must be unpinned via
put_user_page().
The underlying rules are:
* These are gup-internal flags, so the call sites should not directly
set FOLL_PIN nor FOLL_LONGTERM. That behavior is enforced with
assertions, for the new FOLL_PIN flag. However, for the pre-existing
FOLL_LONGTERM flag, which has some call sites that still directly
set FOLL_LONGTERM, there is no assertion yet.
* Call sites that want to indicate that they are going to do DirectIO
("DIO") or something with similar characteristics, should call a
get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
will:
* Start with "pin_user_pages" instead of "get_user_pages". That
makes it easy to find and audit the call sites.
* Set FOLL_PIN
* For pages that are received via FOLL_PIN, those pages must be returned
via put_user_page().
Signed-off-by: John Hubbard
---
include/linux/mm.h | 53 -
mm/gup.c | 284 +
2 files changed, 311 insertions(+), 26 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index cc292273e6ba..62c838a3e6c7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1526,9 +1526,23 @@ long get_user_pages_remote(struct task_struct *tsk,
struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas, int *locked);
+long pin_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas, int *locked);
+long pin_longterm_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas, int *locked);
long get_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas);
+long pin_user_pages(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas);
+long pin_longterm_pages(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas);
long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages, int *locked);
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
@@ -1536,6 +1550,10 @@ long get_user_pages_unlocked(unsigned long start,
unsigned long nr_pages,
int get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages);
+int pin_user_pages_fast(unsigned long start, int nr_pages,
+ unsigned int gup_flags, struct page **pages);
+int pin_longterm_pages_fast(unsigned long start, int nr_pages,
+ unsigned int gup_flags, struct page **pages);
int account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc);
int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
@@ -2594,13 +2612,15 @@ struct page *follow_page(struct vm_area_struct *vma,
unsigned long address,
#define FOLL_ANON 0x8000 /* don't do file mappings */
#define FOLL_LONGTERM 0x1 /* mapping lifetime is indefinite: see below */
#define FOLL_SPLIT_PMD 0x2 /* split huge pmd before returning */
+#define FOLL_PIN 0x4 /* pages must be released via put_user_page() */
/*
- * NOTE on FOLL_LONGTERM:
+ * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
+ * other. Here is what they mean, and how to use them:
*
* FOLL_LONGTERM indicates that the page will be held for an indefinite time
- * period _often_ under userspace control. This is contrasted with
- * iov_iter_get_pages() where usages which are transient.
+ * period _often_ under userspace control. This is in contrast to
+ * iov_iter_get_pages(), where usages which are transient.
*
* FIXME: For
[PATCH 15/19] powerpc: book3s64: convert to pin_longterm_pages() and put_user_page()
1. Convert from get_user_pages(FOLL_LONGTERM) to pin_longterm_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
3. Release each page in mem->hpages[] (instead of mem->hpas[]), because
that is the array that pin_longterm_pages() filled in. This is more
accurate and should be a little safer from a maintenance point of
view.
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Signed-off-by: John Hubbard
---
arch/powerpc/mm/book3s64/iommu_api.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index 56cc84520577..69d79cb50d47 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -103,9 +103,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
unsigned long ua,
for (entry = 0; entry < entries; entry += chunk) {
unsigned long n = min(entries - entry, chunk);
- ret = get_user_pages(ua + (entry << PAGE_SHIFT), n,
- FOLL_WRITE | FOLL_LONGTERM,
- mem->hpages + entry, NULL);
+ ret = pin_longterm_pages(ua + (entry << PAGE_SHIFT), n,
+FOLL_WRITE, mem->hpages + entry, NULL);
if (ret == n) {
pinned += n;
continue;
@@ -167,9 +166,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
unsigned long ua,
return 0;
free_exit:
- /* free the reference taken */
- for (i = 0; i < pinned; i++)
- put_page(mem->hpages[i]);
+ /* free the references taken */
+ put_user_pages(mem->hpages, pinned);
vfree(mem->hpas);
kfree(mem);
@@ -212,10 +210,9 @@ static void mm_iommu_unpin(struct
mm_iommu_table_group_mem_t *mem)
if (!page)
continue;
- if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
- SetPageDirty(page);
+ put_user_pages_dirty_lock(>hpages[i], 1,
+ MM_IOMMU_TABLE_GROUP_PAGE_DIRTY);
- put_page(page);
mem->hpas[i] = 0;
}
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: potential information leak in do_fb_ioctl()
On Wed, Oct 30, 2019 at 02:26:21PM -0500, Eric W. Biederman wrote:
> Andrea Righi writes:
>
> > On Tue, Oct 29, 2019 at 02:02:11PM -0500, Eric W. Biederman wrote:
> >> Dan Carpenter writes:
> >>
> >> > The "fix" struct has a 2 byte hole after ->ywrapstep and the
> >> > "fix = info->fix;" assignment doesn't necessarily clear it. It depends
> >> > on the compiler.
> >> >
> >> > Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex
> >> > held")
> >> > Signed-off-by: Dan Carpenter
> >> > ---
> >> > I have 13 more similar places to patch... I'm not totally sure I
> >> > understand all the issues involved.
> >>
> >> What I have done in a similar situation with struct siginfo, is that
> >> where the structure first appears I have initialized it with memset,
> >> and then field by field.
> >>
> >> Then when the structure is copied I copy the structure with memcpy.
> >>
> >> That ensures all of the bytes in the original structure are initialized
> >> and that all of the bytes are copied.
> >>
> >> The goal is to avoid memory that has values of the previous users of
> >> that memory region from leaking to userspace. Which depending on who
> >> the previous user of that memory region is could tell userspace
> >> information about what the kernel is doing that it should not be allowed
> >> to find out.
> >>
> >> I tried to trace through where "info" and thus presumably "info->fix" is
> >> coming from and only made it as far as register_framebuffer. Given
> >> that I suspect a local memset, and then a field by field copy right
> >> before copy_to_user might be a sound solution. But ick. That is a lot
> >> of fields to copy.
> >
> > I know it might sound quite inefficient, but what about making struct
> > fb_fix_screeninfo __packed?
> >
> > This doesn't solve other potential similar issues, but for this
> > particular case it could be a reasonable and simple fix.
>
> It is part of the user space ABI. As such you can't move the fields.
>
> Eric
Oh, that's right! Then memset() + memcpy() is probably the best option,
since copying all those fields one by one looks quite ugly to me...
-Andrea
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/19] mm/gup: track FOLL_PIN pages
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Pages that have been pinned via FOLL_PIN are identifiable via a
new function call:
bool page_dma_pinned(struct page *page);
What to do in response to encountering such a page, is left to later
patchsets. There is discussion about this in [1].
This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
This also has a couple of trivial, non-functional change fixes to
try_get_compound_head(). That function got moved to the top of the
file.
This includes the following fix from Ira Weiny:
DAX requires detection of a page crossing to a ref count of 1. Fix this
for GUP pages by introducing put_devmap_managed_user_page() which
accounts for GUP_PIN_COUNTING_BIAS now used by GUP.
[1] https://lwn.net/Articles/784574/ "Some slow progress on
get_user_pages()"
Suggested-by: Jan Kara
Suggested-by: Jérôme Glisse
Signed-off-by: Ira Weiny
Signed-off-by: John Hubbard
---
include/linux/mm.h | 80 +++
include/linux/mmzone.h | 2 +
include/linux/page_ref.h | 10 ++
mm/gup.c | 213 +++
mm/huge_memory.c | 32 +-
mm/hugetlb.c | 28 -
mm/memremap.c| 4 +-
mm/vmstat.c | 2 +
8 files changed, 300 insertions(+), 71 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 62c838a3e6c7..882fda919c81 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -972,9 +972,10 @@ static inline bool is_zone_device_page(const struct page
*page)
#endif
#ifdef CONFIG_DEV_PAGEMAP_OPS
-void __put_devmap_managed_page(struct page *page);
+void __put_devmap_managed_page(struct page *page, int count);
DECLARE_STATIC_KEY_FALSE(devmap_managed_key);
-static inline bool put_devmap_managed_page(struct page *page)
+
+static inline bool page_is_devmap_managed(struct page *page)
{
if (!static_branch_unlikely(_managed_key))
return false;
@@ -983,7 +984,6 @@ static inline bool put_devmap_managed_page(struct page
*page)
switch (page->pgmap->type) {
case MEMORY_DEVICE_PRIVATE:
case MEMORY_DEVICE_FS_DAX:
- __put_devmap_managed_page(page);
return true;
default:
break;
@@ -991,6 +991,19 @@ static inline bool put_devmap_managed_page(struct page
*page)
return false;
}
+static inline bool put_devmap_managed_page(struct page *page)
+{
+ bool is_devmap = page_is_devmap_managed(page);
+
+ if (is_devmap) {
+ int count = page_ref_dec_return(page);
+
+ __put_devmap_managed_page(page, count);
+ }
+
+ return is_devmap;
+}
+
#else /* CONFIG_DEV_PAGEMAP_OPS */
static inline bool put_devmap_managed_page(struct page *page)
{
@@ -1038,6 +1051,8 @@ static inline __must_check bool try_get_page(struct page
*page)
return true;
}
+__must_check bool user_page_ref_inc(struct page *page);
+
static inline void put_page(struct page *page)
{
page = compound_head(page);
@@ -1055,31 +1070,56 @@ static inline void put_page(struct page *page)
__put_page(page);
}
-/**
- * put_user_page() - release a gup-pinned page
- * @page:pointer to page to be released
+/*
+ * GUP_PIN_COUNTING_BIAS, and the associated functions that use it, overload
+ * the page's refcount so that two separate items are tracked: the original
page
+ * reference count, and also a new count of how many get_user_pages() calls
were
+ * made against the page. ("gup-pinned" is another term for the latter).
+ *
+ * With this scheme, get_user_pages() becomes special: such pages are marked
+ * as distinct from normal pages. As such, the new put_user_page() call (and
+ * its variants) must be used in order to release gup-pinned pages.
+ *
+ * Choice of value:
*
- * Pages that were pinned via get_user_pages*() must be released via
- * either put_user_page(), or one of the put_user_pages*() routines
- * below. This is so that eventually, pages that are pinned via
- * get_user_pages*() can be separately tracked and uniquely handled. In
- * particular, interactions with RDMA and filesystems need special
- * handling.
+ * By making GUP_PIN_COUNTING_BIAS a power of two, debugging of page reference
+ * counts with respect to get_user_pages() and put_user_page() becomes simpler,
+ * due to the fact that adding an even power of two to the page refcount has
+ * the effect of using only the upper N bits, for the code that counts up using
+ * the bias value. This means that the lower bits are left for the exclusive
+ * use of the original code that increments and decrements by one (or at least,
+ * by much smaller values than the bias value).
*
- *
