Re: [PATCH 00/30] [Set 1] Rid W=1 warnings in SCSI
Lee, > This set is part of a larger effort attempting to clean-up W=1 kernel > builds, which are currently overwhelmingly riddled with niggly little > warnings. Applied everything but patch 29 to 5.13/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
[AMD Public Use]
Ping
-Original Message-
From: Zhang, Jack (Jian)
Sent: Monday, March 15, 2021 1:24 PM
To: Jack Zhang ; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org; Koenig, Christian ;
Grodzovsky, Andrey ; Liu, Monk ;
Deng, Emily ; Rob Herring ; Tomeu Vizoso
; Steven Price
Subject: RE: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
[AMD Public Use]
Hi, Rob/Tomeu/Steven,
Would you please help to review this patch for panfrost driver?
Thanks,
Jack Zhang
-Original Message-
From: Jack Zhang
Sent: Monday, March 15, 2021 1:21 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
Christian ; Grodzovsky, Andrey
; Liu, Monk ; Deng, Emily
Cc: Zhang, Jack (Jian)
Subject: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
re-insert Bailing jobs to avoid memory leak.
V2: move re-insert step to drm/scheduler logic
V3: add panfrost's return value for bailing jobs in case it hits the memleak
issue.
Signed-off-by: Jack Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 8 ++--
drivers/gpu/drm/panfrost/panfrost_job.c| 4 ++--
drivers/gpu/drm/scheduler/sched_main.c | 8 +++-
include/drm/gpu_scheduler.h| 1 +
5 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 79b9cc73763f..86463b0f936e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4815,8 +4815,10 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
job ? job->base.id : -1);
/* even we skipped this reset, still need to set the job to
guilty */
- if (job)
+ if (job) {
drm_sched_increase_karma(&job->base);
+ r = DRM_GPU_SCHED_STAT_BAILING;
+ }
goto skip_recovery;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 759b34799221..41390bdacd9e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -34,6 +34,7 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
struct amdgpu_job *job = to_amdgpu_job(s_job);
struct amdgpu_task_info ti;
struct amdgpu_device *adev = ring->adev;
+ int ret;
memset(&ti, 0, sizeof(struct amdgpu_task_info));
@@ -52,8 +53,11 @@ static enum drm_gpu_sched_stat amdgpu_job_timedout(struct
drm_sched_job *s_job)
ti.process_name, ti.tgid, ti.task_name, ti.pid);
if (amdgpu_device_should_recover_gpu(ring->adev)) {
- amdgpu_device_gpu_recover(ring->adev, job);
- return DRM_GPU_SCHED_STAT_NOMINAL;
+ ret = amdgpu_device_gpu_recover(ring->adev, job);
+ if (ret == DRM_GPU_SCHED_STAT_BAILING)
+ return DRM_GPU_SCHED_STAT_BAILING;
+ else
+ return DRM_GPU_SCHED_STAT_NOMINAL;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 6003cfeb1322..e2cb4f32dae1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -444,7 +444,7 @@ static enum drm_gpu_sched_stat panfrost_job_timedout(struct
drm_sched_job
* spurious. Bail out.
*/
if (dma_fence_is_signaled(job->done_fence))
- return DRM_GPU_SCHED_STAT_NOMINAL;
+ return DRM_GPU_SCHED_STAT_BAILING;
dev_err(pfdev->dev, "gpu sched timeout, js=%d, config=0x%x,
status=0x%x, head=0x%x, tail=0x%x, sched_job=%p",
js,
@@ -456,7 +456,7 @@ static enum drm_gpu_sched_stat panfrost_job_timedout(struct
drm_sched_job
/* Scheduler is already stopped, nothing to do. */
if (!panfrost_scheduler_stop(&pfdev->js->queue[js], sched_job))
- return DRM_GPU_SCHED_STAT_NOMINAL;
+ return DRM_GPU_SCHED_STAT_BAILING;
/* Schedule a reset if there's no reset in progress. */
if (!atomic_xchg(&pfdev->reset.pending, 1)) diff --git
a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 92d8de24d0a1..a44f621fb5c4 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -314,6 +314,7 @@ static void drm_sched_job_timedout(struct work_struct
*work) {
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+ int ret;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
@@ -331,8 +332,13 @@ static void drm_sched_job_timedout(struct work_st
[PULL] drm-misc-next
Hi, It's been a fairly quiet week, but here are the changes for drm-misc-next Thanks! Maxime drm-misc-next-2021-03-16: drm-misc-next for 5.13: UAPI Changes: - Documentation for the DRM_CAP_* defines Cross-subsystem Changes: Core Changes: - dma-fence: More documentation for the recoverable page faults - fb_defio: Remove custom address_space operations Driver Changes: - panel: Support for the Innolux N116BCA-EA1 - stm: Use simple encoder for lcdc - virtio: Fix potential virtio_gpu_object_array leak The following changes since commit 762949bb1da78941b25e63f7e952af037eee15a9: drm: fix drm_mode_create_blob comment (2021-03-02 20:43:34 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-03-16 for you to fetch changes up to ccf953d8f3d68e85e577e843fdcde8872b0a9769: fb_defio: Remove custom address_space_operations (2021-03-12 15:10:03 +0100) drm-misc-next for 5.13: UAPI Changes: - Documentation for the DRM_CAP_* defines Cross-subsystem Changes: Core Changes: - dma-fence: More documentation for the recoverable page faults - fb_defio: Remove custom address_space operations Driver Changes: - panel: Support for the Innolux N116BCA-EA1 - stm: Use simple encoder for lcdc - virtio: Fix potential virtio_gpu_object_array leak Christian König (1): drm/sched: select new rq even if there is only one v3 Daniel Vetter (1): dma-fence: Document recoverable page fault implications Douglas Anderson (6): drm/panel-simple: Undo enable if HPD never asserts drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay drm/panel-simple: Retry if we timeout waiting for HPD dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1 drm/panel-simple: Add N116BCA-EA1 drm: panel: simple: Set enable delay for BOE NV110WTM-N61 Jagan Teki (1): drm/stm: ltdc: Use simple encoder Jianhui Zhao (1): docs: gpu: fix typo Linus Walleij (1): drm/mcde/panel: Inverse misunderstood flag Matthew Wilcox (Oracle) (1): fb_defio: Remove custom address_space_operations Paul Cercueil (1): drm/ingenic: Fix non-OSD mode Simon Ser (1): drm/uapi: document kernel capabilities Tian Tao (1): drm/vboxvideo: Use managed VRAM-helper initialization Yannick Fertre (1): drm/stm: dsi: Avoid printing errors for -EPROBE_DEFER xndcn (1): drm/virtio: fix possible leak/unlock virtio_gpu_object_array .../bindings/display/panel/panel-simple.yaml | 2 + Documentation/driver-api/dma-buf.rst | 76 + Documentation/gpu/todo.rst | 2 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +- drivers/gpu/drm/mcde/mcde_dsi.c| 2 +- drivers/gpu/drm/panel/panel-novatek-nt35510.c | 3 +- drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 4 +- drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 1 - drivers/gpu/drm/panel/panel-simple.c | 85 +- drivers/gpu/drm/panel/panel-sony-acx424akp.c | 3 +- drivers/gpu/drm/scheduler/sched_entity.c | 6 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 9 +- drivers/gpu/drm/stm/ltdc.c | 12 +- drivers/gpu/drm/vboxvideo/vbox_ttm.c | 7 +- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +- drivers/gpu/drm/virtio/virtgpu_object.c| 1 + drivers/video/fbdev/core/fb_defio.c| 35 -- drivers/video/fbdev/core/fbmem.c | 4 - include/linux/fb.h | 3 - include/uapi/drm/drm.h | 125 - 20 files changed, 303 insertions(+), 90 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-buf: Add an API for exporting sync files (v7)
Hi Jason, Thank you for the patch! Yet something to improve: [auto build test ERROR on tegra-drm/drm/tegra/for-next] [also build test ERROR on linus/master v5.12-rc3 next-20210316] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Jason-Ekstrand/dma-buf-add-dma_fence_array_for_each-v2/20210316-135402 base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next config: h8300-randconfig-r006-20210316 (attached as .config) compiler: h8300-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/c5e7feadea6d3792fc5e76c66944982eb5f4780b git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Jason-Ekstrand/dma-buf-add-dma_fence_array_for_each-v2/20210316-135402 git checkout c5e7feadea6d3792fc5e76c66944982eb5f4780b # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): h8300-linux-ld: drivers/dma-buf/dma-buf.o: in function `.L385': >> dma-buf.c:(.text+0x18e1): undefined reference to `sync_file_create' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c:721:65-70: WARNING: conversion to bool not needed here. ./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c:1139:67-72: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c index 6e864b1..434d3c4 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c @@ -718,7 +718,7 @@ bool dpp3_program_blnd_lut( next_mode = LUT_RAM_B; dpp3_power_on_blnd_lut(dpp_base, true); - dpp3_configure_blnd_lut(dpp_base, next_mode == LUT_RAM_A ? true:false); + dpp3_configure_blnd_lut(dpp_base, next_mode == LUT_RAM_A); if (next_mode == LUT_RAM_A) dpp3_program_blnd_luta_settings(dpp_base, params); @@ -1136,7 +1136,7 @@ bool dpp3_program_shaper( else next_mode = LUT_RAM_A; - dpp3_configure_shaper_lut(dpp_base, next_mode == LUT_RAM_A ? true:false); + dpp3_configure_shaper_lut(dpp_base, next_mode == LUT_RAM_A); if (next_mode == LUT_RAM_A) dpp3_program_shaper_luta_settings(dpp_base, params); -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-buf: Add an API for exporting sync files (v6)
On 2021-03-16 12:10 a.m., Jason Ekstrand wrote:
> On Mon, Mar 15, 2021 at 4:05 PM Jason Ekstrand wrote:
>>
>> Modern userspace APIs like Vulkan are built on an explicit
>> synchronization model. This doesn't always play nicely with the
>> implicit synchronization used in the kernel and assumed by X11 and
>> Wayland. The client -> compositor half of the synchronization isn't too
>> bad, at least on intel, because we can control whether or not i915
>> synchronizes on the buffer and whether or not it's considered written.
>>
>> The harder part is the compositor -> client synchronization when we get
>> the buffer back from the compositor. We're required to be able to
>> provide the client with a VkSemaphore and VkFence representing the point
>> in time where the window system (compositor and/or display) finished
>> using the buffer. With current APIs, it's very hard to do this in such
>> a way that we don't get confused by the Vulkan driver's access of the
>> buffer. In particular, once we tell the kernel that we're rendering to
>> the buffer again, any CPU waits on the buffer or GPU dependencies will
>> wait on some of the client rendering and not just the compositor.
>>
>> This new IOCTL solves this problem by allowing us to get a snapshot of
>> the implicit synchronization state of a given dma-buf in the form of a
>> sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
>> instead of CPU waiting directly, it encapsulates the wait operation, at
>> the current moment in time, in a sync_file so we can check/wait on it
>> later. As long as the Vulkan driver does the sync_file export from the
>> dma-buf before we re-introduce it for rendering, it will only contain
>> fences from the compositor or display. This allows to accurately turn
>> it into a VkFence or VkSemaphore without any over- synchronization.
>>
>> v2 (Jason Ekstrand):
>> - Use a wrapper dma_fence_array of all fences including the new one
>>when importing an exclusive fence.
>>
>> v3 (Jason Ekstrand):
>> - Lock around setting shared fences as well as exclusive
>> - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
>> - Initialize ret to 0 in dma_buf_wait_sync_file
>>
>> v4 (Jason Ekstrand):
>> - Use the new dma_resv_get_singleton helper
>>
>> v5 (Jason Ekstrand):
>> - Rename the IOCTLs to import/export rather than wait/signal
>> - Drop the WRITE flag and always get/set the exclusive fence
>>
>> v6 (Jason Ekstrand):
>> - Drop the sync_file import as it was all-around sketchy and not nearly
>>as useful as import.
>> - Re-introduce READ/WRITE flag support for export
>> - Rework the commit message
>>
>> Signed-off-by: Jason Ekstrand
>> ---
>> drivers/dma-buf/dma-buf.c| 55
>> include/uapi/linux/dma-buf.h | 6
>> 2 files changed, 61 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index f264b70c383eb..e7f9dd62c19a9 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
[...]
>> @@ -362,6 +363,57 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
>> const char __user *buf)
>> return ret;
>> }
>>
>> +static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
>> +void __user *user_data)
>> +{
>> + struct dma_buf_sync_file arg;
>> + struct dma_fence *fence = NULL;
>> + struct sync_file *sync_file;
>> + int fd, ret;
>> +
>> + if (copy_from_user(&arg, user_data, sizeof(arg)))
>> + return -EFAULT;
>> +
>> + if (arg.flags & ~DMA_BUF_SYNC_RW)
>> + return -EINVAL;
>> +
>> + fd = get_unused_fd_flags(O_CLOEXEC);
>> + if (fd < 0)
>> + return fd;
>> +
>> + if (arg.flags & DMA_BUF_SYNC_WRITE) {
>> + ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence);
>> + if (ret)
>> + goto err_put_fd;
>> + } else if (arg.flags & DMA_BUF_SYNC_READ) {
>> + fence = dma_resv_get_excl(dmabuf->resv);
>> + }
>> +
>> + if (!fence)
>> + fence = dma_fence_get_stub();
>> +
>> + sync_file = sync_file_create(fence);
>> +
>> + dma_fence_put(fence);
>> +
>> + if (!sync_file) {
>> + ret = -EINVAL;
>
> Should this be -EINVAL or -ENOMEM?
The latter makes more sense to me, since sync_file_create returning NULL is not
related to invalid ioctl parameters.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Need -fixes commit in drm-misc-next
Hi!
On Tue, Mar 09, 2021 at 06:08:49PM +0100, Noralf Trønnes wrote:
> Hi drm-misc maintainers,
>
> I have this series:
>
> GUD USB Display driver
> https://patchwork.freedesktop.org/series/87044/#rev3
>
> That depends on this drm-misc-fixes commit:
>
> 3a3fe21242a3 ("drm: Use USB controller's DMA mask when importing dmabufs")
>
> I would would be nice if it would show up in drm-misc-next soon.
I pushed it earlier today
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/15/21 7:47 PM, Christian König wrote:
> >
> >
> > Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
> > >
> > > On 3/15/21 11:26 AM, Christian König wrote:
> > > >
> > > >
> > > > Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
> > > > > Hi, Christian
> > > > >
> > > > > On 3/12/21 10:38 AM, Christian König wrote:
> > > > > > We seem to have some more driver bugs than thought.
> > > > > >
> > > > > > Signed-off-by: Christian König
> > > > > > ---
> > > > > > include/drm/ttm/ttm_bo_api.h | 6 --
> > > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/include/drm/ttm/ttm_bo_api.h
> > > > > > b/include/drm/ttm/ttm_bo_api.h
> > > > > > index 4fb523dfab32..df9fe596e7c5 100644
> > > > > > --- a/include/drm/ttm/ttm_bo_api.h
> > > > > > +++ b/include/drm/ttm/ttm_bo_api.h
> > > > > > @@ -603,9 +603,11 @@ static inline void
> > > > > > ttm_bo_pin(struct ttm_buffer_object *bo)
> > > > > > static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
> > > > > > {
> > > > > > dma_resv_assert_held(bo->base.resv);
> > > > > > - WARN_ON_ONCE(!bo->pin_count);
> > > > > > WARN_ON_ONCE(!kref_read(&bo->kref));
> > > > > > - --bo->pin_count;
> > > > > > + if (bo->pin_count)
> > > > > > + --bo->pin_count;
> > > > > > + else
> > > > > > + WARN_ON_ONCE(true);
> > > > > > }
> > > > > > int ttm_mem_evict_first(struct ttm_device *bdev,
> > > > >
> > > > > Since I now have been staring for half a year at the code of
> > > > > the driver that made pinning an art, I have a couple of
> > > > > suggestions here, Could we use an atomic for pin_count,
> > > > > allowing unlocked unpinning but require the lock only for
> > > > > pin_count transition 0->1, (but unlocked for
> > > > > pin_if_already_pinned). In particular I think vmwgfx would
> > > > > benefit from unlocked unpins. Also if the atomic were a
> > > > > refcount_t, that would probably give you the above
> > > > > behaviour?
> > > >
> > > > Nope, I've considered this as well while moving the pin count into TTM.
> > > >
> > > > The problem is that you not only need the BO reserved for 0->1
> > > > transitions, but also for 1->0 transitions to move the BO on the
> > > > LRU correctly.
> > >
> > > Ah, and there is no way to have us know the correct LRU list without
> > > reservation?
> >
> > Not really, there is always the chance that CPU A is reducing the count
> > from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
> > which doesn't match the pin count.
> >
> > We could try to do something like a loop updating the LRU status until
> > it matches the pin count, but the implications of that are usually
> > really nasty.
> >
> OK, yeah I was more thinking along the lines of protecting the LRU status
> with the global lru lock and unpin would then be
>
> if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
> add_to_relevant_lrus(bo, bo->lru_status);
> spin_unlock(&ttm_glob.lru_lock);
> }
>
> But looking at ttm_bo_move_to_lru_tail() I realize that's not really trivial
> anymore. I hope it's doable at some point though.
>
> But meanwhile, perhaps TTM needs to accept and pave over that drivers are in
> fact destroying pinned buffers?
Do we have more trouble than the very fancy tricks vmwgfx does? If so I
think we could do a small helper that like ttm_dont_check_unpin() to shut
it up. Since vmwgfx drivers tend to not be loaded with any other drivers
that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
out what to do - maybe you do need your own in-house pin/unpin for these
special bo?
I did try to parse your reply in the other thread, and tbh I didn't grock
it.
Also I think a comment why we need dma_resv (maybe in the kerneldoc for
pin count), i.e. that it's needed to keep lru state in sync with pin state
would be really good?
-Daniel
>
> /Thomas
>
>
>
>
>
> > Christian.
> >
> > >
> > > /Thomas
> > >
> > >
> > > >
> > > > Christian.
> > > >
> > > > >
> > > > > /Thomas
> > > > >
> > > > >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [syzbot] upstream boot error: WARNING in vkms_vblank_simulate
On Fri, Mar 12, 2021 at 05:10:43PM +0100, Dmitry Vyukov wrote: > On Fri, Mar 12, 2021 at 3:22 PM Daniel Vetter wrote: > > > > On Fri, Mar 12, 2021 at 11:46:27AM +0100, Dmitry Vyukov wrote: > > > On Fri, Mar 12, 2021 at 11:26 AM syzbot > > > wrote: > > > > > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit:f78d76e7 Merge tag 'drm-fixes-2021-03-12-1' of > > > > git://anong.. > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=11c16ba2d0 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=dc02c6afcb046874 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=333bd014262fd5d0a418 > > > > userspace arch: arm > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > > commit: > > > > Reported-by: syzbot+333bd014262fd5d0a...@syzkaller.appspotmail.com > > > > > > This WARNING seems to be happening just randomly. > > > It was already reported as: > > > > > > #syz dup: WARNING in vkms_vblank_simulate (2) > > > https://syzkaller.appspot.com/bug?id=9b10491371879700d6a21c15684c2232ff015084 > > > > > > It now has whooping 48589 crashes and also crashes slow qemu tcg > > > instances. > > > > Yeah your box is too slow. We're trying to simulate hw here, which means > > if we can process less than 1 hrtimer per vblank (standard every 16ms) > > then we scream, because things go very wrong with the simulated hw. And > > the hrtimer is really not that big, all the expensive processing is pushed > > to worker, where we have code to handle if it falls back too much. > > > > So either patch this out or make the code robust against a kernel that > > somehow can't process a single hrtimer every 16ms. > > -Daniel > > Majority of these happen on the latest Intel CPUs. If that's not fast, > then I don't know what' fast :) > WARNING must not be used for timing-triggerable conditions. pr_warn is > more appropriate here. I assume the call stack and the rest of the > info that WARNING prints is completely useless, it's only the binary > condition, right. Hm, maybe we do have some bug somewhere left still. But yeah if pr_warn does not trigger a full abort with syzbot then we can do that I guess. Care to submit that pathc please with a short explainer why it upsets syzbot? Thanks, Daniel > > > > > > [ cut here ] > > > > WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/vkms/vkms_crtc.c:21 > > > > vkms_vblank_simulate+0x26c/0x2f4 drivers/gpu/drm/vkms/vkms_crtc.c:41 > > > > Modules linked in: > > > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > > > 5.12.0-rc2-syzkaller-00338-gf78d76e72a46 #0 > > > > Hardware name: linux,dummy-virt (DT) > > > > pstate: 2085 (nzCv daIf -PAN -UAO -TCO BTYPE=--) > > > > pc : vkms_vblank_simulate+0x26c/0x2f4 > > > > drivers/gpu/drm/vkms/vkms_crtc.c:21 > > > > lr : hrtimer_forward_now include/linux/hrtimer.h:510 [inline] > > > > lr : vkms_vblank_simulate+0x90/0x2f4 drivers/gpu/drm/vkms/vkms_crtc.c:19 > > > > sp : 6a693cd0 > > > > x29: 6a693cd0 x28: 0c9d1e58 > > > > x27: dfff8000 x26: 6a67f540 > > > > x25: 1fffed4cfeb1 x24: 1fffed4cfeaa > > > > x23: 0c9d0d30 x22: 00fe4c00 > > > > x21: 6a67f540 x20: 0c9d0e58 > > > > x19: 0c9d1e58 x18: 6a6a1b48 > > > > x17: 1fffe1952345 x16: > > > > x15: 8000197bf810 x14: 1fffed4d2750 > > > > x13: 0001 x12: 0033 > > > > x11: 12fb4936 x10: 0007 > > > > x9 : 12fb4943 x8 : 800017d14c00 > > > > x7 : f1f1f1f1 x6 : dfff8000 > > > > x5 : 7fff x4 : 0008e44f6b90 > > > > x3 : 0008e54db790 x2 : 0008e44f6b90 > > > > x1 : 0008e54db790 x0 : 0002 > > > > Call trace: > > > > vkms_vblank_simulate+0x26c/0x2f4 drivers/gpu/drm/vkms/vkms_crtc.c:41 > > > > __run_hrtimer kernel/time/hrtimer.c:1519 [inline] > > > > __hrtimer_run_queues+0x590/0xe40 kernel/time/hrtimer.c:1583 > > > > hrtimer_interrupt+0x2d4/0x810 kernel/time/hrtimer.c:1645 > > > > timer_handler drivers/clocksource/arm_arch_timer.c:647 [inline] > > > > arch_timer_handler_phys+0x4c/0x70 > > > > drivers/clocksource/arm_arch_timer.c:665 > > > > handle_percpu_devid_irq+0x19c/0x330 kernel/irq/chip.c:930 > > > > generic_handle_irq_desc include/linux/irqdesc.h:158 [inline] > > > > generic_handle_irq kernel/irq/irqdesc.c:652 [inline] > > > > __handle_domain_irq+0x11c/0x1f0 kernel/irq/irqdesc.c:689 > > > > handle_domain_irq include/linux/irqdesc.h:176 [inline] > > > > gic_handle_irq+0x5c/0x1b0 drivers/irqchip/irq-gic.c:370 > > > > el1_irq+0xb4/0x180 arch/arm64/kernel/entry.S:669 > > > > arch_local_irq_restore arch/arm64/include/asm/irqflags.h:124 [inline] > > > > queue_work_on+0x74/0x110 kernel/workqueue.c:1528 > > > > queue_work include/linux/workqueue.h:507 [inline] > > > > cursor_timer_handler
Re: [PATCH] drm/amdgpu: nuke the ih reentrant lock
On Fri, Mar 12, 2021 at 03:50:35PM +0100, Christian König wrote:
> Am 12.03.21 um 15:36 schrieb Daniel Vetter:
> > On Fri, Mar 12, 2021 at 03:35:50PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 12, 2021 at 03:27:58PM +0100, Christian König wrote:
> > > >
> > > > Am 12.03.21 um 15:04 schrieb Daniel Vetter:
> > > > > On Fri, Mar 12, 2021 at 02:59:06PM +0100, Christian König wrote:
> > > > > > Interrupts on are non-reentrant on linux. This is just an ancient
> > > > > > leftover from radeon where irq processing was kicked of from
> > > > > > different
> > > > > > places.
> > > > > >
> > > > > > Signed-off-by: Christian König
> > > > > Man you tricked me into grepping this on radeon and it looks horrible.
> > > > > atomic_t is unordered in linux, so whatever was built there for radeon
> > > > > does not wokr like a lock. It's missing all the barriers afiui. Good
> > > > > riddance at least for amdgpu.
> > > > Hui? atomic_xchg() is perfectly ordered as far as I know.
> > > Oh right, if atomic_ returns a value it's fully ordered. Nice tour into
> > > memory-barriers.txt. It's the atomic_t operations that don't return
> > > anything which are fully unordered, and I mixed that up.
> > >
> > > > IIRC Alex added this for R600 because we had boards where interrupts
> > > > where
> > > > sporadically swallowed during driver startup and we had to kick of ring
> > > > buffer processing manually.
> > > >
> > > > Anyway we have a fence processing fallback timer in amdgpu instead and
> > > > that
> > > > stuff is probably unused on any modern hardware.
> > > Ah yes that stuff. Kinda annoying we have these old dma_fence around where
> > > dma_fence_wait doesn't really work that well, but oh well.
> > Argh I'm not awake. dma_fence_wait() works well on these, but the generic
> > cb stuff (which is used in ever more place) doesn't, because it misses the
> > fallback timer the ->wait does.
>
> That's not what I meant. See amdgpu_fence_schedule_fallback().
>
> As soon as somebody requested a dma_fence to be signaled we start a 500ms
> timeout for fence processing which is cleared as soon as we see the first
> interrupt.
>
> That is necessary because some motherboards have the ugly behavior of
> swallowing approx ~0.1% if all MSI interrupts after some idle time.
>
> No idea where exactly that comes from, but I have the feeling that this was
> the same bug Alex tried to handle on R6xx over 10 years ago with kicking of
> interrupt processing manually after enabling interrupts for the first time.
That's the same thing I mean. I think at least on radeon this is handled
by periodically waking up in the ->wait callback, but unfortunately that
doesn't take care of any of the callback based fence waiters. Maybe
there's a different reason on radeon for the lost interrupts, but I
thought consequences are the same. I think i915 also had some hacks like
that, not sure why it still has a ->wait callback tbh. Maybe that's still
needed for handling the gpu recovery flow on gen2/3, which is rather
non-standard and violates dma_fence nesting rules a bit. But oh well,
that's real old stuff.
-Daniel
>
> Regards,
> Christian.
>
> > -Daniel
> >
> > > > > Reviewed-by: Daniel Vetter
> > > > Thanks,
> > > > Christian.
> > > >
> > > > > > ---
> > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
> > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 5 -
> > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 1 -
> > > > > >3 files changed, 7 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > > index a15f1b604733..886625fb464b 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > > > > @@ -3284,7 +3284,6 @@ int amdgpu_device_init(struct amdgpu_device
> > > > > > *adev,
> > > > > > /* mutex initialization are all done here so we
> > > > > > * can recall function without having locking issues */
> > > > > > - atomic_set(&adev->irq.ih.lock, 0);
> > > > > > mutex_init(&adev->firmware.mutex);
> > > > > > mutex_init(&adev->pm.mutex);
> > > > > > mutex_init(&adev->gfx.gpu_clock_mutex);
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > > > > index 1024065f1f03..faaa6aa2faaf 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > > > > @@ -228,10 +228,6 @@ int amdgpu_ih_process(struct amdgpu_device
> > > > > > *adev, struct amdgpu_ih_ring *ih)
> > > > > > wptr = amdgpu_ih_get_wptr(adev, ih);
> > > > > >restart_ih:
> > > > > > - /* is somebody else already processing irqs? */
> > > > > > - if (atomic_xchg(&ih->lock, 1))
> > > > > > - return IRQ_NONE;
> > > > > > -
> > > > > > DRM_DEBUG("%s: rptr %d, wptr %d\n", __func__, ih->rptr, wptr);
Re: [PATCH 3/3] drm/ttm: switch to per device LRU lock
On Mon, Mar 15, 2021 at 05:04:22PM +0100, Christian König wrote:
> Instead of having a global lock.
>
> Signed-off-by: Christian König
I guess per zone lru lock is a lot more work since then we need to handle
ordering and ABBA deadlocks? s/zone/mem region/ I think is the proper ttm
lingo.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
> drivers/gpu/drm/qxl/qxl_release.c | 5 +--
> drivers/gpu/drm/ttm/ttm_bo.c | 49 --
> drivers/gpu/drm/ttm/ttm_device.c | 12 +++
> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
> drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
> include/drm/ttm/ttm_bo_driver.h| 4 +--
> include/drm/ttm/ttm_device.h | 4 +--
> 8 files changed, 43 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 9d19078246c8..ae18c0e32347 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
> *adev,
> struct amdgpu_vm_bo_base *bo_base;
>
> if (vm->bulk_moveable) {
> - spin_lock(&ttm_glob.lru_lock);
> + spin_lock(&adev->mman.bdev.lru_lock);
> ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
> - spin_unlock(&ttm_glob.lru_lock);
> + spin_unlock(&adev->mman.bdev.lru_lock);
> return;
> }
>
> memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
>
> - spin_lock(&ttm_glob.lru_lock);
> + spin_lock(&adev->mman.bdev.lru_lock);
> list_for_each_entry(bo_base, &vm->idle, vm_status) {
> struct amdgpu_bo *bo = bo_base->bo;
>
> @@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
> *adev,
> &bo->shadow->tbo.mem,
> &vm->lru_bulk_move);
> }
> - spin_unlock(&ttm_glob.lru_lock);
> + spin_unlock(&adev->mman.bdev.lru_lock);
>
> vm->bulk_moveable = true;
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> b/drivers/gpu/drm/qxl/qxl_release.c
> index f5845c96d414..b19f2f00b215 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct
> qxl_release *release)
> release->id | 0xf000, release->base.seqno);
> trace_dma_fence_emit(&release->base);
>
> - spin_lock(&ttm_glob.lru_lock);
> -
> list_for_each_entry(entry, &release->bos, head) {
> bo = entry->bo;
>
> dma_resv_add_shared_fence(bo->base.resv, &release->base);
> - ttm_bo_move_to_lru_tail(bo, &bo->mem, NULL);
> + ttm_bo_move_to_lru_tail_unlocked(bo);
> dma_resv_unlock(bo->base.resv);
> }
> - spin_unlock(&ttm_glob.lru_lock);
> ww_acquire_fini(&release->ticket);
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index a1be88be357b..a8103c8718a3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -242,9 +242,9 @@ static int ttm_bo_individualize_resv(struct
> ttm_buffer_object *bo)
>* reference it any more. The only tricky case is the trylock on
>* the resv object while holding the lru_lock.
>*/
> - spin_lock(&ttm_glob.lru_lock);
> + spin_lock(&bo->bdev->lru_lock);
> bo->base.resv = &bo->base._resv;
> - spin_unlock(&ttm_glob.lru_lock);
> + spin_unlock(&bo->bdev->lru_lock);
> }
>
> return r;
> @@ -303,7 +303,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
>
> if (unlock_resv)
> dma_resv_unlock(bo->base.resv);
> - spin_unlock(&ttm_glob.lru_lock);
> + spin_unlock(&bo->bdev->lru_lock);
>
> lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
>30 * HZ);
> @@ -313,7 +313,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
> else if (lret == 0)
> return -EBUSY;
>
> - spin_lock(&ttm_glob.lru_lock);
> + spin_lock(&bo->bdev->lru_lock);
> if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
> /*
>* We raced, and lost, someone else holds the
> reservation now,
> @@ -323,7 +323,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
> *bo,
>* delayed destruction would succeed, so just return
> success
>* here.
>*/
> - spin_unlock(&ttm_glob.lru_lock);
> + spin_unlock(&bo->bdev->lru_lock);
>
Re: [PATCH 1/3] drm/qxl: clean up qxl_bo_move_notify
On Mon, 15 Mar 2021 at 19:14, Christian König wrote: > > Remove the unused evict parameter and drop swapping bo->mem. > > Signed-off-by: Christian König For the series, Reviewed-by: Matthew Auld ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC 1/6] drm/i915: Individual request cancellation
On Mon, Mar 15, 2021 at 05:37:27PM +, Tvrtko Ursulin wrote:
>
> On 12/03/2021 15:46, Tvrtko Ursulin wrote:
> > From: Chris Wilson
> >
> > Currently, we cancel outstanding requests within a context when the
> > context is closed. We may also want to cancel individual requests using
> > the same graceful preemption mechanism.
> >
> > v2 (Tvrtko):
> > * Cancel waiters carefully considering no timeline lock and RCU.
> > * Fixed selftests.
> >
> > Signed-off-by: Chris Wilson
> > Signed-off-by: Tvrtko Ursulin
>
> [snip]
>
> > +void i915_request_cancel(struct i915_request *rq, int error)
> > +{
> > + if (!i915_request_set_error_once(rq, error))
> > + return;
> > +
> > + set_bit(I915_FENCE_FLAG_SENTINEL, &rq->fence.flags);
> > +
> > + if (i915_sw_fence_signaled(&rq->submit)) {
> > + struct i915_dependency *p;
> > +
> > +restart:
> > + rcu_read_lock();
> > + for_each_waiter(p, rq) {
> > + struct i915_request *w =
> > + container_of(p->waiter, typeof(*w), sched);
> > +
> > + if (__i915_request_is_complete(w) ||
> > + fatal_error(w->fence.error))
> > + continue;
> > +
> > + w = i915_request_get(w);
> > + rcu_read_unlock();
> > + /* Recursion bound by the number of engines */
> > + i915_request_cancel(w, error);
> > + i915_request_put(w);
> > +
> > + /* Restart after having to drop rcu lock. */
> > + goto restart;
> > + }
>
> So I need to fix this error propagation to waiters in order to avoid
> potential stack overflow caught in shards (gem_ctx_ringsize).
>
> Or alternatively we decide not to propagate fence errors. Not sure that
> consequences either way are particularly better or worse. Things will break
> anyway since what userspace inspects for unexpected fence errors?!
fence error propagation is one of these "sounds like a good idea" things
that turned into a can of worms. See the recent revert Jason submitted, I
replied with a more in-depth discussion.
So I'd say if we don't need this internally somehow for scheduler state,
remove it. Maybe even the entire scaffolding we have for the forwarding.
Maybe best if you sync with Jason here, we need to stuff Jason's patch
into -fixes since there's a pretty bad regression going on. I think Jason
also said there's a pile of igts to remove once we give up on fence error
propagation.
> So rendering corruption more or less. Can it cause a further stream of GPU
> hangs I am not sure. Only if there is a inter-engine data dependency
> involving data more complex than images/textures.
Yup. Also at least on modern-ish hw our userspace goes with
non-recoverable contexts anyway, because everything needs to be
reconstructed. vk is even more brutal, it just hands you back a
vk_device_lost and everything is gone (textures, data, all api objects,
really everything afaiui). Trying to continue is something only old
userspace is doing, because the fully emit the entire ctx state at the
start of each batch anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 6/6] drm/i915: Allow configuring default request expiry via modparam
On Fri, Mar 12, 2021 at 03:46:22PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Module parameter is added (request_timeout_ms) to allow configuring the
> default request/fence expiry.
>
> Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
Yeah I think this makes sense for debugging and testing (e.g. in igt we
can crank down the timeout to make stuff fail real fast, could help with
runtime on some tests).
Acked-by: Daniel Vetter
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +---
> drivers/gpu/drm/i915/i915_params.c | 5 +
> drivers/gpu/drm/i915/i915_params.h | 1 +
> 3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 21c0176e27a0..1dae5e2514a9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -866,7 +866,7 @@ static void __set_default_fence_expiry(struct
> i915_gem_context *ctx)
> return;
>
> /* Default expiry for user fences. */
> - ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
> + ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000);
> if (ret)
> drm_notice(&i915->drm,
> "Failed to configure default fence expiry! (%d)",
> @@ -1442,13 +1442,15 @@ __set_watchdog(struct i915_gem_context *ctx, unsigned
> long timeout_us)
> static int set_watchdog(struct i915_gem_context *ctx,
> struct drm_i915_gem_context_param *args)
> {
> + struct drm_i915_private *i915 = ctx->i915;
> +
> if (args->size)
> return -EINVAL;
>
> /* Disallow disabling or configuring longer watchdog than default. */
> - if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
> + if (i915->params.request_timeout_ms &&
> (!args->value ||
> - args->value > CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000))
> + args->value > i915->params.request_timeout_ms * 1000))
> return -EPERM;
>
> return __set_watchdog(ctx, args->value);
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 6939634e56ed..0320878d96b0 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -197,6 +197,11 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
> "Fake LMEM start offset (default: 0)");
> #endif
>
> +#if CONFIG_DRM_I915_REQUEST_TIMEOUT
> +i915_param_named_unsafe(request_timeout_ms, uint, 0600,
> + "Default request/fence/batch buffer expiration
> timeout.");
> +#endif
> +
> static __always_inline void _print_param(struct drm_printer *p,
>const char *name,
>const char *type,
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 48f47e44e848..34ebb0662547 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -72,6 +72,7 @@ struct drm_printer;
> param(int, enable_dpcd_backlight, -1, 0600) \
> param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
> param(unsigned long, fake_lmem_start, 0, 0400) \
> + param(unsigned int, request_timeout_ms,
> CONFIG_DRM_I915_REQUEST_TIMEOUT, 0600) \
> /* leave bools at the end to not create holes */ \
> param(bool, enable_hangcheck, true, 0600) \
> param(bool, load_detect_test, false, 0600) \
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 4/6] drm/i915: Allow userspace to configure the watchdog
On Fri, Mar 12, 2021 at 03:46:20PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Idea here is to make the watchdog mechanism more useful than for just
> default request/fence expiry.
>
> To this effect a new context param I915_CONTEXT_PARAM_WATCHDOG is added
> where the value fields allows passing in a timeout in micro-seconds.
>
> This allows userspace to set a limit to how long they expect their batches
> to take, or otherwise they will be cancelled, and userspace notified via
> one of the available mechanisms.
>
> Main attractiveness of adding uapi here is perhaps to extend the proposal
> by passing in a structure instead of a single value, like for illustration
> only:
>
> struct drm_i915_gem_context_watchdog {
> __u64 flags;
> #define I915_CONTEXT_WATCHDOG_WALL_TIME BIT(0)
> #define I915_CONTEXT_WATCHDOG_GPU_TIME BIT(1)
> #define I915_CONTEXT_WATCHDOG_FROM_SUBMITBIT(2)
> #define I915_CONTEXT_WATCHDOG_FROM_RUNNABLE BIT(3)
> __64 timeout_us;
> };
>
> Point being to prepare the uapi for different semantics from the start.
> Given how not a single one makes complete sense for all use cases. And
> also perhaps satisfy the long wanted media watchdog feature request.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
I think what's been discussed forever is a gpu time watchdog for media.
Otherwise I don't think userspace should be allowed to configure anything
here, and even the watch really should only allow to fail faster.
Now for the workloads that we do break with the next patch (and those
exist), the real solution is the preempt-ctx dma_fence that amdkfd does,
and which we're also working on. But unfortunately that's a lot more work
than a quick simple patch.
So please drop this one from the next round. If media wants a fast
gpu timeout then we should roll that in as a separate series, with
userspace and igt and all the usual bells&whistles.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 57 +++
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 4 ++
> drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +++-
> include/uapi/drm/i915_drm.h | 5 +-
> 4 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ca37d93ef5e7..32b05af4fc8f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -233,6 +233,8 @@ static void intel_context_set_gem(struct intel_context
> *ce,
> if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> intel_engine_has_timeslices(ce->engine))
> __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
> +
> + intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
> }
>
> static void __free_engines(struct i915_gem_engines *e, unsigned int count)
> @@ -1397,6 +1399,28 @@ static int set_ringsize(struct i915_gem_context *ctx,
>__intel_context_ring_size(args->value));
> }
>
> +static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
> +{
> + return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
> +}
> +
> +static int set_watchdog(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + int ret;
> +
> + if (args->size)
> + return -EINVAL;
> +
> + ret = context_apply_all(ctx, __apply_watchdog,
> + (void *)(uintptr_t)args->value);
> +
> + if (!ret)
> + ctx->watchdog.timeout_us = args->value;
> +
> + return ret;
> +}
> +
> static int __get_ringsize(struct intel_context *ce, void *arg)
> {
> long sz;
> @@ -1426,6 +1450,17 @@ static int get_ringsize(struct i915_gem_context *ctx,
> return 0;
> }
>
> +static int get_watchdog(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + if (args->size)
> + return -EINVAL;
> +
> + args->value = ctx->watchdog.timeout_us;
> +
> + return 0;
> +}
> +
> int
> i915_gem_user_to_context_sseu(struct intel_gt *gt,
> const struct drm_i915_gem_context_param_sseu
> *user,
> @@ -2075,6 +2110,10 @@ static int ctx_setparam(struct drm_i915_file_private
> *fpriv,
> ret = set_ringsize(ctx, args);
> break;
>
> + case I915_CONTEXT_PARAM_WATCHDOG:
> + ret = set_watchdog(ctx, args);
> + break;
> +
> case I915_CONTEXT_PARAM_BAN_PERIOD:
> default:
> ret = -EINVAL;
> @@ -2196,6 +2235,19 @@ static int clone_schedattr(struct i915_gem_context
> *dst,
> return 0;
> }
>
> +static int clone_watchdog(struct i915_gem_context *dst,
> + struct i915_gem_context *src)
> +{
> + int ret;
> +
> + ret = context_apply_all(dst, __apply_watchdog,
> +
Re: [RFC 5/6] drm/i915: Fail too long user submissions by default
On Fri, Mar 12, 2021 at 03:46:21PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
> to 10s, and this timeout is applied to _all_ contexts using the previously
> added watchdog facility.
>
> Result of this is that any user submission will simply fail after this
> time, either causing a reset (for non-preemptable) or incomplete results.
>
> This can have an effect that workloads which used to work fine will
> suddenly start failing.
>
> When the default expiry is active userspace will not be allowed to
> decrease the timeout using the context param setting.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
I think this should explain that it will break long running compute
workloads, and that maybe the modparam in the next patch can paper over
that until we've implemented proper long running compute workload support
in upstream. Which is unfortunately still some ways off.
Otherwise makes all sense to me. Maybe if you want also copy some of the
discussion from your cover letter into this commit message, and think
there's some good stuff there.
-Daniel
> ---
> drivers/gpu/drm/i915/Kconfig.profile| 8
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ++---
> 2 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.profile
> b/drivers/gpu/drm/i915/Kconfig.profile
> index 35bbe2b80596..55e15773 100644
> --- a/drivers/gpu/drm/i915/Kconfig.profile
> +++ b/drivers/gpu/drm/i915/Kconfig.profile
> @@ -1,3 +1,11 @@
> +config DRM_I915_REQUEST_TIMEOUT
> + int "Default timeout for requests (ms)"
> + default 1 # milliseconds
> + help
> + ...
> +
> + May be 0 to disable the timeout.
> +
> config DRM_I915_FENCE_TIMEOUT
> int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"
> default 1 # milliseconds
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 32b05af4fc8f..21c0176e27a0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -854,6 +854,25 @@ static void __assign_timeline(struct i915_gem_context
> *ctx,
> context_apply_all(ctx, __apply_timeline, timeline);
> }
>
> +static int
> +__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us);
> +
> +static void __set_default_fence_expiry(struct i915_gem_context *ctx)
> +{
> + struct drm_i915_private *i915 = ctx->i915;
> + int ret;
> +
> + if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
> + return;
> +
> + /* Default expiry for user fences. */
> + ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
> + if (ret)
> + drm_notice(&i915->drm,
> +"Failed to configure default fence expiry! (%d)",
> +ret);
> +}
> +
> static struct i915_gem_context *
> i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> {
> @@ -898,6 +917,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
> unsigned int flags)
> intel_timeline_put(timeline);
> }
>
> + __set_default_fence_expiry(ctx);
> +
> trace_i915_context_create(ctx);
>
> return ctx;
> @@ -1404,23 +1425,35 @@ static int __apply_watchdog(struct intel_context *ce,
> void *timeout_us)
> return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
> }
>
> -static int set_watchdog(struct i915_gem_context *ctx,
> - struct drm_i915_gem_context_param *args)
> +static int
> +__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
> {
> int ret;
>
> - if (args->size)
> - return -EINVAL;
> -
> ret = context_apply_all(ctx, __apply_watchdog,
> - (void *)(uintptr_t)args->value);
> + (void *)(uintptr_t)timeout_us);
>
> if (!ret)
> - ctx->watchdog.timeout_us = args->value;
> + ctx->watchdog.timeout_us = timeout_us;
>
> return ret;
> }
>
> +static int set_watchdog(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + if (args->size)
> + return -EINVAL;
> +
> + /* Disallow disabling or configuring longer watchdog than default. */
> + if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
> + (!args->value ||
> + args->value > CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000))
> + return -EPERM;
> +
> + return __set_watchdog(ctx, args->value);
> +}
> +
> static int __get_ringsize(struct intel_context *ce, void *arg)
> {
> long sz;
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
Re: Need -fixes commit in drm-misc-next
Den 16.03.2021 10.08, skrev Maxime Ripard:
> Hi!
>
> On Tue, Mar 09, 2021 at 06:08:49PM +0100, Noralf Trønnes wrote:
>> Hi drm-misc maintainers,
>>
>> I have this series:
>>
>> GUD USB Display driver
>> https://patchwork.freedesktop.org/series/87044/#rev3
>>
>> That depends on this drm-misc-fixes commit:
>>
>> 3a3fe21242a3 ("drm: Use USB controller's DMA mask when importing dmabufs")
>>
>> I would would be nice if it would show up in drm-misc-next soon.
>
> I pushed it earlier today
>
Thanks Maxime!
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h
b/include/drm/ttm/ttm_bo_api.h
index 4fb523dfab32..df9fe596e7c5 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -603,9 +603,11 @@ static inline void
ttm_bo_pin(struct ttm_buffer_object *bo)
static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
- WARN_ON_ONCE(!bo->pin_count);
WARN_ON_ONCE(!kref_read(&bo->kref));
- --bo->pin_count;
+ if (bo->pin_count)
+ --bo->pin_count;
+ else
+ WARN_ON_ONCE(true);
}
int ttm_mem_evict_first(struct ttm_device *bdev,
Since I now have been staring for half a year at the code of
the driver that made pinning an art, I have a couple of
suggestions here, Could we use an atomic for pin_count,
allowing unlocked unpinning but require the lock only for
pin_count transition 0->1, (but unlocked for
pin_if_already_pinned). In particular I think vmwgfx would
benefit from unlocked unpins. Also if the atomic were a
refcount_t, that would probably give you the above
behaviour?
Nope, I've considered this as well while moving the pin count into TTM.
The problem is that you not only need the BO reserved for 0->1
transitions, but also for 1->0 transitions to move the BO on the
LRU correctly.
Ah, and there is no way to have us know the correct LRU list without
reservation?
Not really, there is always the chance that CPU A is reducing the count
from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
which doesn't match the pin count.
We could try to do something like a loop updating the LRU status until
it matches the pin count, but the implications of that are usually
really nasty.
OK, yeah I was more thinking along the lines of protecting the LRU status
with the global lru lock and unpin would then be
if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
add_to_relevant_lrus(bo, bo->lru_status);
spin_unlock(&ttm_glob.lru_lock);
}
But looking at ttm_bo_move_to_lru_tail() I realize that's not really trivial
anymore. I hope it's doable at some point though.
But meanwhile, perhaps TTM needs to accept and pave over that drivers are in
fact destroying pinned buffers?
Do we have more trouble than the very fancy tricks vmwgfx does? If so I
think we could do a small helper that like ttm_dont_check_unpin() to shut
it up. Since vmwgfx drivers tend to not be loaded with any other drivers
that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
out what to do - maybe you do need your own in-house pin/unpin for these
special bo?
I did try to parse your reply in the other thread, and tbh I didn't grock
it.
Not sure if you mean the description was unclear or if you thought it
was a bad idea, but in case the former, what I mean is
static void ttm_bo_pin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held() // No surprises if an
evictor determined that this object is not pinned.
if (!refcount_inc_not_zero(&bo->pin_count)) { // Could be made
ttm_bo_pin_if_pinned() and exported if there are users
spin_lock(&ttm_glob.lru_lock); // Don't race with
unpin 1->0
if (refcount_read(&bo->pin_count) == 0 && bo->lru)
ttm_bo_del_from_lru(bo);
refcount_inc(&bo->pin_count);
spin_unlock(&ttm_glob.lru_lock);
}
}
static void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
ttm_bo_move_to_lru_tail(bo, bo->lru_mem_type, bo->lru_prio,
NULL);
spin_unlock(&ttm_glob.lru_lock);
}
}
In addition, bo->lru_mem_type and bo->lru_prio would need to be
protected by the lru lock, and updated together with the LRU list
position, which would be the extra complexity in fastpaths. Wouldn't
that resolve the pin - lru inconsistency?
But yeah if vmwgfx is the only driver hitting trouble because of this,
then I agree let's leave it for when / if it becomes needed. Having had
that requirement in the Intel driver would have complicated the dma_resv
work quite a lot.
/Thomas
Also I think a comment why we need dma_resv (maybe in the kerneldoc for
pin count), i.e. that it's needed to keep lru state in sync with pin state
would be really good?
-Daniel
/Thomas
Christian.
/Thomas
Christian.
/Thomas
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
> Hi,
>
> On 3/16/21 10:27 AM, Daniel Vetter wrote:
> > On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/15/21 7:47 PM, Christian König wrote:
> > > >
> > > > Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
> > > > > On 3/15/21 11:26 AM, Christian König wrote:
> > > > > >
> > > > > > Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
> > > > > > > Hi, Christian
> > > > > > >
> > > > > > > On 3/12/21 10:38 AM, Christian König wrote:
> > > > > > > > We seem to have some more driver bugs than thought.
> > > > > > > >
> > > > > > > > Signed-off-by: Christian König
> > > > > > > > ---
> > > > > > > > include/drm/ttm/ttm_bo_api.h | 6 --
> > > > > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/include/drm/ttm/ttm_bo_api.h
> > > > > > > > b/include/drm/ttm/ttm_bo_api.h
> > > > > > > > index 4fb523dfab32..df9fe596e7c5 100644
> > > > > > > > --- a/include/drm/ttm/ttm_bo_api.h
> > > > > > > > +++ b/include/drm/ttm/ttm_bo_api.h
> > > > > > > > @@ -603,9 +603,11 @@ static inline void
> > > > > > > > ttm_bo_pin(struct ttm_buffer_object *bo)
> > > > > > > > static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
> > > > > > > > {
> > > > > > > > dma_resv_assert_held(bo->base.resv);
> > > > > > > > - WARN_ON_ONCE(!bo->pin_count);
> > > > > > > > WARN_ON_ONCE(!kref_read(&bo->kref));
> > > > > > > > - --bo->pin_count;
> > > > > > > > + if (bo->pin_count)
> > > > > > > > + --bo->pin_count;
> > > > > > > > + else
> > > > > > > > + WARN_ON_ONCE(true);
> > > > > > > > }
> > > > > > > > int ttm_mem_evict_first(struct ttm_device *bdev,
> > > > > > > Since I now have been staring for half a year at the code of
> > > > > > > the driver that made pinning an art, I have a couple of
> > > > > > > suggestions here, Could we use an atomic for pin_count,
> > > > > > > allowing unlocked unpinning but require the lock only for
> > > > > > > pin_count transition 0->1, (but unlocked for
> > > > > > > pin_if_already_pinned). In particular I think vmwgfx would
> > > > > > > benefit from unlocked unpins. Also if the atomic were a
> > > > > > > refcount_t, that would probably give you the above
> > > > > > > behaviour?
> > > > > > Nope, I've considered this as well while moving the pin count into
> > > > > > TTM.
> > > > > >
> > > > > > The problem is that you not only need the BO reserved for 0->1
> > > > > > transitions, but also for 1->0 transitions to move the BO on the
> > > > > > LRU correctly.
> > > > > Ah, and there is no way to have us know the correct LRU list without
> > > > > reservation?
> > > > Not really, there is always the chance that CPU A is reducing the count
> > > > from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
> > > > which doesn't match the pin count.
> > > >
> > > > We could try to do something like a loop updating the LRU status until
> > > > it matches the pin count, but the implications of that are usually
> > > > really nasty.
> > > >
> > > OK, yeah I was more thinking along the lines of protecting the LRU status
> > > with the global lru lock and unpin would then be
> > >
> > > if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
> > > add_to_relevant_lrus(bo, bo->lru_status);
> > > spin_unlock(&ttm_glob.lru_lock);
> > > }
> > >
> > > But looking at ttm_bo_move_to_lru_tail() I realize that's not really
> > > trivial
> > > anymore. I hope it's doable at some point though.
> > >
> > > But meanwhile, perhaps TTM needs to accept and pave over that drivers are
> > > in
> > > fact destroying pinned buffers?
> > Do we have more trouble than the very fancy tricks vmwgfx does? If so I
> > think we could do a small helper that like ttm_dont_check_unpin() to shut
> > it up. Since vmwgfx drivers tend to not be loaded with any other drivers
> > that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
> > out what to do - maybe you do need your own in-house pin/unpin for these
> > special bo?
> >
> > I did try to parse your reply in the other thread, and tbh I didn't grock
> > it.
>
> Not sure if you mean the description was unclear or if you thought it was a
> bad idea, but in case the former, what I mean is
My unclarity is on what you explained in the vmwgfx thread about how
vmwgfx uses its pin/unpin and why. That was full of vmwgfx concepts I
don't know about. This here looks reasonably clear to me, but it does have
the race Christian sees I think.
> static void ttm_bo_pin(struct ttm_buffer_object *bo)
> {
>
> dma_resv_assert_held() // No surprises if an evictor
> determined that this object is not pinned.
>
> if (!refcount_inc_not_zero(&bo->pin_count)) { // Could be made
> ttm_bo_pin_if_pinned() and exported if there are users
> spin_lock(&ttm_glob.lru_lock);
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On 3/16/21 12:06 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h
b/include/drm/ttm/ttm_bo_api.h
index 4fb523dfab32..df9fe596e7c5 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -603,9 +603,11 @@ static inline void
ttm_bo_pin(struct ttm_buffer_object *bo)
static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
- WARN_ON_ONCE(!bo->pin_count);
WARN_ON_ONCE(!kref_read(&bo->kref));
- --bo->pin_count;
+ if (bo->pin_count)
+ --bo->pin_count;
+ else
+ WARN_ON_ONCE(true);
}
int ttm_mem_evict_first(struct ttm_device *bdev,
Since I now have been staring for half a year at the code of
the driver that made pinning an art, I have a couple of
suggestions here, Could we use an atomic for pin_count,
allowing unlocked unpinning but require the lock only for
pin_count transition 0->1, (but unlocked for
pin_if_already_pinned). In particular I think vmwgfx would
benefit from unlocked unpins. Also if the atomic were a
refcount_t, that would probably give you the above
behaviour?
Nope, I've considered this as well while moving the pin count into TTM.
The problem is that you not only need the BO reserved for 0->1
transitions, but also for 1->0 transitions to move the BO on the
LRU correctly.
Ah, and there is no way to have us know the correct LRU list without
reservation?
Not really, there is always the chance that CPU A is reducing the count
from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
which doesn't match the pin count.
We could try to do something like a loop updating the LRU status until
it matches the pin count, but the implications of that are usually
really nasty.
OK, yeah I was more thinking along the lines of protecting the LRU status
with the global lru lock and unpin would then be
if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
add_to_relevant_lrus(bo, bo->lru_status);
spin_unlock(&ttm_glob.lru_lock);
}
But looking at ttm_bo_move_to_lru_tail() I realize that's not really trivial
anymore. I hope it's doable at some point though.
But meanwhile, perhaps TTM needs to accept and pave over that drivers are in
fact destroying pinned buffers?
Do we have more trouble than the very fancy tricks vmwgfx does? If so I
think we could do a small helper that like ttm_dont_check_unpin() to shut
it up. Since vmwgfx drivers tend to not be loaded with any other drivers
that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
out what to do - maybe you do need your own in-house pin/unpin for these
special bo?
I did try to parse your reply in the other thread, and tbh I didn't grock
it.
Not sure if you mean the description was unclear or if you thought it was a
bad idea, but in case the former, what I mean is
My unclarity is on what you explained in the vmwgfx thread about how
vmwgfx uses its pin/unpin and why. That was full of vmwgfx concepts I
don't know about. This here looks reasonably clear to me, but it does have
the race Christian sees I think.
Hmm, OK, I thought transition 0->1 under the LRU lock would have
resolved that...
static void ttm_bo_pin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held() // No surprises if an evictor
determined that this object is not pinned.
if (!refcount_inc_not_zero(&bo->pin_count)) { // Could be made
ttm_bo_pin_if_pinned() and exported if there are users
spin_lock(&ttm_glob.lru_lock); // Don't race with unpin
1->0
if (refcount_read(&bo->pin_count) == 0 && bo->lru)
ttm_bo_del_from_lru(bo);
refcount_inc(&bo->pin_count);
spin_unlock(&ttm_glob.lru_lock);
}
}
static void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
ttm_bo_move_to_lru_tail(bo, bo->lru_mem_type, bo->lru_prio,
NULL);
spin_unlock(&ttm_glob.lru_lock);
}
}
In addition, bo->lru_mem_type and bo->lru_prio would need to be protected by
the lru lock, and updated together with the LRU list position, which would
be the extra complexity in fastpaths. Wouldn't that resolve the pin - lru
inconsistency?
But yeah if vmwgfx is the only driver hitting trouble because of t
Re: [PATCH] drm: xlnx: call pm_runtime_get_sync before setting pixel clock
Ping.
Any comment on this patch?
Thanks,
Quanyang
On 3/10/21 12:59 PM, quanyang.w...@windriver.com wrote:
From: Quanyang Wang
The Runtime PM subsystem will force the device "fd4a.zynqmp-display"
to enter suspend state while booting if the following conditions are met:
- the usage counter is zero (pm_runtime_get_sync hasn't been called yet)
- no 'active' children (no zynqmp-dp-snd-xx node under dpsub node)
- no other device in the same power domain (dpdma node has no
"power-domains = <&zynqmp_firmware PD_DP>" property)
So there is a scenario as below:
1) DP device enters suspend state <- call zynqmp_gpd_power_off
2) zynqmp_disp_crtc_setup_clock <- configurate register VPLL_FRAC_CFG
3) pm_runtime_get_sync <- call zynqmp_gpd_power_on and clear
previous
VPLL_FRAC_CFG configuration
4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG
configuration is corrupted
From above, we can see that pm_runtime_get_sync may clear register
VPLL_FRAC_CFG configuration and result the failure of clk enabling.
Putting pm_runtime_get_sync at the very beginning of the function
zynqmp_disp_crtc_atomic_enable can resolve this issue.
Signed-off-by: Quanyang Wang
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 148add0ca1d6..909e6c265406 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1445,9 +1445,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode = &crtc->state->adjusted_mode;
int ret, vrefresh;
+ pm_runtime_get_sync(disp->dev);
+
zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode);
- pm_runtime_get_sync(disp->dev);
ret = clk_prepare_enable(disp->pclk);
if (ret) {
dev_err(disp->dev, "failed to enable a pixel clock\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/ttm: switch to per device LRU lock
Am 16.03.21 um 10:35 schrieb Daniel Vetter:
On Mon, Mar 15, 2021 at 05:04:22PM +0100, Christian König wrote:
Instead of having a global lock.
Signed-off-by: Christian König
I guess per zone lru lock is a lot more work since then we need to handle
ordering and ABBA deadlocks? s/zone/mem region/ I think is the proper ttm
lingo.
Making the LRU per resource manager is the long term goal, yes.
My key idea so far is that we make bo->mem a pointer and then move the
LRU handling into the resource object instead of the BO.
The resource object then just references the BO and so that we can
figure out which BO to evict or which fence to wait for to free up a
resource.
Regards,
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
include/drm/ttm/ttm_bo_driver.h| 4 +--
include/drm/ttm/ttm_device.h | 4 +--
8 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9d19078246c8..ae18c0e32347 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
*adev,
struct amdgpu_vm_bo_base *bo_base;
if (vm->bulk_moveable) {
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&adev->mman.bdev.lru_lock);
ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&adev->mman.bdev.lru_lock);
return;
}
memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&adev->mman.bdev.lru_lock);
list_for_each_entry(bo_base, &vm->idle, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
@@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
&bo->shadow->tbo.mem,
&vm->lru_bulk_move);
}
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&adev->mman.bdev.lru_lock);
vm->bulk_moveable = true;
}
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index f5845c96d414..b19f2f00b215 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(&release->base);
- spin_lock(&ttm_glob.lru_lock);
-
list_for_each_entry(entry, &release->bos, head) {
bo = entry->bo;
dma_resv_add_shared_fence(bo->base.resv, &release->base);
- ttm_bo_move_to_lru_tail(bo, &bo->mem, NULL);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
dma_resv_unlock(bo->base.resv);
}
- spin_unlock(&ttm_glob.lru_lock);
ww_acquire_fini(&release->ticket);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a1be88be357b..a8103c8718a3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -242,9 +242,9 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
* reference it any more. The only tricky case is the trylock on
* the resv object while holding the lru_lock.
*/
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&bo->bdev->lru_lock);
bo->base.resv = &bo->base._resv;
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
}
return r;
@@ -303,7 +303,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
if (unlock_resv)
dma_resv_unlock(bo->base.resv);
- spin_unlock(&ttm_glob.lru_lock);
+ spin_unlock(&bo->bdev->lru_lock);
lret = dma_resv_wait_timeout_rcu(resv, true, interruptible,
30 * HZ);
@@ -313,7 +313,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
else if (lret == 0)
return -EBUSY;
- spin_lock(&ttm_glob.lru_lock);
+ spin_lock(&bo->bdev->lru_lock);
if (unlock_resv && !dma_resv_trylock(bo->base.resv)) {
/*
* We raced, and lost, someone else holds the
reservation now,
@@ -323,7 +323,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
Re: [PATCH 3/3] drm/ttm: switch to per device LRU lock
On Tue, Mar 16, 2021 at 1:03 PM Christian König
wrote:
>
> Am 16.03.21 um 10:35 schrieb Daniel Vetter:
> > On Mon, Mar 15, 2021 at 05:04:22PM +0100, Christian König wrote:
> >> Instead of having a global lock.
> >>
> >> Signed-off-by: Christian König
> > I guess per zone lru lock is a lot more work since then we need to handle
> > ordering and ABBA deadlocks? s/zone/mem region/ I think is the proper ttm
> > lingo.
>
> Making the LRU per resource manager is the long term goal, yes.
>
> My key idea so far is that we make bo->mem a pointer and then move the
> LRU handling into the resource object instead of the BO.
>
> The resource object then just references the BO and so that we can
> figure out which BO to evict or which fence to wait for to free up a
> resource.
Hm yeah that could work out fairly nicely. Both from locking but also
refcounting pov. And maybe we could then use entirely free-standing
mem objects instead of ghost objects? Since that's a part of ttm I
don't grok and it always looks a bit like a hack to me. So for these
ghost mem objects you'd only need the lru + dma_fence_wait (can grab a
fence ref under the lru and then drop lru lock for that) for eviction,
no dma_resv_lock.
-Daniel
>
> Regards,
> Christian.
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
> >> drivers/gpu/drm/qxl/qxl_release.c | 5 +--
> >> drivers/gpu/drm/ttm/ttm_bo.c | 49 --
> >> drivers/gpu/drm/ttm/ttm_device.c | 12 +++
> >> drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
> >> drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
> >> include/drm/ttm/ttm_bo_driver.h| 4 +--
> >> include/drm/ttm/ttm_device.h | 4 +--
> >> 8 files changed, 43 insertions(+), 56 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> index 9d19078246c8..ae18c0e32347 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> @@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
> >> *adev,
> >> struct amdgpu_vm_bo_base *bo_base;
> >>
> >> if (vm->bulk_moveable) {
> >> -spin_lock(&ttm_glob.lru_lock);
> >> +spin_lock(&adev->mman.bdev.lru_lock);
> >> ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
> >> -spin_unlock(&ttm_glob.lru_lock);
> >> +spin_unlock(&adev->mman.bdev.lru_lock);
> >> return;
> >> }
> >>
> >> memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
> >>
> >> -spin_lock(&ttm_glob.lru_lock);
> >> +spin_lock(&adev->mman.bdev.lru_lock);
> >> list_for_each_entry(bo_base, &vm->idle, vm_status) {
> >> struct amdgpu_bo *bo = bo_base->bo;
> >>
> >> @@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
> >> *adev,
> >> &bo->shadow->tbo.mem,
> >> &vm->lru_bulk_move);
> >> }
> >> -spin_unlock(&ttm_glob.lru_lock);
> >> +spin_unlock(&adev->mman.bdev.lru_lock);
> >>
> >> vm->bulk_moveable = true;
> >> }
> >> diff --git a/drivers/gpu/drm/qxl/qxl_release.c
> >> b/drivers/gpu/drm/qxl/qxl_release.c
> >> index f5845c96d414..b19f2f00b215 100644
> >> --- a/drivers/gpu/drm/qxl/qxl_release.c
> >> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> >> @@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct
> >> qxl_release *release)
> >> release->id | 0xf000, release->base.seqno);
> >> trace_dma_fence_emit(&release->base);
> >>
> >> -spin_lock(&ttm_glob.lru_lock);
> >> -
> >> list_for_each_entry(entry, &release->bos, head) {
> >> bo = entry->bo;
> >>
> >> dma_resv_add_shared_fence(bo->base.resv, &release->base);
> >> -ttm_bo_move_to_lru_tail(bo, &bo->mem, NULL);
> >> +ttm_bo_move_to_lru_tail_unlocked(bo);
> >> dma_resv_unlock(bo->base.resv);
> >> }
> >> -spin_unlock(&ttm_glob.lru_lock);
> >> ww_acquire_fini(&release->ticket);
> >> }
> >>
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >> index a1be88be357b..a8103c8718a3 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >> @@ -242,9 +242,9 @@ static int ttm_bo_individualize_resv(struct
> >> ttm_buffer_object *bo)
> >> * reference it any more. The only tricky case is the trylock
> >> on
> >> * the resv object while holding the lru_lock.
> >> */
> >> -spin_lock(&ttm_glob.lru_lock);
> >> +spin_lock(&bo->bdev->lru_lock);
> >> bo->base.resv = &bo->base._resv;
> >> -spin_unlock(&ttm_glob.lru_lock);
> >> +spin_unlock(&bo->bdev->lru_lock);
> >> }
> >>
> >> return r;
> >> @@ -303,7 +303,7 @@ static int ttm_b
Re: [PATCH v8 0/3] GUD USB Display driver
Den 13.03.2021 12.25, skrev Noralf Trønnes: > Hi, > > A while back I had the idea to turn a Raspberry Pi Zero into a $5 > USB to HDMI/SDTV/DPI display adapter. > > The protocol is open so people are free to make displays implementing it and > use this driver, all that's needed is to add a USB vid:pid to the driver for > the display. > > See the wiki[1] for more information and images for the Raspberry Pi Zero/4. > > Changes in this version: > - Forgot to filter RGB111 from reaching userspace > - Handle a device that only returns unknown device properties (Peter) > - s/GUD_PIXEL_FORMAT_RGB111/GUD_PIXEL_FORMAT_XRGB/ (Peter) > - Fix R1 and XRGB format conversion > - Add FIXME about Big Endian being broken (Peter, Ilia) > > I will apply the patches as soon as the dependency shows up in drm-misc-next. > > Dependency: > drm: Use USB controller's DMA mask when importing dmabufs[2] > (currently in drm-misc-fixes but not in drm-misc-next yet, also present in > drm-tip and linux-next) > > Noralf. > > [1] https://github.com/notro/gud/wiki > [2] > https://patchwork.freedesktop.org/patch/msgid/20210303133229.3288-1-tzimmerm...@suse.de > > > Noralf Trønnes (3): > drm/uapi: Add USB connector type > drm/probe-helper: Check epoch counter in output_poll_execute() > drm: Add GUD USB Display driver > Patches are now applied to drm-misc-next. Thanks for reviewing and testing! Noralf. > MAINTAINERS | 8 + > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/drm_connector.c | 1 + > drivers/gpu/drm/drm_probe_helper.c | 7 +- > drivers/gpu/drm/gud/Kconfig | 14 + > drivers/gpu/drm/gud/Makefile| 4 + > drivers/gpu/drm/gud/gud_connector.c | 729 > drivers/gpu/drm/gud/gud_drv.c | 661 + > drivers/gpu/drm/gud/gud_internal.h | 154 ++ > drivers/gpu/drm/gud/gud_pipe.c | 552 + > include/drm/gud.h | 333 + > include/uapi/drm/drm_mode.h | 1 + > 13 files changed, 2466 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/gud/Kconfig > create mode 100644 drivers/gpu/drm/gud/Makefile > create mode 100644 drivers/gpu/drm/gud/gud_connector.c > create mode 100644 drivers/gpu/drm/gud/gud_drv.c > create mode 100644 drivers/gpu/drm/gud/gud_internal.h > create mode 100644 drivers/gpu/drm/gud/gud_pipe.c > create mode 100644 include/drm/gud.h > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
On 2021-03-15 08:33, Christoph Hellwig wrote: On Fri, Mar 12, 2021 at 04:18:24PM +, Robin Murphy wrote: Let me know what you think of the version here: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup I'll happily switch the patch to you as the author if you're fine with that as well. I still have reservations about removing the attribute API entirely and pretending that io_pgtable_cfg is anything other than a SoC-specific private interface, I think a private inteface would make more sense. For now I've just condensed it down to a generic set of quirk bits and dropped the attrs structure, which seems like an ok middle ground for now. That being said I wonder why that quirk isn't simply set in the device tree? Because it's a software policy decision rather than any inherent property of the platform, and the DT certainly doesn't know *when* any particular device might prefer its IOMMU to use cacheable pagetables to minimise TLB miss latency vs. saving the cache capacity for larger data buffers. It really is most logical to decide this at the driver level. In truth the overall concept *is* relatively generic (a trend towards larger system caches and cleverer usage is about both raw performance and saving power on off-SoC DRAM traffic), it's just the particular implementation of using io-pgtable to set an outer-cacheable walk attribute in an SMMU TCR that's pretty much specific to Qualcomm SoCs. Hence why having a common abstraction at the iommu_domain level, but where the exact details are free to vary across different IOMMUs and their respective client drivers, is in many ways an ideal fit. but the reworked patch on its own looks reasonable to me, thanks! (I wasn't too convinced about the iommu_cmd_line wrappers either...) Just iommu_get_dma_strict() needs an export since the SMMU drivers can be modular - I consciously didn't add that myself since I was mistakenly thinking only iommu-dma would call it. Fixed. Can I get your signoff for the patch? Then I'll switch it to over to being attributed to you. Sure - I would have thought that the one I originally posted still stands, but for the avoidance of doubt, for the parts of commit 8b6d45c495bd in your tree that remain from what I wrote: Signed-off-by: Robin Murphy Cheers, Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: dsi: fix unsigned expression compared with zero
On 14/03/2021 04:15, Laurent Pinchart wrote: Hi Junlin, Thank you for the patch. On Fri, Mar 12, 2021 at 03:14:45PM +0800, angkery wrote: From: Junlin Yang r is "u32" always >= 0,mipi_dsi_create_packet may return little than zero. so r < 0 condition is never accessible. Fixes coccicheck warnings: ./drivers/gpu/drm/omapdrm/dss/dsi.c:2155:5-6: WARNING: Unsigned expression compared with zero: r < 0 Signed-off-by: Junlin Yang Reviewed-by: Laurent Pinchart Tomi, will you take this in your tree ? Thanks. Yes, I'll pick this up. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On Tue, Mar 16, 2021 at 12:24 PM Thomas Hellström (Intel)
wrote:
>
>
> On 3/16/21 12:06 PM, Daniel Vetter wrote:
> > On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
> >> Hi,
> >>
> >> On 3/16/21 10:27 AM, Daniel Vetter wrote:
> >>> On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
> On 3/15/21 7:47 PM, Christian König wrote:
> > Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
> >> On 3/15/21 11:26 AM, Christian König wrote:
> >>> Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
> Hi, Christian
>
> On 3/12/21 10:38 AM, Christian König wrote:
> > We seem to have some more driver bugs than thought.
> >
> > Signed-off-by: Christian König
> > ---
> > include/drm/ttm/ttm_bo_api.h | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/drm/ttm/ttm_bo_api.h
> > b/include/drm/ttm/ttm_bo_api.h
> > index 4fb523dfab32..df9fe596e7c5 100644
> > --- a/include/drm/ttm/ttm_bo_api.h
> > +++ b/include/drm/ttm/ttm_bo_api.h
> > @@ -603,9 +603,11 @@ static inline void
> > ttm_bo_pin(struct ttm_buffer_object *bo)
> > static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
> > {
> > dma_resv_assert_held(bo->base.resv);
> > -WARN_ON_ONCE(!bo->pin_count);
> > WARN_ON_ONCE(!kref_read(&bo->kref));
> > ---bo->pin_count;
> > +if (bo->pin_count)
> > +--bo->pin_count;
> > +else
> > +WARN_ON_ONCE(true);
> > }
> > int ttm_mem_evict_first(struct ttm_device *bdev,
> Since I now have been staring for half a year at the code of
> the driver that made pinning an art, I have a couple of
> suggestions here, Could we use an atomic for pin_count,
> allowing unlocked unpinning but require the lock only for
> pin_count transition 0->1, (but unlocked for
> pin_if_already_pinned). In particular I think vmwgfx would
> benefit from unlocked unpins. Also if the atomic were a
> refcount_t, that would probably give you the above
> behaviour?
> >>> Nope, I've considered this as well while moving the pin count into
> >>> TTM.
> >>>
> >>> The problem is that you not only need the BO reserved for 0->1
> >>> transitions, but also for 1->0 transitions to move the BO on the
> >>> LRU correctly.
> >> Ah, and there is no way to have us know the correct LRU list without
> >> reservation?
> > Not really, there is always the chance that CPU A is reducing the count
> > from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
> > which doesn't match the pin count.
> >
> > We could try to do something like a loop updating the LRU status until
> > it matches the pin count, but the implications of that are usually
> > really nasty.
> >
> OK, yeah I was more thinking along the lines of protecting the LRU status
> with the global lru lock and unpin would then be
>
> if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
> add_to_relevant_lrus(bo, bo->lru_status);
> spin_unlock(&ttm_glob.lru_lock);
> }
>
> But looking at ttm_bo_move_to_lru_tail() I realize that's not really
> trivial
> anymore. I hope it's doable at some point though.
>
> But meanwhile, perhaps TTM needs to accept and pave over that drivers
> are in
> fact destroying pinned buffers?
> >>> Do we have more trouble than the very fancy tricks vmwgfx does? If so I
> >>> think we could do a small helper that like ttm_dont_check_unpin() to shut
> >>> it up. Since vmwgfx drivers tend to not be loaded with any other drivers
> >>> that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
> >>> out what to do - maybe you do need your own in-house pin/unpin for these
> >>> special bo?
> >>>
> >>> I did try to parse your reply in the other thread, and tbh I didn't grock
> >>> it.
> >> Not sure if you mean the description was unclear or if you thought it was a
> >> bad idea, but in case the former, what I mean is
> > My unclarity is on what you explained in the vmwgfx thread about how
> > vmwgfx uses its pin/unpin and why. That was full of vmwgfx concepts I
> > don't know about. This here looks reasonably clear to me, but it does have
> > the race Christian sees I think.
>
> Hmm, OK, I thought transition 0->1 under the LRU lock would have
> resolved that...
Hm now you make me question how this all works again, and when it
stops working. I do think yours works, but it triggers another icky
thing I have with refcounts and locking. And at this point pin_count
is more a refcount really ...
So imo the way to do a weak refcount is kre
Re: [PATCH] drm/panel: panel-dsi-cm: disable TE for now
Hi Sebastian, Sam, Thierry,
On 27/02/2021 23:45, Sebastian Reichel wrote:
From: Sebastian Reichel
Disable TE for Droid 4 panel, since implementation is currently
broken. Also disable it for N950 panel, which is untested.
Reported-by: Tony Lindgren
Reported-by: Tomi Valkeinen
Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core")
Signed-off-by: Sebastian Reichel
---
I suggest to start by fix the regression like this and look into
proper Droid 4 TE support separatly. Assumption is, that Tomi
tested taal panel, droid4 panel is 'broken' and N950 (himalaya)
is untested [*], so choosing safe default. Patch is compile-tested
only.
[*] N950 display is not yet functional on mainline, since it needs
the omap3 FIFO workaround:
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/commit/?h=n950-display-tony&id=d4cbc226a30b29bf258397b052c9ec68c8a3
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
Reviewed-by: Tomi Valkeinen
Sam, Thierry, will you pick this up or can I push to drm-misc-fixes?
Tomi
diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
b/drivers/gpu/drm/panel/panel-dsi-cm.c
index af381d756ac1..5fbfb71ca3d9 100644
--- a/drivers/gpu/drm/panel/panel-dsi-cm.c
+++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
@@ -37,6 +37,7 @@ struct dsic_panel_data {
u32 height_mm;
u32 max_hs_rate;
u32 max_lp_rate;
+ bool te_support;
};
struct panel_drv_data {
@@ -334,9 +335,11 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
if (r)
goto err;
- r = mipi_dsi_dcs_set_tear_on(ddata->dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
- if (r)
- goto err;
+ if (ddata->panel_data->te_support) {
+ r = mipi_dsi_dcs_set_tear_on(ddata->dsi,
MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (r)
+ goto err;
+ }
/* possible panel bug */
msleep(100);
@@ -619,6 +622,7 @@ static const struct dsic_panel_data taal_data = {
.height_mm = 0,
.max_hs_rate = 3,
.max_lp_rate = 1000,
+ .te_support = true,
};
static const struct dsic_panel_data himalaya_data = {
@@ -629,6 +633,7 @@ static const struct dsic_panel_data himalaya_data = {
.height_mm = 88,
.max_hs_rate = 3,
.max_lp_rate = 1000,
+ .te_support = false,
};
static const struct dsic_panel_data droid4_data = {
@@ -639,6 +644,7 @@ static const struct dsic_panel_data droid4_data = {
.height_mm = 89,
.max_hs_rate = 3,
.max_lp_rate = 1000,
+ .te_support = false,
};
static const struct of_device_id dsicm_of_match[] = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-buf: Add an API for exporting sync files (v6)
On Tue, Mar 16, 2021 at 3:51 AM Michel Dänzer wrote:
>
> On 2021-03-16 12:10 a.m., Jason Ekstrand wrote:
> > On Mon, Mar 15, 2021 at 4:05 PM Jason Ekstrand wrote:
> >>
> >> Modern userspace APIs like Vulkan are built on an explicit
> >> synchronization model. This doesn't always play nicely with the
> >> implicit synchronization used in the kernel and assumed by X11 and
> >> Wayland. The client -> compositor half of the synchronization isn't too
> >> bad, at least on intel, because we can control whether or not i915
> >> synchronizes on the buffer and whether or not it's considered written.
> >>
> >> The harder part is the compositor -> client synchronization when we get
> >> the buffer back from the compositor. We're required to be able to
> >> provide the client with a VkSemaphore and VkFence representing the point
> >> in time where the window system (compositor and/or display) finished
> >> using the buffer. With current APIs, it's very hard to do this in such
> >> a way that we don't get confused by the Vulkan driver's access of the
> >> buffer. In particular, once we tell the kernel that we're rendering to
> >> the buffer again, any CPU waits on the buffer or GPU dependencies will
> >> wait on some of the client rendering and not just the compositor.
> >>
> >> This new IOCTL solves this problem by allowing us to get a snapshot of
> >> the implicit synchronization state of a given dma-buf in the form of a
> >> sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
> >> instead of CPU waiting directly, it encapsulates the wait operation, at
> >> the current moment in time, in a sync_file so we can check/wait on it
> >> later. As long as the Vulkan driver does the sync_file export from the
> >> dma-buf before we re-introduce it for rendering, it will only contain
> >> fences from the compositor or display. This allows to accurately turn
> >> it into a VkFence or VkSemaphore without any over- synchronization.
> >>
> >> v2 (Jason Ekstrand):
> >> - Use a wrapper dma_fence_array of all fences including the new one
> >>when importing an exclusive fence.
> >>
> >> v3 (Jason Ekstrand):
> >> - Lock around setting shared fences as well as exclusive
> >> - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
> >> - Initialize ret to 0 in dma_buf_wait_sync_file
> >>
> >> v4 (Jason Ekstrand):
> >> - Use the new dma_resv_get_singleton helper
> >>
> >> v5 (Jason Ekstrand):
> >> - Rename the IOCTLs to import/export rather than wait/signal
> >> - Drop the WRITE flag and always get/set the exclusive fence
> >>
> >> v6 (Jason Ekstrand):
> >> - Drop the sync_file import as it was all-around sketchy and not nearly
> >>as useful as import.
> >> - Re-introduce READ/WRITE flag support for export
> >> - Rework the commit message
> >>
> >> Signed-off-by: Jason Ekstrand
> >> ---
> >> drivers/dma-buf/dma-buf.c| 55
> >> include/uapi/linux/dma-buf.h | 6
> >> 2 files changed, 61 insertions(+)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index f264b70c383eb..e7f9dd62c19a9 100644
> >> --- a/drivers/dma-buf/dma-buf.c
> >> +++ b/drivers/dma-buf/dma-buf.c
> [...]
> >> @@ -362,6 +363,57 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
> >> const char __user *buf)
> >> return ret;
> >> }
> >>
> >> +static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
> >> +void __user *user_data)
> >> +{
> >> + struct dma_buf_sync_file arg;
> >> + struct dma_fence *fence = NULL;
> >> + struct sync_file *sync_file;
> >> + int fd, ret;
> >> +
> >> + if (copy_from_user(&arg, user_data, sizeof(arg)))
> >> + return -EFAULT;
> >> +
> >> + if (arg.flags & ~DMA_BUF_SYNC_RW)
> >> + return -EINVAL;
> >> +
> >> + fd = get_unused_fd_flags(O_CLOEXEC);
> >> + if (fd < 0)
> >> + return fd;
> >> +
> >> + if (arg.flags & DMA_BUF_SYNC_WRITE) {
> >> + ret = dma_resv_get_singleton(dmabuf->resv, NULL, &fence);
> >> + if (ret)
> >> + goto err_put_fd;
> >> + } else if (arg.flags & DMA_BUF_SYNC_READ) {
> >> + fence = dma_resv_get_excl(dmabuf->resv);
> >> + }
> >> +
> >> + if (!fence)
> >> + fence = dma_fence_get_stub();
> >> +
> >> + sync_file = sync_file_create(fence);
> >> +
> >> + dma_fence_put(fence);
> >> +
> >> + if (!sync_file) {
> >> + ret = -EINVAL;
> >
> > Should this be -EINVAL or -ENOMEM?
>
> The latter makes more sense to me, since sync_file_create returning NULL is
> not related to invalid ioctl parameters.
I've switched to -ENOMEM. It'll be part of v8 whenever I send it out.
I'd like to get some "real" review first.
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mail
Re: [PATCH 3/3] drm/ttm: switch to per device LRU lock
Am 16.03.21 um 13:05 schrieb Daniel Vetter:
On Tue, Mar 16, 2021 at 1:03 PM Christian König
wrote:
Am 16.03.21 um 10:35 schrieb Daniel Vetter:
On Mon, Mar 15, 2021 at 05:04:22PM +0100, Christian König wrote:
Instead of having a global lock.
Signed-off-by: Christian König
I guess per zone lru lock is a lot more work since then we need to handle
ordering and ABBA deadlocks? s/zone/mem region/ I think is the proper ttm
lingo.
Making the LRU per resource manager is the long term goal, yes.
My key idea so far is that we make bo->mem a pointer and then move the
LRU handling into the resource object instead of the BO.
The resource object then just references the BO and so that we can
figure out which BO to evict or which fence to wait for to free up a
resource.
Hm yeah that could work out fairly nicely. Both from locking but also
refcounting pov. And maybe we could then use entirely free-standing
mem objects instead of ghost objects? Since that's a part of ttm I
don't grok and it always looks a bit like a hack to me. So for these
ghost mem objects you'd only need the lru + dma_fence_wait (can grab a
fence ref under the lru and then drop lru lock for that) for eviction,
no dma_resv_lock.
Exactly that's the background here, yes.
Those ghost objects are more than just a bit of a hack and result in
tons of checks in the driver if a BO is really a BO or a ghost.
Moving all that handling into the resource objects not only allows us to
remove that, but also makes things like delayed delete work out pretty
nicely.
Christian.
-Daniel
Regards,
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 ++---
drivers/gpu/drm/qxl/qxl_release.c | 5 +--
drivers/gpu/drm/ttm/ttm_bo.c | 49 --
drivers/gpu/drm/ttm/ttm_device.c | 12 +++
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 8 ++---
drivers/gpu/drm/ttm/ttm_resource.c | 9 +++--
include/drm/ttm/ttm_bo_driver.h| 4 +--
include/drm/ttm/ttm_device.h | 4 +--
8 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9d19078246c8..ae18c0e32347 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -638,15 +638,15 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device
*adev,
struct amdgpu_vm_bo_base *bo_base;
if (vm->bulk_moveable) {
-spin_lock(&ttm_glob.lru_lock);
+spin_lock(&adev->mman.bdev.lru_lock);
ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
-spin_unlock(&ttm_glob.lru_lock);
+spin_unlock(&adev->mman.bdev.lru_lock);
return;
}
memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
-spin_lock(&ttm_glob.lru_lock);
+spin_lock(&adev->mman.bdev.lru_lock);
list_for_each_entry(bo_base, &vm->idle, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
@@ -660,7 +660,7 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
&bo->shadow->tbo.mem,
&vm->lru_bulk_move);
}
-spin_unlock(&ttm_glob.lru_lock);
+spin_unlock(&adev->mman.bdev.lru_lock);
vm->bulk_moveable = true;
}
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index f5845c96d414..b19f2f00b215 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -426,16 +426,13 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
release->id | 0xf000, release->base.seqno);
trace_dma_fence_emit(&release->base);
-spin_lock(&ttm_glob.lru_lock);
-
list_for_each_entry(entry, &release->bos, head) {
bo = entry->bo;
dma_resv_add_shared_fence(bo->base.resv, &release->base);
-ttm_bo_move_to_lru_tail(bo, &bo->mem, NULL);
+ttm_bo_move_to_lru_tail_unlocked(bo);
dma_resv_unlock(bo->base.resv);
}
-spin_unlock(&ttm_glob.lru_lock);
ww_acquire_fini(&release->ticket);
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a1be88be357b..a8103c8718a3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -242,9 +242,9 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
* reference it any more. The only tricky case is the trylock on
* the resv object while holding the lru_lock.
*/
-spin_lock(&ttm_glob.lru_lock);
+spin_lock(&bo->bdev->lru_lock);
bo->base.resv = &bo->base._resv;
-spin_unlock(&ttm_glob.lru_lock);
+spin_unlock(&bo->bdev->lru_lock);
}
return r;
@@ -303,7 +303,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
[PATCH 0/3] switch to unsafe_follow_pfn
Hi all, This are the leftovers from my pull that landed in 5.12: https://lore.kernel.org/dri-devel/CAKMK7uHQ=6ojcrgucutib456rwdcfwsnexv8pqsfspodtj6...@mail.gmail.com/ Only changes compared to the old submission are: - dropped vfio and kvm patch - add patch to just remove follow_pfn at the end Assuming no objections I'd like to lande these three patches in my topic branch for 5.13, for sufficient amounts of testing in linux-next before the merge window. Ack/review especially on the two mm patches very much thought after. Cheers, Daniel Daniel Vetter (3): mm: Add unsafe_follow_pfn media/videobuf1|2: Mark follow_pfn usage as unsafe mm: unexport follow_pfn drivers/media/common/videobuf2/frame_vector.c | 2 +- drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- include/linux/mm.h| 4 +- mm/memory.c | 46 --- mm/nommu.c| 28 --- security/Kconfig | 13 ++ 6 files changed, 68 insertions(+), 27 deletions(-) -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] mm: Add unsafe_follow_pfn
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea.
Unfortunately there's some users where this is not fixable (like v4l
userptr of iomem mappings) or involves a pile of work (vfio type1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Also mark up follow_pfn as EXPORT_SYMBOL_GPL. The only safe way to use
that by drivers/modules is together with an mmu_notifier, and that's
all _GPL stuff.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v5: Suggestions from Christoph
- reindent for less weirdness
- use IS_ENABLED instead of #ifdef
- same checks for nommu, for consistency
- EXPORT_SYMBOL_GPL for follow_pfn.
- kerneldoc was already updated in previous versions to explain when
follow_pfn can be used safely
---
include/linux/mm.h | 2 ++
mm/memory.c| 34 --
mm/nommu.c | 27 ++-
security/Kconfig | 13 +
4 files changed, 73 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 64a71bf20536..caec8b25d66f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1695,6 +1695,8 @@ int follow_pte(struct mm_struct *mm, unsigned long
address,
pte_t **ptepp, spinlock_t **ptlp);
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
unsigned int flags, unsigned long *prot, resource_size_t *phys);
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 5efa07fb6cdc..e8a145505b69 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4741,7 +4741,12 @@ EXPORT_SYMBOL_GPL(follow_pte);
* @address: user virtual address
* @pfn: location to store found PFN
*
- * Only IO mappings and raw PFN mappings are allowed.
+ * Only IO mappings and raw PFN mappings are allowed. Note that callers must
+ * ensure coherency with pte updates by using a &mmu_notifier to follow
updates.
+ * If this is not feasible, or the access to the @pfn is only very short term,
+ * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
+ * the access instead. Any caller not following these requirements must use
+ * unsafe_follow_pfn() instead.
*
* This function does not allow the caller to read the permissions
* of the PTE. Do not use it.
@@ -4765,7 +4770,32 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
pte_unmap_unlock(ptep, ptl);
return 0;
}
-EXPORT_SYMBOL(follow_pfn);
+EXPORT_SYMBOL_GPL(follow_pfn);
+
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+ if (IS_ENABLED(CONFIG_STRICT_FOLLOW_PFN)) {
+ pr_info("unsafe follow_pfn usage rejected, see
CONFIG_STRICT_FOLLOW_PFN\n");
+ return -EINVAL;
+ }
+
+ WARN_ONCE(1, "unsafe follow_pfn usage\n");
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+
+ return follow_pfn(vma, address, pfn);
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
#ifdef CONFIG_HAVE_IOREMAP_PROT
int follow_phys(struct vm_area_struct *vma,
diff --git a/mm/nommu.c b/mm/nommu.c
index 5c9ab799c0e6..1dc983f50e2c 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -130,7 +130,32 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
*pfn = address >> PAGE_SHIFT;
return
[PATCH 2/3] media/videobuf1|2: Mark follow_pfn usage as unsafe
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.
userptr for normal memory will keep working as-is, this only affects
the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
videobuf2-dma-sg: Support io userptr operations on io memory").
Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Daniel Jordan
Cc: Michel Lespinasse
Signed-off-by: Daniel Vetter
--
v3:
- Reference the commit that enabled the zerocopy userptr use case to
make it abundandtly clear that this patch only affects that, and not
normal memory userptr. The old commit message already explained that
normal memory userptr is unaffected, but I guess that was not clear
enough.
---
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/videobuf2/frame_vector.c
b/drivers/media/common/videobuf2/frame_vector.c
index a0e65481a201..1a82ec13ea00 100644
--- a/drivers/media/common/videobuf2/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
break;
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
- err = follow_pfn(vma, start, &nums[ret]);
+ err = unsafe_follow_pfn(vma, start, &nums[ret]);
if (err) {
if (ret == 0)
ret = err;
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 52312ce2ba05..821c4a76ab96 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
user_address = untagged_baddr;
while (pages_done < (mem->size >> PAGE_SHIFT)) {
- ret = follow_pfn(vma, user_address, &this_pfn);
+ ret = unsafe_follow_pfn(vma, user_address, &this_pfn);
if (ret)
break;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] mm: unexport follow_pfn
Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
follow_pte()")) have lost their callsites of follow_pfn(). All the
other ones have been switched over to unsafe_follow_pfn because they
cannot be fixed without breaking userspace api.
Argueably the vfio code is still racy, but that's kinda a bigger
picture. But since it does leak the pte beyond where it drops the pt
lock, without anything else like an mmu notifier guaranteeing
coherence, the problem is at least clearly visible in the vfio code.
So good enough with me.
I've decided to keep the explanation that after dropping the pt lock
you must have an mmu notifier if you keep using the pte somehow by
adjusting it and moving it into the kerneldoc for the new follow_pte()
function.
Cc: 3...@google.com
Cc: Jann Horn
Cc: Paolo Bonzini
Cc: Jason Gunthorpe
Cc: Cornelia Huck
Cc: Peter Xu
Cc: Alex Williamson
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
include/linux/mm.h | 2 --
mm/memory.c| 26 +-
mm/nommu.c | 13 +
3 files changed, 6 insertions(+), 35 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index caec8b25d66f..304588e2f829 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1693,8 +1693,6 @@ int follow_invalidate_pte(struct mm_struct *mm, unsigned
long address,
pmd_t **pmdpp, spinlock_t **ptlp);
int follow_pte(struct mm_struct *mm, unsigned long address,
pte_t **ptepp, spinlock_t **ptlp);
-int follow_pfn(struct vm_area_struct *vma, unsigned long address,
- unsigned long *pfn);
int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
diff --git a/mm/memory.c b/mm/memory.c
index e8a145505b69..317e653c8aeb 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4724,7 +4724,10 @@ int follow_invalidate_pte(struct mm_struct *mm, unsigned
long address,
* should be taken for read.
*
* KVM uses this function. While it is arguably less bad than ``follow_pfn``,
- * it is not a good general-purpose API.
+ * it is not a good general-purpose API: If callers use the pte after they've
+ * unlocked @ptlp they must ensure coherency with pte updates by using a
+ * &mmu_notifier to follow updates. Any caller not following these requirements
+ * must use unsafe_follow_pfn() instead.
*
* Return: zero on success, -ve otherwise.
*/
@@ -4735,25 +4738,7 @@ int follow_pte(struct mm_struct *mm, unsigned long
address,
}
EXPORT_SYMBOL_GPL(follow_pte);
-/**
- * follow_pfn - look up PFN at a user virtual address
- * @vma: memory mapping
- * @address: user virtual address
- * @pfn: location to store found PFN
- *
- * Only IO mappings and raw PFN mappings are allowed. Note that callers must
- * ensure coherency with pte updates by using a &mmu_notifier to follow
updates.
- * If this is not feasible, or the access to the @pfn is only very short term,
- * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
- * the access instead. Any caller not following these requirements must use
- * unsafe_follow_pfn() instead.
- *
- * This function does not allow the caller to read the permissions
- * of the PTE. Do not use it.
- *
- * Return: zero and the pfn at @pfn on success, -ve otherwise.
- */
-int follow_pfn(struct vm_area_struct *vma, unsigned long address,
+static int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn)
{
int ret = -EINVAL;
@@ -4770,7 +4755,6 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
pte_unmap_unlock(ptep, ptl);
return 0;
}
-EXPORT_SYMBOL_GPL(follow_pfn);
/**
* unsafe_follow_pfn - look up PFN at a user virtual address
diff --git a/mm/nommu.c b/mm/nommu.c
index 1dc983f50e2c..cee29d0791b3 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -111,17 +111,7 @@ unsigned int kobjsize(const void *objp)
return page_size(page);
}
-/**
- * follow_pfn - look up PFN at a user virtual address
- * @vma: memory mapping
- * @address: user virtual address
- * @pfn: location to store found PFN
- *
- * Only IO mappings and raw PFN mappings are allowed.
- *
- * Returns zero and the pfn at @pfn on success, -ve otherwise.
- */
-int follow_pfn(struct vm_area_struct *vma, unsigned long address,
+static int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn)
{
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
@@ -130,7 +120,6 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
*pfn = address >> PAGE_SHIFT;
return 0;
}
-EXPORT_SYMBOL_GPL(follow_pfn);
/**
* unsafe_follow_pfn - look up PFN at a user virtual
Re: [PATCH 2/3] media/videobuf1|2: Mark follow_pfn usage as unsafe
On Tue, Mar 16, 2021 at 4:46 PM Christoph Hellwig wrote:
>
> On Tue, Mar 16, 2021 at 04:33:02PM +0100, Daniel Vetter wrote:
> > The media model assumes that buffers are all preallocated, so that
> > when a media pipeline is running we never miss a deadline because the
> > buffers aren't allocated or available.
> >
> > This means we cannot fix the v4l follow_pfn usage through
> > mmu_notifier, without breaking how this all works. The only real fix
> > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> > tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >
> > userptr for normal memory will keep working as-is, this only affects
> > the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> > videobuf2-dma-sg: Support io userptr operations on io memory").
>
> Maybe I'm missing something, but wasn't the conclusion last time that
> this hackish early device to device copy support can just go away?
My understanding is mostly, but with some objections. And I kinda
don't want to let this die in a bikeshed and then not getting rid of
follow_pfn as a result. There's enough people who acked this, and the
full removal got some nack from Mauro iirc.
Maybe if no bug report ever shows up for 1-2 years we can sunset it
for real&completely.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Default request/fence expiry + watchdog
From: Tvrtko Ursulin "Watchdog" aka "restoring hangcheck" aka default request/fence expiry - second post of a somewhat controversial feature, now upgraded to patch status. I quote the "watchdog" becuase in classical sense watchdog would allow userspace to ping it and so remain alive. I quote "restoring hangcheck" because this series, contrary to the old hangcheck, is not looking at whether the workload is making any progress from the kernel side either. (Although disclaimer my memory may be leaky - Daniel suspects old hangcheck had some stricter, more indiscriminatory, angles to it. But apart from being prone to both false negatives and false positives I can't remember that myself.) Short version - ask is to fail any user submissions after a set time period. In this RFC that time is twelve seconds. Time counts from the moment user submission is "runnable" (implicit and explicit dependencies have been cleared) and keeps counting regardless of the GPU contetion caused by other users of the system. So semantics are really a bit weak, but again, I understand this is really really wanted by the DRM core even if I am not convinced it is a good idea. There are two dangers with doing this, text borrowed from a patch in the series: This can have an effect that workloads which used to work fine will suddenly start failing. Another interaction is with hangcheck where care needs to be taken timeout is not set lower or close to three times the heartbeat interval. Otherwise a hang in any application can cause complete termination of all submissions from unrelated clients. Any users modifying the per engine heartbeat intervals therefore need to be aware of this potential denial of service to avoid inadvertently enabling it. v2: * Dropped context param. * Improved commit messages and Kconfig text. Test-with: 20210316161840.1993818-1-tvrtko.ursu...@linux.intel.com Cc: Daniel Vetter Chris Wilson (1): drm/i915: Individual request cancellation Tvrtko Ursulin (5): drm/i915: Restrict sentinel requests further drm/i915: Handle async cancellation in sentinel assert drm/i915: Request watchdog infrastructure drm/i915: Fail too long user submissions by default drm/i915: Allow configuring default request expiry via modparam drivers/gpu/drm/i915/Kconfig.profile | 14 ++ drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 .../gpu/drm/i915/gem/i915_gem_context_types.h | 4 + drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 4 + .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 + .../drm/i915/gt/intel_execlists_submission.c | 16 +- .../drm/i915/gt/intel_execlists_submission.h | 2 + drivers/gpu/drm/i915/gt/intel_gt.c| 3 + drivers/gpu/drm/i915/gt/intel_gt.h| 2 + drivers/gpu/drm/i915/gt/intel_gt_requests.c | 21 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 + drivers/gpu/drm/i915/i915_params.c| 5 + drivers/gpu/drm/i915/i915_params.h| 1 + drivers/gpu/drm/i915/i915_request.c | 108 +- drivers/gpu/drm/i915/i915_request.h | 12 +- drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++ 17 files changed, 442 insertions(+), 9 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/i915: Restrict sentinel requests further
From: Tvrtko Ursulin Disallow sentinel requests follow previous sentinels to make request cancellation work better when faced with a chain of requests which have all been marked as in error. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4c2acb5a6c0a..4b870eca9693 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev, if (__i915_request_is_complete(next)) return true; - if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & + if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) & (BIT(I915_FENCE_FLAG_NOPREEMPT) | BIT(I915_FENCE_FLAG_SENTINEL return false; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/i915: Individual request cancellation
From: Chris Wilson
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully considering no timeline lock and RCU.
* Fixed selftests.
v3 (Tvrtko):
* Remove error propagation to waiters for now.
Signed-off-by: Chris Wilson
Signed-off-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 9 +-
drivers/gpu/drm/i915/i915_request.c | 52 -
drivers/gpu/drm/i915/i915_request.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
5 files changed, 261 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..e2fb3ae2aaf3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
mutex_unlock(&ce->timeline->mutex);
}
+ intel_engine_flush_scheduler(engine);
intel_engine_pm_put(engine);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 85ff5fe861b4..4c2acb5a6c0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
ce->lrc.lrca = lrc_update_regs(ce, engine, head);
}
+static bool bad_request(const struct i915_request *rq)
+{
+ return rq->fence.error && i915_request_started(rq);
+}
+
static struct intel_engine_cs *
__execlists_schedule_in(struct i915_request *rq)
{
@@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
!intel_engine_has_heartbeat(engine)))
intel_context_set_banned(ce);
- if (unlikely(intel_context_is_banned(ce)))
+ if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
reset_active(rq, engine);
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct
intel_engine_cs *engine,
return 0;
/* Force a fast reset for terminated contexts (ignoring sysfs!) */
- if (unlikely(intel_context_is_banned(rq->context)))
+ if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
return 1;
return READ_ONCE(engine->props.preempt_timeout_ms);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a6..b4511ac05e9a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -33,7 +33,10 @@
#include "gem/i915_gem_context.h"
#include "gt/intel_breadcrumbs.h"
#include "gt/intel_context.h"
+#include "gt/intel_engine.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_gpu_commands.h"
+#include "gt/intel_reset.h"
#include "gt/intel_ring.h"
#include "gt/intel_rps.h"
@@ -429,20 +432,22 @@ void __i915_request_skip(struct i915_request *rq)
rq->infix = rq->postfix;
}
-void i915_request_set_error_once(struct i915_request *rq, int error)
+bool i915_request_set_error_once(struct i915_request *rq, int error)
{
int old;
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
if (i915_request_signaled(rq))
- return;
+ return false;
old = READ_ONCE(rq->fence.error);
do {
if (fatal_error(old))
- return;
+ return false;
} while (!try_cmpxchg(&rq->fence.error, &old, error));
+
+ return true;
}
struct i915_request *i915_request_mark_eio(struct i915_request *rq)
@@ -609,6 +614,47 @@ void i915_request_unsubmit(struct i915_request *request)
spin_unlock_irqrestore(&se->lock, flags);
}
+static struct intel_engine_cs *active_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(&locked->sched.lock);
+ while (unlikely(locked != (engine = READ_ONCE(rq->engine {
+ spin_unlock(&locked->sched.lock);
+ locked = engine;
+ spin_lock(&locked->sched.lock);
+ }
+
+ engine = NULL;
+ if (i915_request_is_active(rq) && !__i915_request_is_complete(rq))
+ engine = locked;
+
+ spin_unlock_irq(&locked->sched.lock);
+
+ return engine;
+}
+
+static void __cancel_request(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = active_engine(rq);
+
+ if (engine && intel_engine_pulse(engine))
+ intel_gt_handle_error(engine->gt, engine->mask, 0,
[PATCH 3/6] drm/i915: Handle async cancellation in sentinel assert
From: Tvrtko Ursulin
With the watchdog cancelling requests asynchronously to preempt-to-busy we
need to relax one assert making it apply only to requests not in error.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 4b870eca9693..a886f0c9b288 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -752,8 +752,11 @@ assert_pending_valid(const struct intel_engine_execlists
*execlists,
* Sentinels are supposed to be the last request so they flush
* the current execution off the HW. Check that they are the
only
* request in the pending submission.
+*
+* Due async nature of preempt-to-busy and request cancellation
+* we need to skip this assert for cancelled requests.
*/
- if (sentinel) {
+ if (sentinel && !rq->fence.error) {
GEM_TRACE_ERR("%s: context:%llx after sentinel in
pending[%zd]\n",
engine->name,
ce->timeline->fence_context,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/i915: Request watchdog infrastructure
From: Tvrtko Ursulin
Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activeted due yet missing ability to actually
configure the timer.
Outline of the basic operation:
A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.
If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.
Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().
Associated timeout value is stored in rq->context.watchdog.timeout_us.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 ++
.../drm/i915/gt/intel_execlists_submission.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 21 +++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +++
drivers/gpu/drm/i915/i915_request.c | 56 +++
drivers/gpu/drm/i915/i915_request.h | 8 +++
8 files changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0ea18c9e2aca..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,10 @@ struct intel_context {
#define CONTEXT_FORCE_SINGLE_SUBMISSION7
#define CONTEXT_NOPREEMPT 8
+ struct {
+ u64 timeout_us;
+ } watchdog;
+
u32 *lrc_reg_state;
union {
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index f7bd3fccfee8..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -6,6 +6,7 @@
#ifndef __INTEL_EXECLISTS_SUBMISSION_H__
#define __INTEL_EXECLISTS_SUBMISSION_H__
+#include
#include
struct drm_printer;
@@ -13,6 +14,7 @@ struct drm_printer;
struct i915_request;
struct intel_context;
struct intel_engine_cs;
+struct intel_gt;
enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..8d77dcbad059 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
+ init_llist_head(>->watchdog.list);
+ INIT_WORK(>->watchdog.work, intel_gt_watchdog_work);
+
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index a17bd8b3195f..7ec395cace69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -78,4 +78,6 @@ static inline bool intel_gt_is_wedged(const struct intel_gt
*gt)
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
+void intel_gt_watchdog_work(struct work_struct *work);
+
#endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 36ec97f79174..df12fc7f0aa7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -8,6 +8,7 @@
#include "i915_drv.h" /* for_each_engine() */
#include "i915_request.h"
#include "intel_engine_heartbeat.h"
+#include "intel_execlists_submission.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -242,4 +243,24 @@ void intel_gt_fini_requests(struct intel_gt *gt)
{
/* Wait until the work is marked as finished before unloading! */
cancel_delayed_work_sync(>->requests.retire_work);
+
+ flush_work(>->watchdog.work);
+}
+
+void intel_gt_watchdog_work(struct work_struct *work)
+{
+ struct intel_gt *gt =
+ container_of(work, typeof(*gt), watchdog.work);
+ struct i915_request *rq, *rn;
+ struct llist_node *first;
+
+ first = llist_del_all(>->watchdog.list);
+ if (!first)
+ return;
+
+ llist_for_each_entry_safe(rq, rn, first, watchdog.link) {
+ if (!i915_request_completed(rq))
+ i915_request_cancel(rq, -EINTR);
+ i915_request_put(rq);
+ }
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 626a
[PATCH 5/6] drm/i915: Fail too long user submissions by default
From: Tvrtko Ursulin
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 12s, and this timeout is applied to all users contexts using the
previously added watchdog facility.
Result of this is that any user submission will simply fail after this
timeout, either causing a reset (for non-preemptable), or incomplete
results.
This can have an effect that workloads which used to work fine will
suddenly start failing.
Another interaction is with hangcheck where care needs to be taken timeout
is not set lower or close to three times the heartbeat interval. Otherwise
a hang in any application can cause complete termination of all
submissions from unrelated clients. Any users modifying the per engine
heartbeat intervals therefore need to be aware of this potential denial of
service to avoid inadvertently enabling it.
v2:
* Improved commit message and Kconfig text.
* Pull in some helper code from patch which got dropped.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig.profile | 14 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +-
4 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 35bbe2b80596..d856ed33ca5d 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,17 @@
+config DRM_I915_REQUEST_TIMEOUT
+ int "Default timeout for requests (ms)"
+ default 12000 # milliseconds
+ help
+ Configures the default timeout after which any user submissions will
+ be forcefully terminated.
+
+ Beware setting this value lower, or close to heartbeat interval
+ rounded to whole seconds times three, in order to avoid allowing
+ misbehaving applications causing total rendering failure in unrelated
+ clients.
+
+ May be 0 to disable the timeout.
+
config DRM_I915_FENCE_TIMEOUT
int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"
default 1 # milliseconds
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e7..be71be21800b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -233,6 +233,8 @@ static void intel_context_set_gem(struct intel_context *ce,
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
+
+ intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
}
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -852,6 +854,40 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
}
+static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
+{
+ return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
+}
+
+static int
+__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
+{
+ int ret;
+
+ ret = context_apply_all(ctx, __apply_watchdog,
+ (void *)(uintptr_t)timeout_us);
+ if (!ret)
+ ctx->watchdog.timeout_us = timeout_us;
+
+ return ret;
+}
+
+static void __set_default_fence_expiry(struct i915_gem_context *ctx)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ int ret;
+
+ if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
+ return;
+
+ /* Default expiry for user fences. */
+ ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
+ if (ret)
+ drm_notice(&i915->drm,
+ "Failed to configure default fence expiry! (%d)",
+ ret);
+}
+
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
@@ -896,6 +932,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
intel_timeline_put(timeline);
}
+ __set_default_fence_expiry(ctx);
+
trace_i915_context_create(ctx);
return ctx;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index d5bc75508048..f17da7e26c43 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -150,6 +150,10 @@ struct i915_gem_context {
*/
atomic_t active_count;
+ struct {
+ u64 timeout_us;
+ } watchdog;
+
/**
* @hang_timestamp: The last time(s) this context caused a GPU hang
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_context_param.h
b/drivers/gpu
[PATCH 6/6] drm/i915: Allow configuring default request expiry via modparam
From: Tvrtko Ursulin Module parameter is added (request_timeout_ms) to allow configuring the default request/fence expiry. Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Acked-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++-- drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/drm/i915/i915_params.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index be71be21800b..cf5b706a39b8 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -877,11 +877,12 @@ static void __set_default_fence_expiry(struct i915_gem_context *ctx) struct drm_i915_private *i915 = ctx->i915; int ret; - if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT)) + if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) || + !i915->params.request_timeout_ms) return; /* Default expiry for user fences. */ - ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000); + ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000); if (ret) drm_notice(&i915->drm, "Failed to configure default fence expiry! (%d)", diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 6939634e56ed..0320878d96b0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -197,6 +197,11 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400, "Fake LMEM start offset (default: 0)"); #endif +#if CONFIG_DRM_I915_REQUEST_TIMEOUT +i915_param_named_unsafe(request_timeout_ms, uint, 0600, + "Default request/fence/batch buffer expiration timeout."); +#endif + static __always_inline void _print_param(struct drm_printer *p, const char *name, const char *type, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 48f47e44e848..34ebb0662547 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -72,6 +72,7 @@ struct drm_printer; param(int, enable_dpcd_backlight, -1, 0600) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \ param(unsigned long, fake_lmem_start, 0, 0400) \ + param(unsigned int, request_timeout_ms, CONFIG_DRM_I915_REQUEST_TIMEOUT, 0600) \ /* leave bools at the end to not create holes */ \ param(bool, enable_hangcheck, true, 0600) \ param(bool, load_detect_test, false, 0600) \ -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave & Daniel - drm-intel-next-2021-03-16: Highlights: - Alderlake S enabling, via topic branch (Aditya, Anusha, Caz, José, Lucas, Matt, Tejas) - Refactor display code to shrink intel_display.c etc. (Dave) - Support more gen 9 and Tigerlake PCH combinations (Lyude, Tejas) - Add eDP MSO support (Jani) Display: - Refactor to support multiple PSR instances (Gwan-gyeong) - Link training debug logging updates (Sean) - Updates to eDP fixed mode handling (Jani) - Disable PSR2 on JSL/EHL (Edmund) - Support DDR5 and LPDDR5 for bandwidth computation (Clint, José) - Update VBT DP max link rate table (Shawn) - Disable the QSES check for HDCP2.2 over MST (Juston) - PSR updates, refactoring, selective fetch (José, Gwan-gyeong) - Display init sequence refactoring (Lucas) - Limit LSPCON to gen 9 and 10 platforms (Ankit) - Fix DDI lane polarity per VBT info (Uma) - Fix HDMI vswing programming location in mode set (Ville) - Various display improvements and refactorings and cleanups (Ville) - Clean up DDI clock routing and readout (Ville) - Workaround async flip + VT-d corruption on HSW/BDW (Ville) - SAGV watermark fixes and cleanups (Ville) - Silence pipe tracepoint WARNs (Ville) Other: - Remove require_force_probe protection from RKL, may need to be revisited (Tejas) - Detect loss of MMIO access (Matt) - GVT display improvements - drm/i915: Disable runtime power management during shutdown (Imre) - Perf/OA updates (Umesh) - Remove references to struct drm_device.pdev, via topic branch (Thomas) - Backmerge (Jani) BR, Jani. The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-03-16 for you to fetch changes up to 2b25fb31a38d4fe8e745754036052ef8b16fe712: Merge tag 'gvt-next-2021-03-16' of https://github.com/intel/gvt-linux into drm-intel-next (2021-03-16 13:42:33 +0200) Highlights: - Alderlake S enabling, via topic branch (Aditya, Anusha, Caz, José, Lucas, Matt, Tejas) - Refactor display code to shrink intel_display.c etc. (Dave) - Support more gen 9 and Tigerlake PCH combinations (Lyude, Tejas) - Add eDP MSO support (Jani) Display: - Refactor to support multiple PSR instances (Gwan-gyeong) - Link training debug logging updates (Sean) - Updates to eDP fixed mode handling (Jani) - Disable PSR2 on JSL/EHL (Edmund) - Support DDR5 and LPDDR5 for bandwidth computation (Clint, José) - Update VBT DP max link rate table (Shawn) - Disable the QSES check for HDCP2.2 over MST (Juston) - PSR updates, refactoring, selective fetch (José, Gwan-gyeong) - Display init sequence refactoring (Lucas) - Limit LSPCON to gen 9 and 10 platforms (Ankit) - Fix DDI lane polarity per VBT info (Uma) - Fix HDMI vswing programming location in mode set (Ville) - Various display improvements and refactorings and cleanups (Ville) - Clean up DDI clock routing and readout (Ville) - Workaround async flip + VT-d corruption on HSW/BDW (Ville) - SAGV watermark fixes and cleanups (Ville) - Silence pipe tracepoint WARNs (Ville) Other: - Remove require_force_probe protection from RKL, may need to be revisited (Tejas) - Detect loss of MMIO access (Matt) - GVT display improvements - drm/i915: Disable runtime power management during shutdown (Imre) - Perf/OA updates (Umesh) - Remove references to struct drm_device.pdev, via topic branch (Thomas) - Backmerge (Jani) Aditya Swarup (8): drm/i915/tgl: Use TGL stepping info for applying WAs drm/i915/adl_s: Configure DPLL for ADL-S drm/i915/adl_s: Configure Port clock registers for ADL-S drm/i915/adl_s: Initialize display for ADL-S drm/i915/adl_s: Add adl-s ddc pin mapping drm/i915/adl_s: Add vbt port and aux channel settings for adls drm/i915/adl_s: Add display WAs for ADL-S drm/i915/adl_s: Add GT and CTX WAs for ADL-S Ankit Nautiyal (1): drm/i915: Fix HAS_LSPCON macro for platforms between GEN9 and GEN10 Anshuman Gupta (1): drm/i915/debugfs: HDCP capability enc NULL check Anusha Srivatsa (4): drm/i915/adl_s: Add PCH support drm/i915/adl_s: Add Interrupt Support drm/i915/adl_s: Add PHYs for Alderlake S drm/i915/adl_s: Load DMC Bhaskar Chowdhury (1): drm/i915/gvt: Fixed couple of spellings in the file gtt.c Caz Yokoyama (2): drm/i915/adl_s: Add ADL-S platform info and PCI ids x86/gpu: Add Alderlake-S stolen memory support Clint Taylor (1): drm/i915/display: support ddr5 mem types Colin Ian King (1): drm/i915/display: fix spelling mistake "Couldnt" -> "Couldn't" Colin Xu (2): drm/i915/gvt: Get accurate vGPU virtual display refresh rate from vreg drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual display Dave Airlie (9): drm/i915: refactor ddi translations
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Wed, Feb 3, 2021 at 2:14 PM Rob Clark wrote: > > On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote: > > > > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: > > > On 2021-02-01 23:50, Jordan Crouse wrote: > > > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > > > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > > > > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan > > > > > > > > wrote: > > > > > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > > > > > > > > > On reflection, I'm a bit worried about exposing this because I > > > > > > > > think it > > > > > > > > will > > > > > > > > introduce a mismatched virtual alias with the CPU (we don't > > > > > > > > even have a > > > > > > > > MAIR > > > > > > > > set up for this memory type). Now, we also have that issue for > > > > > > > > the PTW, > > > > > > > > but > > > > > > > > since we always use cache maintenance (i.e. the streaming API) > > > > > > > > for > > > > > > > > publishing the page-tables to a non-coheren walker, it works > > > > > > > > out. > > > > > > > > However, > > > > > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API > > > > > > > > coherent > > > > > > > > allocation, then they're potentially in for a nasty surprise > > > > > > > > due to the > > > > > > > > mismatched outer-cacheability attributes. > > > > > > > > > > > > > > > > > > > > > > Can't we add the syscached memory type similar to what is done on > > > > > > > android? > > > > > > > > > > > > Maybe. How does the GPU driver map these things on the CPU side? > > > > > > > > > > Currently we use writecombine mappings for everything, although there > > > > > are some cases that we'd like to use cached (but have not merged > > > > > patches that would give userspace a way to flush/invalidate) > > > > > > > > > > > > > LLC/system cache doesn't have a relationship with the CPU cache. Its > > > > just a > > > > little accelerator that sits on the connection from the GPU to DDR and > > > > caches > > > > accesses. The hint that Sai is suggesting is used to mark the buffers as > > > > 'no-write-allocate' to prevent GPU write operations from being cached in > > > > the LLC > > > > which a) isn't interesting and b) takes up cache space for read > > > > operations. > > > > > > > > Its easiest to think of the LLC as a bonus accelerator that has no cost > > > > for > > > > us to use outside of the unfortunate per buffer hint. > > > > > > > > We do have to worry about the CPU cache w.r.t I/O coherency (which is a > > > > different hint) and in that case we have all of concerns that Will > > > > identified. > > > > > > > > > > For mismatched outer cacheability attributes which Will mentioned, I was > > > referring to [1] in android kernel. > > > > I've lost track of the conversation here :/ > > > > When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped > > into the CPU and with what attributes? Rob said "writecombine for > > everything" -- does that mean ioremap_wc() / MEMREMAP_WC? > > Currently userspace asks for everything WC, so pgprot_writecombine() > > The kernel doesn't enforce this, but so far provides no UAPI to do > anything useful with non-coherent cached mappings (although there is > interest to support this) > btw, I'm looking at a benchmark (gl_driver2_off) where (after some other in-flight optimizations land) we end up bottlenecked on writing to WC cmdstream buffers. I assume in the current state, WC goes all the way to main memory rather than just to system cache? BR, -R > BR, > -R > > > Finally, we need to be careful when we use the word "hint" as "allocation > > hint" has a specific meaning in the architecture, and if we only mismatch on > > those then we're actually ok. But I think IOMMU_LLC is more than just a > > hint, since it actually drives eviction policy (i.e. it enables writeback). > > > > Sorry for the pedantry, but I just want to make sure we're all talking > > about the same things! > > > > Cheers, > > > > Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Tue, Mar 16, 2021 at 10:04 AM Rob Clark wrote: > > On Wed, Feb 3, 2021 at 2:14 PM Rob Clark wrote: > > > > On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote: > > > > > > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: > > > > On 2021-02-01 23:50, Jordan Crouse wrote: > > > > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > > > > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > > > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan > > > > > > > wrote: > > > > > > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > > > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan > > > > > > > > > wrote: > > > > > > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > > > > > > > > > > > On reflection, I'm a bit worried about exposing this because > > > > > > > > > I think it > > > > > > > > > will > > > > > > > > > introduce a mismatched virtual alias with the CPU (we don't > > > > > > > > > even have a > > > > > > > > > MAIR > > > > > > > > > set up for this memory type). Now, we also have that issue > > > > > > > > > for the PTW, > > > > > > > > > but > > > > > > > > > since we always use cache maintenance (i.e. the streaming > > > > > > > > > API) for > > > > > > > > > publishing the page-tables to a non-coheren walker, it works > > > > > > > > > out. > > > > > > > > > However, > > > > > > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API > > > > > > > > > coherent > > > > > > > > > allocation, then they're potentially in for a nasty surprise > > > > > > > > > due to the > > > > > > > > > mismatched outer-cacheability attributes. > > > > > > > > > > > > > > > > > > > > > > > > > Can't we add the syscached memory type similar to what is done > > > > > > > > on android? > > > > > > > > > > > > > > Maybe. How does the GPU driver map these things on the CPU side? > > > > > > > > > > > > Currently we use writecombine mappings for everything, although > > > > > > there > > > > > > are some cases that we'd like to use cached (but have not merged > > > > > > patches that would give userspace a way to flush/invalidate) > > > > > > > > > > > > > > > > LLC/system cache doesn't have a relationship with the CPU cache. Its > > > > > just a > > > > > little accelerator that sits on the connection from the GPU to DDR and > > > > > caches > > > > > accesses. The hint that Sai is suggesting is used to mark the buffers > > > > > as > > > > > 'no-write-allocate' to prevent GPU write operations from being cached > > > > > in > > > > > the LLC > > > > > which a) isn't interesting and b) takes up cache space for read > > > > > operations. > > > > > > > > > > Its easiest to think of the LLC as a bonus accelerator that has no > > > > > cost > > > > > for > > > > > us to use outside of the unfortunate per buffer hint. > > > > > > > > > > We do have to worry about the CPU cache w.r.t I/O coherency (which is > > > > > a > > > > > different hint) and in that case we have all of concerns that Will > > > > > identified. > > > > > > > > > > > > > For mismatched outer cacheability attributes which Will mentioned, I was > > > > referring to [1] in android kernel. > > > > > > I've lost track of the conversation here :/ > > > > > > When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped > > > into the CPU and with what attributes? Rob said "writecombine for > > > everything" -- does that mean ioremap_wc() / MEMREMAP_WC? > > > > Currently userspace asks for everything WC, so pgprot_writecombine() > > > > The kernel doesn't enforce this, but so far provides no UAPI to do > > anything useful with non-coherent cached mappings (although there is > > interest to support this) > > > > btw, I'm looking at a benchmark (gl_driver2_off) where (after some > other in-flight optimizations land) we end up bottlenecked on writing > to WC cmdstream buffers. I assume in the current state, WC goes all > the way to main memory rather than just to system cache? > oh, I guess this (mentioned earlier in thread) is what I really want for this benchmark: https://android-review.googlesource.com/c/kernel/common/+/1549097/3 > BR, > -R > > > BR, > > -R > > > > > Finally, we need to be careful when we use the word "hint" as "allocation > > > hint" has a specific meaning in the architecture, and if we only mismatch > > > on > > > those then we're actually ok. But I think IOMMU_LLC is more than just a > > > hint, since it actually drives eviction policy (i.e. it enables > > > writeback). > > > > > > Sorry for the pedantry, but I just want to make sure we're all talking > > > about the same things! > > > > > > Cheers, > > > > > > Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2021 X.Org Foundation Election Candidates
Correction, we have 7 candidates for 4 positions. I seem to have overlooked Walter Harms's nomination email. My sincerest apologies. His personal affiliation, statement of contribution, and personal statement are below. The full slate of candidates can be found at https://wiki.freedesktop.org/xorg/BoardOfDirectors/Elections/2021/ ## Walter Harms __Current Affiliation:__ Scientist @ Bundesamt für Strahlenschutz __Statement of Contribution:__ I am involved into the open source since studying physics several years ago. I am also certified trainer for programmers. I contributed in the last years to projects like linux kernel, man pages, etc. Since a few years i have commit rights for X11 and did some work on libX11 and libXt. __Personal Statement:__ Since i started to become a trainer i have a predilection for documentation. Xorg has a lot good documentation but today is it less. NTL what is important is the application. I would like to see more training material and more X11 applications especially for remote access. But i was never involved in the xorg organisation. So i see myself more as an apprentice. We will see if i can help. Thanks, Harry Wentland, on behalf of the X.Org elections committee On 2021-03-15 2:47 p.m., Harry Wentland wrote: To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 22 March 2021. We have 6 candidates who are running for 4 seats. They are (in alphabetical order): Samuel Iglesias Gonsálvez Manasi Navare Lyude Paul Rodrigo Siqueira Lucas Stach Daniel Vetter Attached below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ** Nominees ** ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have been contributing to Mesa and piglit for 7 years improving open-source drivers for both OpenGL and Vulkan. During my time on the board, I have become the XDC organization coordinator and the XDC CFP committee chair, due to my experience organizing the XDC 2018 in A Coruña, Spain. Thanks to these experiences, I have been deeply involved in the XDC organization process, where I have helped make a great and welcoming conference every year. If I am elected, I plan to continue leading both the XDC organization process and the XDC CFP committee. ## Manasi Navare __Current Affiliation:__ Intel __Statement of contribution:__ I am a lead contributor to Intel’s Open source graphics kernel driver i915 as well as to the Linux Kernel DRM subsystem. One of my most widely used contributions is the Display Port Compliance code in i915, DRM as well as in Xserver and IGT to make the entire graphics stack Display Port compliant and reward the end users with black screen free displays. I have also enabled features like Display stream compression across DRM and i915 as per VESA’s DSC specification for Display Port. Most recently I have been working with both the DRM and i915 community as well as the AMD developers to implement and enable adaptive sync feature for variable refresh rate on display drivers for enhanced gaming experience. I also have commit rights to several upstream projects like drm-intel, drm-misc and Intel GPU Tools. I have served on X.org board of directors for last 2 years organizing XDC conferences, being on Code of Conduct committee for X.org and Freedesktop and taking over the treasurer responsibility since September 2020. __Personal Statement:__ I have been a Linux Open Source contributor for last 7 years since I joined Intel's Open source technology center. My major contributions are in enabling display interfaces and develop display features in upcoming display specifications in i915 and Linux DRM subsystem. I have presented several talks at Linux Graphics conferences like Embedded Linux Conference, XDC and FOSDEM on several graphics display features like Display Port compliance and Display Stream Compression, Tiled display support, Adaptive Sync or Va
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On 3/16/21 3:07 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 12:24 PM Thomas Hellström (Intel)
wrote:
On 3/16/21 12:06 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h
b/include/drm/ttm/ttm_bo_api.h
index 4fb523dfab32..df9fe596e7c5 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -603,9 +603,11 @@ static inline void
ttm_bo_pin(struct ttm_buffer_object *bo)
static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
-WARN_ON_ONCE(!bo->pin_count);
WARN_ON_ONCE(!kref_read(&bo->kref));
---bo->pin_count;
+if (bo->pin_count)
+--bo->pin_count;
+else
+WARN_ON_ONCE(true);
}
int ttm_mem_evict_first(struct ttm_device *bdev,
Since I now have been staring for half a year at the code of
the driver that made pinning an art, I have a couple of
suggestions here, Could we use an atomic for pin_count,
allowing unlocked unpinning but require the lock only for
pin_count transition 0->1, (but unlocked for
pin_if_already_pinned). In particular I think vmwgfx would
benefit from unlocked unpins. Also if the atomic were a
refcount_t, that would probably give you the above
behaviour?
Nope, I've considered this as well while moving the pin count into TTM.
The problem is that you not only need the BO reserved for 0->1
transitions, but also for 1->0 transitions to move the BO on the
LRU correctly.
Ah, and there is no way to have us know the correct LRU list without
reservation?
Not really, there is always the chance that CPU A is reducing the count
from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
which doesn't match the pin count.
We could try to do something like a loop updating the LRU status until
it matches the pin count, but the implications of that are usually
really nasty.
OK, yeah I was more thinking along the lines of protecting the LRU status
with the global lru lock and unpin would then be
if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
add_to_relevant_lrus(bo, bo->lru_status);
spin_unlock(&ttm_glob.lru_lock);
}
But looking at ttm_bo_move_to_lru_tail() I realize that's not really trivial
anymore. I hope it's doable at some point though.
But meanwhile, perhaps TTM needs to accept and pave over that drivers are in
fact destroying pinned buffers?
Do we have more trouble than the very fancy tricks vmwgfx does? If so I
think we could do a small helper that like ttm_dont_check_unpin() to shut
it up. Since vmwgfx drivers tend to not be loaded with any other drivers
that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
out what to do - maybe you do need your own in-house pin/unpin for these
special bo?
I did try to parse your reply in the other thread, and tbh I didn't grock
it.
Not sure if you mean the description was unclear or if you thought it was a
bad idea, but in case the former, what I mean is
My unclarity is on what you explained in the vmwgfx thread about how
vmwgfx uses its pin/unpin and why. That was full of vmwgfx concepts I
don't know about. This here looks reasonably clear to me, but it does have
the race Christian sees I think.
Hmm, OK, I thought transition 0->1 under the LRU lock would have
resolved that...
Hm now you make me question how this all works again, and when it
stops working. I do think yours works, but it triggers another icky
thing I have with refcounts and locking. And at this point pin_count
is more a refcount really ...
So imo the way to do a weak refcount is kref_get_unless_zero, because
that way you do not have to hold the lock on the final unref, but
instead you can remove all weakly referenced entries (lookup caches,
lru, whatever) simply in your cleanup code (and there still grab the
right lock ofc), and the refcount_dec isn't special.
The other approach is the refcount_dec_and_lock, and this works, but
only for a single lock. So as soon as you have multiple weak
references, or possible weak references, then it falls apart, because
you can't take all the locks for all of them for the final decrement.
Now ofc our pin_count here isn't a weak reference, but I think it's
easier to analyze with that concept in mind. But conclusion is the
same, as soon as we need multiple lru locks for the final unpin, we'r
[Bug 212293] [amdgpu] divide error: 0000 on resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212293 --- Comment #3 from Sefa Eyeoglu (cont...@scrumplex.net) --- This took some time, as I apparently went wrong paths sometimes. Anyways. I bisected between tags v5.10 (good) and v5.11 (bad), while only looking at path "drivers/gpu/drm/amd". At the end I landed at commit 12f4849a1cfd69f3c37cca042f2e9c512f923741 by Simon Ser (emersion). I will do some debugging myself to see if it's the real deal, but that change might very well be it. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212293] [amdgpu] divide error: 0000 on resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212293 --- Comment #4 from Sefa Eyeoglu (cont...@scrumplex.net) --- Created attachment 295887 --> https://bugzilla.kernel.org/attachment.cgi?id=295887&action=edit git bisect log -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212293] [amdgpu] divide error: 0000 on resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212293 --- Comment #5 from Sefa Eyeoglu (cont...@scrumplex.net) --- I was unable to add Simon Ser to CC -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On Tue, Mar 16, 2021 at 7:18 PM Thomas Hellström (Intel)
wrote:
>
>
> On 3/16/21 3:07 PM, Daniel Vetter wrote:
> > On Tue, Mar 16, 2021 at 12:24 PM Thomas Hellström (Intel)
> > wrote:
> >>
> >> On 3/16/21 12:06 PM, Daniel Vetter wrote:
> >>> On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
> Hi,
>
> On 3/16/21 10:27 AM, Daniel Vetter wrote:
> > On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel)
> > wrote:
> >> On 3/15/21 7:47 PM, Christian König wrote:
> >>> Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
> On 3/15/21 11:26 AM, Christian König wrote:
> > Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
> >> Hi, Christian
> >>
> >> On 3/12/21 10:38 AM, Christian König wrote:
> >>> We seem to have some more driver bugs than thought.
> >>>
> >>> Signed-off-by: Christian König
> >>> ---
> >>> include/drm/ttm/ttm_bo_api.h | 6 --
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/include/drm/ttm/ttm_bo_api.h
> >>> b/include/drm/ttm/ttm_bo_api.h
> >>> index 4fb523dfab32..df9fe596e7c5 100644
> >>> --- a/include/drm/ttm/ttm_bo_api.h
> >>> +++ b/include/drm/ttm/ttm_bo_api.h
> >>> @@ -603,9 +603,11 @@ static inline void
> >>> ttm_bo_pin(struct ttm_buffer_object *bo)
> >>> static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
> >>> {
> >>> dma_resv_assert_held(bo->base.resv);
> >>> -WARN_ON_ONCE(!bo->pin_count);
> >>> WARN_ON_ONCE(!kref_read(&bo->kref));
> >>> ---bo->pin_count;
> >>> +if (bo->pin_count)
> >>> +--bo->pin_count;
> >>> +else
> >>> +WARN_ON_ONCE(true);
> >>> }
> >>>int ttm_mem_evict_first(struct ttm_device *bdev,
> >> Since I now have been staring for half a year at the code of
> >> the driver that made pinning an art, I have a couple of
> >> suggestions here, Could we use an atomic for pin_count,
> >> allowing unlocked unpinning but require the lock only for
> >> pin_count transition 0->1, (but unlocked for
> >> pin_if_already_pinned). In particular I think vmwgfx would
> >> benefit from unlocked unpins. Also if the atomic were a
> >> refcount_t, that would probably give you the above
> >> behaviour?
> > Nope, I've considered this as well while moving the pin count into
> > TTM.
> >
> > The problem is that you not only need the BO reserved for 0->1
> > transitions, but also for 1->0 transitions to move the BO on the
> > LRU correctly.
> Ah, and there is no way to have us know the correct LRU list without
> reservation?
> >>> Not really, there is always the chance that CPU A is reducing the
> >>> count
> >>> from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
> >>> which doesn't match the pin count.
> >>>
> >>> We could try to do something like a loop updating the LRU status until
> >>> it matches the pin count, but the implications of that are usually
> >>> really nasty.
> >>>
> >> OK, yeah I was more thinking along the lines of protecting the LRU
> >> status
> >> with the global lru lock and unpin would then be
> >>
> >> if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
> >>add_to_relevant_lrus(bo, bo->lru_status);
> >>spin_unlock(&ttm_glob.lru_lock);
> >> }
> >>
> >> But looking at ttm_bo_move_to_lru_tail() I realize that's not really
> >> trivial
> >> anymore. I hope it's doable at some point though.
> >>
> >> But meanwhile, perhaps TTM needs to accept and pave over that drivers
> >> are in
> >> fact destroying pinned buffers?
> > Do we have more trouble than the very fancy tricks vmwgfx does? If so I
> > think we could do a small helper that like ttm_dont_check_unpin() to
> > shut
> > it up. Since vmwgfx drivers tend to not be loaded with any other drivers
> > that shouldn't reduce any test coverage. And allows vmwgfx folks to
> > figure
> > out what to do - maybe you do need your own in-house pin/unpin for these
> > special bo?
> >
> > I did try to parse your reply in the other thread, and tbh I didn't
> > grock
> > it.
> Not sure if you mean the description was unclear or if you thought it
> was a
> bad idea, but in case the former, what I mean is
> >>> My unclarity is on what you explained in the vmwgfx thread about how
> >>> vmwgfx uses its pin/unpin and why. That was full of vmwgfx concepts I
> >>> don't know about. This here looks reasonably clear to me, but it does have
> >>> the race Chris
Re: [PATCH] drm/ttm: make ttm_bo_unpin more defensive
On 3/16/21 7:28 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 7:18 PM Thomas Hellström (Intel)
wrote:
On 3/16/21 3:07 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 12:24 PM Thomas Hellström (Intel)
wrote:
On 3/16/21 12:06 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h
b/include/drm/ttm/ttm_bo_api.h
index 4fb523dfab32..df9fe596e7c5 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -603,9 +603,11 @@ static inline void
ttm_bo_pin(struct ttm_buffer_object *bo)
static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
{
dma_resv_assert_held(bo->base.resv);
-WARN_ON_ONCE(!bo->pin_count);
WARN_ON_ONCE(!kref_read(&bo->kref));
---bo->pin_count;
+if (bo->pin_count)
+--bo->pin_count;
+else
+WARN_ON_ONCE(true);
}
int ttm_mem_evict_first(struct ttm_device *bdev,
Since I now have been staring for half a year at the code of
the driver that made pinning an art, I have a couple of
suggestions here, Could we use an atomic for pin_count,
allowing unlocked unpinning but require the lock only for
pin_count transition 0->1, (but unlocked for
pin_if_already_pinned). In particular I think vmwgfx would
benefit from unlocked unpins. Also if the atomic were a
refcount_t, that would probably give you the above
behaviour?
Nope, I've considered this as well while moving the pin count into TTM.
The problem is that you not only need the BO reserved for 0->1
transitions, but also for 1->0 transitions to move the BO on the
LRU correctly.
Ah, and there is no way to have us know the correct LRU list without
reservation?
Not really, there is always the chance that CPU A is reducing the count
from 1->0 while CPU B is doing 0->1 and you end up with a LRU status
which doesn't match the pin count.
We could try to do something like a loop updating the LRU status until
it matches the pin count, but the implications of that are usually
really nasty.
OK, yeah I was more thinking along the lines of protecting the LRU status
with the global lru lock and unpin would then be
if (refcount_dec_and_lock(&bo->pin_count, &ttm_glob.lru_lock)) {
add_to_relevant_lrus(bo, bo->lru_status);
spin_unlock(&ttm_glob.lru_lock);
}
But looking at ttm_bo_move_to_lru_tail() I realize that's not really trivial
anymore. I hope it's doable at some point though.
But meanwhile, perhaps TTM needs to accept and pave over that drivers are in
fact destroying pinned buffers?
Do we have more trouble than the very fancy tricks vmwgfx does? If so I
think we could do a small helper that like ttm_dont_check_unpin() to shut
it up. Since vmwgfx drivers tend to not be loaded with any other drivers
that shouldn't reduce any test coverage. And allows vmwgfx folks to figure
out what to do - maybe you do need your own in-house pin/unpin for these
special bo?
I did try to parse your reply in the other thread, and tbh I didn't grock
it.
Not sure if you mean the description was unclear or if you thought it was a
bad idea, but in case the former, what I mean is
My unclarity is on what you explained in the vmwgfx thread about how
vmwgfx uses its pin/unpin and why. That was full of vmwgfx concepts I
don't know about. This here looks reasonably clear to me, but it does have
the race Christian sees I think.
Hmm, OK, I thought transition 0->1 under the LRU lock would have
resolved that...
Hm now you make me question how this all works again, and when it
stops working. I do think yours works, but it triggers another icky
thing I have with refcounts and locking. And at this point pin_count
is more a refcount really ...
So imo the way to do a weak refcount is kref_get_unless_zero, because
that way you do not have to hold the lock on the final unref, but
instead you can remove all weakly referenced entries (lookup caches,
lru, whatever) simply in your cleanup code (and there still grab the
right lock ofc), and the refcount_dec isn't special.
The other approach is the refcount_dec_and_lock, and this works, but
only for a single lock. So as soon as you have multiple weak
references, or possible weak references, then it falls apart, because
you can't take all the locks for all of them for the final decrement.
Now ofc our pin_count here isn't a weak reference, but I think it's
easier to analyze
[Bug 212293] [amdgpu] divide error: 0000 on resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212293
--- Comment #6 from Sefa Eyeoglu (cont...@scrumplex.net) ---
Okay I tried to debug it by printing.
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 573cf17262da..8e6b890ad611 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9271,6 +9271,8 @@ static int dm_check_crtc_cursor(struct drm_atomic_state
*state,
return 0;
}
+ printk("SCRUMPLEX_DEBUG %d %d %d %d", new_cursor_state->src_w,
new_cursor_state->src_h, new_primary_state->src_w, new_primary_state->src_h);
+
cursor_scale_w = new_cursor_state->crtc_w * 1000 /
(new_cursor_state->src_w >> 16);
cursor_scale_h = new_cursor_state->crtc_h * 1000 /
--
2.31.0
This adds my very professional printk, which outputs all values that are used
to divide in any way later.
While reproducing the issue I got the following output
[ 89.850437] SCRUMPLEX_DEBUG 8388608 8388608 0 0
So some weird state is causing the src_w and src_h values of
"new_primary_state" to be 0.
That would explain the issue to me. Now I don't know enough about
drm_plane_state and drm_atomic_get_new_plane_state to say why this is like
this. But as with most of these kinds of issues. A simple condition check
beforehand would solve this issue.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 3/3] drm: Add GUD USB Display driver
Den 15.03.2021 20.37, skrev Peter Stuge:
> Hi Noralf,
>
> super fair call with the BE testing, let's hope for some testing soonish.
>
>
> I was thinking about my device doing protocol STALL when I try to
> return 0 bytes, and while it *is* a bug in my device, from a standards
> point of view it's actually completely valid, if not expected:
>
> --8<-- usb_20.pdf 8.5.3.4 STALL Handshakes Returned by Control Pipes
> If the device is unable to complete a command, it returns a STALL in the
> Data and/or Status stages of the control transfer. Unlike the case of a
> functional stall, protocol stall does not indicate an error with the device.
> -->8--
>
> I think it's fair to say that a device can't complete the command
> when it has no data to return.
>
> So how about allowing STALL for optional GUD_REQ_GET_:s to mean the same
> as a 0 byte response? Should I propose a separate patch for it later?
>
Yeah, that would be nice.
We can't look for -EPIPE though, since GUD_REQ_GET_STATUS will ask for
the actual error. We have these to choose from currently:
#define GUD_STATUS_OK 0x00
#define GUD_STATUS_BUSY 0x01
#define GUD_STATUS_REQUEST_NOT_SUPPORTED 0x02
#define GUD_STATUS_PROTOCOL_ERROR 0x03
#define GUD_STATUS_INVALID_PARAMETER 0x04
#define GUD_STATUS_ERROR 0x05
Maybe REQUEST_NOT_SUPPORTED (-EOPNOTSUPP) or add a more fitting status
value.
If the driver sees -EPIPE this means that the device has failed to
respond properly. See gud_usb_transfer().
>
> Noralf Trønnes wrote:
>> +++ b/drivers/gpu/drm/gud/gud_connector.c
> ..
>> +static int gud_connector_get_modes(struct drm_connector *connector)
> ..
>> +ret = gud_usb_get(gdrm, GUD_REQ_GET_CONNECTOR_EDID, connector->index,
>> + edid_ctx.buf, GUD_CONNECTOR_MAX_EDID_LEN);
>
> if (ret == -EPIPE)
> ret = 0;
>
>> +if (ret > 0 && ret % EDID_LENGTH) {
>> +gud_conn_err(connector, "Invalid EDID size", ret);
>> +} else if (ret > 0) {
>> +edid_ctx.len = ret;
>> +edid = drm_do_get_edid(connector, gud_connector_get_edid_block,
>> &edid_ctx);
>> +}
>
>
>> +static int gud_connector_add_properties(struct gud_device *gdrm, struct
>> gud_connector *gconn)
> ..
>> +ret = gud_usb_get(gdrm, GUD_REQ_GET_CONNECTOR_PROPERTIES,
>> connector->index,
>> + properties, GUD_CONNECTOR_PROPERTIES_MAX_NUM *
>> sizeof(*properties));
>
> if (ret == -EPIPE)
> ret = 0;
>
>> +if (ret <= 0)
>> +goto out;
>> +if (ret % sizeof(*properties)) {
>> +ret = -EIO;
>> +goto out;
>> +}
>
>
>> +++ b/drivers/gpu/drm/gud/gud_drv.c
> ..
> ..
>> +static int gud_get_properties(struct gud_device *gdrm)
> ..
>> +ret = gud_usb_get(gdrm, GUD_REQ_GET_PROPERTIES, 0,
>> + properties, GUD_PROPERTIES_MAX_NUM *
>> sizeof(*properties));
>
> if (ret == -EPIPE)
> ret = 0;
>
>> +if (ret <= 0)
>> +goto out;
>> +if (ret % sizeof(*properties)) {
>> +ret = -EIO;
>> +goto out;
>> +}
>
>
> Then I looked whether a device could cause trouble in the driver by
> returning complex/unexpected data, and found this:
>
>> +static int gud_probe(struct usb_interface *intf, const struct usb_device_id
>> *id)
> ..
>> +/* Add room for emulated XRGB */
>> +formats = devm_kmalloc_array(dev, GUD_FORMATS_MAX_NUM + 1,
>> sizeof(*formats), GFP_KERNEL);
>
> It looks like this +1 and the way xrgb_emulation_format works means
> that an interface will not always work correctly if multiple emulated
> formats (R1, XRGB, RGB565) are returned, because only one emulated
> mode is added after the loop, with struct drm_format_info for the last
> emulated format returned by the device. So userspace would only see the
> last emulated mode and the bulk output would only ever use that
> particular pixel format, any earlier ones would be unavailable?
>
> If this is EWONTFIX then how about adding an error message if multiple
> emulated modes are returned and ignore all but the first, rather than
> all but the last?
>
It does ignore all but the first... doesn't it?
You could make a patch if you care about this:
case GUD_DRM_FORMAT_R1:
fallthrough;
case GUD_DRM_FORMAT_XRGB:
if (!xrgb_emulation_format)
xrgb_emulation_format = info;
+ else
+ dev_err(dev, "...");
break;
It's only needed for the formats that are not exported to userspace.
>
> Related: Can userspace find out which GUD_PIXEL_FORMAT_* is behind an
> emulated format? It's needed to decide how the emulated framebuffer
> should be used, in particular to not use G or B if GUD_PIXEL_FORMAT_R1.
>
There's no way for userspace to kn
Re: [PATCH] drm: xlnx: call pm_runtime_get_sync before setting pixel clock
Hi Quanyang,
Thank you for the patch.
On Wed, Mar 10, 2021 at 12:59:45PM +0800, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang
>
> The Runtime PM subsystem will force the device "fd4a.zynqmp-display"
> to enter suspend state while booting if the following conditions are met:
> - the usage counter is zero (pm_runtime_get_sync hasn't been called yet)
> - no 'active' children (no zynqmp-dp-snd-xx node under dpsub node)
> - no other device in the same power domain (dpdma node has no
> "power-domains = <&zynqmp_firmware PD_DP>" property)
>
> So there is a scenario as below:
> 1) DP device enters suspend state <- call zynqmp_gpd_power_off
> 2) zynqmp_disp_crtc_setup_clock <- configurate register
> VPLL_FRAC_CFG
> 3) pm_runtime_get_sync<- call zynqmp_gpd_power_on and
> clear previous
> VPLL_FRAC_CFG configuration
> 4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG
> configuration is corrupted
>
> From above, we can see that pm_runtime_get_sync may clear register
> VPLL_FRAC_CFG configuration and result the failure of clk enabling.
> Putting pm_runtime_get_sync at the very beginning of the function
> zynqmp_disp_crtc_atomic_enable can resolve this issue.
Isn't this an issue in the firmware though, which shouldn't clear the
previous VPLLF_FRAC_CFG ?
> Signed-off-by: Quanyang Wang
Nonetheless, this change looks good to me, I actually had the same patch
in my tree while investigation issues related to the clock rate, so
Reviewed-by: Laurent Pinchart
Tested-by: Laurent Pinchart
I was hoping it would solve the issue I'm experiencing with the DP
clock, but that's not the case :-( In a nutshell, when the DP is first
started, the clock frequency is incorrect. The following quick & dirty
patch fixes the problem:
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 74ac0a064eb5..fdbe1b0640aa 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1439,6 +1439,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc,
pm_runtime_get_sync(disp->dev);
+ ret = clk_prepare_enable(disp->pclk);
+ if (!ret)
+ clk_disable_unprepare(disp->pclk);
+
zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode);
ret = clk_prepare_enable(disp->pclk);
The problem doesn't seem to be in the kernel, but on the TF-A or PMU
firmware side. Have you experienced this by any chance ?
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 148add0ca1d6..909e6c265406 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -1445,9 +1445,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_display_mode *adjusted_mode = &crtc->state->adjusted_mode;
> int ret, vrefresh;
>
> + pm_runtime_get_sync(disp->dev);
> +
> zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode);
>
> - pm_runtime_get_sync(disp->dev);
> ret = clk_prepare_enable(disp->pclk);
> if (ret) {
> dev_err(disp->dev, "failed to enable a pixel clock\n");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/3] drm/panel: panel-simple: Add the panel on sc7180-trogdor-pompom
This adds an entry to simple panel for the timings of a panel that
might be attached to the board sc7180-trogdor-pompom.
As talked about in the previous patch ("dt-bindings: display: simple:
Add the panel on sc7180-trogdor-pompom") any number of panels might be
attached. These panels might have different timings or even different
resolutions.
When we see a pompom panel we'll use some conservative power sequence
timings that can work with any of the panels that will be
attached. All the rest of the details about the panel can be found by
read its EDID.
NOTE: if we wanted to optimize things a bit we could figure out which
of the panels was actually attached and perhaps reduce some of the
timings by a tiny bit if it was a panel that we recognized. I won't
attempt this right now but it could be a nice future optimization,
epsecially getting rid of the 200 ms "enable delay" imposed by the
Starry panel.
Signed-off-by: Douglas Anderson
---
For overall discussion about the idea of defining a generic panel at
the board level, please respond in the bindings patch so we can keep
all discussion in one place.
drivers/gpu/drm/panel/panel-simple.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4e2dad314c79..c8964efd562b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2205,6 +2205,15 @@ static const struct panel_desc hitachi_tx23d38vm0caa = {
},
};
+static const struct panel_desc google_pompom_panel = {
+ .delay = {
+ .hpd_absent_delay = 200,
+ .enable = 200,
+ .unprepare = 500,
+ },
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
+};
+
static const struct drm_display_mode innolux_at043tn24_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -4265,6 +4274,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "hit,tx23d38vm0caa",
.data = &hitachi_tx23d38vm0caa
+ }, {
+ .compatible = "google,pompom-panel",
+ .data = &google_pompom_panel,
}, {
.compatible = "innolux,at043tn24",
.data = &innolux_at043tn24,
--
2.31.0.rc2.261.g7f71774620-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
The sc7180-trogdor-pompom board might be attached to any number of a pile of eDP panels. At the moment I'm told that the list might include: - KD KD116N21-30NV-A010 - KD KD116N09-30NH-A016 - Starry 2081116HHD028001-51D - Sharp LQ116M1JW10 It should be noted that while the EDID programmed in the first 3 panels indicates that they should run with exactly the same timing (to keep things simple), the 4th panel not only needs different timing but has a different resolution. As is true in general with eDP panels, we can figure out which panel we have and all the info needed to drive its pixel clock by reading the EDID. However, we can do this only after we've powered the panel on. Powering on the panels requires following the timing diagram in each panel's datasheet which specifies delays between certain actions. This means that, while we can be quite dynamic about handling things we can't just totally skip out on describing the panel like we could do if it was connected to an external-facing DP port. While the different panels have slightly different delays, it's possible to come up with a set of unified delays that will work on all the panels. From reading the datasheets: * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 - HPD absent delay: 200 ms - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) * Starry 2081116HHD028001-51D - HPD absent delay: 100 ms - Enable delay: (link training done till enable BL): 200 ms - Unprepare delay: 500 ms * Sharp LQ116M1JW10 - HPD absent delay: 200 ms - Unprepare delay: 500 ms - Prepare to enable delay (power on till backlight): 100 ms Unified: - HPD absent delay: 200 ms - Unprepare delay: 500 ms - Enable delay: 200 ms NOTE: in theory the only thing that we _really_ need unity on is the "HPD absent delay" since once the panel asserts HPD we can read the EDID and could make per-panel decisions if we wanted. Let's create a definition of "a panel that can be attached to pompom" as a panel that provides a valid EDID and can work with the standard pompom power sequencing. If more panels are later attached to pompom then it's fine as long as they work in a compatible way. One might ask why we can't just use a generic string here and provide the timings directly in the device tree file. As I understand it, trying to describe generic power sequencing in the device tree is frowned upon and the one instance (SD/MMC) is regarded as a mistake that shouldn't be repeated. Specifying a power sequence per board (or per board class) feels like a reasonable compromise. We're not trying to define fully generic power sequence bindings but we can also take advantage of the semi-probable properties of the attached device. NOTE: I believe that past instances of supporting this type of thing have used the "white lie" approach. One representative panel was listed in the device tree. The power sequencings of this representative panel were OK to use across all panels that might be attached and other differences were handled by EDID. This patch attempts to set a new precedent and avoid the need for the white lie. Signed-off-by: Douglas Anderson --- .../devicetree/bindings/display/panel/panel-simple.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 62b0d54d87b7..9807dbc1cceb 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -140,6 +140,10 @@ properties: - giantplus,gpg48273qs5 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel - giantplus,gpm940b0 +# A panel connected to a google,pompom board. Panel is guaranteed to +# confirm to google,pompom-panel power sequencing requirements and then +# the specific panel will be probed via EDID. + - google,pompom-panel # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel - hannstar,hsd070pww1 # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel -- 2.31.0.rc2.261.g7f71774620-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 3/3] arm64: dts: qcom: Don't specify exactly what panel is on pompom
As talked about in the previous patch ("dt-bindings: display: simple:
Add the panel on sc7180-trogdor-pompom") any number of panels might be
attached.
Let's stop specifying a single panel and just specify that we have a
"pompom panel".
Signed-off-by: Douglas Anderson
---
Before landing this we need the patch ("drm/panel: panel-simple: Add
the panel on sc7180-trogdor-pompom") from earlier in this series. Less
obviously, though, we also need the patch ("drm/bridge: ti-sn65dsi86:
Properly get the EDID, but only if refclk") [1].
[1]
https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c74b876e68@changeid
arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
index d253a08f6fc8..f98c18f6ff94 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
@@ -108,7 +108,7 @@ ap_ts: touchscreen@10 {
};
&panel {
- compatible = "kingdisplay,kd116n21-30nv-a010";
+ compatible = "google,pompom-panel";
};
&pen_insert {
--
2.31.0.rc2.261.g7f71774620-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen wrote: > > On Mon, 8 Mar 2021 16:52:58 -0800 > "Navare, Manasi" wrote: > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote: > > > On Wed, 3 Mar 2021 12:44:33 -0800 > > > "Navare, Manasi" wrote: > > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote: > > > > > On Tue, 2 Mar 2021 12:41:32 -0800 > > > > > Manasi Navare wrote: > > > > > > > > > > > In case of a modeset where a mode gets split across mutiple CRTCs > > > > > > in the driver specific implementation (bigjoiner in i915) we > > > > > > wrongly count > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate the > > > > > > stolen CRTC as > > > > > > an affected CRTC in atomic_check_only(). > > > > > > This triggers a warning since affected CRTCs doent match requested > > > > > > CRTC. > > > > > > > > > > > > To fix this in such bigjoiner configurations, we should only > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not > > > > > > if it is just used internally in the driver to split the mode. > > > > > > > > > > Hi, > > > > > > > > > > I think that makes sense to me. Stealing CRTCs that are not currently > > > > > used by the userspace (display server) should be ok, as long as that > > > > > is completely invisible to userspace: meaning that it does not cause > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic > > > > > completion events. > > > > > > > > Yes since we are only doing atomic_check_only() here, the stolen > > > > > > But the real not-test-only commit will follow if this test-only commit > > > succeeds, and keeping the guarantees for the real commit are important. > > > > Hmm well after the actual real commit, since the second crtc is stolen > > even though it is not being used for the display output, it is > > used for joiner so the uapi.enable will be true after the real commit. > > > > so actually the assertion would fail in this case. > > > > @Ville @Danvet any suggestions here in that case? That is very bad. We can't frob uapi state like that. I think that calls for even more checks to make sure kms drivers who try to play clever games don't get it wrong, so we probably need to check uapi enable and active state in another mask before/after ->atomic_check too. Or something like that. > Hi, > > that is not what I was talking about, but sounds like you found a > different problem. It seems like the problem you are talking about > would be guaranteed to be hit if bigjoiner was used. Have you not > tested this? > > However, I was talking about the real commit itself, not what happens > on commits after it, see below. > > > > > crtc is completely invisible to the userspace and hence that is > > > > indicated by uapi.enable which is not true for this stolen > > > > crtc. However if allow modeset flag set, then it will do a full > > > > modeset and indicate the uapi.enable for this stolen crtc as well > > > > since that cannot be used for other modeset requested by userspace. > > > > > > > > > > > > > > Can that also be asserted somehow, or does this already do that? > > > > > > > > Not clear what you want the assertion for? Could you elaborate > > > > > > As assertion that when the real atomic commit happens and then > > > completion events are fired, they match exactly the affected crtcs mask. > > This is my concern and a question, although like I say below, only > tangential to this patch. > > However, as this patch aims to allow bigjoiner usage, naturally the > question will arise whether the completion events then match what > userspace expects or not. Userspace does not expect completion events > referring to the stolen CRTCs. Yeah we also must make sure that we don't send out events for these additional crtc in bigjoiner usage. Sounds like igt testing didn't catch this, I think we need a lot more igts here to make sure all these surprises don't happen. Plus maybe triple-checking that drm_atomic_uapi.c makes sure we can't send out events for stuff that userspace didn't ask for. -Daniel > > > > I understand this may be off-topic for this particular patch, but since > > > we are discussing the topic, such checks would be really nice. I'm > > > curious if such checks already exist. > > > Thanks, > pq > > > > > > > --- > > > > > > drivers/gpu/drm/drm_atomic.c | 6 -- > > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c > > > > > > b/drivers/gpu/drm/drm_atomic.c > > > > > > index 5b4547e0f775..d7acd6bbd97e 100644 > > > > > > --- a/drivers/gpu/drm/drm_atomic.c > > > > > > +++ b/drivers/gpu/drm/drm_atomic.c > > > > > > @@ -1358,8 +1358,10 @@ int drm_atomic_check_only(struct > > > > > > drm_atomic_state *state) > > > > > > } > > > > > > } > > > > > > > > > > > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) > > > > > > - affected_crtc |= drm_crtc_mask(crtc); > >
Re: [PATCH 3/3] drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk
Hi Doug,
On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> On Sat, Mar 13, 2021 at 1:17 PM Laurent Pinchart wrote:
> > On Thu, Mar 04, 2021 at 03:52:01PM -0800, Douglas Anderson wrote:
> > > In commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
> > > DDC") we attempted to make the ti-sn65dsi86 bridge properly read the
> > > EDID from the panel. That commit kinda worked but it had some serious
> > > problems.
> > >
> > > The problems all stem from the fact that userspace wants to be able to
> > > read the EDID before it explicitly enables the panel. For eDP panels,
> > > though, we don't actually power the panel up until the pre-enable
> > > stage and the pre-enable call happens right before the enable call
> > > with no way to interject in-between. For eDP panels, you can't read
> > > the EDID until you power the panel. The result was that
> > > ti_sn_bridge_connector_get_modes() was always failing to read the EDID
> > > (falling back to what drm_panel_get_modes() returned) until _after_
> > > the EDID was needed.
> > >
> > > To make it concrete, on my system I saw this happen:
> > > 1. We'd attach the bridge.
> > > 2. Userspace would ask for the EDID (several times). We'd try but fail
> > >to read the EDID over and over again and fall back to the hardcoded
> > >modes.
> > > 3. Userspace would decide on a mode based only on the hardcoded modes.
> > > 4. Userspace would ask to turn the panel on.
> > > 5. Userspace would (eventually) check the modes again (in Chrome OS
> > >this happens on the handoff from the boot splash screen to the
> > >browser). Now we'd read them properly and, if they were different,
> > >userspace would request to change the mode.
> > >
> > > The fact that userspace would always end up using the hardcoded modes
> > > at first significantly decreases the benefit of the EDID
> > > reading. Also: if the modes were even a tiny bit different we'd end up
> > > doing a wasteful modeset and at boot.
> >
> > s/and at/at/ ?
>
> Sure, I can correct if/when I respin or it can be corrected when landed.
>
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > index 491c9c4f32d1..af3fb4657af6 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > @@ -16,6 +16,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > >
> > > @@ -130,6 +131,12 @@
> > > * @ln_assign:Value to program to the LN_ASSIGN register.
> > > * @ln_polrs: Value for the 4-bit LN_POLRS field of SN_ENH_FRAME_REG.
> > > *
> > > + * @pre_enabled_early: If true we did an early pre_enable at attach.
> > > + * @pre_enable_timeout_work: Delayed work to undo the pre_enable from
> > > attach
> > > + * if a normal pre_enable never came.
> >
> > Could we simplify this by using the runtime PM autosuspend feature ? The
> > configuration of the bridge would be moved from pre_enable to the PM
> > runtime resume handler, the clk_disable_unprepare() call moved from
> > post_disable to the runtime suspend handler, and the work queue replaced
> > by usage of pm_runtime_put_autosuspend().
>
> It's an interesting idea but I don't think I can make it work, at
> least not in a generic enough way. Specifically we can also use this
> bridge chip as a generic GPIO provider in Linux. When someone asks us
> to read a GPIO then we have to power the bridge on
> (pm_runtime_get_sync()) and when someone asks us to configure a GPIO
> as an output then we actually leave the bridge powered until they stop
> requesting it as an output. At the moment the only user of this
> functionality (that I know of) is for the HPD pin on trogdor boards
> (long story about why we don't use the dedicated HPD) but the API
> supports using these GPIOs for anything and I've tested that it works.
> It wouldn't be great to have to keep the panel on in order to access
> the GPIOs.
The issue you're trying to fix doesn't seem specific to this bridge, so
handling it in the bridge driver bothers me :-S Is there any way we
could handle this in the DRM core ? I don't want to see similar
implementations duplicated in all HDMI/DP bridges.
> The other problem is that I think the time scales are different. At
> boot time I think we'd want to leave the panel on for tens of seconds
> to give userspace a chance to start up and configure the panel. After
> userspace starts up I think we'd want autosuspend to be much faster.
> This could probably be solved by tweaking the runtime delay in code
> but I didn't fully dig because of the above problem.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock
On Mon, Mar 08, 2021 at 03:03:58PM +0100, Sebastian Reichel wrote: > Hi, > > On Sat, Mar 06, 2021 at 11:56:45AM -0800, Rob Herring wrote: > > On Tue, Feb 23, 2021 at 02:26:57AM +0100, Sebastian Reichel wrote: > > > On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote: > > > > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > > > > > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > > > > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > > > > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > > > > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > > > > > the clock is disabled and all i.MX6 functionality depending on > > > > > > the 32 KHz clock has undefined behaviour. On systems using hardware > > > > > > watchdog it seems to likely trigger a lot earlier than configured. > > > > > > > > > > > > The proper solution would be to describe this dependency in DT, > > > > > > but that will result in a deadlock. The kernel will see, that > > > > > > i.MX6 system clock needs the RTC clock and do probe deferral. > > > > > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > > > > > CKIL clock and thus the RTC's clock will not be probed. So from > > > > > > the kernel's perspective this is a chicken-and-egg problem. > > > > > > > > > > > > > > > > Reading the previous paragraph, I was going to suggest describing the > > > > > dependency and wondering whether this would cause a circular > > > > > dependency. > > > > > I guess this will keep being an issue for clocks on an I2C or SPI > > > > > bus... > > > > > > Yes, it is a circular dependency on this particular system on > > > module. It only works because the RTC enables the clock by > > > default. The i.MX6 CKIL is expected to be always enabled. > > > > I think you should describe the circular clocking and then provide a way > > to break the dependency. > > This is very much not trivial. The clock is required during early > initialization of the i.MX. At this point we are far from probing > I2C drivers and without the I2C driver the clock is not registered. > The current i.MX code expects the system clocks to be fixed clocks, > since they must be enabled before any code is executed (incl. > bootloader) and must never be disabled. From a HW design point of > view it does not make sense to have a SW controllable clock for it, > since it just adds extra cost. I believe for QMX6 it is only SW > controllable, because that avoids the need for an extra crystal. > > So how is the clock framework supposed to know, that it can ignore > the clock during registration? I see the following options: > > 1. My solution is the simplest one. Keep i.MX clock code the same >(it assumes a fixed-clock being used for CKIL) and avoid >registering RTC clock. This basically means the RTC is considered >to be a fixed-clock on this system, which is what the HW designers >seemed to have in mind (vendor kernel for the QMX6 is old enough >(4.9.x) to not to have CLK feature in the RTC driver. Vendor >U-Boot also does not touch the RTC. Booting mainline kernel once >bricks QMX6 boards until RTC battery is removed, so one could >actually argue addition of the CLK feature in 1373e77b4f10 (4.13) >is a regression). Currently Qualcomm device uses "protected-clocks" >for FW controlled clocks where Linux would crash the system by >trying to access them. IMHO the RTC is similar, since disabling >or modifying its frequency on QMX6 results in undefined behaviour >and possibly system crash. > > 2. Make i.MX clock code use the RTC as CKIL clock provider, but >ignore it somehow. I see three sub-options: > > 2.1. Add a property 'boot-enabled' to the RTC node, so that the > clock framework is aware of clock being enabled. This can > be used to satisfy clock dependencies somehow. > > 2.2. The RTC device is not probed without I2C bus, but the driver > could also register a fake clock purely based on DT > information by adding some early init hook and take over > the clock once the I2C part is being probed. I think this > is a bad idea regarding maintainability of the driver. > Also for systems not using the RTC clock, the early clock > registration is basically wrong: If the kernel disables > the RTC it will stay disabled across boots if the RTC has > a backup battery. Basically we cannot imply anything from > the RTC compatible value alone. > > 2.3 The i.MX core code could request CKIL with some flag, that > it's fine to have an unresolvable clock and just expect it > to be boot-enabled. The rationale would be, that CKIL must > be always-enabled. I think 2.1 or 2.3 is fine. It boils down to detecting a cycle and then either you have a property or implicitly know to ignore a dependency. > > It's a somewhat common issue. > > It is? This only works, because one can
[PATCH] drm/i915: Add Wa_14011060649
This is a permanent workaround for TGL,RKL,DG1 and ADLS.
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 23 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3b4a7da60f0b..683a0446337a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1117,11 +1117,34 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
}
+/*
+ * This is a common function for WA 14011060649
+ */
+static void
+wa_14011060649(struct drm_i915_private *i915, struct i915_wa_list *wal)
+{
+ struct intel_engine_cs *engine;
+ struct intel_gt *gt = &i915->gt;
+ int id;
+
+ for_each_engine(engine, gt, id) {
+ if ((engine->class != VIDEO_DECODE_CLASS) ||
+ (engine->instance % 2))
+ continue;
+
+ wa_write_or(wal, VDBOX_CGCTL3F10(engine->mmio_base),
+ IECPUNIT_CLKGATE_DIS);
+ }
+}
+
static void
gen12_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
{
wa_init_mcr(i915, wal);
+
+ /* Wa_14011060649:tgl,rkl,dg1,adls */
+ wa_14011060649(i915, wal);
}
static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e5dd0203991b..cc60556306e2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2715,6 +2715,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ */
#define RING_CTX_TIMESTAMP(base) _MMIO((base) + 0x3a8) /* gen8+ */
+#define VDBOX_CGCTL3F10(base) _MMIO((base) + 0x3f10)
+#define IECPUNIT_CLKGATE_DIS REG_BIT(22)
+
#define ERROR_GEN6 _MMIO(0x40a0)
#define GEN7_ERR_INT _MMIO(0x44040)
#define ERR_INT_POISON (1 << 31)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
On Wed, Mar 10, 2021 at 05:55:31PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.
>
> Signed-off-by: Liu Ying
> ---
> v4->v5:
> * Newly introduced in v5. (Rob)
>
> .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 202
> +
> 1 file changed, 202 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> new file mode 100644
> index ..0e724d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> @@ -0,0 +1,202 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/fsl,imx8qxp-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings
> +
> +maintainers:
> + - Liu Ying
> +
> +description: |
> + As a system controller, the Freescale i.MX8qm/qxp Control and Status
> + Registers(CSR) module represents a set of miscellaneous registers of a
> + specific subsystem. It may provide control and/or status report interfaces
> + to a mix of standalone hardware devices within that subsystem. One typical
> + use-case is for some other nodes to acquire a reference to the syscon node
> + by phandle, and the other typical use-case is that the operating system
> + should consider all subnodes of the CSR module as separate child devices.
> +
> +select:
> + properties:
> +compatible:
> + contains:
> +enum:
> + - fsl,imx8qxp-mipi-lvds-csr
> + - fsl,imx8qm-lvds-csr
You shouldn't need this, we filter out 'syscon' and 'simple-mfd'.
> + required:
> +- compatible
> +
> +properties:
> + $nodename:
> +pattern: "^syscon@[0-9a-f]+$"
> +
> + compatible:
> +items:
> + - enum:
> + - fsl,imx8qxp-mipi-lvds-csr
> + - fsl,imx8qm-lvds-csr
> + - const: syscon
> + - const: simple-mfd
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +const: ipg
> +
> +patternProperties:
> + "^(ldb|phy|pxl2dpi)$":
> +type: object
> +description: The possible child devices of the CSR module.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: fsl,imx8qxp-mipi-lvds-csr
> +then:
> + required:
> +- pxl2dpi
> +- ldb
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: fsl,imx8qm-lvds-csr
> +then:
> + required:
> +- phy
> +- ldb
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +mipi_lvds_0_csr: syscon@56221000 {
> +compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd";
> +reg = <0x56221000 0x1000>;
> +clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
> +clock-names = "ipg";
> +
> +mipi_lvds_0_pxl2dpi: pxl2dpi {
> +compatible = "fsl,imx8qxp-pxl2dpi";
> +fsl,sc-resource = ;
> +power-domains = <&pd IMX_SC_R_MIPI_0>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <0>;
> +
> +mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
> +reg = <0>;
> +remote-endpoint =
> <&dc0_pixel_link0_mipi_lvds_0_pxl2dpi>;
> +};
> +
> +mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 {
> +reg = <1>;
> +remote-endpoint =
> <&dc0_pixel_link1_mipi_lvds_0_pxl2dpi>;
> +};
> +};
> +
> +port@1 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +reg = <1>;
> +
> +mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
> +reg = <0>;
> +remote-endpoint =
> <&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
> +};
> +
> +mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
> +reg = <1>;
> +remote-endpoint =
> <&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
> +};
> +};
> +};
> +};
> +
> +mipi_lvds_0_ldb: ldb {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = "fsl,imx8qxp-ldb";
> +clocks =
Re: [PATCH v5 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding
On Wed, 10 Mar 2021 17:55:32 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI). > > Signed-off-by: Liu Ying > --- > v4->v5: > * No change. > > v3->v4: > * Add 'fsl,sc-resource' property. (Rob) > > v2->v3: > * Drop 'fsl,syscon' property. (Rob) > * Mention the CSR module controls PXL2DPI. > > v1->v2: > * Use graph schema. (Laurent) > > .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 108 > + > 1 file changed, 108 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/2] drm/tegra: dc: Support memory bandwidth management
15.03.2021 21:39, Dmitry Osipenko пишет: >>> + /* >>> +* Horizontal downscale needs a lower memory latency, which roughly >>> +* depends on the scaled width. Trying to tune latency of a memory >>> +* client alone will likely result in a strong negative impact on >>> +* other memory clients, hence we will request a higher bandwidth >>> +* since latency depends on bandwidth. This allows to prevent memory >>> +* FIFO underflows for a large plane downscales, meanwhile allowing >>> +* display to share bandwidth fairly with other memory clients. >>> +*/ >>> + if (src_w > dst_w) >>> + mul = (src_w - dst_w) * bpp / 2048 + 1; >>> + else >>> + mul = 1; >> [...] >> >> One point is unexplained yet: why is the multiplier proportional to a >> *difference* between src and dst widths? Also, I would expect max (worst >> case) is pixclock * read_size when src_w/dst_w >= read_size. > IIRC, the difference gives a more adequate/practical result than the > proportion. Although, downstream driver uses proportion. I'll try to > revisit this for the next version of the patch. I tried to re-test everything and can't reproduce problems that existed previously. We didn't have a finished memory drivers back then and I think that Tegra30 latency tuning support and various Tegra20 changes fixed those problems. I'll remove this hunk in the next version. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Is LLVM 13 (git) really ready for testing/development? libclc didn't compile
[CC trimmed - excluded Marek] Too bad Jan, 'configure' works, now. But compilation brakes after that. How can we add '-cl-no-stdinc' only to CMAKE_CLC_FLAGS and NOT CXX flags (see below)? Tried libclc/build> pwd /opt/llvm-project/libclc/build libclc/build> cmake ../ -DLLVM_CONFIG=/usr/local/bin/llvm-config -DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc and libclc/build> cmake ../../../llvm-project/libclc/ -DLLVM_CONFIG=/usr/local/bin/llvm-config -DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -- The CXX compiler identification is GNU 10.2.1 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done LLVM version: 13.0.0git LLVM system libs: LLVM libs: -lLLVM-13git LLVM libdir: /usr/local/lib LLVM bindir: /usr/local/bin LLVM ld flags: -L/usr/local/lib LLVM cxx flags: -I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions;-fno-exceptions;-cl-no-stdinc clang: /usr/local/bin/clang llvm-as: /usr/local/bin/llvm-as llvm-link: /usr/local/bin/llvm-link opt: /usr/local/bin/opt llvm-spirv: /usr/local/bin/llvm-spirv -- Check for working CLC compiler: /usr/local/bin/clang -- Check for working CLC compiler: /usr/local/bin/clang -- works -- Check for working LLAsm compiler: /usr/local/bin/llvm-as -- Check for working LLAsm compiler: /usr/local/bin/llvm-as -- works -- Found Python3: /usr/bin/python3.8 (found version "3.8.8") found components: Interpreter BUILDING amdgcn-- DEVICE: tahiti ( pitcairn;verde;oland;hainan;bonaire;kabini;kaveri;hawaii;mullins;tonga;iceland;carrizo;fiji;stoney;polaris10;polaris11;gfx900;gfx902;gfx904;gfx906 ) BUILDING amdgcn--amdhsa DEVICE: none ( ) BUILDING amdgcn-mesa-mesa3d DEVICE: tahiti ( pitcairn;verde;oland;hainan;bonaire;kabini;kaveri;hawaii;mullins;tonga;iceland;carrizo;fiji;stoney;polaris10;polaris11;gfx900;gfx902;gfx904;gfx906 ) BUILDING clspv-- DEVICE: none ( ) BUILDING nvptx-- DEVICE: none ( ) BUILDING nvptx--nvidiacl DEVICE: none ( ) BUILDING nvptx64-- DEVICE: none ( ) BUILDING nvptx64--nvidiacl DEVICE: none ( ) BUILDING r600-- DEVICE: cedar ( palm;sumo;sumo2;redwood;juniper ) DEVICE: cypress ( hemlock ) DEVICE: barts ( turks;caicos ) DEVICE: cayman ( aruba ) BUILDING spirv-mesa3d- DEVICE: none ( ) BUILDING spirv64-mesa3d- DEVICE: none ( ) -- Configuring done -- Generating done -- Build files have been written to: /opt/llvm-project/libclc/build libclc/build> make -j Scanning dependencies of target generate_convert.cl Scanning dependencies of target prepare_builtins [ 0%] Generating convert.cl [ 0%] Building CXX object CMakeFiles/prepare_builtins.dir/utils/prepare-builtins.cpp.o c++: error: unrecognized command-line option ‘-cl-no-stdinc’; did you mean ‘-nostdinc’? make[2]: *** [CMakeFiles/prepare_builtins.dir/build.make:82: CMakeFiles/prepare_builtins.dir/utils/prepare-builtins.cpp.o] Fehler 1 make[1]: *** [CMakeFiles/Makefile2:1810: CMakeFiles/prepare_builtins.dir/all] Fehler 2 make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet [ 0%] Built target generate_convert.cl make: *** [Makefile:160: all] Fehler 2 And YES, my time during these 'Corona-Times' is limited, too... ...my wife is a children's nurse, we 5 aktive doctors (4 pneumologist), 7 entire in our family and my second discipline was medicine, too. ;-) Greetings and Gesundheit to all of you! Dieter Am 10.03.2021 18:03, schrieb Jan Vesely: One more update. without changing any cmake files the following cmdline should work: cmake ../llvm-project/libclc/ -DLLVM_CONFIG=/usr/local/llvm-git/bin/llvm-config -DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc Jan On Wed, Mar 10, 2021 at 1:20 AM Jan Vesely wrote: hi, sorry the option is actually -cl-no-stdinc. you can add it to 'target_compiler_options'. I should have a patch ready soon(tm), but time is scarce. Jan On Sun, Mar 7, 2021 at 9:51 PM Dieter Nützel wrote: Hello Jan, I very much appreciate your advice. Tried several places... ...where to put it? Dieter Am 06.03.2021 17:56, schrieb Jan Vesely: Not Marek, but hope this answer will help. libclc uses clang CLC preprocessor on .ll files, llvm/clang-13 started including clc declarations by default (clang cf3ef15a6ec5e5b45c6c54e8fbe3769255e815ce), thus corrupting any .ll assembly files that are used by libclc. Inclusion of the default declarations can be turned off using a cmdline switch but that remains to be implemented in the libclc build system. manually adding '-cl-no-stdinc' should work as a workaround. Jan On Thu, Mar 4, 2021 at 10:27 PM Dieter Nützel wrote: Hello Marek, can'
Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Tue, 16 Mar 2021 at 21:35, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen > wrote: > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for the display output, it is > > > used for joiner so the uapi.enable will be true after the real commit. > > > > > > so actually the assertion would fail in this case. > > > > > > @Ville @Danvet any suggestions here in that case? > > That is very bad. We can't frob uapi state like that. I think that > calls for even more checks to make sure kms drivers who try to play > clever games don't get it wrong, so we probably need to check uapi > enable and active state in another mask before/after ->atomic_check > too. Or something like that. > Yeah. We can _never_ generate externally-visible completion events. We can later fail to enable the stolen CRTC - because trying to enable new things can fail for any reason whatsoever - but we can't generate spurious completion events, as doing so falls into the uncanny valley. If the kernel is doing clever things behind userspace's back - such as stealing planes or CRTCs - then userspace can never know about it, apart from failing to enable those resources later. The kernel can either never do anything clever (and make userspace bind them both together), or be extremely clever (by hiding the entire details from userspace), but it cannot choose the halfway house of doing clever things behind userspace's back (such as stealing new CRTCs) whilst also exposing all those details to userspace (such as delivering spurious completion events for resources userspace never requested to be programmed). Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Add Wa_14011060649
This is a permanent workaround for TGL,RKL,DG1 and ADLS.
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3b4a7da60f0b..01f34a6bdf3e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1117,11 +1117,38 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
}
+/*
+ * Though there are per-engine instances of these registers,
+ * they retain their value through engine resets and should
+ * only be provided on the GT workaround list rather than
+ * the engine-specific workaround list.
+ *
+ */
+static void
+wa_14011060649(struct drm_i915_private *i915, struct i915_wa_list *wal)
+{
+ struct intel_engine_cs *engine;
+ struct intel_gt *gt = &i915->gt;
+ int id;
+
+ for_each_engine(engine, gt, id) {
+ if ((engine->class != VIDEO_DECODE_CLASS) ||
+ (engine->instance % 2))
+ continue;
+
+ wa_write_or(wal, VDBOX_CGCTL3F10(engine->mmio_base),
+ IECPUNIT_CLKGATE_DIS);
+ }
+}
+
static void
gen12_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
{
wa_init_mcr(i915, wal);
+
+ /* Wa_14011060649:tgl,rkl,dg1,adls */
+ wa_14011060649(i915, wal);
}
static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e5dd0203991b..cc60556306e2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2715,6 +2715,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ */
#define RING_CTX_TIMESTAMP(base) _MMIO((base) + 0x3a8) /* gen8+ */
+#define VDBOX_CGCTL3F10(base) _MMIO((base) + 0x3f10)
+#define IECPUNIT_CLKGATE_DIS REG_BIT(22)
+
#define ERROR_GEN6 _MMIO(0x40a0)
#define GEN7_ERR_INT _MMIO(0x44040)
#define ERR_INT_POISON (1 << 31)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk
Hi,
On Tue, Mar 16, 2021 at 2:46 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> > On Sat, Mar 13, 2021 at 1:17 PM Laurent Pinchart wrote:
> > > On Thu, Mar 04, 2021 at 03:52:01PM -0800, Douglas Anderson wrote:
> > > > In commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
> > > > DDC") we attempted to make the ti-sn65dsi86 bridge properly read the
> > > > EDID from the panel. That commit kinda worked but it had some serious
> > > > problems.
> > > >
> > > > The problems all stem from the fact that userspace wants to be able to
> > > > read the EDID before it explicitly enables the panel. For eDP panels,
> > > > though, we don't actually power the panel up until the pre-enable
> > > > stage and the pre-enable call happens right before the enable call
> > > > with no way to interject in-between. For eDP panels, you can't read
> > > > the EDID until you power the panel. The result was that
> > > > ti_sn_bridge_connector_get_modes() was always failing to read the EDID
> > > > (falling back to what drm_panel_get_modes() returned) until _after_
> > > > the EDID was needed.
> > > >
> > > > To make it concrete, on my system I saw this happen:
> > > > 1. We'd attach the bridge.
> > > > 2. Userspace would ask for the EDID (several times). We'd try but fail
> > > >to read the EDID over and over again and fall back to the hardcoded
> > > >modes.
> > > > 3. Userspace would decide on a mode based only on the hardcoded modes.
> > > > 4. Userspace would ask to turn the panel on.
> > > > 5. Userspace would (eventually) check the modes again (in Chrome OS
> > > >this happens on the handoff from the boot splash screen to the
> > > >browser). Now we'd read them properly and, if they were different,
> > > >userspace would request to change the mode.
> > > >
> > > > The fact that userspace would always end up using the hardcoded modes
> > > > at first significantly decreases the benefit of the EDID
> > > > reading. Also: if the modes were even a tiny bit different we'd end up
> > > > doing a wasteful modeset and at boot.
> > >
> > > s/and at/at/ ?
> >
> > Sure, I can correct if/when I respin or it can be corrected when landed.
> >
> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > index 491c9c4f32d1..af3fb4657af6 100644
> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > > > @@ -16,6 +16,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include
> > > >
> > > > @@ -130,6 +131,12 @@
> > > > * @ln_assign:Value to program to the LN_ASSIGN register.
> > > > * @ln_polrs: Value for the 4-bit LN_POLRS field of
> > > > SN_ENH_FRAME_REG.
> > > > *
> > > > + * @pre_enabled_early: If true we did an early pre_enable at attach.
> > > > + * @pre_enable_timeout_work: Delayed work to undo the pre_enable from
> > > > attach
> > > > + * if a normal pre_enable never came.
> > >
> > > Could we simplify this by using the runtime PM autosuspend feature ? The
> > > configuration of the bridge would be moved from pre_enable to the PM
> > > runtime resume handler, the clk_disable_unprepare() call moved from
> > > post_disable to the runtime suspend handler, and the work queue replaced
> > > by usage of pm_runtime_put_autosuspend().
> >
> > It's an interesting idea but I don't think I can make it work, at
> > least not in a generic enough way. Specifically we can also use this
> > bridge chip as a generic GPIO provider in Linux. When someone asks us
> > to read a GPIO then we have to power the bridge on
> > (pm_runtime_get_sync()) and when someone asks us to configure a GPIO
> > as an output then we actually leave the bridge powered until they stop
> > requesting it as an output. At the moment the only user of this
> > functionality (that I know of) is for the HPD pin on trogdor boards
> > (long story about why we don't use the dedicated HPD) but the API
> > supports using these GPIOs for anything and I've tested that it works.
> > It wouldn't be great to have to keep the panel on in order to access
> > the GPIOs.
>
> The issue you're trying to fix doesn't seem specific to this bridge, so
> handling it in the bridge driver bothers me :-S Is there any way we
> could handle this in the DRM core ? I don't want to see similar
> implementations duplicated in all HDMI/DP bridges.
Yes, it is true that this problem could affect other drivers. ...and
in full disclosure I think there are other similar workarounds already
present. I haven't personally worked on those chips, but in
ps8640_bridge_get_edid() there is a somewhat similar workaround to
chain a pre-enable (though maybe it's not quite as optimized?). I'm
told that maybe something had to be handled for anx7625 (in
anx7625_get_edid()?) but that definitely doesn't look at all like it's
doing a pre-en
[PATCH AUTOSEL 5.11 43/61] drm/amd/display: Enable pflip interrupt upon pipe enable
From: Qingqing Zhuo
[ Upstream commit 7afa0033d6f7fb8a84798ef99d1117661c4e696c ]
[Why]
pflip interrupt would not be enabled promptly if a pipe is disabled
and re-enabled, causing flip_done timeout error during DP
compliance tests
[How]
Enable pflip interrupt upon pipe enablement
Tested-by: Daniel Wheeler
Signed-off-by: Qingqing Zhuo
Reviewed-by: Nicholas Kazlauskas
Acked-by: Eryk Brol
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/dc/dc.h | 1 +
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c | 11 +++
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h | 6 ++
.../gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 7 +++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c | 1 +
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c| 6 ++
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c | 1 +
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c | 1 +
drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h | 2 ++
10 files changed, 37 insertions(+)
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 947cd923fb4c..71d3040afaca 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4607,6 +4607,7 @@ static int fill_dc_plane_attributes(struct amdgpu_device
*adev,
dc_plane_state->global_alpha_value = plane_info.global_alpha_value;
dc_plane_state->dcc = plane_info.dcc;
dc_plane_state->layer_index = plane_info.layer_index; // Always returns 0
+ dc_plane_state->flip_int_enabled = true;
/*
* Always set input transfer function, since plane state is refreshed
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 3aedadb34548..414b44b4ced4 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -889,6 +889,7 @@ struct dc_plane_state {
int layer_index;
union surface_update_flags update_flags;
+ bool flip_int_enabled;
/* private to DC core */
struct dc_plane_status status;
struct dc_context *ctx;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c
index 9e796dfeac20..714c71a5fbde 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c
@@ -1257,6 +1257,16 @@ void hubp1_soft_reset(struct hubp *hubp, bool reset)
REG_UPDATE(DCHUBP_CNTL, HUBP_DISABLE, reset ? 1 : 0);
}
+void hubp1_set_flip_int(struct hubp *hubp)
+{
+ struct dcn10_hubp *hubp1 = TO_DCN10_HUBP(hubp);
+
+ REG_UPDATE(DCSURF_SURFACE_FLIP_INTERRUPT,
+ SURFACE_FLIP_INT_MASK, 1);
+
+ return;
+}
+
void hubp1_init(struct hubp *hubp)
{
//do nothing
@@ -1290,6 +1300,7 @@ static const struct hubp_funcs dcn10_hubp_funcs = {
.dmdata_load = NULL,
.hubp_soft_reset = hubp1_soft_reset,
.hubp_in_blank = hubp1_in_blank,
+ .hubp_set_flip_int = hubp1_set_flip_int,
};
/*/
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h
index a9a6ed7f4f99..e2f2f6995935 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h
@@ -74,6 +74,7 @@
SRI(DCSURF_SURFACE_EARLIEST_INUSE_C, HUBPREQ, id),\
SRI(DCSURF_SURFACE_EARLIEST_INUSE_HIGH_C, HUBPREQ, id),\
SRI(DCSURF_SURFACE_CONTROL, HUBPREQ, id),\
+ SRI(DCSURF_SURFACE_FLIP_INTERRUPT, HUBPREQ, id),\
SRI(HUBPRET_CONTROL, HUBPRET, id),\
SRI(DCN_EXPANSION_MODE, HUBPREQ, id),\
SRI(DCHUBP_REQ_SIZE_CONFIG, HUBP, id),\
@@ -183,6 +184,7 @@
uint32_t DCSURF_SURFACE_EARLIEST_INUSE_C; \
uint32_t DCSURF_SURFACE_EARLIEST_INUSE_HIGH_C; \
uint32_t DCSURF_SURFACE_CONTROL; \
+ uint32_t DCSURF_SURFACE_FLIP_INTERRUPT; \
uint32_t HUBPRET_CONTROL; \
uint32_t DCN_EXPANSION_MODE; \
uint32_t DCHUBP_REQ_SIZE_CONFIG; \
@@ -332,6 +334,7 @@
HUBP_SF(HUBPREQ0_DCSURF_SURFACE_CONTROL, SECONDARY_META_SURFACE_TMZ_C,
mask_sh),\
HUBP_SF(HUBPREQ0_DCSURF_SURFACE_CONTROL, SECONDARY_SURFACE_DCC_EN,
mask_sh),\
HUBP_SF(HUBPREQ0_DCSURF_SURFACE_CONTROL,
SECONDARY_SURFACE_DCC_IND_64B_BLK, mask_sh),\
+ HUBP_SF(HUBPREQ0_DCSURF_SURFACE_FLIP_INTERRUPT, SURFACE_FLIP_INT_MASK,
mask_sh),\
HUBP_SF(HUBPRET0_HUBPRET_CONTROL, DET_BUF_PLANE1_BASE_ADDRESS,
mask_sh),\
HUBP_SF(HUBPRET0_HUBPRET_CONTROL, CROSSBAR_SRC_CB_B, mask_sh),\
HUBP_SF(HUBPRET0_HUBPRET_CONTROL, CROSSBAR_SRC_CR_R, mask_sh),\
@@ -531,6 +534,7 @@
type PRIMARY_SURFACE_DCC_IND_64B_BLK;\
type SECONDARY_SURFACE_D
[PATCH AUTOSEL 5.11 44/61] drm/amd/display: Revert dram_clock_change_latency for DCN2.1
From: Sung Lee
[ Upstream commit b0075d114c33580f5c9fa9cee8e13d06db41471b ]
[WHY & HOW]
Using values provided by DF for latency may cause hangs in
multi display configurations. Revert change to previous value.
Tested-by: Daniel Wheeler
Signed-off-by: Sung Lee
Reviewed-by: Haonan Wang
Acked-by: Eryk Brol
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 072f8c880924..2d2541cab705 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -296,7 +296,7 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.num_banks = 8,
.num_chans = 4,
.vmm_page_size_bytes = 4096,
- .dram_clock_change_latency_us = 11.72,
+ .dram_clock_change_latency_us = 23.84,
.return_bus_width_bytes = 64,
.dispclk_dppclk_vco_speed_mhz = 3600,
.xfc_bus_transport_time_us = 4,
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.11 47/61] drm/amdgpu: fb BO should be ttm_bo_type_device
From: Nirmoy Das
[ Upstream commit 521f04f9e3ffc73ef96c776035f8a0a31b4cdd81 ]
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 0bf7d36c6686..5b716404eee1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -146,7 +146,7 @@ static int amdgpufb_create_pinned_object(struct
amdgpu_fbdev *rfbdev,
size = mode_cmd->pitches[0] * height;
aligned_size = ALIGN(size, PAGE_SIZE);
ret = amdgpu_gem_object_create(adev, aligned_size, 0, domain, flags,
- ttm_bo_type_kernel, NULL, &gobj);
+ ttm_bo_type_device, NULL, &gobj);
if (ret) {
pr_err("failed to allocate framebuffer (%d)\n", aligned_size);
return -ENOMEM;
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.11 46/61] drm/amdgpu/display: Use wm_table.entries for dcn301 calculate_wm
From: Zhan Liu
[ Upstream commit eda29602f1a8b2b32d8c8c354232d9d1ee1c064d ]
[Why]
For DGPU Navi, the wm_table.nv_entries are used. These entires are not
populated for DCN301 Vangogh APU, but instead wm_table.entries are.
[How]
Use DCN21 Renoir style wm calculations.
Signed-off-by: Leo Li
Signed-off-by: Zhan Liu
Reviewed-by: Dmytro Laktyushkin
Acked-by: Zhan Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../amd/display/dc/dcn301/dcn301_resource.c | 96 ++-
1 file changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
index 35f5bf08ae96..23bc208cbfa4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
@@ -1722,12 +1722,106 @@ static void dcn301_update_bw_bounding_box(struct dc
*dc, struct clk_bw_params *b
dml_init_instance(&dc->dml, &dcn3_01_soc, &dcn3_01_ip,
DML_PROJECT_DCN30);
}
+static void calculate_wm_set_for_vlevel(
+ int vlevel,
+ struct wm_range_table_entry *table_entry,
+ struct dcn_watermarks *wm_set,
+ struct display_mode_lib *dml,
+ display_e2e_pipe_params_st *pipes,
+ int pipe_cnt)
+{
+ double dram_clock_change_latency_cached =
dml->soc.dram_clock_change_latency_us;
+
+ ASSERT(vlevel < dml->soc.num_states);
+ /* only pipe 0 is read for voltage and dcf/soc clocks */
+ pipes[0].clks_cfg.voltage = vlevel;
+ pipes[0].clks_cfg.dcfclk_mhz = dml->soc.clock_limits[vlevel].dcfclk_mhz;
+ pipes[0].clks_cfg.socclk_mhz = dml->soc.clock_limits[vlevel].socclk_mhz;
+
+ dml->soc.dram_clock_change_latency_us = table_entry->pstate_latency_us;
+ dml->soc.sr_exit_time_us = table_entry->sr_exit_time_us;
+ dml->soc.sr_enter_plus_exit_time_us =
table_entry->sr_enter_plus_exit_time_us;
+
+ wm_set->urgent_ns = get_wm_urgent(dml, pipes, pipe_cnt) * 1000;
+ wm_set->cstate_pstate.cstate_enter_plus_exit_ns =
get_wm_stutter_enter_exit(dml, pipes, pipe_cnt) * 1000;
+ wm_set->cstate_pstate.cstate_exit_ns = get_wm_stutter_exit(dml, pipes,
pipe_cnt) * 1000;
+ wm_set->cstate_pstate.pstate_change_ns = get_wm_dram_clock_change(dml,
pipes, pipe_cnt) * 1000;
+ wm_set->pte_meta_urgent_ns = get_wm_memory_trip(dml, pipes, pipe_cnt) *
1000;
+ wm_set->frac_urg_bw_nom = get_fraction_of_urgent_bandwidth(dml, pipes,
pipe_cnt) * 1000;
+ wm_set->frac_urg_bw_flip =
get_fraction_of_urgent_bandwidth_imm_flip(dml, pipes, pipe_cnt) * 1000;
+ wm_set->urgent_latency_ns = get_urgent_latency(dml, pipes, pipe_cnt) *
1000;
+ dml->soc.dram_clock_change_latency_us =
dram_clock_change_latency_cached;
+
+}
+
+static void dcn301_calculate_wm_and_dlg(
+ struct dc *dc, struct dc_state *context,
+ display_e2e_pipe_params_st *pipes,
+ int pipe_cnt,
+ int vlevel_req)
+{
+ int i, pipe_idx;
+ int vlevel, vlevel_max;
+ struct wm_range_table_entry *table_entry;
+ struct clk_bw_params *bw_params = dc->clk_mgr->bw_params;
+
+ ASSERT(bw_params);
+
+ vlevel_max = bw_params->clk_table.num_entries - 1;
+
+ /* WM Set D */
+ table_entry = &bw_params->wm_table.entries[WM_D];
+ if (table_entry->wm_type == WM_TYPE_RETRAINING)
+ vlevel = 0;
+ else
+ vlevel = vlevel_max;
+ calculate_wm_set_for_vlevel(vlevel, table_entry,
&context->bw_ctx.bw.dcn.watermarks.d,
+ &context->bw_ctx.dml, pipes,
pipe_cnt);
+ /* WM Set C */
+ table_entry = &bw_params->wm_table.entries[WM_C];
+ vlevel = min(max(vlevel_req, 2), vlevel_max);
+ calculate_wm_set_for_vlevel(vlevel, table_entry,
&context->bw_ctx.bw.dcn.watermarks.c,
+ &context->bw_ctx.dml, pipes,
pipe_cnt);
+ /* WM Set B */
+ table_entry = &bw_params->wm_table.entries[WM_B];
+ vlevel = min(max(vlevel_req, 1), vlevel_max);
+ calculate_wm_set_for_vlevel(vlevel, table_entry,
&context->bw_ctx.bw.dcn.watermarks.b,
+ &context->bw_ctx.dml, pipes,
pipe_cnt);
+
+ /* WM Set A */
+ table_entry = &bw_params->wm_table.entries[WM_A];
+ vlevel = min(vlevel_req, vlevel_max);
+ calculate_wm_set_for_vlevel(vlevel, table_entry,
&context->bw_ctx.bw.dcn.watermarks.a,
+ &context->bw_ctx.dml, pipes,
pipe_cnt);
+
+ for (i = 0, pipe_idx = 0; i < dc->res_pool->pipe_count; i++) {
+ if (!context->res_ctx.pipe_ctx[i].stream)
+ continue;
+
+ pipes[pipe_idx].clks_cfg.dispclk_mhz =
get_dispclk_calculated(&context->bw_ctx.dml, pipes, pipe_cnt);
+ pipes[pip
[PATCH AUTOSEL 5.11 48/61] drm/radeon: fix AGP dependency
From: Christian König [ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index af6c6d214d91..f0c0ccdc8a10 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -232,6 +232,7 @@ source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU + depends on AGP || !AGP select FW_LOADER select DRM_KMS_HELPER select DRM_TTM -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.11 45/61] drm/amd/display: Enabled pipe harvesting in dcn30
From: Dillon Varone
[ Upstream commit d2c91285958a3e77db99c352c136af4243f8f529 ]
[Why & How]
Ported logic from dcn21 for reading in pipe fusing to dcn30.
Supported configurations are 1 and 6 pipes. Invalid fusing
will revert to 1 pipe being enabled.
Tested-by: Daniel Wheeler
Signed-off-by: Dillon Varone
Reviewed-by: Jun Lei
Acked-by: Eryk Brol
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dcn30/dcn30_resource.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
index 5e126fdf6ec1..7ec8936346b2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
@@ -2601,6 +2601,19 @@ static const struct resource_funcs dcn30_res_pool_funcs
= {
.patch_unknown_plane_state = dcn20_patch_unknown_plane_state,
};
+#define CTX ctx
+
+#define REG(reg_name) \
+ (DCN_BASE.instance[0].segment[mm ## reg_name ## _BASE_IDX] + mm ##
reg_name)
+
+static uint32_t read_pipe_fuses(struct dc_context *ctx)
+{
+ uint32_t value = REG_READ(CC_DC_PIPE_DIS);
+ /* Support for max 6 pipes */
+ value = value & 0x3f;
+ return value;
+}
+
static bool dcn30_resource_construct(
uint8_t num_virtual_links,
struct dc *dc,
@@ -2610,6 +2623,15 @@ static bool dcn30_resource_construct(
struct dc_context *ctx = dc->ctx;
struct irq_service_init_data init_data;
struct ddc_service_init_data ddc_init_data;
+ uint32_t pipe_fuses = read_pipe_fuses(ctx);
+ uint32_t num_pipes = 0;
+
+ if (!(pipe_fuses == 0 || pipe_fuses == 0x3e)) {
+ BREAK_TO_DEBUGGER();
+ dm_error("DC: Unexpected fuse recipe for navi2x !\n");
+ /* fault to single pipe */
+ pipe_fuses = 0x3e;
+ }
DC_FP_START();
@@ -2739,6 +2761,15 @@ static bool dcn30_resource_construct(
/* PP Lib and SMU interfaces */
init_soc_bounding_box(dc, pool);
+ num_pipes = dcn3_0_ip.max_num_dpp;
+
+ for (i = 0; i < dcn3_0_ip.max_num_dpp; i++)
+ if (pipe_fuses & 1 << i)
+ num_pipes--;
+
+ dcn3_0_ip.max_num_dpp = num_pipes;
+ dcn3_0_ip.max_num_otg = num_pipes;
+
dml_init_instance(&dc->dml, &dcn3_0_soc, &dcn3_0_ip, DML_PROJECT_DCN30);
/* IRQ */
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 40/54] drm/amd/display: Revert dram_clock_change_latency for DCN2.1
From: Sung Lee
[ Upstream commit b0075d114c33580f5c9fa9cee8e13d06db41471b ]
[WHY & HOW]
Using values provided by DF for latency may cause hangs in
multi display configurations. Revert change to previous value.
Tested-by: Daniel Wheeler
Signed-off-by: Sung Lee
Reviewed-by: Haonan Wang
Acked-by: Eryk Brol
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index 4e2dcf259428..b2b1e3664f28 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -295,7 +295,7 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.num_banks = 8,
.num_chans = 4,
.vmm_page_size_bytes = 4096,
- .dram_clock_change_latency_us = 11.72,
+ .dram_clock_change_latency_us = 23.84,
.return_bus_width_bytes = 64,
.dispclk_dppclk_vco_speed_mhz = 3600,
.xfc_bus_transport_time_us = 4,
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 42/54] drm/radeon: fix AGP dependency
From: Christian König [ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 16f73c102394..ca868271f4c4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -239,6 +239,7 @@ source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU + depends on AGP || !AGP select FW_LOADER select DRM_KMS_HELPER select DRM_TTM -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 41/54] drm/amdgpu: fb BO should be ttm_bo_type_device
From: Nirmoy Das
[ Upstream commit 521f04f9e3ffc73ef96c776035f8a0a31b4cdd81 ]
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index e2c2eb45a793..1ea8af48ae2f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -146,7 +146,7 @@ static int amdgpufb_create_pinned_object(struct
amdgpu_fbdev *rfbdev,
size = mode_cmd->pitches[0] * height;
aligned_size = ALIGN(size, PAGE_SIZE);
ret = amdgpu_gem_object_create(adev, aligned_size, 0, domain, flags,
- ttm_bo_type_kernel, NULL, &gobj);
+ ttm_bo_type_device, NULL, &gobj);
if (ret) {
pr_err("failed to allocate framebuffer (%d)\n", aligned_size);
return -ENOMEM;
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 28/37] drm/amd/display: Revert dram_clock_change_latency for DCN2.1
From: Sung Lee
[ Upstream commit b0075d114c33580f5c9fa9cee8e13d06db41471b ]
[WHY & HOW]
Using values provided by DF for latency may cause hangs in
multi display configurations. Revert change to previous value.
Tested-by: Daniel Wheeler
Signed-off-by: Sung Lee
Reviewed-by: Haonan Wang
Acked-by: Eryk Brol
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index f63cbbee7b33..11a4c4029a90 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -257,7 +257,7 @@ struct _vcs_dpi_soc_bounding_box_st dcn2_1_soc = {
.num_banks = 8,
.num_chans = 4,
.vmm_page_size_bytes = 4096,
- .dram_clock_change_latency_us = 11.72,
+ .dram_clock_change_latency_us = 23.84,
.return_bus_width_bytes = 64,
.dispclk_dppclk_vco_speed_mhz = 3600,
.xfc_bus_transport_time_us = 4,
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 30/37] drm/radeon: fix AGP dependency
From: Christian König [ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index e67c194c2aca..649f17dfcf45 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -206,6 +206,7 @@ source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU + depends on AGP || !AGP select FW_LOADER select DRM_KMS_HELPER select DRM_TTM -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 29/37] drm/amdgpu: fb BO should be ttm_bo_type_device
From: Nirmoy Das
[ Upstream commit 521f04f9e3ffc73ef96c776035f8a0a31b4cdd81 ]
FB BO should not be ttm_bo_type_kernel type and
amdgpufb_create_pinned_object() pins the FB BO anyway.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index eaa5e7b7c19d..fd94a17fb2c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -146,7 +146,7 @@ static int amdgpufb_create_pinned_object(struct
amdgpu_fbdev *rfbdev,
size = mode_cmd->pitches[0] * height;
aligned_size = ALIGN(size, PAGE_SIZE);
ret = amdgpu_gem_object_create(adev, aligned_size, 0, domain, flags,
- ttm_bo_type_kernel, NULL, &gobj);
+ ttm_bo_type_device, NULL, &gobj);
if (ret) {
pr_err("failed to allocate framebuffer (%d)\n", aligned_size);
return -ENOMEM;
--
2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 19/23] drm/radeon: fix AGP dependency
From: Christian König [ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index e44e567bd789..a050a9aa9a5e 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -192,6 +192,7 @@ source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU + depends on AGP || !AGP select FW_LOADER select DRM_KMS_HELPER select DRM_TTM -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 18/21] drm/radeon: fix AGP dependency
From: Christian König [ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 83cb2a88c204..595d0c96ba89 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -156,6 +156,7 @@ source "drivers/gpu/drm/arm/Kconfig" config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU + depends on AGP || !AGP select FW_LOADER select DRM_KMS_HELPER select DRM_TTM -- 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] clk: Add range accessors
Quoting Maxime Ripard (2021-03-03 00:45:27) > Hi Stephen, > > On Tue, Mar 02, 2021 at 03:18:58PM -0800, Stephen Boyd wrote: > > Quoting Maxime Ripard (2021-02-25 07:59:02) > > > Some devices might need to access the current available range of a clock > > > to discover their capabilities. Let's add those accessors. > > > > This needs more than two sentences to describe what's required. > > > > > > > > Signed-off-by: Maxime Ripard > > > --- > > > drivers/clk/clk.c | 30 ++ > > > include/linux/clk.h | 16 > > > 2 files changed, 46 insertions(+) > > > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > > > index 8c1d04db990d..b7307d4f090d 100644 > > > --- a/drivers/clk/clk.c > > > +++ b/drivers/clk/clk.c > > > @@ -2407,6 +2407,36 @@ int clk_set_max_rate(struct clk *clk, unsigned > > > long rate) > > > } > > > EXPORT_SYMBOL_GPL(clk_set_max_rate); > > > > > > +long clk_get_min_rate(struct clk *clk) > > > > I need to read the rest of the patches but I don't see the justification > > for this sort of API vs. having the consumer constrain the clk frequency > > that it wants. Is the code that's setting the min/max constraints not > > the same as the code that's calling this API? Would an OPP table better > > serve this so the device knows what frequencies are valid?s Please > > provide the use case/justification in the commit text. > > The patch that uses it is the patch 4 > > The issue I'm trying to solve is that all the RaspberryPi have a > configuration file for the firmware, and the firmware is in charge of > the clocks communicating through a mailbox interface. > > By default, one of the main clocks in the system can only reach 500MHz, > and that's the range reported by the firmware when queried. However, in > order to support display modes with a fairly high bandwidth such as 4k > at 60Hz, that clock needs to be raised to at least 550MHz, and the > firmware configuration has a special parameter for that one. Setting > that parameter will increase the range of the clock to have proper > boundaries for that display mode. > > If a user doesn't enable it and tries to use those display modes, the > display will be completely blank. > > There's no way to query the firmware configuration directly, so we can > instead query the range of the clock and see if the firmware enables us > to use those modes, warn the user and ignore the modes that wouldn't > work. That's what those accessors are here for How does the clk driver query the firmware but it can't be done directly by the drm driver? > > > Why two functions instead of one function to get both min and max? > > Since we have clk_set_min_rate and clk_set_max_rate, it made sense to me > to mirror that, but I'd be happy to change if you think otherwise > Does using clk_round_rate() work just as well? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vmwgfx leaking bo pins?
On 3/15/21 6:35 PM, Thomas Hellström (Intel) wrote: On 3/15/21 9:38 PM, Daniel Vetter wrote: On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin wrote: On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote: On 3/12/21 12:02 AM, Zack Rusin wrote: On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) wrote: Hi, Zack On 3/11/21 10:07 PM, Zack Rusin wrote: On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) wrote: Hi, I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework? Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in drm-misc-next in the drm-misc tree for a while but hasn’t been merged for 5.12. z Hmm, yes but doesn't that fix trip the ttm_bo_unpin() dma_resv_assert_held(bo->base.resv)? No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be working fine. With CONFIG_PROVE_LOCKING=y I see this: [ 7.117145] [drm] FIFO at 0xfe00 size is 8192 kiB [ 7.117284] [drm] VRAM at 0xe800 size is 131072 kiB [ 7.117291] INFO: trying to register non-static key. [ 7.117295] the code is fine but needs lockdep annotation. [ 7.117298] turning off the locking correctness validator Which will probably mask that dma_resv_assert_held(bo->base.resv) Ah, yes, you're right. After fixing that I do see the dma_resv_assert_held triggered. Technically trivially fixable with ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but it's a little ugly that some places e.g. vmw_bo_unreference will require ttm_bo_reserve/ttm_bo_unreserve around ttm_bo_unpin but some won't e.g. vmw_mob_destroy won't because its lock is held by ttm_bo_delayed_delete without a very clear indication within the function which is which. It looks like, like Daniel hints below, for the mob pagetable bos since they are pinned and hence not on a LRU list, the parent bo is holding the only reference, which is utilized in vmw_mob_unbind() to make sure the tryreserve always succeeds. (unpin could be called in vmw_mob_unbind for the pagetable bo just after fencing if necessary), That's a little tricky because then we'd have to pin on bind, otherwise after moves, which unbind, we wouldn't be pinned anymore. Plus bind would have to check if the bo is already pinned (i.e. it's the first time bind is called on it) since we pin on creation. Or just stop pinning on creation and do it explicitly in bind/unbind. In general we probably should make pinning explicit in vmwgfx like in the other drivers because, as is, we sometimes have to treat pin_count as a boolean (e.g. in vmw_bo_pin_reserved) because often times the object has already been pinned during creation. This will break if we'll have drm utilities use pin/unpin. That's a problem of our own making though, the issue of whether or not the bo has already been reserved is a little more muddy because having multiple nested pin/unpin sites (as long as they're consistent in their matching pin/unpin usage) isn't a problem, but having nested reserved calls is a problem. Although this might be a case of an old man yelling at the sun because I'm too lazy to remember whether or not each callback is already called reserved and instead should just add dma_resv_assert_held(bo->resv) in more places to clarify which is which or like you mention use tryreserve everywhere. But it's constructs like that, that really makes me think we shouldn't need to reserve to unpin. Yea, that would be pretty convenient. z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
On Tue, 2021-03-16 at 16:38 -0600, Rob Herring wrote:
> On Wed, Mar 10, 2021 at 05:55:31PM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp Control and Status Registers
> > module.
> >
> > Signed-off-by: Liu Ying
> > ---
> > v4->v5:
> > * Newly introduced in v5. (Rob)
> >
> > .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 202
> > +
> > 1 file changed, 202 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> > b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> > new file mode 100644
> > index ..0e724d9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> > @@ -0,0 +1,202 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fmfd%2Ffsl%2Cimx8qxp-csr.yaml%23&data=04%7C01%7Cvictor.liu%40nxp.com%7C8ee75a0dde484a3d221608d8e8cc47f6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637515311382184508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fkym85OLtd5cA%2FdwJkXUbiR0EwkZX4yP4INsAaCywUo%3D&reserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cvictor.liu%40nxp.com%7C8ee75a0dde484a3d221608d8e8cc47f6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637515311382184508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3n2mTxsUNF480D9xQQuXj7U0noiLCUBT3zneyWPr6ck%3D&reserved=0
> > +
> > +title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings
> > +
> > +maintainers:
> > + - Liu Ying
> > +
> > +description: |
> > + As a system controller, the Freescale i.MX8qm/qxp Control and Status
> > + Registers(CSR) module represents a set of miscellaneous registers of a
> > + specific subsystem. It may provide control and/or status report
> > interfaces
> > + to a mix of standalone hardware devices within that subsystem. One
> > typical
> > + use-case is for some other nodes to acquire a reference to the syscon
> > node
> > + by phandle, and the other typical use-case is that the operating system
> > + should consider all subnodes of the CSR module as separate child devices.
> > +
> > +select:
> > + properties:
> > +compatible:
> > + contains:
> > +enum:
> > + - fsl,imx8qxp-mipi-lvds-csr
> > + - fsl,imx8qm-lvds-csr
>
> You shouldn't need this, we filter out 'syscon' and 'simple-mfd'.
Will drop this in next version. Thanks.
Liu Ying
>
> > + required:
> > +- compatible
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^syscon@[0-9a-f]+$"
> > +
> > + compatible:
> > +items:
> > + - enum:
> > + - fsl,imx8qxp-mipi-lvds-csr
> > + - fsl,imx8qm-lvds-csr
> > + - const: syscon
> > + - const: simple-mfd
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +maxItems: 1
> > +
> > + clock-names:
> > +const: ipg
> > +
> > +patternProperties:
> > + "^(ldb|phy|pxl2dpi)$":
> > +type: object
> > +description: The possible child devices of the CSR module.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > +
> > +allOf:
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: fsl,imx8qxp-mipi-lvds-csr
> > +then:
> > + required:
> > +- pxl2dpi
> > +- ldb
> > +
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +const: fsl,imx8qm-lvds-csr
> > +then:
> > + required:
> > +- phy
> > +- ldb
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +mipi_lvds_0_csr: syscon@56221000 {
> > +compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd";
> > +reg = <0x56221000 0x1000>;
> > +clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
> > +clock-names = "ipg";
> > +
> > +mipi_lvds_0_pxl2dpi: pxl2dpi {
> > +compatible = "fsl,imx8qxp-pxl2dpi";
> > +fsl,sc-resource = ;
> > +power-domains = <&pd IMX_SC_R_MIPI_0>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <0>;
> > +
> > +mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
> > +reg = <0>;
> > +remote-endpoint =
> > <&dc0_pixel_link0_mipi_lvds_0_pxl2d
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function
'vop_plane_atomic_update':
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:882:26: warning: unused variable
'old_state' [-Wunused-variable]
882 | struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(state,
| ^
Introduced by commit
977697e20b3d ("drm/atomic: Pass the full state to planes atomic disable and
update")
--
Cheers,
Stephen Rothwell
pgp54544F9WAW.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Remove need for reiterating the compatibles
After spending a non-negligible time trying to figure out why
dpu_kms_init() would dereference a NULL dpu_kms->pdev, it turns out that
in addition to adding the new compatible to the msm_drv of_match_table
one also need to teach add_display_components() to register the child
nodes - which includes the DPU platform_device.
Replace the open coded test for compatibles with a check against the
match data of the mdss device to save others this trouble in the future.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/msm_drv.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 94525ac76d4e..0f6e186a609d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1173,10 +1173,11 @@ static int compare_name_mdp(struct device *dev, void
*data)
return (strstr(dev_name(dev), "mdp") != NULL);
}
-static int add_display_components(struct device *dev,
+static int add_display_components(struct platform_device *pdev,
struct component_match **matchptr)
{
struct device *mdp_dev;
+ struct device *dev = &pdev->dev;
int ret;
/*
@@ -1185,9 +1186,9 @@ static int add_display_components(struct device *dev,
* Populate the children devices, find the MDP5/DPU node, and then add
* the interfaces to our components list.
*/
- if (of_device_is_compatible(dev->of_node, "qcom,mdss") ||
- of_device_is_compatible(dev->of_node, "qcom,sdm845-mdss") ||
- of_device_is_compatible(dev->of_node, "qcom,sc7180-mdss")) {
+ switch (get_mdp_ver(pdev)) {
+ case KMS_MDP5:
+ case KMS_DPU:
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
DRM_DEV_ERROR(dev, "failed to populate children
devices\n");
@@ -1206,9 +1207,11 @@ static int add_display_components(struct device *dev,
/* add the MDP component itself */
drm_of_component_match_add(dev, matchptr, compare_of,
mdp_dev->of_node);
- } else {
+ break;
+ case KMS_MDP4:
/* MDP4 */
mdp_dev = dev;
+ break;
}
ret = add_components_mdp(mdp_dev, matchptr);
@@ -1273,7 +1276,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
int ret;
if (get_mdp_ver(pdev)) {
- ret = add_display_components(&pdev->dev, &match);
+ ret = add_display_components(pdev, &match);
if (ret)
return ret;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: xlnx: call pm_runtime_get_sync before setting pixel clock
Hi Laurent, On 3/17/21 4:32 AM, Laurent Pinchart wrote: Hi Quanyang, Thank you for the patch. On Wed, Mar 10, 2021 at 12:59:45PM +0800, quanyang.w...@windriver.com wrote: From: Quanyang Wang The Runtime PM subsystem will force the device "fd4a.zynqmp-display" to enter suspend state while booting if the following conditions are met: - the usage counter is zero (pm_runtime_get_sync hasn't been called yet) - no 'active' children (no zynqmp-dp-snd-xx node under dpsub node) - no other device in the same power domain (dpdma node has no "power-domains = <&zynqmp_firmware PD_DP>" property) So there is a scenario as below: 1) DP device enters suspend state <- call zynqmp_gpd_power_off 2) zynqmp_disp_crtc_setup_clock <- configurate register VPLL_FRAC_CFG 3) pm_runtime_get_sync <- call zynqmp_gpd_power_on and clear previous VPLL_FRAC_CFG configuration 4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG configuration is corrupted From above, we can see that pm_runtime_get_sync may clear register VPLL_FRAC_CFG configuration and result the failure of clk enabling. Putting pm_runtime_get_sync at the very beginning of the function zynqmp_disp_crtc_atomic_enable can resolve this issue. Isn't this an issue in the firmware though, which shouldn't clear the previous VPLLF_FRAC_CFG ? Thank you for your review. I used to look into the atf and PWU code and it seems (I didn't add debug code to PMU to make sure if PMU really does this, I only in kernel call zynqmp_pm_get_pll_frac_data to make sure that the value in data field of VPLL_FRAC_CFG register is changed from 0x4000 to 0x0 after run pm_runtime_get_sync) that PMU intends to reset VPLL when there is an Off and On in DP Powerdomain. Linux ATF PWU zynqmp_gpd_power_on ->zynqmp_pm_set_requirement -->send PM_SET_REQUIREMENT to ATF ==>ATF send ipi to PWU ==> PmSetRequirement ->PmRequirementUpdate -->PmUpdateSlave(masterReq->slave) --->PmSlaveChangeState >PmSlaveChangeState ->PmSlaveClearAfterState -->PmClockRelease --->PmClockReleaseInt(&ch->clock->base) >clk->class->release(clk) ->PmPllBypassAndReset //Here reset the VPLL then VPLL_FRAC_CFG is cleared. Signed-off-by: Quanyang Wang Nonetheless, this change looks good to me, I actually had the same patch in my tree while investigation issues related to the clock rate, so Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart I was hoping it would solve the issue I'm experiencing with the DP clock, but that's not the case :-( In a nutshell, when the DP is first started, the clock frequency is incorrect. The following quick & dirty patch fixes the problem: diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c index 74ac0a064eb5..fdbe1b0640aa 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c @@ -1439,6 +1439,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc, pm_runtime_get_sync(disp->dev); + ret = clk_prepare_enable(disp->pclk); + if (!ret) + clk_disable_unprepare(disp->pclk); + zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode); ret = clk_prepare_enable(disp->pclk); The problem doesn't seem to be in the kernel, but on the TF-A or PMU firmware side. Have you experienced this by any chance ? Yes, I bumped into the same issue and I used to make a patch (Patch 1) as below. I didn't send it to mainline because it seems not to be a driver issue. The mode of VPLL is not set correctly because: 1) VPLL is enabled before linux 2) linux calling pm_clock_set_pll_mode can't really set register because in ATF it only store the mode value to a structure and wait a clk-enable request to do the register-set operation. 3) linux call clk_enable will not send a clk-enable request since it checks that the VPLL is already hardware-enabled because of 1). So the firmware should disable VPLL when it exits and also in linux zynqmp clk driver there should be a check list to reset some clks to a predefined state. By the way, there is a tiny patch (Patch 2) to fix the black screen issue in DP. I
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_sprite.c
between commit:
92f1d09ca4ed ("drm: Switch to %p4cc format modifier")
from the drm tree and commit:
46d12f911821 ("drm/i915: migrate skl planes code new file (v5)")
from the drm-intel tree.
I fixed it up (I used the latter version of the file and applied the
following patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Wed, 17 Mar 2021 14:05:42 +1100
Subject: [PATCH] merge fix for "drm: Switch to %p4cc format modifier"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 1f335cb09149..45ceff436bf7 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1120,7 +1120,6 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int rotation = plane_state->hw.rotation;
- struct drm_format_name_buf format_name;
if (!fb)
return 0;
@@ -1168,9 +1167,8 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_XVYU12_16161616:
case DRM_FORMAT_XVYU16161616:
drm_dbg_kms(&dev_priv->drm,
- "Unsupported pixel format %s for 90/270!\n",
- drm_get_format_name(fb->format->format,
- &format_name));
+ "Unsupported pixel format %p4cc for
90/270!\n",
+ &fb->format->format);
return -EINVAL;
default:
break;
--
2.30.0
--
Cheers,
Stephen Rothwell
pgpz86G3Fd7FI.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 00/14] Add some DRM bridge drivers support for i.MX8qm/qxp SoCs
Hi,
This is the v6 series to add some DRM bridge drivers support
for i.MX8qm/qxp SoCs.
The bridges may chain one by one to form display pipes to support
LVDS displays. The relevant display controller is DPU embedded in
i.MX8qm/qxp SoCs.
The DPU KMS driver can be found at:
https://www.spinics.net/lists/arm-kernel/msg878542.html
This series supports the following display pipes:
1) i.MX8qxp:
prefetch eng -> DPU -> pixel combiner -> pixel link ->
pixel link to DPI(PXL2DPI) -> LVDS display bridge(LDB)
2) i.MX8qm:
prefetch eng -> DPU -> pixel combiner -> pixel link -> LVDS display bridge(LDB)
This series dropped the patch 'phy: Add LVDS configuration options', as
suggested by Robert Foss, because it has already been sent with the following
series to add Mixel combo PHY found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html
So, this version depends on that series.
Patch 1/14 and 2/14 add bus formats used by pixel combiner.
Patch 7/14 adds dt-binding for Control and Status Registers module(a syscon
used by PXL2DPI and LDB), which references the PXL2DPI and LDB schemas.
Patch 10/14 adds a helper for LDB bridge drivers.
Patch 3/14 ~ 6/14, 8/14, 9/14 and 11/14 ~ 13/14 add drm bridge drivers and
dt-bindings support for the bridges.
Patch 14/14 updates MAINTAINERS.
I've tested this series with a koe,tx26d202vm0bwa dual link LVDS panel and
a LVDS to HDMI bridge(with a downstream drm bridge driver).
Welcome comments, thanks.
v5->v6:
* Fix data organizations in documentation(patch 2/14) for
MEDIA_BUS_FMT_RGB{666,888}_1X30-CPADLO. (Laurent)
* Add Laurent's R-b tags on patch 1/14 and 2/14.
* Drop 'select' schema from the CSR dt-binding documentation(patch 7/14). (Rob)
* Add Rob's R-b tag on patch 8/14.
v4->v5:
* Drop the patch 'phy: Add LVDS configuration options'. (Robert)
* Add Robert's R-b tags on patch 1/14, 2/14, 4/14 and 6/14.
* Drop the 'PC_BUF_PARA_REG' register definition from the pixel combiner bridge
driver(patch 4/14). (Robert)
* Make a comment occupy a line in the pixel link bridge driver(patch 6/14).
(Robert)
* Introduce a new patch(patch 7/14) to add dt-binding for Control and Status
Registers module. (Rob)
* Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
driver and i.MX8qm LDB bridge driver, instead of a module. Correspondingly,
rename 'imx8{qm, qxp}-ldb.c' to 'imx8{qm, qxp}-ldb-drv.c'. (Robert)
* Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
(Robert)
* s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
v3->v4:
* Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
the PXL2DPI instance instead of using alias ID. (Rob)
* Add Rob's R-b tag on patch 11/14.
v2->v3:
* Drop 'fsl,syscon' DT properties from fsl,imx8qxp-ldb.yaml and
fsl,imx8qxp-pxl2dpi.yaml. (Rob)
* Mention the CSR module controls LDB and PXL2DPI in fsl,imx8qxp-ldb.yaml and
fsl,imx8qxp-pxl2dpi.yaml.
* Call syscon_node_to_regmap() to get regmaps from LDB bridge helper driver
and PXL2DPI bridger driver instead of syscon_regmap_lookup_by_phandle().
* Drop two macros from pixel link bridge driver which help define functions
and define them directly.
* Properly disable all pixel link controls to POR value by calling
imx8qxp_pixel_link_disable_all_controls() from
imx8qxp_pixel_link_bridge_probe().
* Add Rob's R-b tags on patch 4/14 and 6/14.
v1->v2:
* Rebase the series upon the latest drm-misc-next branch(5.11-rc2 based).
* Use graph schema in the dt-bindings of the bridges. (Laurent)
* Require all four pixel link output ports in fsl,imx8qxp-pixel-link.yaml.
(Laurent)
* Side note i.MX8qm/qxp LDB official name 'pixel mapper' in
fsl,imx8qxp-ldb.yaml.
(Laurent)
* Mention pixel link is accessed via SCU firmware in
fsl,imx8qxp-pixel-link.yaml.
(Rob)
* Use enum instead of oneOf + const for the reg property of pixel combiner
channels in fsl,imx8qxp-pixel-combiner.yaml. (Rob)
* Rewrite the function to find the next bridge in pixel link bridge driver
by properly using OF APIs and dropping unnecessary DT validation. (Rob)
* Drop unnecessary port availability check in i.MX8qxp pixel link to DPI
bridge driver.
* Drop unnecessary DT validation from i.MX8qxp LDB bridge driver.
* Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
get the input remote endpoint in imx8qxp_ldb_set_di_id() of i.MX8qxp LDB
bridge driver.
* Avoid using companion_port OF node after putting it in
imx8qxp_ldb_parse_dt_companion() of i.MX8qxp LDB bridge driver.
* Drop unnecessary check for maximum available LDB channels from
i.MX8qm LDB bridge driver.
* Mention i.MX8qm/qxp LDB official name 'pixel mapper' in i.MX8qm/qxp LDB
bridge drivers and Kconfig help messages.
Liu Ying (14):
media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
[PATCH v6 01/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner. The RGB pixels with padding low per component are transmitted on a 30-bit input bus(10-bit per component) from a display controller or a 36-bit output bus(12-bit per component) to a pixel link. Reviewed-by: Robert Foss Reviewed-by: Laurent Pinchart Signed-off-by: Liu Ying --- v5->v6: * Add Laurent's R-b tag. v4->v5: * Add Robert's R-b tag. v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. include/uapi/linux/media-bus-format.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 0dfc11e..ec3323d 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 0x101e */ +/* RGB - next is 0x1022 */ #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 @@ -59,9 +59,13 @@ #define MEDIA_BUS_FMT_RGB888_3X8_DELTA 0x101d #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 +#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO 0x101e +#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO 0x101f #define MEDIA_BUS_FMT_ARGB_1X320x100d #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f #define MEDIA_BUS_FMT_RGB101010_1X30 0x1018 +#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO 0x1020 +#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO 0x1021 #define MEDIA_BUS_FMT_RGB121212_1X36 0x1019 #define MEDIA_BUS_FMT_RGB161616_1X48 0x101a -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 02/14] media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
pixel combiner. The RGB pixels with padding low per component are
transmitted on a 30-bit input bus(10-bit per component) from a display
controller or a 36-bit output bus(12-bit per component) to a pixel link.
Reviewed-by: Robert Foss
Reviewed-by: Laurent Pinchart
Signed-off-by: Liu Ying
---
Robert, I keep your R-b tag from v5. Let me know if you want me to drop it, as
v6 contains a fix.
v5->v6:
* Fix data organizations of MEDIA_BUS_FMT_RGB{666,888}_1X30-CPADLO. (Laurent)
* Add Laurent's R-b tag.
v4->v5:
* Add Robert's R-b tag.
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
.../userspace-api/media/v4l/subdev-formats.rst | 156 +
1 file changed, 156 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst
b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index 7f16cbe..1402e18 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -1488,6 +1488,80 @@ The following tables list existing packed RGB formats.
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB666-1X30-CPADLO:
+
+ - MEDIA_BUS_FMT_RGB666_1X30-CPADLO
+ - 0x101e
+ -
+ -
+ -
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+* .. _MEDIA-BUS-FMT-RGB888-1X30-CPADLO:
+
+ - MEDIA_BUS_FMT_RGB888_1X30-CPADLO
+ - 0x101f
+ -
+ -
+ -
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - 0
+ - 0
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - 0
+ - 0
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - 0
+ - 0
* .. _MEDIA-BUS-FMT-ARGB888-1X32:
- MEDIA_BUS_FMT_ARGB888_1X32
@@ -1665,6 +1739,88 @@ The following table list existing packed 36bit wide RGB
formats.
- 2
- 1
- 0
+* .. _MEDIA-BUS-FMT-RGB666-1X36-CPADLO:
+
+ - MEDIA_BUS_FMT_RGB666_1X36_CPADLO
+ - 0x1020
+ -
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - 0
+ - 0
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - 0
+ - 0
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - 0
+ - 0
+* .. _MEDIA-BUS-FMT-RGB888-1X36-CPADLO:
+
+ - MEDIA_BUS_FMT_RGB888_1X36_CPADLO
+ - 0x1021
+ -
+ - r\ :sub:`7`
+ - r\ :sub:`6`
+ - r\ :sub:`5`
+ - r\ :sub:`4`
+ - r\ :sub:`3`
+ - r\ :sub:`2`
+ - r\ :sub:`1`
+ - r\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - g\ :sub:`7`
+ - g\ :sub:`6`
+ - g\ :sub:`5`
+ - g\ :sub:`4`
+ - g\ :sub:`3`
+ - g\ :sub:`2`
+ - g\ :sub:`1`
+ - g\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
+ - b\ :sub:`7`
+ - b\ :sub:`6`
+ - b\ :sub:`5`
+ - b\ :sub:`4`
+ - b\ :sub:`3`
+ - b\ :sub:`2`
+ - b\ :sub:`1`
+ - b\ :sub:`0`
+ - 0
+ - 0
+ - 0
+ - 0
* .. _MEDIA-BUS-FMT-RGB121212-1X36:
- MEDIA_BUS_FMT_RGB121212_1X36
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
This patch adds bindings for i.MX8qm/qxp pixel combiner.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* Add Rob's R-b tag.
v1->v2:
* Use graph schema. (Laurent)
* Use enum instead of oneOf + const for the reg property of pixel combiner
channels. (Rob)
.../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144 +
1 file changed, 144 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
new file mode 100644
index ..50bae21
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Pixel Combiner
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
+ single display controller and manipulates the two streams to support a number
+ of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as
+ either one screen, two screens, or virtual screens. The pixel combiner is
+ also responsible for generating some of the control signals for the pixel
link
+ output channel.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qm-pixel-combiner
+ - fsl,imx8qxp-pixel-combiner
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: apb
+
+ power-domains:
+maxItems: 1
+
+patternProperties:
+ "^channel@[0-1]$":
+type: object
+description: Represents a display stream of pixel combiner.
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ reg:
+description: The display stream index.
+enum: [ 0, 1 ]
+
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input endpoint of the display stream.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output endpoint of the display stream.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+pixel-combiner@5602 {
+compatible = "fsl,imx8qxp-pixel-combiner";
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x5602 0x1>;
+clocks = <&dc0_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
+clock-names = "apb";
+power-domains = <&pd IMX_SC_R_DC_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
+remote-endpoint = <&dc0_dpu_disp0_dc0_pixel_combiner_ch0>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
+remote-endpoint =
<&dc0_pixel_link0_dc0_pixel_combiner_ch0>;
+};
+};
+};
+
+channel@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
+remote-endpoint = <&dc0_dpu_disp1_dc0_pixel_combiner_ch1>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
+remote-endpoint =
<&dc0_pixel_link1_dc0_pixel_combiner_ch1>;
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 04/14] drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support
This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two screens, or virtual screens. The pixel
combiner is also responsible for generating some of the control signals
for the pixel link output channel. For now, the driver only supports
the bypass mode.
Reviewed-by: Robert Foss
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* Drop the 'PC_BUF_PARA_REG' register definition. (Robert)
* Add Robert's R-b tag.
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
drivers/gpu/drm/bridge/Kconfig | 2 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
drivers/gpu/drm/bridge/imx/Makefile| 1 +
.../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 448 +
5 files changed, 460 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6c..84944e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -256,6 +256,8 @@ source "drivers/gpu/drm/bridge/adv7511/Kconfig"
source "drivers/gpu/drm/bridge/cadence/Kconfig"
+source "drivers/gpu/drm/bridge/imx/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc..bc80cae 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -27,4 +27,5 @@ obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
obj-y += analogix/
obj-y += cadence/
+obj-y += imx/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
new file mode 100644
index ..f1c91b6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -0,0 +1,8 @@
+config DRM_IMX8QXP_PIXEL_COMBINER
+ tristate "Freescale i.MX8QM/QXP pixel combiner"
+ depends on OF
+ depends on COMMON_CLK
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable pixel combiner found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
new file mode 100644
index ..7d7c8d6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
new file mode 100644
index ..0b9403a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -0,0 +1,448 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define PC_CTRL_REG0x0
+#define PC_COMBINE_ENABLE BIT(0)
+#define PC_DISP_BYPASS(n) BIT(1 + 21 * (n))
+#define PC_DISP_HSYNC_POLARITY(n) BIT(2 + 11 * (n))
+#define PC_DISP_HSYNC_POLARITY_POS(n) DISP_HSYNC_POLARITY(n)
+#define PC_DISP_VSYNC_POLARITY(n) BIT(3 + 11 * (n))
+#define PC_DISP_VSYNC_POLARITY_POS(n) DISP_VSYNC_POLARITY(n)
+#define PC_DISP_DVALID_POLARITY(n)BIT(4 + 11 * (n))
+#define PC_DISP_DVALID_POLARITY_POS(n)DISP_DVALID_POLARITY(n)
+#define PC_VSYNC_MASK_ENABLE BIT(5)
+#define PC_SKIP_MODE BIT(6)
+#define PC_SKIP_NUMBER_MASK GENMASK(12, 7)
+#define PC_SKIP_NUMBER(n) FIELD_PREP(PC_SKIP_NUMBER_MASK, (n))
+#define PC_DISP0_PIX_DATA_FORMAT_MASK GENMASK(18, 16)
+#define PC_DISP0_PIX_DATA_FORMAT(fmt) \
+ FIELD_PREP(PC_DISP0_PIX_DATA_FORMAT_MASK, (fmt))
+#define PC_DISP1_PIX_DATA_FORMAT_MASK GENMASK(21, 19)
+#define PC_DISP1_PIX_DATA_FORMAT(fmt) \
+ FIELD_PREP(PC_DISP1_PIX_DATA_FORMAT_MASK, (fmt))
+
+#define PC_SW_RESET_REG0x20
+#define PC_SW_RESET_N BIT(0)
+#define PC_DISP_SW_RESET_N(n) BIT(1 + (n))
+#define PC_FULL_RESET_N (PC_SW_RESET_N |\
+PC_DISP_SW_RESET_N(0) |\
+PC_DISP_SW_RESET_N(1))
+
+#define PC_REG_SET 0x4
+#define PC_REG_CLR 0x8
+
+#define DRIVER_NAME"imx8qxp-pixel-combiner"
+
+enum imx8qxp_pc_pix_data_format {
+ RGB,
+ YUV444,
+ YUV422,
+ SPLIT_RGB,
+};
+
+struct imx8qxp_pc_channel {
+ struct
[PATCH v6 05/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding
This patch adds bindings for i.MX8qm/qxp display pixel link.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* No change.
v2->v3:
* Add Rob's R-b tag.
v1->v2:
* Use graph schema. (Laurent)
* Require all four pixel link output ports. (Laurent)
* Mention pixel link is accessed via SCU firmware. (Rob)
.../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106 +
1 file changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
new file mode 100644
index ..3af67cc
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-link.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Pixel Link
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
+ asynchronous linkage between pixel sources(display controller or
+ camera module) and pixel consumers(imaging or displays).
+ It consists of two distinct functions, a pixel transfer function and a
+ control interface. Multiple pixel channels can exist per one control
channel.
+ This binding documentation is only for pixel links whose pixel sources are
+ display controllers.
+
+ The i.MX8qm/qxp Display Pixel Link is accessed via System Controller
Unit(SCU)
+ firmware.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qm-dc-pixel-link
+ - fsl,imx8qxp-dc-pixel-link
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: The pixel link input port node from upstream video source.
+
+patternProperties:
+ "^port@[1-4]$":
+$ref: /schemas/graph.yaml#/properties/port
+description: The pixel link output port node to downstream bridge.
+
+required:
+ - port@0
+ - port@1
+ - port@2
+ - port@3
+ - port@4
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+dc0-pixel-link0 {
+compatible = "fsl,imx8qxp-dc-pixel-link";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* from dc0 pixel combiner channel0 */
+port@0 {
+reg = <0>;
+
+dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
+remote-endpoint =
<&dc0_pixel_combiner_ch0_dc0_pixel_link0>;
+};
+};
+
+/* to PXL2DPIs in MIPI/LVDS combo subsystems */
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&mipi_lvds_0_pxl2dpi_dc0_pixel_link0>;
+};
+
+dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&mipi_lvds_1_pxl2dpi_dc0_pixel_link0>;
+};
+};
+
+/* unused */
+port@2 {
+reg = <2>;
+};
+
+/* unused */
+port@3 {
+reg = <3>;
+};
+
+/* to imaging subsystem */
+port@4 {
+reg = <4>;
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 06/14] drm/bridge: imx: Add i.MX8qm/qxp display pixel link support
This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays). It consists of two distinct
functions, a pixel transfer function and a control interface.
Reviewed-by: Robert Foss
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* Make a comment occupy a line. (Robert)
* Add Robert's R-b tag.
v3->v4:
* No change.
v2->v3:
* Drop two macros which help define functions and define them directly.
* Properly disable all pixel link controls to POR value by calling
imx8qxp_pixel_link_disable_all_controls() from
imx8qxp_pixel_link_bridge_probe().
v1->v2:
* Rewrite the function to find the next bridge by properly using OF APIs
and dropping unnecessary DT validation. (Rob)
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 427
3 files changed, 436 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index f1c91b6..4d1f027 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,3 +6,11 @@ config DRM_IMX8QXP_PIXEL_COMBINER
help
Choose this to enable pixel combiner found in
Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK
+ tristate "Freescale i.MX8QM/QXP display pixel link"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable display pixel link found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 7d7c8d6..c15469f 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
new file mode 100644
index ..a549624
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -0,0 +1,427 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#define DRIVER_NAME"imx8qxp-display-pixel-link"
+#define PL_MAX_MST_ADDR3
+#define PL_MAX_NEXT_BRIDGES2
+
+struct imx8qxp_pixel_link {
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+ struct device *dev;
+ struct imx_sc_ipc *ipc_handle;
+ int id;
+ int stream_id;
+ int dc_id;
+ u32 sink_rsc;
+ u32 mst_addr;
+ u8 mst_addr_ctrl;
+ u8 mst_en_ctrl;
+ u8 mst_vld_ctrl;
+ u8 sync_ctrl;
+};
+
+static void imx8qxp_pixel_link_enable_mst_en(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_en_ctrl, true);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to enable DC%d stream%d pixel link mst_en:
%d\n",
+ pl->dc_id, pl->stream_id, ret);
+}
+
+static void imx8qxp_pixel_link_enable_mst_vld(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_vld_ctrl, true);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to enable DC%d stream%d pixel link mst_vld: %d\n",
+ pl->dc_id, pl->stream_id, ret);
+}
+
+static void imx8qxp_pixel_link_enable_sync(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->sync_ctrl, true);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to enable DC%d stream%d pixel link sync: %d\n",
+ pl->dc_id, pl->stream_id, ret);
+}
+
+static int imx8qxp_pixel_link_disable_mst_en(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_en_ctrl, false);
+ if (ret)
+ DRM_DEV_ERROR(pl->dev,
+ "failed to disable DC%d stream%d pixel link mst_en: %d\n",
+ pl->dc_id, pl->stream_id, ret);
+
+ return ret;
+}
+
+static int imx8qxp_pixel_link_disable_mst_vld(struct imx8qxp_pixel_link *pl)
+{
+ int ret;
+
+ ret = imx_sc_mi
[PATCH v6 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding
This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.
Signed-off-by: Liu Ying
---
v5->v6:
* Drop 'select' schema. (Rob)
v4->v5:
* Newly introduced in v5. (Rob)
.../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml | 192 +
1 file changed, 192 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
new file mode 100644
index ..f095771
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
@@ -0,0 +1,192 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/fsl,imx8qxp-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings
+
+maintainers:
+ - Liu Ying
+
+description: |
+ As a system controller, the Freescale i.MX8qm/qxp Control and Status
+ Registers(CSR) module represents a set of miscellaneous registers of a
+ specific subsystem. It may provide control and/or status report interfaces
+ to a mix of standalone hardware devices within that subsystem. One typical
+ use-case is for some other nodes to acquire a reference to the syscon node
+ by phandle, and the other typical use-case is that the operating system
+ should consider all subnodes of the CSR module as separate child devices.
+
+properties:
+ $nodename:
+pattern: "^syscon@[0-9a-f]+$"
+
+ compatible:
+items:
+ - enum:
+ - fsl,imx8qxp-mipi-lvds-csr
+ - fsl,imx8qm-lvds-csr
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: ipg
+
+patternProperties:
+ "^(ldb|phy|pxl2dpi)$":
+type: object
+description: The possible child devices of the CSR module.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8qxp-mipi-lvds-csr
+then:
+ required:
+- pxl2dpi
+- ldb
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8qm-lvds-csr
+then:
+ required:
+- phy
+- ldb
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+mipi_lvds_0_csr: syscon@56221000 {
+compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd";
+reg = <0x56221000 0x1000>;
+clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
+clock-names = "ipg";
+
+mipi_lvds_0_pxl2dpi: pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+fsl,sc-resource = ;
+power-domains = <&pd IMX_SC_R_MIPI_0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint =
<&dc0_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 {
+reg = <1>;
+remote-endpoint =
<&dc0_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint =
<&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint =
<&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
+
+mipi_lvds_0_ldb: ldb {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx8qxp-ldb";
+clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+clock-names = "pixel", "bypass";
+power-domains = <&pd IMX_SC_R_LVDS_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+phys = <&mipi_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+reg = <0>;
+
+mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
+remote-endpoi
[PATCH v6 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding
This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* Add Rob's R-b tag.
v4->v5:
* No change.
v3->v4:
* Add 'fsl,sc-resource' property. (Rob)
v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls PXL2DPI.
v1->v2:
* Use graph schema. (Laurent)
.../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 108 +
1 file changed, 108 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
new file mode 100644
index ..e4e77fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
+ interfaces the pixel link 36-bit data output and the DSI controller’s
+ MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
+ used in LVDS mode, to remap the pixel color codings between those modules.
+ This module is purely combinatorial.
+
+ The i.MX8qxp PXL2DPI is controlled by Control and Status Registers(CSR)
module.
+ The CSR module, as a system controller, contains the PXL2DPI's configuration
+ register.
+
+properties:
+ compatible:
+const: fsl,imx8qxp-pxl2dpi
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this PXL2DPI instance.
+
+ power-domains:
+maxItems: 1
+
+ fsl,companion-pxl2dpi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+ A phandle which points to companion PXL2DPI which is used by downstream
+ LVDS Display Bridge(LDB) in split mode.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: The PXL2DPI input port node from pixel link.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: The PXL2DPI output port node to downstream bridge.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - fsl,sc-resource
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+fsl,sc-resource = ;
+power-domains = <&pd IMX_SC_R_MIPI_0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&dc_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dc_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint =
<&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint =
<&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 09/14] drm/bridge: imx: Add i.MX8qxp pixel link to DPI support
This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI). The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color codings between those modules. The PXL2DPI is purely
combinatorial.
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
the PXL2DPI instance instead of using alias ID. (Rob)
v2->v3:
* Call syscon_node_to_regmap() to get regmap instead of
syscon_regmap_lookup_by_phandle().
v1->v2:
* Drop unnecessary port availability check.
drivers/gpu/drm/bridge/imx/Kconfig | 8 +
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 485 +++
3 files changed, 494 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 4d1f027..1ea1ce7 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -14,3 +14,11 @@ config DRM_IMX8QXP_PIXEL_LINK
help
Choose this to enable display pixel link found in
Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
+ tristate "Freescale i.MX8QXP pixel link to display pixel interface"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Choose this to enable pixel link to display pixel interface(PXL2DPI)
+ found in Freescale i.MX8qxp processor.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index c15469f..e74dd64 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
new file mode 100644
index ..6696855
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -0,0 +1,485 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define PXL2DPI_CTRL 0x40
+#define CFG1_16BIT0x0
+#define CFG2_16BIT0x1
+#define CFG3_16BIT0x2
+#define CFG1_18BIT0x3
+#define CFG2_18BIT0x4
+#define CFG_24BIT 0x5
+
+#define DRIVER_NAME"imx8qxp-pxl2dpi"
+
+struct imx8qxp_pxl2dpi {
+ struct regmap *regmap;
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+ struct drm_bridge *companion;
+ struct device *dev;
+ struct imx_sc_ipc *ipc_handle;
+ u32 sc_resource;
+ u32 in_bus_format;
+ u32 out_bus_format;
+ u32 pl_sel;
+};
+
+#define bridge_to_p2d(b) container_of(b, struct imx8qxp_pxl2dpi, bridge)
+
+static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ DRM_DEV_ERROR(p2d->dev,
+ "do not support creating a drm_connector\n");
+ return -EINVAL;
+ }
+
+ if (!bridge->encoder) {
+ DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
+ return -ENODEV;
+ }
+
+ return drm_bridge_attach(bridge->encoder,
+p2d->next_bridge, bridge,
+DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static int
+imx8qxp_pxl2dpi_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+ p2d->in_bus_format = bridge_state->input_bus_cfg.format;
+ p2d->out_bus_format = bridge_state->output_bus_cfg.format;
+
+ return 0;
+}
+
+static void
+imx8qxp_pxl2dpi_bridge_mode_set(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted_mode)
+{
+ struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+ struct imx8qxp_pxl2dpi *companion_p2d;
+ int ret;
+
+ ret = pm_runtime_get_sync(p2d->dev);
+ if (ret < 0)
+ DRM_DEV_ERROR(p2d->dev,
+
