[Bug 110483] Power management
https://bugs.freedesktop.org/show_bug.cgi?id=110483 Daniel Stone changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED Group||spam --- Comment #3 from Daniel Stone --- Just more spam from children. -- 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 v1 4/4] drm/mediatek: fix possible_crtcs
Hi Frank,
On Tue, 2019-04-16 at 16:58 +0200, Frank Wunderlich wrote:
> From: Ryder Lee
>
> without this patch there is purple stretched font on fbconsole
>
> source: http://forum.banana-pi.org/t/kernel-4-19-rc1-for-testers/6618/52
>
> Signed-off-by: Ryder Lee
> Tested-by: Frank Wunderlich
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 5d333138f913..c171b01f77e0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device
> *master, void *data)
> drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
>
> /* Currently DPI0 is fixed to be driven by OVL1 */
> - dpi->encoder.possible_crtcs = BIT(1);
> + dpi->encoder.possible_crtcs = BIT(0)|BIT(1);
This patch is not a good solution.
The solution should find the components in the arrays to determine the
correct crtcs, not just set all available bits. You see the problem
because the hardware connections(BIT0) is not the same as driver
reports(BIT1 changed to BIT0|BIT1, but BIT1 is not supported).
Regards,
yt.shen
>
> ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL);
> if (ret) {
> --
> 2.17.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110488] [1042669.035207] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, signaled seq=4, emitted seq=8
https://bugs.freedesktop.org/show_bug.cgi?id=110488 Bug ID: 110488 Summary: [1042669.035207] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, signaled seq=4, emitted seq=8 Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: baopeng88_...@163.com Created attachment 144066 --> https://bugs.freedesktop.org/attachment.cgi?id=144066&action=edit umr info We use vce to encode and then hang up dmesg as follows: [1042669.035207] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, signaled seq=4, emitted seq=8 [1042669.035211] [drm] GPU recovery disabled. and we use umr to analyze the vce: vce0 is 100% and vce1 is 0%. can anyone help me? thank you. -- 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] android: libdrm_platform: add liblog shared dependency
Hi, I can try replacing with , but I would like to get confirmation from Chih-Wei, the original author of [1] Mauro [1] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=9d2a4cc3a16b5b464fda0a0c321dd1f5acadaa33 On Mon, Mar 18, 2019 at 2:32 PM Tapani Pälli wrote: > > > > On 3/18/19 3:25 PM, Robert Foss wrote: > > Hey, > > > > On 3/18/19 2:11 PM, Mauro Rossi wrote: > >> Hi, > >> > >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss > >> wrote: > >>> > >>> Hey Mauro, > >>> > >>> On 3/18/19 9:38 AM, Mauro Rossi wrote: > Hi Robert, > > On Mon, Mar 18, 2019 at 9:21 AM Robert Foss > wrote: > > > > On a second note, this does not apply on libdrm/master due > > to: > > > > LOCAL_SHARED_LIBRARIES := \ > > libcutils > > Sorry, we have an additional Google patch, not present in libdrm/master > that adds libdrm_platform module, but it is for a specific Google > issue. [1] > > However with libdrm module we have both liblog and libcutils shared > dependencies > > [1] > http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e > > >>> > >>> Do you know if [1] causes incompatibility issues with earlier android > >>> verions? > >>> If not I would suggest upstreaming it too. > >> > >> I used those patches to build with nougat-x86 and there was no issue. > >> > >> To be precise I did a double rookie mistake, because __android_log_vprint > >> not used in upstream libdrm and libdrm_platform not used either. > >> > >> Now starting from my mistakes, let's see if there is anything useful > >> to libdrm project > >> > >> In our builds Chih-Wei Huang said that libdrm_platform is not used, > >> meaning not added to packages list, > >> however with oreo-x86 the build error appeared and the liblog dependency. > >> > >> __android_log_vprint is used with __ANDROID__ braces > >> in a special patch [2] by Chih-Wei Huang which adds capability to > >> print logs > >> in logcat > >> > >> If it's not too invasive in libdrm, it could be useful. > >> Cheers > >> Mauro > >> > >> [2] > >> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9 > >> > > > > [2] Seems like a good idea to me. > > Logcat really is the only intended path for logging on Android, and > > redirecting our logs there does make sense to me. > > > > But, I'm not sure about I like the way [2] disregards log-levels in > > drmMsg(). > > > > Yeah, I think it's a good idea. I see that in mesa we include > "android/log.h", not "log/log.h", will need to make sure we get that > correctly, maybe older versions did "log/log.h"? > > // Tapani ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] android: libdrm_platform: add liblog shared dependency
Hi Emil, Chih-Wei, what about the series of latest three patches we have in oreo-x86 branch? [oreo-x86 branch] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=history;f=Android.mk;h=f832b24e99007c75ce3a8d9a3ece34d4e475e957;hb=refs/heads/oreo-x86 My doubt is about the one "android: make libdrm*.so available to the vendor partition", should we keep it (and send to mesa/drm) so that we will simply have our x86 branches aligned to mesa/drm, or should we skip it in both cases? Once this is assessed I will either send the series of 3 or just the android logging one. Mauro Mauro On Wed, Apr 17, 2019 at 7:50 PM Emil Velikov wrote: > > On Mon, 18 Mar 2019 at 13:32, Tapani Pälli wrote: > > On 3/18/19 3:25 PM, Robert Foss wrote: > > > Hey, > > > > > > On 3/18/19 2:11 PM, Mauro Rossi wrote: > > >> Hi, > > >> > > >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss > > >> wrote: > > >>> > > >>> Hey Mauro, > > >>> > > >>> On 3/18/19 9:38 AM, Mauro Rossi wrote: > > Hi Robert, > > > > On Mon, Mar 18, 2019 at 9:21 AM Robert Foss > > wrote: > > > > > > On a second note, this does not apply on libdrm/master due > > > to: > > > > > > LOCAL_SHARED_LIBRARIES := \ > > > libcutils > > > > Sorry, we have an additional Google patch, not present in libdrm/master > > that adds libdrm_platform module, but it is for a specific Google > > issue. [1] > > > > However with libdrm module we have both liblog and libcutils shared > > dependencies > > > > [1] > > http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e > > > > >>> > > >>> Do you know if [1] causes incompatibility issues with earlier android > > >>> verions? > > >>> If not I would suggest upstreaming it too. > > >> > > >> I used those patches to build with nougat-x86 and there was no issue. > > >> > > >> To be precise I did a double rookie mistake, because __android_log_vprint > > >> not used in upstream libdrm and libdrm_platform not used either. > > >> > > >> Now starting from my mistakes, let's see if there is anything useful > > >> to libdrm project > > >> > > >> In our builds Chih-Wei Huang said that libdrm_platform is not used, > > >> meaning not added to packages list, > > >> however with oreo-x86 the build error appeared and the liblog dependency. > > >> > > >> __android_log_vprint is used with __ANDROID__ braces > > >> in a special patch [2] by Chih-Wei Huang which adds capability to > > >> print logs > > >> in logcat > > >> > > >> If it's not too invasive in libdrm, it could be useful. > > >> Cheers > > >> Mauro > > >> > > >> [2] > > >> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9 > > >> > > > > > > [2] Seems like a good idea to me. > > > Logcat really is the only intended path for logging on Android, and > > > redirecting our logs there does make sense to me. > > > > > > But, I'm not sure about I like the way [2] disregards log-levels in > > > drmMsg(). > > > > > > > Yeah, I think it's a good idea. I see that in mesa we include > > "android/log.h", not "log/log.h", will need to make sure we get that > > correctly, maybe older versions did "log/log.h"? > > > I would also be in favour of adding logcat support to libdrm. > > Mauro, please respin when you have the time. > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-next
Hi Dave, Just log cleanup patches of Exynos KMS and DMA drivers including one trivial style fixup. Please kinkdly let me know if there is any problem. Thanks, Inki Dae The following changes since commit dbb92471674a48892f5e50779425e03388073ab9: Revert "drm: allow render capable master with DRM_AUTH ioctls" (2019-04-18 06:46:33 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v5.2 for you to fetch changes up to 35319804851fad62dfa6284f4e638a7e2a620fe8: drm/ipp: clean up debug messages (2019-04-22 12:13:44 +0900) Log cleanups - Correct the use of log macro in error case. - Drop unnecessary messages. - Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG. - Print out debug messages with correct device name in vidi and ipp drivers. One trivial cleanup - Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver. Inki Dae (6): drm/fimd: use DRM_ERROR instead of DRM_INFO in error case drm/exynos: remove unnecessary messages drm/exynos: use DRM_DEV_ERROR to print out error message drm/exynos: use DRM_DEV_DEBUG* instead of DRM_DEBUG macro drm/vidi: replace platform_device pointer with device one drm/ipp: clean up debug messages Seung-Woo Kim (1): drm/exynos: g2d: remove style error drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 +- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 26 +++ drivers/gpu/drm/exynos/exynos_dp.c| 9 ++- drivers/gpu/drm/exynos/exynos_drm_dma.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 ++- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_fb.c| 9 ++- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 --- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 97 ++- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 48 +++-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 51 +++--- drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 72 ++-- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 71 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 9 +-- drivers/gpu/drm/exynos/exynos_drm_mic.c | 29 drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +++-- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 5 +- drivers/gpu/drm/exynos/exynos_drm_scaler.c| 5 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 49 -- drivers/gpu/drm/exynos/exynos_hdmi.c | 75 - drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++- 22 files changed, 400 insertions(+), 298 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ttm: wait mem space if user allow while gpu busy
heavy gpu job could occupy memory long time, which could lead to other
user fail to get memory.
Change-Id: I0b322d98cd76e5ac32b00462bbae8008d76c5e11
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c484729f9b2..6c596cc24bec 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -830,8 +830,10 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
if (mem->mm_node)
break;
ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
- if (unlikely(ret != 0))
- return ret;
+ if (unlikely(ret != 0)) {
+ if (!ctx || ctx->no_wait_gpu || ret != -EBUSY)
+ return ret;
+ }
} while (1);
mem->mem_type = mem_type;
return ttm_bo_add_move_fence(bo, man, mem);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110488] [1042669.035207] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, signaled seq=4, emitted seq=8
https://bugs.freedesktop.org/show_bug.cgi?id=110488 --- Comment #1 from baopeng --- Created attachment 144067 --> https://bugs.freedesktop.org/attachment.cgi?id=144067&action=edit umr info umr info regs and ring buffer msg -- 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 v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.
Ping for patches 3, new patch 5 and patch 6.
Andrey
On 4/18/19 11:00 AM, Andrey Grodzovsky wrote:
> Also reject TDRs if another one already running.
>
> v2:
> Stop all schedulers across device and entire XGMI hive before
> force signaling HW fences.
> Avoid passing job_signaled to helper fnctions to keep all the decision
> making about skipping HW reset in one place.
>
> v3:
> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
> against it's decrement in drm_sched_stop in non HW reset case.
> v4: rebase
> v5: Revert v3 as we do it now in sceduler code.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143
> +++--
> 1 file changed, 95 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a0e165c..85f8792 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> - drm_sched_stop(&ring->sched, &job->base);
> -
> /* after all hw jobs are reset, hw fence is meaningless, so
> force_completion */
> amdgpu_fence_driver_force_completion(ring);
> }
> @@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if(job)
> drm_sched_increase_karma(&job->base);
>
> + /* Don't suspend on bare metal if we are not going to HW reset the ASIC
> */
> if (!amdgpu_sriov_vf(adev)) {
>
> if (!need_full_reset)
> @@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct
> amdgpu_hive_info *hive,
> return r;
> }
>
> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool trylock)
> {
> - int i;
> -
> - for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> - struct amdgpu_ring *ring = adev->rings[i];
> -
> - if (!ring || !ring->sched.thread)
> - continue;
> -
> - if (!adev->asic_reset_res)
> - drm_sched_resubmit_jobs(&ring->sched);
> + if (trylock) {
> + if (!mutex_trylock(&adev->lock_reset))
> + return false;
> + } else
> + mutex_lock(&adev->lock_reset);
>
> - drm_sched_start(&ring->sched, !adev->asic_reset_res);
> - }
> -
> - if (!amdgpu_device_has_dc_support(adev)) {
> - drm_helper_resume_force_mode(adev->ddev);
> - }
> -
> - adev->asic_reset_res = 0;
> -}
> -
> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
> -{
> - mutex_lock(&adev->lock_reset);
> atomic_inc(&adev->gpu_reset_counter);
> adev->in_gpu_reset = 1;
> /* Block kfd: SRIOV would do it separately */
> if (!amdgpu_sriov_vf(adev))
> amdgpu_amdkfd_pre_reset(adev);
> +
> + return true;
> }
>
> static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
> @@ -3538,40 +3521,42 @@ static void amdgpu_device_unlock_adev(struct
> amdgpu_device *adev)
> int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
> struct amdgpu_job *job)
> {
> - int r;
> + struct list_head device_list, *device_list_handle = NULL;
> + bool need_full_reset, job_signaled;
> struct amdgpu_hive_info *hive = NULL;
> - bool need_full_reset = false;
> struct amdgpu_device *tmp_adev = NULL;
> - struct list_head device_list, *device_list_handle = NULL;
> + int i, r = 0;
>
> + need_full_reset = job_signaled = false;
> INIT_LIST_HEAD(&device_list);
>
> dev_info(adev->dev, "GPU reset begin!\n");
>
> + hive = amdgpu_get_xgmi_hive(adev, false);
> +
> /*
> - * In case of XGMI hive disallow concurrent resets to be triggered
> - * by different nodes. No point also since the one node already
> executing
> - * reset will also reset all the other nodes in the hive.
> + * Here we trylock to avoid chain of resets executing from
> + * either trigger by jobs on different adevs in XGMI hive or jobs on
> + * different schedulers for same device while this TO handler is
> running.
> + * We always reset all schedulers for device and all devices for XGMI
> + * hive so that should take care of them too.
>*/
> - hive = amdgpu_get_xgmi_hive(adev, 0);
> - if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
> - !mutex_trylock(&hive->reset_lock))
> +
> + if (hive && !mutex_trylock(&hive->reset_lock)) {
> + DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another
> already in progress",
> + job->base.id, hive->hive_id);
>
Re: [PATCH v5 3/6] drm/scheduler: rework job destruction
Hi Andrey,
static void drm_sched_process_job(struct dma_fence *f, struct
dma_fence_cb *cb)
{
...
spin_lock_irqsave(&sched->job_list_lock, flags);
/* remove job from ring_mirror_list */
list_del_init(&s_job->node);
spin_unlock_irqrestore(&sched->job_list_lock, flags);
[David] How about just remove above to worker from irq process? Any
problem? Maybe I missed previous your discussion, but I think removing
lock for list is a risk for future maintenance although you make sure
thread safe currently.
-David
...
schedule_work(&s_job->finish_work);
}
在 2019/4/18 23:00, Andrey Grodzovsky 写道:
> From: Christian König
>
> We now destroy finished jobs from the worker thread to make sure that
> we never destroy a job currently in timeout processing.
> By this we avoid holding lock around ring mirror list in drm_sched_stop
> which should solve a deadlock reported by a user.
>
> v2: Remove unused variable.
> v4: Move guilty job free into sched code.
> v5:
> Move sched->hw_rq_count to drm_sched_start to account for counter
> decrement in drm_sched_stop even when we don't call resubmit jobs
> if guily job did signal.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692
>
> Signed-off-by: Christian König
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +-
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 -
> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 159
> +
> drivers/gpu/drm/v3d/v3d_sched.c| 2 +-
> include/drm/gpu_scheduler.h| 6 +-
> 8 files changed, 102 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 7cee269..a0e165c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3334,7 +3334,7 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> - drm_sched_stop(&ring->sched);
> + drm_sched_stop(&ring->sched, &job->base);
>
> /* after all hw jobs are reset, hw fence is meaningless, so
> force_completion */
> amdgpu_fence_driver_force_completion(ring);
> @@ -3343,8 +3343,6 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if(job)
> drm_sched_increase_karma(&job->base);
>
> -
> -
> if (!amdgpu_sriov_vf(adev)) {
>
> if (!need_full_reset)
> @@ -3482,8 +3480,7 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
> *hive,
> return r;
> }
>
> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
> - struct amdgpu_job *job)
> +static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
> {
> int i;
>
> @@ -3623,7 +3620,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device
> *adev,
>
> /* Post ASIC reset for all devs .*/
> list_for_each_entry(tmp_adev, device_list_handle, gmc.xgmi.head) {
> - amdgpu_device_post_asic_reset(tmp_adev, tmp_adev == adev ? job
> : NULL);
> + amdgpu_device_post_asic_reset(tmp_adev);
>
> if (r) {
> /* bad news, how to tell it to userspace ? */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> index 33854c9..5778d9c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
> @@ -135,13 +135,11 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> mmu_size + gpu->buffer.size;
>
> /* Add in the active command buffers */
> - spin_lock_irqsave(&gpu->sched.job_list_lock, flags);
> list_for_each_entry(s_job, &gpu->sched.ring_mirror_list, node) {
> submit = to_etnaviv_submit(s_job);
> file_size += submit->cmdbuf.size;
> n_obj++;
> }
> - spin_unlock_irqrestore(&gpu->sched.job_list_lock, flags);
>
> /* Add in the active buffer objects */
> list_for_each_entry(vram, &gpu->mmu->mappings, mmu_node) {
> @@ -183,14 +181,12 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
> gpu->buffer.size,
> etnaviv_cmdbuf_get_va(&gpu->buffer));
>
> - spin_lock_irqsave(&gpu->sched.job_list_lock, flags);
> list_for_each_entry(s_job, &gpu->sched.ring_mirror_list, node) {
> submit = to_etnaviv_submit(s_job);
> etnaviv_core_dump_mem(&iter, ETDUMP_BUF_CMD,
> submit->cmdbuf.vaddr, submit->cmdbuf.size,
>
Re: [PATCH v5 4/6] drm/sched: Keep s_fence->parent pointer
+Monk to response this patch.
在 2019/4/18 23:00, Andrey Grodzovsky 写道:
> For later driver's reference to see if the fence is signaled.
>
> v2: Move parent fence put to resubmit jobs.
>
> Signed-off-by: Andrey Grodzovsky
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 7816de7..03e6bd8 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -375,8 +375,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
> struct drm_sched_job *bad)
> if (s_job->s_fence->parent &&
> dma_fence_remove_callback(s_job->s_fence->parent,
> &s_job->cb)) {
> - dma_fence_put(s_job->s_fence->parent);
> - s_job->s_fence->parent = NULL;
I vaguely remember Monk set parent to be NULL to avoiod potiential free
problem after callback removal.
-David
> atomic_dec(&sched->hw_rq_count);
> } else {
> /*
> @@ -403,6 +401,14 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
> struct drm_sched_job *bad)
> sched->ops->free_job(s_job);
> }
> }
> +
> + /*
> + * Stop pending timer in flight as we rearm it in drm_sched_start. This
> + * avoids the pending timeout work in progress to fire right away after
> + * this TDR finished and before the newly restarted jobs had a
> + * chance to complete.
> + */
> + cancel_delayed_work(&sched->work_tdr);
> }
>
> EXPORT_SYMBOL(drm_sched_stop);
> @@ -477,6 +483,7 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler
> *sched)
> if (found_guilty && s_job->s_fence->scheduled.context ==
> guilty_context)
> dma_fence_set_error(&s_fence->finished, -ECANCELED);
>
> + dma_fence_put(s_job->s_fence->parent);
> s_job->s_fence->parent = sched->ops->run_job(s_job);
> }
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.
+Monk.
GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
But out of curious, why guilty job can signal more if the job is already
set to guilty? set it wrongly?
-David
在 2019/4/18 23:00, Andrey Grodzovsky 写道:
> Also reject TDRs if another one already running.
>
> v2:
> Stop all schedulers across device and entire XGMI hive before
> force signaling HW fences.
> Avoid passing job_signaled to helper fnctions to keep all the decision
> making about skipping HW reset in one place.
>
> v3:
> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
> against it's decrement in drm_sched_stop in non HW reset case.
> v4: rebase
> v5: Revert v3 as we do it now in sceduler code.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143
> +++--
> 1 file changed, 95 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a0e165c..85f8792 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3334,8 +3334,6 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if (!ring || !ring->sched.thread)
> continue;
>
> - drm_sched_stop(&ring->sched, &job->base);
> -
> /* after all hw jobs are reset, hw fence is meaningless, so
> force_completion */
> amdgpu_fence_driver_force_completion(ring);
> }
> @@ -3343,6 +3341,7 @@ static int amdgpu_device_pre_asic_reset(struct
> amdgpu_device *adev,
> if(job)
> drm_sched_increase_karma(&job->base);
>
> + /* Don't suspend on bare metal if we are not going to HW reset the ASIC
> */
> if (!amdgpu_sriov_vf(adev)) {
>
> if (!need_full_reset)
> @@ -3480,37 +3479,21 @@ static int amdgpu_do_asic_reset(struct
> amdgpu_hive_info *hive,
> return r;
> }
>
> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool trylock)
> {
> - int i;
> -
> - for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> - struct amdgpu_ring *ring = adev->rings[i];
> -
> - if (!ring || !ring->sched.thread)
> - continue;
> -
> - if (!adev->asic_reset_res)
> - drm_sched_resubmit_jobs(&ring->sched);
> + if (trylock) {
> + if (!mutex_trylock(&adev->lock_reset))
> + return false;
> + } else
> + mutex_lock(&adev->lock_reset);
>
> - drm_sched_start(&ring->sched, !adev->asic_reset_res);
> - }
> -
> - if (!amdgpu_device_has_dc_support(adev)) {
> - drm_helper_resume_force_mode(adev->ddev);
> - }
> -
> - adev->asic_reset_res = 0;
> -}
> -
> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
> -{
> - mutex_lock(&adev->lock_reset);
> atomic_inc(&adev->gpu_reset_counter);
> adev->in_gpu_reset = 1;
> /* Block kfd: SRIOV would do it separately */
> if (!amdgpu_sriov_vf(adev))
> amdgpu_amdkfd_pre_reset(adev);
> +
> + return true;
> }
>
> static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
> @@ -3538,40 +3521,42 @@ static void amdgpu_device_unlock_adev(struct
> amdgpu_device *adev)
> int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
> struct amdgpu_job *job)
> {
> - int r;
> + struct list_head device_list, *device_list_handle = NULL;
> + bool need_full_reset, job_signaled;
> struct amdgpu_hive_info *hive = NULL;
> - bool need_full_reset = false;
> struct amdgpu_device *tmp_adev = NULL;
> - struct list_head device_list, *device_list_handle = NULL;
> + int i, r = 0;
>
> + need_full_reset = job_signaled = false;
> INIT_LIST_HEAD(&device_list);
>
> dev_info(adev->dev, "GPU reset begin!\n");
>
> + hive = amdgpu_get_xgmi_hive(adev, false);
> +
> /*
> - * In case of XGMI hive disallow concurrent resets to be triggered
> - * by different nodes. No point also since the one node already
> executing
> - * reset will also reset all the other nodes in the hive.
> + * Here we trylock to avoid chain of resets executing from
> + * either trigger by jobs on different adevs in XGMI hive or jobs on
> + * different schedulers for same device while this TO handler is
> running.
> + * We always reset all schedulers for device and all devices for XGMI
> + * hive so that should take care of them too.
>*/
> - hive = amdgpu_get_xgmi_hive(adev, 0);
> - if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
> - !mutex_trylock(&hive->reset_lock))
> +
> + if (hive && !mutex_trylock(&hive->reset_lock)) {
> + DRM_INFO("B
[PATCH v2 65/79] docs: ioctl: convert to ReST
Rename the iio documentation files to ReST, add an
index for them and adjust in order to produce a nice html
output via the Sphinx build system.
The cdrom.txt and hdio.txt have their own particular syntax.
In order to speedup the conversion, I used a small ancillary
perl script:
my $d;
$d .= $_ while(<>);
$d =~ s/(\nCDROM\S+)\s+(\w[^\n]*)/$1\n\t$2\n/g;
$d =~ s/(\nHDIO\S+)\s+(\w[^\n]*)/$1\n\t$2\n/g;
$d =~ s/(\n\s*usage:)[\s\n]*(\w[^\n]*)/$1:\n\n\t $2\n/g;
$d =~ s/(\n\s*)(E\w+[\s\n]*\w[^\n]*)/$1- $2/g;
$d =~ s/(\n\s*)(inputs|outputs|notes):\s*(\w[^\n]*)/$1$2:\n\t\t$3\n/g;
print $d;
It basically add blank lines on a few interesting places. The
script is not perfect: still several things require manual work,
but it saved quite some time doing some obvious stuff.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab
---
...g-up-ioctls.txt => botching-up-ioctls.rst} |1 +
Documentation/ioctl/cdrom.rst | 1233 +
Documentation/ioctl/cdrom.txt | 967 -
Documentation/ioctl/{hdio.txt => hdio.rst}| 835 +++
Documentation/ioctl/index.rst | 16 +
...{ioctl-decoding.txt => ioctl-decoding.rst} | 13 +-
drivers/gpu/drm/drm_ioctl.c |2 +-
7 files changed, 1814 insertions(+), 1253 deletions(-)
rename Documentation/ioctl/{botching-up-ioctls.txt => botching-up-ioctls.rst}
(99%)
create mode 100644 Documentation/ioctl/cdrom.rst
delete mode 100644 Documentation/ioctl/cdrom.txt
rename Documentation/ioctl/{hdio.txt => hdio.rst} (54%)
create mode 100644 Documentation/ioctl/index.rst
rename Documentation/ioctl/{ioctl-decoding.txt => ioctl-decoding.rst} (54%)
diff --git a/Documentation/ioctl/botching-up-ioctls.txt
b/Documentation/ioctl/botching-up-ioctls.rst
similarity index 99%
rename from Documentation/ioctl/botching-up-ioctls.txt
rename to Documentation/ioctl/botching-up-ioctls.rst
index 883fb034bd04..ac697fef3545 100644
--- a/Documentation/ioctl/botching-up-ioctls.txt
+++ b/Documentation/ioctl/botching-up-ioctls.rst
@@ -1,3 +1,4 @@
+=
(How to avoid) Botching up ioctls
=
diff --git a/Documentation/ioctl/cdrom.rst b/Documentation/ioctl/cdrom.rst
new file mode 100644
index ..3b4c0506de46
--- /dev/null
+++ b/Documentation/ioctl/cdrom.rst
@@ -0,0 +1,1233 @@
+
+Summary of CDROM ioctl calls
+
+
+- Edward A. Falk
+
+November, 2004
+
+This document attempts to describe the ioctl(2) calls supported by
+the CDROM layer. These are by-and-large implemented (as of Linux 2.6)
+in drivers/cdrom/cdrom.c and drivers/block/scsi_ioctl.c
+
+ioctl values are listed in . As of this writing, they
+are as follows:
+
+ == ===
+ CDROMPAUSE Pause Audio Operation
+ CDROMRESUME Resume paused Audio Operation
+ CDROMPLAYMSFPlay Audio MSF (struct cdrom_msf)
+ CDROMPLAYTRKIND Play Audio Track/index (struct cdrom_ti)
+ CDROMREADTOCHDR Read TOC header (struct cdrom_tochdr)
+ CDROMREADTOCENTRY Read TOC entry (struct cdrom_tocentry)
+ CDROMSTOP Stop the cdrom drive
+ CDROMSTART Start the cdrom drive
+ CDROMEJECT Ejects the cdrom media
+ CDROMVOLCTRLControl output volume (struct cdrom_volctrl)
+ CDROMSUBCHNLRead subchannel data (struct cdrom_subchnl)
+ CDROMREADMODE2 Read CDROM mode 2 data (2336 Bytes)
+ (struct cdrom_read)
+ CDROMREADMODE1 Read CDROM mode 1 data (2048 Bytes)
+ (struct cdrom_read)
+ CDROMREADAUDIO (struct cdrom_read_audio)
+ CDROMEJECT_SW enable(1)/disable(0) auto-ejecting
+ CDROMMULTISESSION Obtain the start-of-last-session
+ address of multi session disks
+ (struct cdrom_multisession)
+ CDROM_GET_MCN Obtain the "Universal Product Code"
+ if available (struct cdrom_mcn)
+ CDROM_GET_UPC Deprecated, use CDROM_GET_MCN instead.
+ CDROMRESET hard-reset the drive
+ CDROMVOLREADGet the drive's volume setting
+ (struct cdrom_volctrl)
+ CDROMREADRAWread data in raw mode (2352 Bytes)
+ (struct cdrom_read)
+ CDROMREADCOOKED read data in cooked mode
+ CDROMSEEK seek msf address
+ CDROMPLAYBLKscsi-cd only, (struct cdrom_blk)
+ CDROMREADALL
[PATCH v2 39/79] docs: EDID/HOWTO.txt: convert it and rename to howto.rst
Sphinx need to know when a paragraph ends. So, do some adjustments
at the file for it to be properly parsed.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
that's said, I believe that this file should be moved to the
GPU/DRM documentation.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/EDID/{HOWTO.txt => howto.rst} | 31 ---
.../admin-guide/kernel-parameters.txt | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
3 files changed, 22 insertions(+), 13 deletions(-)
rename Documentation/EDID/{HOWTO.txt => howto.rst} (83%)
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/howto.rst
similarity index 83%
rename from Documentation/EDID/HOWTO.txt
rename to Documentation/EDID/howto.rst
index 539871c3b785..725fd49a88ca 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/howto.rst
@@ -1,3 +1,9 @@
+:orphan:
+
+
+EDID
+
+
In the good old days when graphics parameters were configured explicitly
in a file called xorg.conf, even broken hardware could be managed.
@@ -34,16 +40,19 @@ Makefile. Please note that the EDID data structure expects
the timing
values in a different way as compared to the standard X11 format.
X11:
-HTimings: hdisp hsyncstart hsyncend htotal
-VTimings: vdisp vsyncstart vsyncend vtotal
+ HTimings:
+hdisp hsyncstart hsyncend htotal
+ VTimings:
+vdisp vsyncstart vsyncend vtotal
-EDID:
-#define XPIX hdisp
-#define XBLANK htotal-hdisp
-#define XOFFSET hsyncstart-hdisp
-#define XPULSE hsyncend-hsyncstart
+EDID::
-#define YPIX vdisp
-#define YBLANK vtotal-vdisp
-#define YOFFSET vsyncstart-vdisp
-#define YPULSE vsyncend-vsyncstart
+ #define XPIX hdisp
+ #define XBLANK htotal-hdisp
+ #define XOFFSET hsyncstart-hdisp
+ #define XPULSE hsyncend-hsyncstart
+
+ #define YPIX vdisp
+ #define YBLANK vtotal-vdisp
+ #define YOFFSET vsyncstart-vdisp
+ #define YPULSE vsyncend-vsyncstart
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 5006f876cf0e..4a2260eac131 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -929,7 +929,7 @@
edid/1680x1050.bin, or edid/1920x1080.bin is given
and no file with the same name exists. Details and
instructions how to build your own EDID data are
- available in Documentation/EDID/HOWTO.txt. An EDID
+ available in Documentation/EDID/howto.rst. An EDID
data set will only be used for a particular connector,
if its name and a colon are prepended to the EDID
name. Each connector may use a unique EDID data
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 39d5f7562f1c..bc5658d7a84b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -140,7 +140,7 @@ config DRM_LOAD_EDID_FIRMWARE
monitor are unable to provide appropriate EDID data. Since this
feature is provided as a workaround for broken hardware, the
default case is N. Details and instructions how to build your own
- EDID data are given in Documentation/EDID/HOWTO.txt.
+ EDID data are given in Documentation/EDID/howto.rst.
config DRM_DP_CEC
bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 21/79] docs: locking: convert docs to ReST and rename to *.rst
Convert the locking documents to ReST and add them to the
kernel development book where it belongs.
Most of the stuff here is just to make Sphinx to properly
parse the text file, as they're already in good shape,
not requiring massive changes in order to be parsed.
The conversion is actually:
- add blank lines and identation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/kernel-hacking/locking.rst | 2 +-
Documentation/locking/index.rst | 24 +++
...{lockdep-design.txt => lockdep-design.rst} | 41 ++--
Documentation/locking/lockstat.rst| 204 ++
Documentation/locking/lockstat.txt| 183
.../{locktorture.txt => locktorture.rst} | 105 +
.../{mutex-design.txt => mutex-design.rst}| 26 ++-
...t-mutex-design.txt => rt-mutex-design.rst} | 139 ++--
.../locking/{rt-mutex.txt => rt-mutex.rst}| 30 +--
.../locking/{spinlocks.txt => spinlocks.rst} | 32 ++-
...w-mutex-design.txt => ww-mutex-design.rst} | 82 +++
Documentation/pi-futex.txt| 2 +-
.../it_IT/kernel-hacking/locking.rst | 2 +-
drivers/gpu/drm/drm_modeset_lock.c| 2 +-
include/linux/lockdep.h | 2 +-
include/linux/mutex.h | 2 +-
include/linux/rwsem.h | 2 +-
kernel/locking/mutex.c| 2 +-
kernel/locking/rtmutex.c | 2 +-
lib/Kconfig.debug | 4 +-
20 files changed, 506 insertions(+), 382 deletions(-)
create mode 100644 Documentation/locking/index.rst
rename Documentation/locking/{lockdep-design.txt => lockdep-design.rst} (93%)
create mode 100644 Documentation/locking/lockstat.rst
delete mode 100644 Documentation/locking/lockstat.txt
rename Documentation/locking/{locktorture.txt => locktorture.rst} (57%)
rename Documentation/locking/{mutex-design.txt => mutex-design.rst} (94%)
rename Documentation/locking/{rt-mutex-design.txt => rt-mutex-design.rst} (91%)
rename Documentation/locking/{rt-mutex.txt => rt-mutex.rst} (71%)
rename Documentation/locking/{spinlocks.txt => spinlocks.rst} (89%)
rename Documentation/locking/{ww-mutex-design.txt => ww-mutex-design.rst} (93%)
diff --git a/Documentation/kernel-hacking/locking.rst
b/Documentation/kernel-hacking/locking.rst
index 519673df0e82..71a843464ec2 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -1364,7 +1364,7 @@ Futex API reference
Further reading
===
-- ``Documentation/locking/spinlocks.txt``: Linus Torvalds' spinlocking
+- ``Documentation/locking/spinlocks.rst``: Linus Torvalds' spinlocking
tutorial in the kernel sources.
- Unix Systems for Modern Architectures: Symmetric Multiprocessing and
diff --git a/Documentation/locking/index.rst b/Documentation/locking/index.rst
new file mode 100644
index ..ef5da7fe9aac
--- /dev/null
+++ b/Documentation/locking/index.rst
@@ -0,0 +1,24 @@
+:orphan:
+
+===
+locking
+===
+
+.. toctree::
+:maxdepth: 1
+
+lockdep-design
+lockstat
+locktorture
+mutex-design
+rt-mutex-design
+rt-mutex
+spinlocks
+ww-mutex-design
+
+.. only:: subproject and html
+
+ Indices
+ ===
+
+ * :ref:`genindex`
diff --git a/Documentation/locking/lockdep-design.txt
b/Documentation/locking/lockdep-design.rst
similarity index 93%
rename from Documentation/locking/lockdep-design.txt
rename to Documentation/locking/lockdep-design.rst
index 39fae143c9cb..49707a5029c5 100644
--- a/Documentation/locking/lockdep-design.txt
+++ b/Documentation/locking/lockdep-design.rst
@@ -2,6 +2,7 @@ Runtime locking correctness validator
=
started by Ingo Molnar
+
additions by Arjan van de Ven
Lock-class
@@ -42,7 +43,7 @@ Where STATE can be either one of
(kernel/locking/lockdep_states.h)
- 'ever used' [ == !unused]
When locking rules are violated, these state bits are presented in the
-locking error messages, inside curlies. A contrived example:
+locking error messages, inside curlies. A contrived example::
modprobe/2287 is trying to acquire lock:
(&sio_locks[i].lock){-.-.}, at: [] mutex_lock+0x21/0x24
@@ -54,10 +55,12 @@ locking error messages, inside curlies. A contrived example:
The bit position indicates STATE, STATE-read, for each of the states listed
above, and the character displayed in each indicates:
+ === ===
'.' acquired while irqs disabled and not in irq context
'-' acquired in irq context
'+
[PATCH v2 45/79] docs: console.txt: convert docs to ReST and rename to *.rst
Convert this small file to ReST in preparation for adding it to
the driver-api book.
While this is not part of the driver-api book, mark it as
:orphan:, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab
---
.../console/{console.txt => console.rst} | 63 ++-
Documentation/fb/fbcon.rst| 4 +-
drivers/tty/Kconfig | 2 +-
3 files changed, 38 insertions(+), 31 deletions(-)
rename Documentation/console/{console.txt => console.rst} (80%)
diff --git a/Documentation/console/console.txt
b/Documentation/console/console.rst
similarity index 80%
rename from Documentation/console/console.txt
rename to Documentation/console/console.rst
index d73c2ab4beda..b374141b027e 100644
--- a/Documentation/console/console.txt
+++ b/Documentation/console/console.rst
@@ -1,3 +1,6 @@
+:orphan:
+
+===
Console Drivers
===
@@ -17,25 +20,26 @@ of driver occupying the consoles.) They can only take over
the console that is
occupied by the system driver. In the same token, if the modular driver is
released by the console, the system driver will take over.
-Modular drivers, from the programmer's point of view, have to call:
+Modular drivers, from the programmer's point of view, have to call::
do_take_over_console() - load and bind driver to console layer
give_up_console() - unload driver; it will only work if driver
is fully unbound
-In newer kernels, the following are also available:
+In newer kernels, the following are also available::
do_register_con_driver()
do_unregister_con_driver()
If sysfs is enabled, the contents of /sys/class/vtconsole can be
examined. This shows the console backends currently registered by the
-system which are named vtcon where is an integer from 0 to 15. Thus:
+system which are named vtcon where is an integer from 0 to 15.
+Thus::
ls /sys/class/vtconsole
. .. vtcon0 vtcon1
-Each directory in /sys/class/vtconsole has 3 files:
+Each directory in /sys/class/vtconsole has 3 files::
ls /sys/class/vtconsole/vtcon0
. .. bind name uevent
@@ -46,27 +50,29 @@ What do these files signify?
read, or acts to bind or unbind the driver to the virtual consoles
when written to. The possible values are:
- 0 - means the driver is not bound and if echo'ed, commands the driver
+ 0
+ - means the driver is not bound and if echo'ed, commands the driver
to unbind
-1 - means the driver is bound and if echo'ed, commands the driver to
+1
+ - means the driver is bound and if echo'ed, commands the driver to
bind
- 2. name - read-only file. Shows the name of the driver in this format:
+ 2. name - read-only file. Shows the name of the driver in this format::
- cat /sys/class/vtconsole/vtcon0/name
- (S) VGA+
+ cat /sys/class/vtconsole/vtcon0/name
+ (S) VGA+
- '(S)' stands for a (S)ystem driver, i.e., it cannot be directly
- commanded to bind or unbind
+ '(S)' stands for a (S)ystem driver, i.e., it cannot be directly
+ commanded to bind or unbind
- 'VGA+' is the name of the driver
+ 'VGA+' is the name of the driver
- cat /sys/class/vtconsole/vtcon1/name
- (M) frame buffer device
+ cat /sys/class/vtconsole/vtcon1/name
+ (M) frame buffer device
- In this case, '(M)' stands for a (M)odular driver, one that can be
- directly commanded to bind or unbind.
+ In this case, '(M)' stands for a (M)odular driver, one that can be
+ directly commanded to bind or unbind.
3. uevent - ignore this file
@@ -75,14 +81,17 @@ driver takes over the consoles vacated by the driver.
Binding, on the other
hand, will bind the driver to the consoles that are currently occupied by a
system driver.
-NOTE1: Binding and unbinding must be selected in Kconfig. It's under:
+NOTE1:
+ Binding and unbinding must be selected in Kconfig. It's under::
-Device Drivers -> Character devices -> Support for binding and unbinding
-console drivers
+Device Drivers ->
+ Character devices ->
+ Support for binding and unbinding console drivers
-NOTE2: If any of the virtual consoles are in KD_GRAPHICS mode, then binding or
-unbinding will not succeed. An example of an application that sets the console
-to KD_GRAPHICS is X.
+NOTE2:
+ If any of the virtual consoles are in KD_GRAPHICS mode, then binding or
+ unbinding will not succeed. An example of an application that sets the
+ console to KD_GRAPHICS is X.
How useful is this feature? This is very useful for console driver
developers. By unbinding the driver from the console layer, one can unload the
@@ -92,10 +101,10 @@ framebuffer console to VGA console and vice versa, this
feature also
Re: [RFC][PATCH 2/5] libdrm: amdgpu: Initialize unions with memset rather than "= {0}"
On Sat, Apr 20, 2019 at 12:25 AM John Stultz wrote:
>
> Clang complains when initializing unions using "= {0}"
> so instead use memset.
>
> Cc: Emil Velikov
> Cc: Sean Paul
> Cc: Alistair Strachan
> Cc: Marissa Wall
> Signed-off-by: John Stultz
Reviewed-by: Alex Deucher
Do you have commit rights?
Alex
> ---
> amdgpu/amdgpu_cs.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
> index 7ee844f..7c5b9d1 100644
> --- a/amdgpu/amdgpu_cs.c
> +++ b/amdgpu/amdgpu_cs.c
> @@ -733,12 +733,13 @@ drm_public int
> amdgpu_cs_submit_raw(amdgpu_device_handle dev,
> struct drm_amdgpu_cs_chunk *chunks,
> uint64_t *seq_no)
> {
> - union drm_amdgpu_cs cs = {0};
> + union drm_amdgpu_cs cs;
> uint64_t *chunk_array;
> int i, r;
> if (num_chunks == 0)
> return -EINVAL;
>
> + memset(&cs, 0, sizeof(cs));
> chunk_array = alloca(sizeof(uint64_t) * num_chunks);
> for (i = 0; i < num_chunks; i++)
> chunk_array[i] = (uint64_t)(uintptr_t)&chunks[i];
> @@ -763,10 +764,11 @@ drm_public int
> amdgpu_cs_submit_raw2(amdgpu_device_handle dev,
> struct drm_amdgpu_cs_chunk *chunks,
> uint64_t *seq_no)
> {
> - union drm_amdgpu_cs cs = {0};
> + union drm_amdgpu_cs cs;
> uint64_t *chunk_array;
> int i, r;
>
> + memset(&cs, 0, sizeof(cs));
> chunk_array = alloca(sizeof(uint64_t) * num_chunks);
> for (i = 0; i < num_chunks; i++)
> chunk_array[i] = (uint64_t)(uintptr_t)&chunks[i];
> @@ -803,9 +805,10 @@ drm_public int
> amdgpu_cs_fence_to_handle(amdgpu_device_handle dev,
> uint32_t what,
> uint32_t *out_handle)
> {
> - union drm_amdgpu_fence_to_handle fth = {0};
> + union drm_amdgpu_fence_to_handle fth;
> int r;
>
> + memset(&fth, 0, sizeof(fth));
> fth.in.fence.ctx_id = fence->context->id;
> fth.in.fence.ip_type = fence->ip_type;
> fth.in.fence.ip_instance = fence->ip_instance;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 3/5] libdrm: Avoid additional drm open close
On Sat, Apr 20, 2019 at 12:25 AM John Stultz wrote:
>
> From: Prabhanjan Kandula
>
> Avoid additional drm device open and close.
>
> Cc: Emil Velikov
> Cc: Sean Paul
> Cc: Alistair Strachan
> Cc: Marissa Wall
> Signed-off-by: John Stultz
Reviewed-by: Alex Deucher
> ---
> xf86drm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index fe822ca..2c19376 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -750,8 +750,8 @@ drm_public int drmOpen(const char *name, const char
> *busid)
> */
> drm_public int drmOpenWithType(const char *name, const char *busid, int type)
> {
> -if (!drmAvailable() && name != NULL && drm_server_info &&
> -drm_server_info->load_module) {
> +if (name != NULL && drm_server_info &&
> +drm_server_info->load_module && !drmAvailable()) {
> /* try to load the kernel module */
> if (!drm_server_info->load_module(name)) {
> drmMsg("[drm] failed to load kernel module \"%s\"\n", name);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/5] libdrm: Use mmap64 instead of __mmap2
On Sat, Apr 20, 2019 at 12:25 AM John Stultz wrote:
>
> From: Sean Paul
>
> __mmap2 isn't supported on all platforms, mmap64 is the right way
> to do this in android.
>
> Also folds in a fix from Stéphane Marchesin
> to use an offset in bytes not pages, as that's what mmap64 takes.
>
> Cc: Emil Velikov
> Cc: Sean Paul
> Cc: Alistair Strachan
> Cc: Marissa Wall
> Signed-off-by: Sean Paul
> Signed-off-by: John Stultz
Acked-by: Alex Deucher
> ---
> libdrm_macros.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libdrm_macros.h b/libdrm_macros.h
> index 95f0ef5..0dca827 100644
> --- a/libdrm_macros.h
> +++ b/libdrm_macros.h
> @@ -48,8 +48,6 @@
> #if defined(ANDROID) && !defined(__LP64__)
> #include /* for EINVAL */
>
> -extern void *__mmap2(void *, size_t, int, int, int, size_t);
> -
> static inline void *drm_mmap(void *addr, size_t length, int prot, int flags,
> int fd, loff_t offset)
> {
> @@ -59,7 +57,7 @@ static inline void *drm_mmap(void *addr, size_t length, int
> prot, int flags,
>return MAP_FAILED;
> }
>
> - return __mmap2(addr, length, prot, flags, fd, (size_t) (offset >> 12));
> + return mmap64(addr, length, prot, flags, fd, offset);
> }
>
> # define drm_munmap(addr, length) \
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 4/5] libdrm: reduce number of reallocations in drmModeAtomicAddProperty
On Sat, Apr 20, 2019 at 12:25 AM John Stultz wrote:
>
> From: Adrian Salido
>
> When calling drmModeAtomicAddProperty allocation of memory happens as
> needed in increments of 16 elements. This can be very slow if there are
> multiple properties to be updated in an Atomic Commit call.
>
> Increase this to as many as can fit in a memory PAGE to avoid having to
> reallocate memory too often.
>
> Cc: Emil Velikov
> Cc: Sean Paul
> Cc: Alistair Strachan
> Cc: Marissa Wall
> Signed-off-by: John Stultz
Reviewed-by: Alex Deucher
> ---
> xf86drmMode.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 8f8633e..c878d9e 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -1259,7 +1259,7 @@ drm_public drmModeAtomicReqPtr
> drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
> return NULL;
> }
> memcpy(new->items, old->items,
> - old->size_items * sizeof(*new->items));
> + old->cursor * sizeof(*new->items));
> } else {
> new->items = NULL;
> }
> @@ -1322,12 +1322,13 @@ drm_public int
> drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
> return -EINVAL;
>
> if (req->cursor >= req->size_items) {
> + const uint32_t item_size_inc = getpagesize() /
> sizeof(*req->items);
> drmModeAtomicReqItemPtr new;
>
> - req->size_items += 16;
> + req->size_items += item_size_inc;
> new = realloc(req->items, req->size_items *
> sizeof(*req->items));
> if (!new) {
> - req->size_items -= 16;
> + req->size_items -= item_size_inc;
> return -ENOMEM;
> }
> req->items = new;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp_aux: Use non-cyclic idr, add suffix option for aux device
On Wed, 2019-04-17 at 23:10 +, Li, Sun peng (Leo) wrote:
>
>
> On 2019-04-16 6:16 p.m., Lyude Paul wrote:
> > Sorry for the slow response, I've been really busy ;_;
>
> No worries :)
>
> > On Fri, 2019-04-12 at 12:05 -0400, sunpeng...@amd.com wrote:
> > > From: Leo Li
> > >
> > > In preparation for adding aux devices for DP MST:
> > >
> > > 1. A non-cyclic idr is used for the device minor version. That way,
> > > hotplug cycling MST devices won't needlessly increment the minor
> > > version index.
> >
> > I really like this btw, cyclic idrs are really annoying for drm_dp_aux_dev,
> > even outside of MST (try reloading a drm driver a couple of times and you'll
> > understand ;). I think we should split this into another commit though
> >
> > > 2. A suffix option is added to the aux device file name. It can be used
> > > to identify the corresponding MST device.
> >
> > I like this idea, but I think there may be a better way that we can do this.
> > Using /dev/nvme* as an example, we have the standard dev paths (/dev/nvme0,
> > /dev/nvme0n1, etc.). But we can also access them through /dev/disk/by-
> > {id,label,partlabel,partuuid,path,uuid}.
> >
> > So what if we added something similar for aux devices? We start off with the
> > standard /dev/drm_dp_aux*, then provide more descriptive symlinks and
> > directories:
> >
> > (feel free to come up with better naming then this if you can)
> >
> > /dev/drm_dp_aux/card0-DP-1 -> /dev/drm_dp_aux1
> > /dev/drm_dp_aux/card0-DP-2 -> /dev/drm_dp_aux2
> > etc.
>
> That does sound neater - although FWICT, this will have to be done with
> udev rules?
>
> I took a brief look at how that's done for storage devices. It looks
> like they have rules defined in
> /lib/udev/rules.d/60-persistent-storage.rules that manages the "by-x"
> symlinks.
>
> To make this happen for aux devices, what we could do is attach sysfs
> attributes to the device. It can then be parsed by udev in a similar
> fashion. Currently, only 'name' attribute is attached, as seen in
> drm_dp_aux_dev.c (after name_show()).
Yeah-that sounds perfect to me!
>
> Thanks,
> Leo
>
> > > Signed-off-by: Leo Li
> > > ---
> > > drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +++--
> > > drivers/gpu/drm/drm_dp_aux_dev.c | 8
> > > drivers/gpu/drm/drm_dp_helper.c| 2 +-
> > > 3 files changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
> > > b/drivers/gpu/drm/drm_crtc_helper_internal.h
> > > index b5ac158..9f0907b 100644
> > > --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> > > +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> > > @@ -46,7 +46,7 @@ static inline int drm_fb_helper_modinit(void)
> > > #ifdef CONFIG_DRM_DP_AUX_CHARDEV
> > > int drm_dp_aux_dev_init(void);
> > > void drm_dp_aux_dev_exit(void);
> > > -int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
> > > +int drm_dp_aux_register_devnode(struct drm_dp_aux *aux, const char
> > > *suffix);
> > > void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
> > > #else
> > > static inline int drm_dp_aux_dev_init(void)
> > > @@ -58,7 +58,8 @@ static inline void drm_dp_aux_dev_exit(void)
> > > {
> > > }
> > >
> > > -static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> > > +static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux,
> > > + const char *suffix)
> > > {
> > > return 0;
> > > }
> > > diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c
> > > b/drivers/gpu/drm/drm_dp_aux_dev.c
> > > index 0e4f25d..2310a67 100644
> > > --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> > > +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> > > @@ -80,8 +80,7 @@ static struct drm_dp_aux_dev
> > > *alloc_drm_dp_aux_dev(struct
> > > drm_dp_aux *aux)
> > > kref_init(&aux_dev->refcount);
> > >
> > > mutex_lock(&aux_idr_mutex);
> > > - index = idr_alloc_cyclic(&aux_idr, aux_dev, 0, DRM_AUX_MINORS,
> > > - GFP_KERNEL);
> > > + index = idr_alloc(&aux_idr, aux_dev, 0, DRM_AUX_MINORS, GFP_KERNEL);
> > > mutex_unlock(&aux_idr_mutex);
> > > if (index < 0) {
> > > kfree(aux_dev);
> > > @@ -290,7 +289,7 @@ void drm_dp_aux_unregister_devnode(struct drm_dp_aux
> > > *aux)
> > > kref_put(&aux_dev->refcount, release_drm_dp_aux_dev);
> > > }
> > >
> > > -int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
> > > +int drm_dp_aux_register_devnode(struct drm_dp_aux *aux, const char
> > > *suffix)
> > > {
> > > struct drm_dp_aux_dev *aux_dev;
> > > int res;
> > > @@ -301,7 +300,8 @@ int drm_dp_aux_register_devnode(struct drm_dp_aux
> > > *aux)
> > >
> > > aux_dev->dev = device_create(drm_dp_aux_dev_class, aux->dev,
> > >MKDEV(drm_dev_major, aux_dev-
> > > >index),
> > > NULL,
> > > -
Re: [PATCH] drm/gma500/cdv: Check vbt config bits when detecting lvds panels
On Sun, Apr 21, 2019 at 8:46 PM Hans de Goede wrote:
>
> Hi,
>
> On 16-04-19 13:46, Patrik Jakobsson wrote:
> > Some machines have an lvds child device in vbt even though a panel is
> > not attached. To make detection more reliable we now also check the lvds
> > config bits available in the vbt.
> >
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
> > Signed-off-by: Patrik Jakobsson
> > Cc: Hans de Goede
> > Cc: Ville Syrjälä
>
> The reporter of https://bugzilla.redhat.com/show_bug.cgi?id=1665766
> just got back to me and he confirms that this patch fixes the
> false-positive LVDS panel detection on his NAS, without needing
> a DMI blacklist.
>
> So it looks like this patch indeed is a better fix then my initial
> DMI blacklist approach and from my pov this patch is ready to
> go upstream.
Thanks Hans, can I add your review tag?
>
> Regards,
>
> Hans
>
>
> > ---
> > drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
> > drivers/gpu/drm/gma500/intel_bios.c | 3 +++
> > drivers/gpu/drm/gma500/psb_drv.h| 1 +
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > index de9531caaca0..9c8446184b17 100644
> > --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> > @@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_device *dev,
> > int pipe;
> > u8 pin;
> >
> > + if (!dev_priv->lvds_enabled_in_vbt)
> > + return;
> > +
> > pin = GMBUS_PORT_PANEL;
> > if (!lvds_is_present_in_vbt(dev, &pin)) {
> > DRM_DEBUG_KMS("LVDS is not present in VBT\n");
> > diff --git a/drivers/gpu/drm/gma500/intel_bios.c
> > b/drivers/gpu/drm/gma500/intel_bios.c
> > index 63bde4e86c6a..e019ea271ffc 100644
> > --- a/drivers/gpu/drm/gma500/intel_bios.c
> > +++ b/drivers/gpu/drm/gma500/intel_bios.c
> > @@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_private *dev_priv,
> > if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
> > dev_priv->edp.support = 1;
> >
> > + dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
> > + DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
> > +
> > /* This bit means to use 96Mhz for DPLL_A or not */
> > if (driver->primary_lfp_id)
> > dev_priv->dplla_96mhz = true;
> > diff --git a/drivers/gpu/drm/gma500/psb_drv.h
> > b/drivers/gpu/drm/gma500/psb_drv.h
> > index 941b238bdcc9..bc608ddc3bd1 100644
> > --- a/drivers/gpu/drm/gma500/psb_drv.h
> > +++ b/drivers/gpu/drm/gma500/psb_drv.h
> > @@ -537,6 +537,7 @@ struct drm_psb_private {
> > int lvds_ssc_freq;
> > bool is_lvds_on;
> > bool is_mipi_on;
> > + bool lvds_enabled_in_vbt;
> > u32 mipi_ctrl_display;
> >
> > unsigned int core_freq;
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Pending panel driver patches - OK to commit?
Hi Sam, On Mon, Apr 1, 2019 at 3:24 PM Sam Ravnborg wrote: > panel-simple support for VXT VL050-8048NT-C01 panel - Fabio Estevam > Any chance to get this one to kernel 5.2? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/5] libdrm: amdgpu: Initialize unions with memset rather than "= {0}"
On Mon, Apr 22, 2019 at 7:59 AM Alex Deucher wrote:
> On Sat, Apr 20, 2019 at 12:25 AM John Stultz wrote:
> >
> > Clang complains when initializing unions using "= {0}"
> > so instead use memset.
> >
> > Cc: Emil Velikov
> > Cc: Sean Paul
> > Cc: Alistair Strachan
> > Cc: Marissa Wall
> > Signed-off-by: John Stultz
>
> Reviewed-by: Alex Deucher
Thanks for the review!
> Do you have commit rights?
I don't.
thanks again,
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm/vmwgfx: Implement an infrastructure for write-coherent resources
Hi Thomas,
With minor comments below
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> This infrastructure will, for coherent resources, make sure that
> from the user-space point of view, data written by the CPU is
> immediately
> automatically available to the GPU at resource validation time.
>
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/Kconfig| 1 +
> drivers/gpu/drm/vmwgfx/Makefile | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 5 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 26 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 410
> ++
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 57 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 11 +
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 74
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 16 +-
> 11 files changed, 588 insertions(+), 20 deletions(-)
> create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
>
> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig
> b/drivers/gpu/drm/vmwgfx/Kconfig
> index 6b28a326f8bb..d5fd81a521f6 100644
> --- a/drivers/gpu/drm/vmwgfx/Kconfig
> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
> @@ -8,6 +8,7 @@ config DRM_VMWGFX
> select FB_CFB_IMAGEBLIT
> select DRM_TTM
> select FB
> + select AS_DIRTY_HELPERS
> # Only needed for the transitional use of drm_crtc_init - can
> be removed
> # again once vmwgfx sets up the primary plane itself.
> select DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/vmwgfx/Makefile
> b/drivers/gpu/drm/vmwgfx/Makefile
> index 8841bd30e1e5..c877a21a0739 100644
> --- a/drivers/gpu/drm/vmwgfx/Makefile
> +++ b/drivers/gpu/drm/vmwgfx/Makefile
> @@ -8,7 +8,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o
> vmwgfx_kms.o vmwgfx_drv.o \
> vmwgfx_cmdbuf_res.o vmwgfx_cmdbuf.o vmwgfx_stdu.o \
> vmwgfx_cotable.o vmwgfx_so.o vmwgfx_binding.o vmwgfx_msg.o
> \
> vmwgfx_simple_resource.o vmwgfx_va.o vmwgfx_blit.o \
> - vmwgfx_validation.o \
> + vmwgfx_validation.o vmwgfx_page_dirty.o \
> ttm_object.o ttm_lock.o
>
> obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index c0829d50eecc..90ca866640fe 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -463,6 +463,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
> {
> struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
>
> + WARN_ON(vmw_bo->dirty);
> vmw_bo_unmap(vmw_bo);
> kfree(vmw_bo);
> }
> @@ -476,8 +477,10 @@ void vmw_bo_bo_free(struct ttm_buffer_object
> *bo)
> static void vmw_user_bo_destroy(struct ttm_buffer_object *bo)
> {
> struct vmw_user_buffer_object *vmw_user_bo =
> vmw_user_buffer_object(bo);
> + struct vmw_buffer_object *vbo = &vmw_user_bo->vbo;
>
> - vmw_bo_unmap(&vmw_user_bo->vbo);
> + WARN_ON(vbo->dirty);
Is it possible for user-space to exploit this WARN? If yes then you
might want to change the logic?
> + vmw_bo_unmap(vbo);
> ttm_prime_object_kfree(vmw_user_bo, prime);
> }
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 6165fe2c4504..74e94138877e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -857,6 +857,11 @@ static int vmw_driver_load(struct drm_device
> *dev, unsigned long chipset)
> DRM_ERROR("Failed initializing TTM buffer object
> driver.\n");
> goto out_no_bdev;
> }
> + dev_priv->vm_ops = *dev_priv->bdev.vm_ops;
> + dev_priv->vm_ops.fault = vmw_bo_vm_fault;
> + dev_priv->vm_ops.pfn_mkwrite = vmw_bo_vm_mkwrite;
> + dev_priv->vm_ops.page_mkwrite = vmw_bo_vm_mkwrite;
> + dev_priv->bdev.vm_ops = &dev_priv->vm_ops;
>
> /*
>* Enable VRAM, but initially don't use it until SVGA is
> enabled and
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index bd6919b90519..f05fce52fbb4 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -95,6 +95,7 @@ struct vmw_fpriv {
> * @dx_query_ctx: DX context if this buffer object is used as a DX
> query MOB
> * @map: Kmap object for semi-persistent mappings
> * @res_prios: Eviction priority counts for attached resources
> + * @dirty: structure for user-space dirty-tracking
> */
> struct vmw_buffer_object {
> struct ttm_buffer_object base;
> @@ -105,6 +106,7 @@ struct vmw_buffer_object {
> /* Protected by reservation */
> struct ttm_bo_kmap_obj map;
> u32 res_prios[TTM_MAX_BO_PRIORITY];
> + struct vmw_bo_dirty *dirty;
> };
>
> /**
> @@ -135,7 +137,8 @@ struct vm
Re: [PATCH 7/9] drm/vmwgfx: Use an RBtree instead of linked list for MOB resources
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> With emulated coherent memory we need to be able to quickly look up
> a resource from the MOB offset. Instead of traversing a linked list
> with
> O(n) worst case, use an RBtree with O(log n) worst case complexity.
>
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 5 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 10 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 33 +-
> --
> 3 files changed, 32 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index 90ca866640fe..e8bc7a7ac031 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -464,6 +464,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
> struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
>
> WARN_ON(vmw_bo->dirty);
> + WARN_ON(!RB_EMPTY_ROOT(&vmw_bo->res_tree));
> vmw_bo_unmap(vmw_bo);
> kfree(vmw_bo);
> }
> @@ -480,6 +481,7 @@ static void vmw_user_bo_destroy(struct
> ttm_buffer_object *bo)
> struct vmw_buffer_object *vbo = &vmw_user_bo->vbo;
>
> WARN_ON(vbo->dirty);
> + WARN_ON(!RB_EMPTY_ROOT(&vbo->res_tree));
> vmw_bo_unmap(vbo);
> ttm_prime_object_kfree(vmw_user_bo, prime);
> }
> @@ -515,8 +517,7 @@ int vmw_bo_init(struct vmw_private *dev_priv,
> memset(vmw_bo, 0, sizeof(*vmw_bo));
> BUILD_BUG_ON(TTM_MAX_BO_PRIORITY <= 3);
> vmw_bo->base.priority = 3;
> -
> - INIT_LIST_HEAD(&vmw_bo->res_list);
> + vmw_bo->res_tree = RB_ROOT;
>
> ret = ttm_bo_init(bdev, &vmw_bo->base, size,
> ttm_bo_type_device, placement,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index f05fce52fbb4..81ebcd668038 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -90,7 +90,7 @@ struct vmw_fpriv {
> /**
> * struct vmw_buffer_object - TTM buffer object with vmwgfx
> additions
> * @base: The TTM buffer object
> - * @res_list: List of resources using this buffer object as a
> backing MOB
> + * @res_tree: RB tree of resources using this buffer object as a
> backing MOB
> * @pin_count: pin depth
> * @dx_query_ctx: DX context if this buffer object is used as a DX
> query MOB
> * @map: Kmap object for semi-persistent mappings
> @@ -99,7 +99,7 @@ struct vmw_fpriv {
> */
> struct vmw_buffer_object {
> struct ttm_buffer_object base;
> - struct list_head res_list;
> + struct rb_root res_tree;
> s32 pin_count;
> /* Not ref-counted. Protected by binding_mutex */
> struct vmw_resource *dx_query_ctx;
> @@ -147,8 +147,8 @@ struct vmw_res_func;
> * pin-count greater than zero. It is not on the resource LRU lists
> and its
> * backup buffer is pinned. Hence it can't be evicted.
> * @func: Method vtable for this resource. Immutable.
> + * @mob_node; Node for the MOB backup rbtree. Protected by @backup
> reserved.
> * @lru_head: List head for the LRU list. Protected by
> @dev_priv::resource_lock.
> - * @mob_head: List head for the MOB backup list. Protected by
> @backup reserved.
> * @binding_head: List head for the context binding list. Protected
> by
> * the @dev_priv::binding_mutex
> * @res_free: The resource destructor.
> @@ -169,8 +169,8 @@ struct vmw_resource {
> unsigned long backup_offset;
> unsigned long pin_count;
> const struct vmw_res_func *func;
> + struct rb_node mob_node;
> struct list_head lru_head;
> - struct list_head mob_head;
> struct list_head binding_head;
> struct vmw_resource_dirty *dirty;
> void (*res_free) (struct vmw_resource *res);
> @@ -743,7 +743,7 @@ void vmw_resource_dirty_update(struct
> vmw_resource *res, pgoff_t start,
> */
> static inline bool vmw_resource_mob_attached(const struct
> vmw_resource *res)
> {
> - return !list_empty(&res->mob_head);
> + return !RB_EMPTY_NODE(&res->mob_node);
> }
>
> /**
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index d35f4bd32cd9..ff9fe5650468 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -41,11 +41,24 @@
> void vmw_resource_mob_attach(struct vmw_resource *res)
> {
> struct vmw_buffer_object *backup = res->backup;
> + struct rb_node **new = &backup->res_tree.rb_node, *parent =
> NULL;
>
> lockdep_assert_held(&backup->base.resv->lock.base);
> res->used_prio = (res->res_dirty) ? res->func->dirty_prio :
> res->func->prio;
> - list_add_tail(&res->mob_head, &backup->res_list);
> +
> + while (*new) {
> + struct vmw_resource *this =
> + container_of(*new, struct vmw_resource,
> mob_node);
> +
> + parent = *
Re: [RFC] MAINTAINERS: Add Sam as reviewer for drm/panel
Hi Thierry et al. > > Sam has been helping out a lot with reviewing DRM panel patches. Add him > > as reviewer to help him do this important work. > > > > Signed-off-by: Thierry Reding > > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index c227d2818c98..3d199592fd2c 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5340,6 +5340,7 @@ T:git git://anongit.freedesktop.org/drm/drm-misc > > > > DRM PANEL DRIVERS > > M: Thierry Reding > > +R: Sam Ravnborg > > L: dri-devel@lists.freedesktop.org > > T: git git://anongit.freedesktop.org/drm/drm-misc > > S: Maintained > > I'm pretending that I know a little about the drm/panel/ subsystem, > so this makes good sense. > My response time will be decided on my day-job, but this is > like is is for all os us. > > I will push the patch myself when I am back in the weekend. > (To try out the dim tooling etc). I have used my new super-power and have pushed this to drm-misc-next, using "dim". Thanks, Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 54/98] drm: Fix drm_release() and device unplug
From: Noralf Trønnes
[ Upstream commit 3f04e0a6cfebf48152ac64502346cdc258811f79 ]
If userspace has open fd(s) when drm_dev_unplug() is run, it will result
in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
then later in drm_release() through the call to drm_put_dev().
Since userspace already holds a ref on drm_device through the drm_minor,
it's not necessary to add extra ref counting based on no open file
handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().
We now have this:
- Userpace holds a ref on drm_device as long as there's open fd(s)
- The driver holds a ref on drm_device as long as it's bound to the
struct device
When both sides are done with drm_device, it is released.
Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-nor...@tronnes.org
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/drm_drv.c | 6 +-
drivers/gpu/drm/drm_file.c | 6 ++
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 12e5e2be7890..7a59b8b3ed5a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -381,11 +381,7 @@ void drm_dev_unplug(struct drm_device *dev)
synchronize_srcu(&drm_unplug_srcu);
drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
- if (dev->open_count == 0)
- drm_dev_put(dev);
- mutex_unlock(&drm_global_mutex);
+ drm_dev_put(dev);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 46f48f245eb5..3f20f598cd7c 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -479,11 +479,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_file_free(file_priv);
- if (!--dev->open_count) {
+ if (!--dev->open_count)
drm_lastclose(dev);
- if (drm_dev_is_unplugged(dev))
- drm_put_dev(dev);
- }
+
mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 49/98] drm/tegra: hub: Fix dereference before check
From: Thierry Reding
[ Upstream commit 7cf77b273a8fc51e7de622fa6691abd4436a9a6b ]
Reported-by: Dan Carpenter
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/tegra/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 922a48d5a483..c7c612579270 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -378,14 +378,16 @@ static int tegra_shared_plane_atomic_check(struct
drm_plane *plane,
static void tegra_shared_plane_atomic_disable(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
- struct tegra_dc *dc = to_tegra_dc(old_state->crtc);
struct tegra_plane *p = to_tegra_plane(plane);
+ struct tegra_dc *dc;
u32 value;
/* rien ne va plus */
if (!old_state || !old_state->crtc)
return;
+ dc = to_tegra_dc(old_state->crtc);
+
/*
* XXX Legacy helpers seem to sometimes call ->atomic_disable() even
* on planes that are already disabled. Make sure we fallback to the
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 57/98] drm/meson: Uninstall IRQ handler
From: Jean-Philippe Brucker
[ Upstream commit 2d8f92897ad816f5dda54b2ed2fd9f2d7cb1abde ]
meson_drv_unbind() doesn't unregister the IRQ handler, which can lead to
use-after-free if the IRQ fires after unbind:
[ 64.656876] Unable to handle kernel paging request at virtual address
11706dbc
...
[ 64.662001] pc : meson_irq+0x18/0x30 [meson_drm]
I'm assuming that a similar problem could happen on the error path of
bind(), so uninstall the IRQ handler there as well.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Jean-Philippe Brucker
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-2-jean-philippe.bruc...@arm.com
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/meson/meson_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index c1115a96453f..a13704ab5d11 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -317,12 +317,14 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
ret = drm_dev_register(drm, 0);
if (ret)
- goto free_drm;
+ goto uninstall_irq;
drm_fbdev_generic_setup(drm, 32);
return 0;
+uninstall_irq:
+ drm_irq_uninstall(drm);
free_drm:
drm_dev_put(drm);
@@ -347,6 +349,7 @@ static void meson_drv_unbind(struct device *dev)
}
drm_dev_unregister(drm);
+ drm_irq_uninstall(drm);
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
drm_dev_put(drm);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.0 56/98] drm/meson: Fix invalid pointer in meson_drv_unbind()
From: Jean-Philippe Brucker
[ Upstream commit 776e78677f514ecddd12dba48b9040958999bd5a ]
meson_drv_bind() registers a meson_drm struct as the device's privdata,
but meson_drv_unbind() tries to retrieve a drm_device. This may cause a
segfault on shutdown:
[ 5194.593429] Unable to handle kernel NULL pointer dereference at virtual
address 0197
...
[ 5194.788850] Call trace:
[ 5194.791349] drm_dev_unregister+0x1c/0x118 [drm]
[ 5194.795848] meson_drv_unbind+0x50/0x78 [meson_drm]
Retrieve the right pointer in meson_drv_unbind().
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Jean-Philippe Brucker
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-1-jean-philippe.bruc...@arm.com
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/meson/meson_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 12ff47b13668..c1115a96453f 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -336,8 +336,8 @@ static int meson_drv_bind(struct device *dev)
static void meson_drv_unbind(struct device *dev)
{
- struct drm_device *drm = dev_get_drvdata(dev);
- struct meson_drm *priv = drm->dev_private;
+ struct meson_drm *priv = dev_get_drvdata(dev);
+ struct drm_device *drm = priv->drm;
if (priv->canvas) {
meson_canvas_free(priv->canvas, priv->canvas_id_osd1);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 43/68] drm: Fix drm_release() and device unplug
From: Noralf Trønnes
[ Upstream commit 3f04e0a6cfebf48152ac64502346cdc258811f79 ]
If userspace has open fd(s) when drm_dev_unplug() is run, it will result
in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
then later in drm_release() through the call to drm_put_dev().
Since userspace already holds a ref on drm_device through the drm_minor,
it's not necessary to add extra ref counting based on no open file
handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().
We now have this:
- Userpace holds a ref on drm_device as long as there's open fd(s)
- The driver holds a ref on drm_device as long as it's bound to the
struct device
When both sides are done with drm_device, it is released.
Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
Reviewed-by: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-nor...@tronnes.org
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/drm_drv.c | 6 +-
drivers/gpu/drm/drm_file.c | 6 ++
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ea4941da9b27..0201ccb22f4c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -381,11 +381,7 @@ void drm_dev_unplug(struct drm_device *dev)
synchronize_srcu(&drm_unplug_srcu);
drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
- if (dev->open_count == 0)
- drm_dev_put(dev);
- mutex_unlock(&drm_global_mutex);
+ drm_dev_put(dev);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ffa8dc35515f..e4ccb52c67ea 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -479,11 +479,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_file_free(file_priv);
- if (!--dev->open_count) {
+ if (!--dev->open_count)
drm_lastclose(dev);
- if (drm_dev_is_unplugged(dev))
- drm_put_dev(dev);
- }
+
mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 45/68] drm/meson: Fix invalid pointer in meson_drv_unbind()
From: Jean-Philippe Brucker
[ Upstream commit 776e78677f514ecddd12dba48b9040958999bd5a ]
meson_drv_bind() registers a meson_drm struct as the device's privdata,
but meson_drv_unbind() tries to retrieve a drm_device. This may cause a
segfault on shutdown:
[ 5194.593429] Unable to handle kernel NULL pointer dereference at virtual
address 0197
...
[ 5194.788850] Call trace:
[ 5194.791349] drm_dev_unregister+0x1c/0x118 [drm]
[ 5194.795848] meson_drv_unbind+0x50/0x78 [meson_drm]
Retrieve the right pointer in meson_drv_unbind().
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Jean-Philippe Brucker
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-1-jean-philippe.bruc...@arm.com
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/meson/meson_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 611ac340fb28..4a72fa53a1d5 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -317,8 +317,8 @@ static int meson_drv_bind(struct device *dev)
static void meson_drv_unbind(struct device *dev)
{
- struct drm_device *drm = dev_get_drvdata(dev);
- struct meson_drm *priv = drm->dev_private;
+ struct meson_drm *priv = dev_get_drvdata(dev);
+ struct drm_device *drm = priv->drm;
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 46/68] drm/meson: Uninstall IRQ handler
From: Jean-Philippe Brucker
[ Upstream commit 2d8f92897ad816f5dda54b2ed2fd9f2d7cb1abde ]
meson_drv_unbind() doesn't unregister the IRQ handler, which can lead to
use-after-free if the IRQ fires after unbind:
[ 64.656876] Unable to handle kernel paging request at virtual address
11706dbc
...
[ 64.662001] pc : meson_irq+0x18/0x30 [meson_drm]
I'm assuming that a similar problem could happen on the error path of
bind(), so uninstall the IRQ handler there as well.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Jean-Philippe Brucker
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-2-jean-philippe.bruc...@arm.com
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/meson/meson_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 4a72fa53a1d5..588b3b0c8315 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -300,10 +300,12 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
ret = drm_dev_register(drm, 0);
if (ret)
- goto free_drm;
+ goto uninstall_irq;
return 0;
+uninstall_irq:
+ drm_irq_uninstall(drm);
free_drm:
drm_dev_put(drm);
@@ -321,6 +323,7 @@ static void meson_drv_unbind(struct device *dev)
struct drm_device *drm = priv->drm;
drm_dev_unregister(drm);
+ drm_irq_uninstall(drm);
drm_kms_helper_poll_fini(drm);
drm_fbdev_cma_fini(priv->fbdev);
drm_mode_config_cleanup(drm);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 38/68] drm/tegra: hub: Fix dereference before check
From: Thierry Reding
[ Upstream commit 7cf77b273a8fc51e7de622fa6691abd4436a9a6b ]
Reported-by: Dan Carpenter
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/tegra/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 8f4fcbb515fb..bb97cad1eb69 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -378,14 +378,16 @@ static int tegra_shared_plane_atomic_check(struct
drm_plane *plane,
static void tegra_shared_plane_atomic_disable(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
- struct tegra_dc *dc = to_tegra_dc(old_state->crtc);
struct tegra_plane *p = to_tegra_plane(plane);
+ struct tegra_dc *dc;
u32 value;
/* rien ne va plus */
if (!old_state || !old_state->crtc)
return;
+ dc = to_tegra_dc(old_state->crtc);
+
/*
* XXX Legacy helpers seem to sometimes call ->atomic_disable() even
* on planes that are already disabled. Make sure we fallback to the
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 30/43] drm/meson: Fix invalid pointer in meson_drv_unbind()
From: Jean-Philippe Brucker
[ Upstream commit 776e78677f514ecddd12dba48b9040958999bd5a ]
meson_drv_bind() registers a meson_drm struct as the device's privdata,
but meson_drv_unbind() tries to retrieve a drm_device. This may cause a
segfault on shutdown:
[ 5194.593429] Unable to handle kernel NULL pointer dereference at virtual
address 0197
...
[ 5194.788850] Call trace:
[ 5194.791349] drm_dev_unregister+0x1c/0x118 [drm]
[ 5194.795848] meson_drv_unbind+0x50/0x78 [meson_drm]
Retrieve the right pointer in meson_drv_unbind().
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Jean-Philippe Brucker
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-1-jean-philippe.bruc...@arm.com
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/meson/meson_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 5deb44ac6791..1a1b0b9cf1fa 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -294,8 +294,8 @@ static int meson_drv_bind(struct device *dev)
static void meson_drv_unbind(struct device *dev)
{
- struct drm_device *drm = dev_get_drvdata(dev);
- struct meson_drm *priv = drm->dev_private;
+ struct meson_drm *priv = dev_get_drvdata(dev);
+ struct drm_device *drm = priv->drm;
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 31/43] drm/meson: Uninstall IRQ handler
From: Jean-Philippe Brucker
[ Upstream commit 2d8f92897ad816f5dda54b2ed2fd9f2d7cb1abde ]
meson_drv_unbind() doesn't unregister the IRQ handler, which can lead to
use-after-free if the IRQ fires after unbind:
[ 64.656876] Unable to handle kernel paging request at virtual address
11706dbc
...
[ 64.662001] pc : meson_irq+0x18/0x30 [meson_drm]
I'm assuming that a similar problem could happen on the error path of
bind(), so uninstall the IRQ handler there as well.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Jean-Philippe Brucker
Acked-by: Neil Armstrong
Signed-off-by: Neil Armstrong
Link:
https://patchwork.freedesktop.org/patch/msgid/20190322152657.13752-2-jean-philippe.bruc...@arm.com
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpu/drm/meson/meson_drv.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 1a1b0b9cf1fa..0608243c3387 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -277,10 +277,12 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
ret = drm_dev_register(drm, 0);
if (ret)
- goto free_drm;
+ goto uninstall_irq;
return 0;
+uninstall_irq:
+ drm_irq_uninstall(drm);
free_drm:
drm_dev_unref(drm);
@@ -298,6 +300,7 @@ static void meson_drv_unbind(struct device *dev)
struct drm_device *drm = priv->drm;
drm_dev_unregister(drm);
+ drm_irq_uninstall(drm);
drm_kms_helper_poll_fini(drm);
drm_fbdev_cma_fini(priv->fbdev);
drm_mode_config_cleanup(drm);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108879] [CIK] [regression] All opencl apps hangs indefinitely in si_create_context
https://bugs.freedesktop.org/show_bug.cgi?id=108879 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Marek Olšák --- Should be fixed by b58e5fb6f317be771326f98d498483e45942beaf Closing. -- 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 8/9] drm/vmwgfx: Implement an infrastructure for read-coherent resources
Minor nits below, otherwise
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> Similar to write-coherent resources, make sure that from the user-
> space
> point of view, GPU rendered contents is automatically available for
> reading by the CPU.
>
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 +
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 8 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 69 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 102
> +-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 2 +
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 3 +-
> 6 files changed, 176 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 3bd28fb97124..0065b138f450 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -42,6 +42,7 @@
> #include
> #include
>
> +
> static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
> struct vm_fault *vmf)
> {
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 81ebcd668038..00794415335e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -96,6 +96,7 @@ struct vmw_fpriv {
> * @map: Kmap object for semi-persistent mappings
> * @res_prios: Eviction priority counts for attached resources
> * @dirty: structure for user-space dirty-tracking
> + * @cleaning: Current validation sequence is cleaning.
> */
> struct vmw_buffer_object {
> struct ttm_buffer_object base;
> @@ -690,7 +691,8 @@ extern void vmw_resource_unreference(struct
> vmw_resource **p_res);
> extern struct vmw_resource *vmw_resource_reference(struct
> vmw_resource *res);
> extern struct vmw_resource *
> vmw_resource_reference_unless_doomed(struct vmw_resource *res);
> -extern int vmw_resource_validate(struct vmw_resource *res, bool
> intr);
> +extern int vmw_resource_validate(struct vmw_resource *res, bool
> intr,
> + bool dirtying);
> extern int vmw_resource_reserve(struct vmw_resource *res, bool
> interruptible,
> bool no_backup);
> extern bool vmw_resource_needs_backup(const struct vmw_resource
> *res);
> @@ -734,6 +736,8 @@ void vmw_resource_mob_attach(struct vmw_resource
> *res);
> void vmw_resource_mob_detach(struct vmw_resource *res);
> void vmw_resource_dirty_update(struct vmw_resource *res, pgoff_t
> start,
> pgoff_t end);
> +int vmw_resources_clean(struct vmw_buffer_object *vbo, pgoff_t
> start,
> + pgoff_t end, pgoff_t *num_prefault);
>
> /**
> * vmw_resource_mob_attached - Whether a resource currently has a
> mob attached
> @@ -1428,6 +1432,8 @@ int vmw_bo_dirty_add(struct vmw_buffer_object
> *vbo);
> void vmw_bo_dirty_transfer_to_res(struct vmw_resource *res);
> void vmw_bo_dirty_clear_res(struct vmw_resource *res);
> void vmw_bo_dirty_release(struct vmw_buffer_object *vbo);
> +void vmw_bo_dirty_unmap(struct vmw_buffer_object *vbo,
> + pgoff_t start, pgoff_t end);
> vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf);
> vm_fault_t vmw_bo_vm_mkwrite(struct vm_fault *vmf);
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
> index 87e4a73b1175..773ff30a4b60 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
> @@ -153,7 +153,6 @@ static void vmw_bo_dirty_scan_mkwrite(struct
> vmw_buffer_object *vbo)
> }
> }
>
> -
> /**
> * vmw_bo_dirty_scan - Scan for dirty pages and add them to the
> dirty
> * tracking structure
> @@ -171,6 +170,51 @@ void vmw_bo_dirty_scan(struct vmw_buffer_object
> *vbo)
> vmw_bo_dirty_scan_mkwrite(vbo);
> }
>
> +/**
> + * vmw_bo_dirty_pre_unmap - write-protect and pick up dirty pages
> before
> + * an unmap_mapping_range operation.
> + * @vbo: The buffer object,
> + * @start: First page of the range within the buffer object.
> + * @end: Last page of the range within the buffer object + 1.
> + *
> + * If we're using the _PAGETABLE scan method, we may leak dirty
> pages
> + * when calling unmap_mapping_range(). This function makes sure we
> pick
> + * up all dirty pages.
> + */
> +static void vmw_bo_dirty_pre_unmap(struct vmw_buffer_object *vbo,
> +pgoff_t start, pgoff_t end)
> +{
> + struct vmw_bo_dirty *dirty = vbo->dirty;
> + unsigned long offset = drm_vma_node_start(&vbo->base.vma_node);
> + struct address_space *mapping = vbo->base.bdev->dev_mapping;
> +
> + if (dirty->method != VMW_BO_DIRTY_PAGETABLE || start >= end)
> + return;
> +
> + apply_as_wrprotect(mapping, start + offset, end - start);
> + apply_as_clean(mapping, start + offset
Query on EVoC
Good day all, I'm Habeeb. Since applications for GSoC have closed, I'd like to know if I can still apply for projects through EVoC and what the deadline for doing this is. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] dt-bindings: display: Add GiantPlus GPM940B0 panel documentation
The GPM940B0 is a 3.0" 320x240 24-bit TFT LCD panel. Signed-off-by: Paul Cercueil Reviewed-by: Rob Herring --- Notes: v2: New patch v3: Add Rob's ack .../bindings/display/panel/giantplus,gpm940b0.txt| 12 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt diff --git a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt new file mode 100644 index ..3dab52f92c26 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt @@ -0,0 +1,12 @@ +GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel + +Required properties: +- compatible: should be "giantplus,gpm940b0" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.21.0.593.g511ec345e18 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] dt-bindings: Add header for the ingenic-drm driver bindings
Hi, Le sam. 20 avril 2019 à 14:23, Ezequiel Garcia a écrit : On Wed, 17 Apr 2019 at 10:48, Rob Herring wrote: On Sun, Apr 14, 2019 at 3:08 PM Paul Cercueil wrote: > > Add macros that can be used with the ingenic,lcd-mode property in the > devicetree node that corresponds to the ingenic-drm driver. DRM is a Linuxism. > > Signed-off-by: Paul Cercueil > Tested-by: Artur Rojek > --- > > Notes: > v2: No change > > v3: s/_DRM// > > include/dt-bindings/display/ingenic,drm.h | 28 DRM is a Linuxism... > 1 file changed, 28 insertions(+) > create mode 100644 include/dt-bindings/display/ingenic,drm.h > > diff --git a/include/dt-bindings/display/ingenic,drm.h b/include/dt-bindings/display/ingenic,drm.h > new file mode 100644 > index ..c749b8c346fc > --- /dev/null > +++ b/include/dt-bindings/display/ingenic,drm.h > @@ -0,0 +1,28 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Ingenic JZ47xx KMS driver Pretty sure this file is not a KMS driver. > + * > + * Copyright (C) 2019, Paul Cercueil > + */ > +#ifndef __INCLUDE_DT_BINDINGS_DISPLAY_INGENIC_DRM_H__ > +#define __INCLUDE_DT_BINDINGS_DISPLAY_INGENIC_DRM_H__ > + > +#define JZ_LCD_GENERIC_16BIT 0 > +#define JZ_LCD_GENERIC_18BIT 16 We have some generic properties for defining the bus width already. Plus, in many cases this can be implied by the panel compatible. The exceptions are cases such as when both the ctrlr and panel support multiple modes. In the same direction as Rob's comment, I'd like to see these decoupled from the register value. Ideally, we'd like to reuse this driver and its bindings for JZ4780, and these values are already different. Well they are not any different on the JZ4780, I just checked on the manual. But yes, I don't mind getting rid of that devicetree property and its corresponding bindings file. The major problem is that we don't have a way to map some of the values there to DRM macros. I sumitted a PR to add a MEDIA_BUS_FMT_RGB888_3X8_BE bus format (that I could detect to support 8-bit serial TFT panels, which is what the Ben Nanonote uses), but I miss a way to detect the special* TFT panels. I will leave these aside for now, but I want to support them eventually. Thanks, -Paul * "special" TFT panels have extra pins (CLS, SPL, REV, PS) and seem to be a thing from Sharp. Ingenic SoCs (as well as i.MX SoCs) have the required hardware to drive these panels. Thanks! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] media: uapi: Add RGB bus formats for the GiantPlus GPM940B0 panel
The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components are transferred sequentially on a 8-bit bus. Signed-off-by: Paul Cercueil --- Notes: v2: New patch v3: No change include/uapi/linux/media-bus-format.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index d6a5a3bfe6c4..f31724d6cd40 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x101b */ +/* RGB - next is 0x101d */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -54,6 +54,8 @@ #define MEDIA_BUS_FMT_RGB888_1X24 0x100a #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c +#define MEDIA_BUS_FMT_RGB888_3X8_BE0x101b +#define MEDIA_BUS_FMT_RGB888_3X8_LE0x101c #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 #define MEDIA_BUS_FMT_ARGB_1X320x100d -- 2.21.0.593.g511ec345e18 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad D330
Hi Jani,
When are the changes in drm-misc-next pushed?
I'm testing recent kernels that don't work with some models because
the dsi display problem you are aware. Works with 4.15 but not with
more recent kernels.
The model I have by going to sleep state and awake it gets the display on,
I want to see if this change makes the display behave different in recent
kernels in more ways than only rotating the display.
Thanks in advance.
El vie., 1 mar. 2019 a las 11:12, Jani Nikula
() escribió:
>
> On Sat, 23 Feb 2019, David Santamaría Rogado wrote:
> > Done Jani. I think it's ok now. Don't worry, at least I could get
> > little familiar with git send-email also with multiple patches :)
>
> Sorry about all the hassle, pushed to drm-misc-next, thanks for the
> patch.
>
> BR,
> Jani.
>
> >
> > El sáb., 23 feb. 2019 a las 22:19, David Santamaría Rogado
> > () escribió:
> >>
> >> Lenovo Ideapad D330 Pentium CPU version has 1920x1200 LCD.
> >> Console output gets rotated at boot as Miix 310.
> >>
> >> Signed-off-by: David Santamaría Rogado
> >> ---
> >> drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >> index 52e445bb1aa5..521aff99b08a 100644
> >> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >> @@ -80,6 +80,12 @@ static const struct drm_dmi_panel_orientation_data
> >> lcd800x1280_rightside_up = {
> >> .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> >> };
> >>
> >> +static const struct drm_dmi_panel_orientation_data
> >> lcd1200x1920_rightside_up = {
> >> + .width = 1200,
> >> + .height = 1920,
> >> + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> >> +};
> >> +
> >> static const struct dmi_system_id orientation_data[] = {
> >> { /* Acer One 10 (S1003) */
> >> .matches = {
> >> @@ -148,6 +154,13 @@ static const struct dmi_system_id orientation_data[]
> >> = {
> >> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX
> >> 320-10ICR"),
> >> },
> >> .driver_data = (void *)&lcd800x1280_rightside_up,
> >> + }, {/* Lenovo Ideapad D330 */
> >> + .matches = {
> >> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
> >> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> >> D330-10IGM"),
> >> + },
> >> + .driver_data = (void *)&lcd1200x1920_rightside_up,
> >> }, {/* VIOS LTH17 */
> >> .matches = {
> >> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
> >> --
> >> 2.20.1
> >>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sched: Fix description of drm_sched_stop
Since commit 222b5f044159 ("drm/sched: Refactor ring mirror list
handling."), drm_sched_hw_job_reset is no longer there, so let's adjust
the doc comment accordingly.
Signed-off-by: Jonathan Neuschäfer
---
drivers/gpu/drm/scheduler/sched_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 19fc601c9eeb..a1bec2779e76 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -366,10 +366,9 @@ void drm_sched_increase_karma(struct drm_sched_job *bad)
EXPORT_SYMBOL(drm_sched_increase_karma);
/**
- * drm_sched_hw_job_reset - stop the scheduler if it contains the bad job
+ * drm_sched_stop - stop the scheduler
*
* @sched: scheduler instance
- * @bad: bad scheduler job
*
*/
void drm_sched_stop(struct drm_gpu_scheduler *sched)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/panel: simple: Add GiantPlus GPM940B0 panel support
The GiantPlus GPM940B0 is a simple 3.0" 320x240 24-bit TFT panel.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
Notes:
v2: Change bus format to MEDIA_BUS_FMT_RGB888_3X8_BE
v3: No change
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 569be4efd8d1..a81b35269a78 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1208,6 +1208,31 @@ static const struct panel_desc giantplus_gpg482739qs5 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct display_timing giantplus_gpm940b0_timing = {
+ .pixelclock = { 1350, 2700, 2750 },
+ .hactive = { 320, 320, 320 },
+ .hfront_porch = { 14, 686, 718 },
+ .hback_porch = { 50, 70, 255 },
+ .hsync_len = { 1, 1, 1 },
+ .vactive = { 240, 240, 240 },
+ .vfront_porch = { 1, 1, 179 },
+ .vback_porch = { 1, 21, 31 },
+ .vsync_len = { 1, 1, 6 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc giantplus_gpm940b0 = {
+ .timings = &giantplus_gpm940b0_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 60,
+ .height = 45,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_3X8_BE,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+};
+
static const struct display_timing hannstar_hsd070pww1_timing = {
.pixelclock = { 6430, 7110, 8200 },
.hactive = { 1280, 1280, 1280 },
@@ -2666,6 +2691,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "giantplus,gpg482739qs5",
.data = &giantplus_gpg482739qs5
+ }, {
+ .compatible = "giantplus,gpm940b0",
+ .data = &giantplus_gpm940b0,
}, {
.compatible = "hannstar,hsd070pww1",
.data = &hannstar_hsd070pww1,
--
2.21.0.593.g511ec345e18
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: ion: solve warning symbol was not declared
These changes solve warning symbol was not declared in the functions:
ion_carveout_heap_create and ion_chunk_heap_create
Signed-off-by: Oscar Gomez Fuente
---
drivers/staging/android/ion/ion_carveout_heap.c | 2 +-
drivers/staging/android/ion/ion_chunk_heap.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
b/drivers/staging/android/ion/ion_carveout_heap.c
index bb9d614..3f359ae 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -103,7 +103,7 @@ static struct ion_heap_ops carveout_heap_ops = {
.unmap_kernel = ion_heap_unmap_kernel,
};
-struct ion_heap *ion_carveout_heap_create(phys_addr_t base, size_t size)
+static inline struct ion_heap *ion_carveout_heap_create(phys_addr_t base,
size_t size)
{
struct ion_carveout_heap *carveout_heap;
int ret;
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
b/drivers/staging/android/ion/ion_chunk_heap.c
index 3cdde9c..7e44344 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -107,7 +107,7 @@ static struct ion_heap_ops chunk_heap_ops = {
.unmap_kernel = ion_heap_unmap_kernel,
};
-struct ion_heap *ion_chunk_heap_create(phys_addr_t base, size_t size, size_t
chunk_size)
+static inline struct ion_heap *ion_chunk_heap_create(phys_addr_t base, size_t
size, size_t chunk_size)
{
struct ion_chunk_heap *chunk_heap;
int ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/dp: Use non-cyclic idr
From: Leo Li
In preparation for adding aux devices for DP MST, make the IDR
non-cyclic. That way, hotplug cycling MST devices won't needlessly
increment the minor version index.
Signed-off-by: Leo Li
---
drivers/gpu/drm/drm_dp_aux_dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 0e4f25d..6d84611 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -80,8 +80,7 @@ static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct
drm_dp_aux *aux)
kref_init(&aux_dev->refcount);
mutex_lock(&aux_idr_mutex);
- index = idr_alloc_cyclic(&aux_idr, aux_dev, 0, DRM_AUX_MINORS,
-GFP_KERNEL);
+ index = idr_alloc(&aux_idr, aux_dev, 0, DRM_AUX_MINORS, GFP_KERNEL);
mutex_unlock(&aux_idr_mutex);
if (index < 0) {
kfree(aux_dev);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/dp_mst: Expose build_mst_prop_path()
From: Leo Li
To give identifiable attributes to MST DP aux devices, we can use the
MST relative address. Expose this function for later use.
Signed-off-by: Leo Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
include/drm/drm_dp_mst_helper.h | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2ab16c9..86ff8e2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1120,7 +1120,7 @@ static void drm_dp_check_mstb_guid(struct
drm_dp_mst_branch *mstb, u8 *guid)
}
}
-static void build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
+void drm_dp_build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
int pnum,
char *proppath,
size_t proppath_size)
@@ -1202,7 +1202,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (created && !port->input) {
char proppath[255];
- build_mst_prop_path(mstb, port->port_num, proppath,
sizeof(proppath));
+ drm_dp_build_mst_prop_path(mstb, port->port_num, proppath,
sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
if (!port->connector) {
/* remove it from the port list */
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 371cc28..81c8d79 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -602,6 +602,10 @@ void drm_dp_mst_deallocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr,
int pbn);
+void drm_dp_build_mst_prop_path(const struct drm_dp_mst_branch *mstb,
+ int pnum,
+ char *proppath,
+ size_t proppath_size);
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/dp_mst: Register AUX devices for MST ports
From: Ville Syrjälä
All available downstream ports - physical and logical - are exposed for
each MST device. They are listed in /dev/, following the same naming
scheme as SST devices by appending an incremental ID.
Additionally, a 'path' attribute is attached to the device. This is to
allow udev to provide more identifiable symlinks to these devices,
similar to /dev/disks. For example, adding the following udev rule:
SUBSYSTEMS=="drm_dp_aux_dev", ATTR{path}=="?*",
SYMLINK+="drm_dp_aux/by-path/$attr{path}"
With a MST topology like so:
+-+
| ASIC |
+-+
Conn-0|
|
+v+
+| MST HUB |+
|+-+|
| |
|Port-1 Port-2|
+-v-+ +-v-+
| MST | | SST |
| Display | | Display |
+---+ +---+
|Port-1
x
Will create the following symlinks in 'drm_dp_aux/by-path/':
AUX Device Name | MST Device
--+--
card0_sst:0 (*) | MST Hub
card0_mst:0-1 | MST Display
card0_mst:0-1-1 | MST Display's disconnected DP out
card0_mst:0-1-8 | MST Display's internal sink
card0_mst:0-2 | SST Display
(*) Note that the first digit is suppose to mean 'Connector ID'.
However, that's only true for 'mst:' paths. A TODO item has been left to
address this.
Although all downstream ports are exposed, only some will work. On
certain MST displays, the upstream physical port will ACK DPCD reads.
However, reads on the local logical port to the internal sink will
*NAK*. i.e. reading mst:0-1 ACKs, but mst:0-1-8 NAKs.
There may also be duplicates. Some displays will return the same GUID
when reading DPCD from both mst:0-1 and mst:0-1-8.
There are some device-dependent behavior as well. The MST hub used
during testing will actually *ACK* read requests on a disconnected
physical port, whereas the MST displays will NAK.
In light of these discrepancies, it's simpler to expose all downstream
ports - both physical and logical - and let the user decide what to use.
Signed-off-by: Ville Syrjälä
Signed-off-by: Leo Li
---
drivers/gpu/drm/drm_dp_aux_dev.c | 53 -
drivers/gpu/drm/drm_dp_mst_topology.c | 103 +-
include/drm/drm_dp_helper.h | 4 ++
include/drm/drm_dp_mst_helper.h | 6 ++
4 files changed, 151 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 6d84611..4218bbf 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -114,10 +115,50 @@ static ssize_t name_show(struct device *dev,
return res;
}
+
+static int is_drm_primary_device(struct device *dev, void *data)
+{
+ return strstr(dev_name(dev), "card") != NULL;
+}
+
+static ssize_t path_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct drm_dp_aux_dev *aux_dev =
+ drm_dp_aux_dev_get_by_minor(MINOR(dev->devt));
+ struct drm_dp_aux *aux = aux_dev->aux;
+ struct drm_dp_mst_port *port;
+ struct device *card;
+ char temp[64];
+ ssize_t res;
+
+ card = device_find_child(dev->parent, NULL,
+is_drm_primary_device);
+
+ if (!aux->is_remote) {
+ /*
+* TODO: AUX index does not correlate with connector ID. See if
+* connector ID can be used instead.
+*/
+ res = sprintf(buf, "%s_%s:%d\n",
+ dev_name(card), "sst", aux_dev->index);
+ return res;
+ }
+
+ port = container_of(aux, struct drm_dp_mst_port, aux);
+ drm_dp_build_mst_prop_path(port->parent, port->port_num,
+ temp, sizeof(temp));
+ res = sprintf(buf, "%s_%s\n", dev_name(card), temp);
+
+ return res;
+}
+
static DEVICE_ATTR_RO(name);
+static DEVICE_ATTR_RO(path);
static struct attribute *drm_dp_aux_attrs[] = {
&dev_attr_name.attr,
+ &dev_attr_path.attr,
NULL,
};
ATTRIBUTE_GROUPS(drm_dp_aux);
@@ -160,7 +201,11 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb, struct
iov_iter *to)
break;
}
- res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+ if (aux_dev->aux->is_remote)
+ res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
todo);
+ else
+ res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+
if (res <= 0)
break;
@@ -207,7 +252,11 @@ static ssize_t auxdev_write_iter(str
Re: [PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
On Wed, Apr 17, 2019 at 2:57 AM Gerd Hoffmann wrote: > > On Fri, Apr 12, 2019 at 04:34:20PM -0700, Chia-I Wu wrote: > > Hi, > > > > I am still new to virgl, and missed the last round of discussion about > > resource_create_v2. > > > > From the discussion below, semantically resource_create_v2 creates a host > > resource object _without_ any storage; memory_create creates a host memory > > object which provides the storage. Is that correct? > > Right now all resource_create_* variants create a resource object with > host storage. memory_create creates guest storage, and > resource_attach_memory binds things together. Then you have to transfer > the data. > > Hmm, maybe we need a flag indicating that host storage is not needed, > for resources where we want establish some kind of shared mapping later > on. > > > Do we expect these new commands to be supported by OpenGL, which does not > > separate resources and memories? > > Well, for opengl you need a 1:1 relationship between memory region and > resource. > > > > Yes, even though it is not clear yet how we are going to handle > > > host-allocated buffers in the vhost-user case ... > > > > This might be another dumb question, but is this only an issue for > > vhost-user(-gpu) case? What mechanisms are used to map host dma-buf into > > the guest address space? > > qemu can change the address space, that includes mmap()ing stuff there. > An external vhost-user process can't do this, it can only read the > address space layout, and read/write from/to guest memory. > > > But one needs to create the resource first to know which memory types can > > be attached to it. I think the metadata needs to be returned with > > resource_create_v2. > > There is a resource_info reply for that. The memory type should probably be in resource_create_v2, not in the reply. The metadata will be different based on the memory heap it's allocated from. Also, not all heaps need to be exposed to the guest kernel. For example, device local memory in Vulkan could be un-mappable. In fact, for resources that are not host visible we might be better off sidestepping the kernel altogether and tracking allocation in guest userspace. Here is an example of memory types the guest kernel may be interested in (based on i965): Type 0 --> DEVICE_LOCAL_BIT | HOST_VISIBLE_BIT | HOST_COHERENT_BIT | HOST_CACHED_BIT | RENDERER_ALLOCATED (Vulkan) Type 1 --> HOST_VISIBLE_BIT | HOST_COHERENT_BIT | EXTERNAL_ALLOCATED (gbm write combine) Type 2 --> HOST_VISIBLE_BIT | HOST_COHERENT_BIT | GUEST_ALLOCATED (guest allocated memory, which I assume is also write combine) Type 3 --> HOST_VISIBLE_BIT | HOST_CACHED | EXTERNAL_ALLOCATED (gbm cached memory) > > > That should be good enough. But by returning alignments, we can minimize > > the gaps when attaching multiple resources, especially when the resources > > are only used by GPU. > > We can add alignments to the resource_info reply. > > cheers, > Gerd > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] ttm: wait mem space if user allow while gpu busy
Acked-by: Prike Liang
Thanks,
Prike
-Original Message-
From: Chunming Zhou
Sent: Monday, April 22, 2019 6:39 PM
To: dri-devel@lists.freedesktop.org
Cc: Liang, Prike ; Zhou, David(ChunMing)
Subject: [PATCH] ttm: wait mem space if user allow while gpu busy
heavy gpu job could occupy memory long time, which could lead to other user
fail to get memory.
Change-Id: I0b322d98cd76e5ac32b00462bbae8008d76c5e11
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index
7c484729f9b2..6c596cc24bec 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -830,8 +830,10 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
if (mem->mm_node)
break;
ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
- if (unlikely(ret != 0))
- return ret;
+ if (unlikely(ret != 0)) {
+ if (!ctx || ctx->no_wait_gpu || ret != -EBUSY)
+ return ret;
+ }
} while (1);
mem->mem_type = mem_type;
return ttm_bo_add_move_fence(bo, man, mem);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm: make legacy support code optional
This series attempts to make the legacy support core code removalable at build time, if no drivers require it. It reduces code size of the core drm.ko by ~10%. It's also available in https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-legacy-cleanup The first patch has Daniels r-b on it, but I've moved DRM_VM selection in the v2. The rest just move code around first, then the last 3 actually make the legacy code removable. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v2)
From: Dave Airlie
There was a nouveau DDX that relied on legacy context ioctls to work,
but we fixed it years ago, give distros that have a modern DDX the
option to break the uAPI and close the mess of holes that legacy
context support is.
Full context of the story:
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine
Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.
The previous attempt was
commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
Author: Daniel Vetter
Date: Thu Aug 8 15:41:21 2013 +0200
drm: mark context support as a legacy subsystem
but this had to be reverted
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie
Date: Fri Sep 20 08:32:59 2013 +1000
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the
previous attempts
- drop the part touching the drm hw lock, that should be a separate
patch.
Signed-off-by: Peter Antoine (v2)
Cc: Peter Antoine (v2)
Reviewed-by: Peter Antoine
Signed-off-by: Daniel Vetter
v2: move DRM_VM dependency into legacy config.
Cc: sta...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig | 12 +++-
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +--
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index 00cd9ab8948d..3ae7a4cfc6bb 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -17,10 +17,20 @@ config DRM_NOUVEAU
select INPUT if ACPI && X86
select THERMAL if ACPI && X86
select ACPI_VIDEO if ACPI && X86
- select DRM_VM
help
Choose this option for open-source NVIDIA support.
+config NOUVEAU_LEGACY_CTX_SUPPORT
+ bool "Nouveau legacy context support"
+ select DRM_VM
+ default y
+ help
+ There was a version of the nouveau DDX that relied on legacy
+ ctx ioctls not erroring out. But that was back in time a long
+ ways, so offer a way to disable it now. For uapi compat with
+ old nouveau ddx this should be on by default, but modern distros
+ should consider turning it off.
+
config NOUVEAU_PLATFORM_DRIVER
bool "Nouveau (NVIDIA) SoC GPUs"
depends on DRM_NOUVEAU && ARCH_TEGRA
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 5020265bfbd9..6ab9033f49da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1094,8 +1094,11 @@ nouveau_driver_fops = {
static struct drm_driver
driver_stub = {
.driver_features =
- DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER |
- DRIVER_KMS_LEGACY_CONTEXT,
+ DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER
+#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT)
+ | DRIVER_KMS_LEGACY_CONTEXT
+#endif
+ ,
.open = nouveau_drm_open,
.postclose = nouveau_drm_postclose,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/legacy: move drm_legacy_master_rmmaps to non-driver legacy header.
From: Dave Airlie This isn't used by drivers, and won't be in the future. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_legacy.h | 3 +++ include/drm/drm_legacy.h | 2 -- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h index 280fbeb846ff..e6bf1a94374b 100644 --- a/drivers/gpu/drm/drm_legacy.h +++ b/drivers/gpu/drm/drm_legacy.h @@ -81,6 +81,9 @@ int __drm_legacy_mapbufs(struct drm_device *, void *, int *, int (*)(void *, int, unsigned long, struct drm_buf *), struct drm_file *); +void drm_legacy_master_rmmaps(struct drm_device *dev, + struct drm_master *master); + #ifdef CONFIG_DRM_VM void drm_legacy_vma_flush(struct drm_device *d); #else diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h index 3e99ab69c122..2182a56ac421 100644 --- a/include/drm/drm_legacy.h +++ b/include/drm/drm_legacy.h @@ -162,8 +162,6 @@ int drm_legacy_addmap(struct drm_device *d, resource_size_t offset, struct drm_local_map *drm_legacy_findmap(struct drm_device *dev, unsigned int token); void drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map); int drm_legacy_rmmap_locked(struct drm_device *d, struct drm_local_map *map); -void drm_legacy_master_rmmaps(struct drm_device *dev, - struct drm_master *master); struct drm_local_map *drm_legacy_getsarea(struct drm_device *dev); int drm_legacy_mmap(struct file *filp, struct vm_area_struct *vma); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] drm/legacy: move map cleanups into drm_bufs.c
From: Dave Airlie
This makes it easier to clean this up later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_drv.c| 5 +
drivers/gpu/drm/drm_legacy.h | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index e407adb033e7..bfc419ed9d6c 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -584,6 +584,14 @@ void drm_legacy_master_rmmaps(struct drm_device *dev,
struct drm_master *master)
mutex_unlock(&dev->struct_mutex);
}
+void drm_legacy_rmmaps(struct drm_device *dev)
+{
+ struct drm_map_list *r_list, *list_temp;
+
+ list_for_each_entry_safe(r_list, list_temp, &dev->maplist, head)
+ drm_legacy_rmmap(dev, r_list->map);
+}
+
/* The rmmap ioctl appears to be unnecessary. All mappings are torn down on
* the last close of the device, and this is necessary for cleanup when things
* exit uncleanly. Therefore, having userland manually remove mappings seems
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 50d849d1bc6e..15b0fd5adaaf 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1038,8 +1038,6 @@ EXPORT_SYMBOL(drm_dev_register);
*/
void drm_dev_unregister(struct drm_device *dev)
{
- struct drm_map_list *r_list, *list_temp;
-
if (drm_core_check_feature(dev, DRIVER_LEGACY))
drm_lastclose(dev);
@@ -1056,8 +1054,7 @@ void drm_dev_unregister(struct drm_device *dev)
if (dev->agp)
drm_pci_agp_destroy(dev);
- list_for_each_entry_safe(r_list, list_temp, &dev->maplist, head)
- drm_legacy_rmmap(dev, r_list->map);
+ drm_legacy_rmmaps(dev);
remove_compat_control_link(dev);
drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index e6bf1a94374b..3dc626090fcb 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -83,6 +83,7 @@ int __drm_legacy_mapbufs(struct drm_device *, void *, int *,
void drm_legacy_master_rmmaps(struct drm_device *dev,
struct drm_master *master);
+void drm_legacy_rmmaps(struct drm_device *dev);
#ifdef CONFIG_DRM_VM
void drm_legacy_vma_flush(struct drm_device *d);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] drm/legacy: move init/destroy of struct members into inlines
From: Dave Airlie
This will allow easier removal later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_drv.c| 10 +++---
drivers/gpu/drm/drm_legacy.h | 14 ++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 18f45f9a955c..e4f36c5ccfcd 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -659,20 +659,16 @@ int drm_dev_init(struct drm_device *dev,
/* no per-device feature limits by default */
dev->driver_features = ~0u;
+ drm_legacy_init_members(dev);
INIT_LIST_HEAD(&dev->filelist);
INIT_LIST_HEAD(&dev->filelist_internal);
INIT_LIST_HEAD(&dev->clientlist);
- INIT_LIST_HEAD(&dev->ctxlist);
- INIT_LIST_HEAD(&dev->vmalist);
- INIT_LIST_HEAD(&dev->maplist);
INIT_LIST_HEAD(&dev->vblank_event_list);
- spin_lock_init(&dev->buf_lock);
spin_lock_init(&dev->event_lock);
mutex_init(&dev->struct_mutex);
mutex_init(&dev->filelist_mutex);
mutex_init(&dev->clientlist_mutex);
- mutex_init(&dev->ctxlist_mutex);
mutex_init(&dev->master_mutex);
dev->anon_inode = drm_fs_inode_new();
@@ -724,7 +720,7 @@ int drm_dev_init(struct drm_device *dev,
err_free:
put_device(dev->dev);
mutex_destroy(&dev->master_mutex);
- mutex_destroy(&dev->ctxlist_mutex);
+ drm_legacy_destroy_members(dev);
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
mutex_destroy(&dev->struct_mutex);
@@ -800,7 +796,7 @@ void drm_dev_fini(struct drm_device *dev)
put_device(dev->dev);
mutex_destroy(&dev->master_mutex);
- mutex_destroy(&dev->ctxlist_mutex);
+ drm_legacy_destroy_members(dev);
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
mutex_destroy(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index ef419d500e51..20c4befc476b 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -136,5 +136,19 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
int drm_legacy_sg_free(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+static inline void drm_legacy_init_members(struct drm_device *dev)
+{
+ INIT_LIST_HEAD(&dev->ctxlist);
+ INIT_LIST_HEAD(&dev->vmalist);
+ INIT_LIST_HEAD(&dev->maplist);
+ spin_lock_init(&dev->buf_lock);
+ mutex_init(&dev->ctxlist_mutex);
+}
+
+static inline void drm_legacy_destroy_members(struct drm_device *dev)
+{
+ mutex_destroy(&dev->ctxlist_mutex);
+}
+
void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct drm_master
*master);
#endif /* __DRM_LEGACY_H__ */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] drm/legacy: move legacy dev reinit into an inline
From: Dave Airlie
This moves the legacy dev reinit into a legacy inline,
also removes some unneeded inlines now.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_file.c | 24
drivers/gpu/drm/drm_legacy.h | 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 9701469a6e93..263fbef73fe5 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -425,30 +425,6 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
return 0;
}
-static void drm_legacy_dev_reinit(struct drm_device *dev)
-{
- if (dev->irq_enabled)
- drm_irq_uninstall(dev);
-
- mutex_lock(&dev->struct_mutex);
-
- drm_legacy_agp_clear(dev);
-
- drm_legacy_sg_cleanup(dev);
- drm_legacy_vma_flush(dev);
- drm_legacy_dma_takedown(dev);
-
- mutex_unlock(&dev->struct_mutex);
-
- dev->sigdata.lock = NULL;
-
- dev->context_flag = 0;
- dev->last_context = 0;
- dev->if_version = 0;
-
- DRM_DEBUG("lastclose completed\n");
-}
-
void drm_lastclose(struct drm_device * dev)
{
DRM_DEBUG("\n");
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index 20c4befc476b..8ee2de06f999 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -150,5 +150,29 @@ static inline void drm_legacy_destroy_members(struct
drm_device *dev)
mutex_destroy(&dev->ctxlist_mutex);
}
+static inline void drm_legacy_dev_reinit(struct drm_device *dev)
+{
+ if (dev->irq_enabled)
+ drm_irq_uninstall(dev);
+
+ mutex_lock(&dev->struct_mutex);
+
+ drm_legacy_agp_clear(dev);
+
+ drm_legacy_sg_cleanup(dev);
+ drm_legacy_vma_flush(dev);
+ drm_legacy_dma_takedown(dev);
+
+ mutex_unlock(&dev->struct_mutex);
+
+ dev->sigdata.lock = NULL;
+
+ dev->context_flag = 0;
+ dev->last_context = 0;
+ dev->if_version = 0;
+
+ DRM_DEBUG("lastclose completed\n");
+}
+
void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct drm_master
*master);
#endif /* __DRM_LEGACY_H__ */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/12] drm/radeon: drop unused ati pcigart include.
From: Dave Airlie Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/radeon_drv.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.h b/drivers/gpu/drm/radeon/radeon_drv.h index afef2d9fccd8..173deb463414 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.h +++ b/drivers/gpu/drm/radeon/radeon_drv.h @@ -35,7 +35,6 @@ #include #include -#include #include "radeon_family.h" /* General customization: -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] drm/legacy: don't include any of ati_pcigart in legacy.
From: Dave Airlie This could probably be done with Kconfig somehow, but I failed in my first 2 minute attempt. Signed-off-by: Dave Airlie --- drivers/gpu/drm/ati_pcigart.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c index 2362f07fe1fc..0420a28f770a 100644 --- a/drivers/gpu/drm/ati_pcigart.c +++ b/drivers/gpu/drm/ati_pcigart.c @@ -5,6 +5,7 @@ * \author Gareth Hughes */ +#if IS_ENABLED(CONFIG_DRM_LEGACY) /* * Created: Wed Dec 13 21:52:19 2000 by gar...@valinux.com * @@ -203,3 +204,4 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct drm_ati_pcigart_info *ga return ret; } EXPORT_SYMBOL(drm_ati_pcigart_init); +#endif -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/12] drm: allow removal of legacy codepaths (v4)
From: Dave Airlie
If you don't want the legacy drivers, then lets get rid of all the
legacy codepaths from the core module.
This drop the size of drm.ko for me by about 10%.
38051574224192 392129 5fbc1
../../drm-next-build/drivers/gpu/drm/drm.ko
35173672984192 363226 58ada
../../drm-next-build/drivers/gpu/drm/drm.ko
v2: drop drm_lock as well, fix some DMA->DRM typos
v3: avoid ifdefs in mainline code
v4: rework ioctl defs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Makefile| 7 ++---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioc32.c | 13 +++-
drivers/gpu/drm/drm_ioctl.c | 55 +++--
drivers/gpu/drm/drm_irq.c | 2 ++
drivers/gpu/drm/drm_legacy.h| 42 +++--
drivers/gpu/drm/drm_vm.c| 2 ++
drivers/gpu/drm/nouveau/Kconfig | 1 +
8 files changed, 93 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7ebae3d45505..340e075f6e06 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -3,11 +3,9 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-drm-y := drm_auth.o drm_bufs.o drm_cache.o \
- drm_context.o drm_dma.o \
+drm-y := drm_auth.o drm_cache.o \
drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \
- drm_lock.o drm_memory.o drm_drv.o \
- drm_scatter.o drm_pci.o \
+ drm_memory.o drm_drv.o drm_pci.o \
drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
drm_encoder_slave.o \
@@ -21,6 +19,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_atomic_uapi.o
+drm-$(CONFIG_DRM_LEGACY) += drm_bufs.o drm_context.o drm_dma.o drm_scatter.o
drm_lock.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index d9a483a5fce0..e19ac7ca602d 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -71,8 +71,10 @@ int drm_legacy_modeset_ctl_ioctl(struct drm_device *dev,
void *data,
/* drm_irq.c */
/* IOCTLS */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
int drm_legacy_irq_control(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+#endif
int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 0e3043e08c69..374b372da58a 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -156,6 +156,7 @@ static int compat_drm_setunique(struct file *file, unsigned
int cmd,
return -EINVAL;
}
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
typedef struct drm_map32 {
u32 offset; /* Requested physical address (0 for SAREA) */
u32 size; /* Requested physical size (bytes) */
@@ -239,6 +240,7 @@ static int compat_drm_rmmap(struct file *file, unsigned int
cmd,
map.handle = compat_ptr(handle);
return drm_ioctl_kernel(file, drm_legacy_rmmap_ioctl, &map, DRM_AUTH);
}
+#endif
typedef struct drm_client32 {
int idx;/* Which client desired? */
@@ -301,6 +303,7 @@ static int compat_drm_getstats(struct file *file, unsigned
int cmd,
return 0;
}
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
typedef struct drm_buf_desc32 {
int count; /* Number of buffers of this size */
int size;/* Size in bytes */
@@ -604,6 +607,7 @@ static int compat_drm_dma(struct file *file, unsigned int
cmd,
return 0;
}
+#endif
#if IS_ENABLED(CONFIG_AGP)
typedef struct drm_agp_mode32 {
@@ -748,6 +752,7 @@ static int compat_drm_agp_unbind(struct file *file,
unsigned int cmd,
}
#endif /* CONFIG_AGP */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
typedef struct drm_scatter_gather32 {
u32 size; /**< In bytes -- will round to page boundary */
u32 handle; /**< Used for mapping / unmapping */
@@ -788,7 +793,7 @@ static int compat_drm_sg_free(struct file *file, unsigned
int cmd,
return drm_ioctl_kernel(file, drm_legacy_sg_free, &request,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY);
}
-
+#endif
#if defined(CONFIG_X86)
typedef struct drm_update_draw32 {
drm_drawable_t handle;
@@ -903,10 +908,13 @@ static struct {
#define DRM_IOCTL32_DEF(n, f) [DRM_IOCTL_NR(n##32)] = {.fn = f, .name = #n}
DRM_IOCTL32_DEF(DRM_IOCTL_VERSION, compat_drm_version),
DRM_IOCTL32_DEF(DRM_IOCTL_GET_UNIQUE, compat_drm_getunique),
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
[PATCH 12/12] drm/legacy: remove some legacy lock struct members
From: Dave Airlie
This removes these unless legacy is enabled.
The lock count init is unneeded anyways since it's kzalloc.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_auth.c | 4 ++--
drivers/gpu/drm/drm_file.c | 1 -
drivers/gpu/drm/drm_legacy.h | 10 ++
include/drm/drm_auth.h | 2 ++
include/drm/drm_file.h | 2 ++
5 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index ef8c4353829b..c3df628bc048 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -103,8 +103,8 @@ struct drm_master *drm_master_create(struct drm_device *dev)
return NULL;
kref_init(&master->refcount);
- spin_lock_init(&master->lock.spinlock);
- init_waitqueue_head(&master->lock.lock_queue);
+
+ drm_master_legacy_init(master);
idr_init(&master->magic_map);
master->dev = dev;
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 263fbef73fe5..233f114d2186 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -128,7 +128,6 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
/* for compatibility root is always authenticated */
file->authenticated = capable(CAP_SYS_ADMIN);
- file->lock_count = 0;
INIT_LIST_HEAD(&file->lhead);
INIT_LIST_HEAD(&file->fbs);
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index 4200e6bd3778..5d97c06d78e4 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -233,4 +233,14 @@ void drm_legacy_lock_master_cleanup(struct drm_device
*dev, struct drm_master *m
#else
static inline void drm_legacy_lock_master_cleanup(struct drm_device *dev,
struct drm_master *master) {}
#endif
+
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
+static inline void drm_master_legacy_init(struct drm_master *master)
+{
+ spin_lock_init(&master->lock.spinlock);
+ init_waitqueue_head(&master->lock.lock_queue);
+}
+#else
+static inline void drm_master_legacy_init(struct drm_master *master) {}
+#endif
#endif /* __DRM_LEGACY_H__ */
diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h
index 86bff9841b54..722199f434f0 100644
--- a/include/drm/drm_auth.h
+++ b/include/drm/drm_auth.h
@@ -80,7 +80,9 @@ struct drm_master {
* &drm_device.master_mutex.
*/
struct idr magic_map;
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
struct drm_lock_data lock;
+#endif
void *driver_priv;
/* Tree of display resource leases, each of which is a drm_master struct
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 6710b612e2f6..67af60bb527a 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -335,7 +335,9 @@ struct drm_file {
struct drm_prime_file_private prime;
/* private: */
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
+#endif
};
/**
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] drm/legacy: place all drm legacy members under DRM_LEGACY.
From: Dave Airlie
This places a bunch of the legacy members of drm_device into
only being there when legacy is enabled.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_legacy.h | 20
include/drm/drm_device.h | 3 ++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index 3c05452a7137..4200e6bd3778 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -72,6 +72,7 @@ int drm_legacy_getsareactx(struct drm_device *d, void *v,
struct drm_file *f);
#define DRM_MAP_HASH_OFFSET 0x1000
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
static inline int drm_legacy_create_map_hash(struct drm_device *dev)
{
return drm_ht_create(&dev->map_hash, 12);
@@ -81,6 +82,14 @@ static inline void drm_legacy_remove_map_hash(struct
drm_device *dev)
{
drm_ht_remove(&dev->map_hash);
}
+#else
+static inline int drm_legacy_create_map_hash(struct drm_device *dev)
+{
+ return 0;
+}
+
+static inline void drm_legacy_remove_map_hash(struct drm_device *dev) {}
+#endif
#if IS_ENABLED(CONFIG_DRM_LEGACY)
@@ -174,6 +183,8 @@ int drm_legacy_sg_free(struct drm_device *dev, void *data,
struct drm_file *file_priv);
#endif
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
+
static inline void drm_legacy_init_members(struct drm_device *dev)
{
INIT_LIST_HEAD(&dev->ctxlist);
@@ -211,6 +222,15 @@ static inline void drm_legacy_dev_reinit(struct drm_device
*dev)
DRM_DEBUG("lastclose completed\n");
}
+#else
+static inline void drm_legacy_init_members(struct drm_device *dev) {}
+static inline void drm_legacy_destroy_members(struct drm_device *dev) {}
+static inline void drm_legacy_dev_reinit(struct drm_device *dev) {}
+#endif
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct drm_master
*master);
+#else
+static inline void drm_legacy_lock_master_cleanup(struct drm_device *dev,
struct drm_master *master) {}
+#endif
#endif /* __DRM_LEGACY_H__ */
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index d5e092dccf3e..7f9ef709b2b6 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -306,7 +306,7 @@ struct drm_device {
/* Everything below here is for legacy driver, never use! */
/* private: */
-
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
/* Context handle management - linked list of context handles */
struct list_head ctxlist;
@@ -353,6 +353,7 @@ struct drm_device {
/* Scatter gather memory */
struct drm_sg_mem *sg;
+#endif
};
#endif
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] drm/legacy: move map_hash create/destroy into inlines
From: Dave Airlie
This allows them to be removed later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_drv.c| 7 +++
drivers/gpu/drm/drm_legacy.h | 10 ++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 15b0fd5adaaf..18f45f9a955c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -692,10 +692,9 @@ int drm_dev_init(struct drm_device *dev,
if (ret)
goto err_minors;
- ret = drm_ht_create(&dev->map_hash, 12);
+ ret = drm_legacy_create_map_hash(dev);
if (ret)
goto err_minors;
-
drm_legacy_ctxbitmap_init(dev);
if (drm_core_check_feature(dev, DRIVER_GEM)) {
@@ -717,7 +716,7 @@ int drm_dev_init(struct drm_device *dev,
drm_gem_destroy(dev);
err_ctxbitmap:
drm_legacy_ctxbitmap_cleanup(dev);
- drm_ht_remove(&dev->map_hash);
+ drm_legacy_remove_map_hash(dev);
err_minors:
drm_minor_free(dev, DRM_MINOR_PRIMARY);
drm_minor_free(dev, DRM_MINOR_RENDER);
@@ -792,7 +791,7 @@ void drm_dev_fini(struct drm_device *dev)
drm_gem_destroy(dev);
drm_legacy_ctxbitmap_cleanup(dev);
- drm_ht_remove(&dev->map_hash);
+ drm_legacy_remove_map_hash(dev);
drm_fs_inode_free(dev->anon_inode);
drm_minor_free(dev, DRM_MINOR_PRIMARY);
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index 974c2be6bcd5..ef419d500e51 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -63,6 +63,16 @@ int drm_legacy_getsareactx(struct drm_device *d, void *v,
struct drm_file *f);
#define DRM_MAP_HASH_OFFSET 0x1000
+static inline int drm_legacy_create_map_hash(struct drm_device *dev)
+{
+ return drm_ht_create(&dev->map_hash, 12);
+}
+
+static inline void drm_legacy_remove_map_hash(struct drm_device *dev)
+{
+ drm_ht_remove(&dev->map_hash);
+}
+
int drm_legacy_getmap_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int drm_legacy_addmap_ioctl(struct drm_device *d, void *v, struct drm_file *f);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] drm/legacy: move lock cleanup for master into lock file
From: Dave Airlie
This makes it easier to remove legacy code later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_auth.c | 14 +-
drivers/gpu/drm/drm_legacy.h | 1 +
drivers/gpu/drm/drm_lock.c | 16
3 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1669c42c40ed..ef8c4353829b 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -275,19 +275,7 @@ void drm_master_release(struct drm_file *file_priv)
goto out;
if (drm_core_check_feature(dev, DRIVER_LEGACY)) {
- /*
-* Since the master is disappearing, so is the
-* possibility to lock.
-*/
- mutex_lock(&dev->struct_mutex);
- if (master->lock.hw_lock) {
- if (dev->sigdata.lock == master->lock.hw_lock)
- dev->sigdata.lock = NULL;
- master->lock.hw_lock = NULL;
- master->lock.file_priv = NULL;
- wake_up_interruptible_all(&master->lock.lock_queue);
- }
- mutex_unlock(&dev->struct_mutex);
+ drm_legacy_lock_master_cleanup(dev, master);
}
if (dev->master == file_priv->master)
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index 3dc626090fcb..974c2be6bcd5 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -126,4 +126,5 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void *data,
int drm_legacy_sg_free(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct drm_master
*master);
#endif /* __DRM_LEGACY_H__ */
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 67a1a2ca7174..b37874a15e23 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -347,3 +347,19 @@ void drm_legacy_lock_release(struct drm_device *dev,
struct file *filp)
_DRM_LOCKING_CONTEXT(file_priv->master->lock.hw_lock->lock));
}
}
+
+void drm_legacy_lock_master_cleanup(struct drm_device *dev, struct drm_master
*master)
+{
+ /*
+* Since the master is disappearing, so is the
+* possibility to lock.
+*/ mutex_lock(&dev->struct_mutex);
+ if (master->lock.hw_lock) {
+ if (dev->sigdata.lock == master->lock.hw_lock)
+ dev->sigdata.lock = NULL;
+ master->lock.hw_lock = NULL;
+ master->lock.file_priv = NULL;
+ wake_up_interruptible_all(&master->lock.lock_queue);
+ }
+ mutex_unlock(&dev->struct_mutex);
+}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/6] drm/amd/display: wait for fence without holding reservation lock
Hello Andrey,
this series can't apply (brake on #3) on top of amd-staging-drm-next.
v2 works (Thu, 11 Apr 2019).
Dieter
Am 18.04.2019 17:00, schrieb Andrey Grodzovsky:
From: Christian König
Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.
Signed-off-by: Christian König
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
1 file changed, 8 insertions(+), 5 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 380a7f9..ad4f0e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4814,23 +4814,26 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
continue;
}
+ abo = gem_to_amdgpu_bo(fb->obj[0]);
+
+ /* Wait for all fences on this FB */
+ r = reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
+ false,
+ MAX_SCHEDULE_TIMEOUT);
+ WARN_ON(r < 0);
+
/*
* TODO This might fail and hence better not used, wait
* explicitly on fences instead
* and in general should be called for
* blocking commit to as per framework helpers
*/
- abo = gem_to_amdgpu_bo(fb->obj[0]);
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0)) {
DRM_ERROR("failed to reserve buffer before flip\n");
WARN_ON(1);
}
- /* Wait for all fences on this FB */
- WARN_ON(reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
false,
-
MAX_SCHEDULE_TIMEOUT) < 0);
-
amdgpu_bo_get_tiling_flags(abo, &tiling_flags);
amdgpu_bo_unreserve(abo);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Aspire A315-21G
https://bugs.freedesktop.org/show_bug.cgi?id=110457 jian-h...@endlessm.com changed: What|Removed |Added Summary|System resumes failed and |System resumes failed and |hits|hits |[drm:amdgpu_job_timedout|[drm:amdgpu_job_timedout |[amdgpu]] *ERROR* ring gfx |[amdgpu]] *ERROR* ring gfx |timeout on Acer Squirtle_SR |timeout on Acer Aspire |laptop |A315-21G -- 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 110258] Lenovo V110-15AST AMD A9-9410 AMD R5 Stoney hangs after waking after suspend. 5.0-5.1rc2
https://bugs.freedesktop.org/show_bug.cgi?id=110258 --- Comment #7 from jian-h...@endlessm.com --- We have Aspire A315-21G and TravelMate B114-21 laptops and get the related problem, too. https://bugzilla.freedesktop.org/show_bug.cgi?id=110457 -- 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 9/9] drm/vmwgfx: Add surface dirty-tracking callbacks
Minor nits below
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 16:04 +, Thomas Hellstrom wrote:
> Add the callbacks necessary to implement emulated coherent memory for
> surfaces. Add a flag to the gb_surface_create ioctl to indicate that
> surface memory should be coherent.
> Also bump the drm minor version to signal the availability of
> coherent
> surfaces.
>
> Signed-off-by: Thomas Hellstrom
> ---
> .../device_include/svga3d_surfacedefs.h | 209 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 390
> +-
> include/uapi/drm/vmwgfx_drm.h | 4 +-
> 4 files changed, 600 insertions(+), 7 deletions(-)
>
> diff --git
> a/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
> b/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
> index f2bfd3d80598..d901206c04e3 100644
> --- a/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
> +++ b/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
> @@ -1280,7 +1280,6 @@
> svga3dsurface_get_pixel_offset(SVGA3dSurfaceFormat format,
> return offset;
> }
>
> -
> static inline u32
> svga3dsurface_get_image_offset(SVGA3dSurfaceFormat format,
> surf_size_struct baseLevelSize,
> @@ -1375,4 +1374,212 @@
> svga3dsurface_is_screen_target_format(SVGA3dSurfaceFormat format)
> return svga3dsurface_is_dx_screen_target_format(format);
> }
>
> +/**
> + * struct svga3dsurface_mip - Mimpmap level information
> + * @bytes: Bytes required in the backing store of this mipmap level.
> + * @img_stride: Byte stride per image.
> + * @row_stride: Byte stride per block row.
> + * @size: The size of the mipmap.
> + */
> +struct svga3dsurface_mip {
> + size_t bytes;
> + size_t img_stride;
> + size_t row_stride;
> + struct drm_vmw_size size;
> +
> +};
> +
> +/**
> + * struct svga3dsurface_cache - Cached surface information
> + * @desc: Pointer to the surface descriptor
> + * @mip: Array of mipmap level information. Valid size is
> @num_mip_levels.
> + * @mip_chain_bytes: Bytes required in the backing store for the
> whole chain
> + * of mip levels.
> + * @num_mip_levels: Valid size of the @mip array. Number of mipmap
> levels in
> + * a chain.
> + * @num_layers: Number of slices in an array texture or number of
> faces in
> + * a cubemap texture.
> + */
> +struct svga3dsurface_cache {
> + const struct svga3d_surface_desc *desc;
> + struct svga3dsurface_mip mip[DRM_VMW_MAX_MIP_LEVELS];
> + size_t mip_chain_bytes;
> + u32 num_mip_levels;
> + u32 num_layers;
> +};
> +
> +/**
> + * struct svga3dsurface_loc - Surface location
> + * @sub_resource: Surface subresource. Defined as layer *
> num_mip_levels +
> + * mip_level.
> + * @x: X coordinate.
> + * @y: Y coordinate.
> + * @z: Z coordinate.
> + */
> +struct svga3dsurface_loc {
> + u32 sub_resource;
> + u32 x, y, z;
> +};
> +
> +/**
> + * svga3dsurface_subres - Compute the subresource from layer and
> mipmap.
> + * @cache: Surface layout data.
> + * @mip_level: The mipmap level.
> + * @layer: The surface layer (face or array slice).
> + *
> + * Return: The subresource.
> + */
> +static inline u32 svga3dsurface_subres(const struct
> svga3dsurface_cache *cache,
> +u32 mip_level, u32 layer)
> +{
> + return cache->num_mip_levels * layer + mip_level;
> +}
> +
> +/**
> + * svga3dsurface_setup_cache - Build a surface cache entry
> + * @size: The surface base level dimensions.
> + * @format: The surface format.
> + * @num_mip_levels: Number of mipmap levels.
> + * @num_layers: Number of layers.
> + * @cache: Pointer to a struct svga3dsurface_cach object to be
> filled in.
> + */
> +static inline void svga3dsurface_setup_cache(const struct
> drm_vmw_size *size,
> + SVGA3dSurfaceFormat
> format,
> + u32 num_mip_levels,
> + u32 num_layers,
> + u32 num_samples,
> + struct svga3dsurface_cache
> *cache)
> +{
> + const struct svga3d_surface_desc *desc;
> + u32 i;
> +
> + memset(cache, 0, sizeof(*cache));
> + cache->desc = desc = svga3dsurface_get_desc(format);
> + cache->num_mip_levels = num_mip_levels;
> + cache->num_layers = num_layers;
> + for (i = 0; i < cache->num_mip_levels; i++) {
> + struct svga3dsurface_mip *mip = &cache->mip[i];
> +
> + mip->size = svga3dsurface_get_mip_size(*size, i);
> + mip->bytes = svga3dsurface_get_image_buffer_size
> + (desc, &mip->size, 0) * num_samples;
> + mip->row_stride =
> + __KERNEL_DIV_ROUND_UP(mip->size.width,
> + desc->block_size.width) *
> + desc->bytes_per_block * num_samp
[Bug 108317] [GCN3] Black Textures only on GCN3 in Cemu Zelda Breath of the Wild (OpenGL 4.5)
https://bugs.freedesktop.org/show_bug.cgi?id=108317 --- Comment #21 from John --- Maybe until a fix is found, could we add a driconfig workaround that disables hyperz automatically for cemu.exe? -- 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
[drm:drm-legacy-cleanup 13/24] drivers/gpu/drm/drm_vm.c:483:10: error: implicit declaration of function 'pte_wrprotect'
tree: git://people.freedesktop.org/~airlied/linux.git drm-legacy-cleanup
head: 7b7678e3949f22d2442179f27d219b4b09ef1730
commit: 739d8489bcb277a1a27e56d0ef529f41c46425b4 [13/24] drm/nouveau: add
kconfig option to turn off nouveau legacy contexts. (v2)
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 739d8489bcb277a1a27e56d0ef529f41c46425b4
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from arch/c6x/include/asm/page.h:10,
from arch/c6x/include/asm/thread_info.h:18,
from include/linux/thread_info.h:38,
from include/asm-generic/current.h:5,
from ./arch/c6x/include/generated/asm/current.h:1,
from include/linux/mutex.h:14,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/cdev.h:5,
from include/drm/drmP.h:36,
from drivers/gpu/drm/drm_vm.c:36:
drivers/gpu/drm/drm_vm.c: In function 'drm_mmap_dma':
>> drivers/gpu/drm/drm_vm.c:483:10: error: implicit declaration of function
>> 'pte_wrprotect' [-Werror=implicit-function-declaration]
(pte_wrprotect
^
include/asm-generic/page.h:59:36: note: in definition of macro '__pgprot'
#define __pgprot(x) ((pgprot_t) { (x) } )
^
drivers/gpu/drm/drm_vm.c:482:16: note: in expansion of macro 'pte_val'
__pgprot(pte_val
^~~
>> include/asm-generic/page.h:51:24: error: request for member 'pte' in
>> something not a structure or union
#define pte_val(x) ((x).pte)
^
include/asm-generic/page.h:59:36: note: in definition of macro '__pgprot'
#define __pgprot(x) ((pgprot_t) { (x) } )
^
drivers/gpu/drm/drm_vm.c:482:16: note: in expansion of macro 'pte_val'
__pgprot(pte_val
^~~
drivers/gpu/drm/drm_vm.c: In function 'drm_mmap_locked':
>> include/asm-generic/page.h:51:24: error: request for member 'pte' in
>> something not a structure or union
#define pte_val(x) ((x).pte)
^
include/asm-generic/page.h:59:36: note: in definition of macro '__pgprot'
#define __pgprot(x) ((pgprot_t) { (x) } )
^
drivers/gpu/drm/drm_vm.c:566:16: note: in expansion of macro 'pte_val'
__pgprot(pte_val
^~~
cc1: some warnings being treated as errors
--
In file included from arch/c6x/include/asm/page.h:10,
from arch/c6x/include/asm/thread_info.h:18,
from include/linux/thread_info.h:38,
from include/asm-generic/current.h:5,
from ./arch/c6x/include/generated/asm/current.h:1,
from include/linux/mutex.h:14,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/cdev.h:5,
from include/drm/drmP.h:36,
from drivers/gpu//drm/drm_vm.c:36:
drivers/gpu//drm/drm_vm.c: In function 'drm_mmap_dma':
drivers/gpu//drm/drm_vm.c:483:10: error: implicit declaration of function
'pte_wrprotect' [-Werror=implicit-function-declaration]
(pte_wrprotect
^
include/asm-generic/page.h:59:36: note: in definition of macro '__pgprot'
#define __pgprot(x) ((pgprot_t) { (x) } )
^
drivers/gpu//drm/drm_vm.c:482:16: note: in expansion of macro 'pte_val'
__pgprot(pte_val
^~~
>> include/asm-generic/page.h:51:24: error: request for member 'pte' in
>> something not a structure or union
#define pte_val(x) ((x).pte)
^
include/asm-generic/page.h:59:36: note: in definition of macro '__pgprot'
#define __pgprot(x) ((pgprot_t) { (x) } )
^
drivers/gpu//drm/drm_vm.c:482:16: note: in expansion of macro 'pte_val'
__pgprot(pte_val
^~~
drivers/gpu//drm/drm_vm.c: In function 'drm_mmap_locked':
>> include/asm-generic/page.h:51:24: error: request for member 'pte' in
>> something not a structure or union
#define pte_val(x) ((x).pte)
^
include/asm-generic/page.h:59:36: note: in definition of macro '__pgprot
Re: [v3 0/7] Add Multi Segment Gamma Support
On Thu, Apr 18, 2019 at 04:11:58PM +0300, Ville Syrjälä wrote: > On Thu, Apr 18, 2019 at 09:13:04AM +0200, Daniel Vetter wrote: > > On Wed, Apr 17, 2019 at 02:57:31PM +0300, Ville Syrjälä wrote: > > > On Wed, Apr 17, 2019 at 09:28:19AM +0200, Daniel Vetter wrote: > > > > On Fri, Apr 12, 2019 at 03:50:56PM +0530, Uma Shankar wrote: > > > > > This series adds support for programmable gamma modes and > > > > > exposes a property interface for the same. Also added, > > > > > support for multi segment gamma mode introduced in ICL+ > > > > > > > > > > It creates GAMMA_MODE property interface. This is an enum > > > > > property with values as blob_id's and exposes > > > > > the various gamma modes supported and the lut ranges Getting the > > > > > blob id in userspace, user can get the mode supported and > > > > > also the range of gamma mode supported with number of lut > > > > > coefficients. It can then set one of the modes using this > > > > > enum property. > > > > > > > > > > Lut values will be sent through already available GAMMA_LUT > > > > > blob property. > > > > > > > > > > It also introduces a CLIENT CAP for advanced GAMMA_MODE. > > > > > This is for user to set the and use advance gamma mode and older > > > > > userspace can continue using the legacy paths. > > > > > > > > > > v2: Used Ville's design and approach to define the interfaces. > > > > > Addressed Matt Roper's review feedback and re-ordered the > > > > > patches. > > > > > > > > > > v3: Converged to 1 property interface and introduced a Client cap > > > > > as suggested by Ville. Fixed review comments received. > > > > > > > > > > Uma Shankar (5): > > > > > drm/i915/icl: Add register definitions for Multi Segmented gamma > > > > > drm/i915/icl: Add support for multi segmented gamma mode > > > > > drm/i915: Attach gamma mode property > > > > > drm: Add Client Cap for advance gamma mode > > > > > drm/i915: Enable advance gamma mode > > > > > > > > > > Ville Syrjälä (2): > > > > > drm: Add gamma mode property > > > > > drm/i915: Define color lut range structure > > > > > > > > Bunch of higher level comments after some internal discussions: > > > > > > > > - we need the userspace for this, can't design new uapi without > > > > involving > > > > the compositor folks for hdr. > > > > > > > > - single property doesn't work: Once userspace has set it, the old blob > > > > property with the list of all options is gone. We need one read-only > > > > property for the list of options, plus a 2nd property that userspace > > > > can > > > > set. This is a general rule for more complex properties, where the > > > > usual > > > > property metadata isn't enough to describe the possible options. > > > > > > I guess no one understood my blob_enum idea? It's an enum where each > > > possible value is a blob. The only thing that changes is the current > > > value (which can only point to one of the enumerated blobs). > > > > Uh yes that's not clear at all, and if we do go with this, I guess we > > should have a pile of core code to make sure it validates and is > > consistent. > > > > >> > - no caps for properties. Yes that gives us a theoretical problem, no > > >> > in > > > > practice it doesn't matter, since people don't even care enough to > > > > make > > > > e.g. fbdev resetting work today for everything. Long form discussion, > > > > see here: > > > > > > > > https://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html > > > > > > > > Nothing happened in this area ever since I typed this up, so I guess > > > > it's really not a real-world concern. > > > > > > > > - Simplest path forward would be if we accept different LUT sizes than > > > > the > > > > one advertised (we already do that for legacy gamma, and this is > > > > officially what we had in mind too), and the kernel automatically > > > > picks > > > > the best lut configuration. Will be somewhat awkard for the > > > > multi-segment lut, but would decouple the uapi discussion a bit. > > > > > > It'll be ridiculously wasteful. IIRC we need a LUT with 32768 entries, > > > and then ~98% of those gets thrown away and never programmed to the > > > hardware. > > > > Yeah it's a few MB, not that awesome really ... > > > > > > - Frankly the uapi proposed looks like fake generic - it tries to model > > > > all possibilities in a generic way, when really userspace needs to > > > > have > > > > special code for special pipelines. > > > > > > I think it can be used pretty easily. Userspace just has to decide > > > whether it wants a straight up LUT or whether an interpolated curve > > > is enough, and how much precision it needs. For x11 the logic would > > > be simple enough: 1. look for straight up LUT with num_entries >= 1< > > if that isn't found fall back to an interpolated curve with >= 1< > > precision, and finally just fall back to whatever gives the best > > > results I suppose. > > > > Hm, there's also a bunch more defines about
