[Bug 208573] Black screen on boot if two displays plugged in with NAVI 10
https://bugzilla.kernel.org/show_bug.cgi?id=208573 Andrej Podzimek (and...@podzimek.org) changed: What|Removed |Added CC||and...@podzimek.org --- Comment #13 from Andrej Podzimek (and...@podzimek.org) --- And here we go, the bug is back in 5.12.5 or so (probably also in earlier 5.12 kernels). In my case this occurs with 4 virtual and 2 physical screens connected (dual 5k MST) and a Radeon Pro W5700. The issue this was deduplicated against has lots of extra investigation. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915/gem: Use list_entry to access list members
Use list_entry() instead of container_of() to access list members.
Also drop unnecessary and misleading NULL checks on the result of
list_entry().
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..4241af5074a9 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -148,7 +148,7 @@ static void dmabuf_gem_object_free(struct kref *kref)
if (vgpu && vgpu->active && !list_empty(>dmabuf_obj_list_head)) {
list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos,
+ dmabuf_obj = list_entry(pos,
struct intel_vgpu_dmabuf_obj, list);
if (dmabuf_obj == obj) {
list_del(pos);
@@ -357,10 +357,8 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if ((dmabuf_obj == NULL) ||
- (dmabuf_obj->info == NULL))
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ if (dmabuf_obj->info == NULL)
continue;
fb_info = (struct intel_vgpu_fb_info *)dmabuf_obj->info;
@@ -387,11 +385,7 @@ pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if (!dmabuf_obj)
- continue;
-
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
if (dmabuf_obj->dmabuf_id == id) {
ret = dmabuf_obj;
break;
@@ -600,8 +594,7 @@ void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
mutex_lock(>dmabuf_lock);
list_for_each_safe(pos, n, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
dmabuf_obj->vgpu = NULL;
idr_remove(>object_idr, dmabuf_obj->dmabuf_id);
--
2.25.1
Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6)
Hi, On Thu, 20 May 2021 at 20:00, Jason Ekstrand wrote: > In the Vulkan world, this is useful for dealing with the out-fence from > vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all > rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we > get a set of fences (VkSemaphores) in vkQueuePresent and have to stash > those as an exclusive (write) fence on the dma-buf. We handle it in > Mesa today with the above mentioned dummy submit trick. This ioctl > would allow us to set it directly without the dummy submit. > > This may also open up possibilities for GPU drivers to move away from > implicit sync for their kernel driver uAPI and instead provide sync > files and rely on dma-buf import/export for communicating with other > implicit sync clients. > > We make the explicit choice here to only allow setting RW fences which > translates to an exclusive fence on the dma_resv. There's no use for > read-only fences for communicating with other implicit sync userspace > and any such attempts are likely to be racy at best. I think I almost follow, but I'm not quite seeing the race you allude to. Let me talk through my understanding so it's hopefully more clear for others as a summary. Please correct me on anything I've misunderstood or just missed completely. (I thought when I wrote this intro that the email might be relatively snappy, but it's really long and takes in a lot of breadth. Sorry.) So as far as I'm reading this patchset and the Mesa MR, this _only_ concerns the out-fence (i.e. compositor -> client AcquireNextImage semaphore/fence) so far. The in-fence (client->compositor QueuePresent wait-semaphores/fences) is handled by the driver ensuring that an exclusive resv is placed on the union of the signal semaphores passed to QueuePresent, either through flags on its CS ioctl, or amdgpu's BO flags, or ... either way, no problem as it should always be exclusive, and it seems pretty uncontroversial that we should pull the wait semaphore into an exclusive fence so that no downstream consumer will begin using it until the client ops have fully retired. For AcquireNextImage, your patchset exports all the fences (shared and exclusive both) on the dma_resv out into the semaphore/fence such that the client can't progress (CPU-side for VkFence, GPU-side for VkSemaphore) until all currently queued operations have completely retired. So, as long as the server ensures that all its kernel-side work is flushed before its IPC to unblock ANI (wl_buffer.release or DRI3 PresentIdle, both indicating that the client is free to reuse the buffer, subject to synchronising against implicit fences on the resv), all good: we snapshot the current resv state, wrap the relevant driver-side Vulkan primitive around it, and go back to explicit synchronisation. The client can't race generating new work against this, because it can't queue any work until ANI has returned and queued a signaling op on the semaphore/fence. So far, so good. I really like both your series up until this narrative point; as I was saying in the userspace-fence thread, the WSI<->client thread is certainly pulling a very big lever with a heavyweight transition between the two different worlds, and I like that the new export ioctl lets us be very clear about what exactly is happening under the hood. Good stuff. So, what gives with the import ioctl? Taking a guess at where you're going, the import ioctl is going to be used in QueuePresent just as the export ioctl is in ANI: instead of having CS flags to write into the resv exclusive slot or per-BO flags to always dump in exclusive, there's a forthcoming patch somewhere which lets drivers skip this and instead have common QueuePresent code dump the wait semaphore into the resv, so servers on the other side of an implicit-only protocol will synchronise their access against the fence imported as part of client-side QueuePresent? That makes sense to me and is nicely symmetrical, plus it gets GPU drivers further out of the business of doing magic winsys/display synchronisation, which is good. But why enforce that imported fences have to go into the exclusive slot? It makes sense from the point of view of clients doing QueueSubmit, but I think it might preclude other uses for no particularly good reason. Certainly on X11 there's no real use for the shared slot - you get into difficulties with mixed client/server rendering - but at least Wayland and GBM are always non-destructive, so conceptually have a good use for being able to import fences into the shared resv. This goes for media and KMS access as well, if you think beyond the usecase of an explicit Vulkan client sending through to a dumb implicit server which just wants to texture. Media clients are definitely a relevant usecase, both directly with V4L2/VA-API, neither of which have support for explicit synchronisation yet and (at least for V4L2) are unlikely to do so in the near future, but even more with pipeline
i915 gvt broke drm-tip; Fix ASAP
Hi,
after creating drm-tip today as part of [1], building drm-tip is now
broken with the error message shown below.
Some register constants appear to be missing from the GVT code. Please
fix ASAP.
Best regards
Thomas
tzimmermann@linux-uq9g:~/Projekte/linux> LANG= make -j8 W=1 O=build-x86_64/
make[1]: Entering directory '/home/tzimmermann/Projekte/linux/build-x86_64'
GEN Makefile
DESCEND objtool
CALL../scripts/atomic/check-atomics.sh
CALL../scripts/checksyscalls.sh
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/via/via_irq.o
CC [M] drivers/gpu/drm/via/via_drv.o
CC [M] drivers/gpu/drm/i915/gvt/handlers.o
CC [M] drivers/gpu/drm/via/via_map.o
CC [M] drivers/gpu/drm/vgem/vgem_drv.o
../drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_skl_mmio_info':
../drivers/gpu/drm/i915/gvt/handlers.c:3345:9: error: 'CSR_SSP_BASE'
undeclared (first use in this function); did you mean 'MSR_FS_BASE'?
3345 | MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
| ^~~~
../drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of
macro 'MMIO_F'
2120 | ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
|^~~
../drivers/gpu/drm/i915/gvt/handlers.c:3345:2: note: in expansion of
macro 'MMIO_D'
3345 | MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
| ^~
../drivers/gpu/drm/i915/gvt/handlers.c:3345:9: note: each undeclared
identifier is reported only once for each function it appears in
3345 | MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
| ^~~~
../drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of
macro 'MMIO_F'
2120 | ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
|^~~
../drivers/gpu/drm/i915/gvt/handlers.c:3345:2: note: in expansion of
macro 'MMIO_D'
3345 | MMIO_D(CSR_SSP_BASE, D_SKL_PLUS);
| ^~
../drivers/gpu/drm/i915/gvt/handlers.c:3346:9: error: 'CSR_HTP_SKL'
undeclared (first use in this function); did you mean 'DMC_HTP_SKL'?
3346 | MMIO_D(CSR_HTP_SKL, D_SKL_PLUS);
| ^~~
../drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of
macro 'MMIO_F'
2120 | ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
|^~~
../drivers/gpu/drm/i915/gvt/handlers.c:3346:2: note: in expansion of
macro 'MMIO_D'
3346 | MMIO_D(CSR_HTP_SKL, D_SKL_PLUS);
| ^~
../drivers/gpu/drm/i915/gvt/handlers.c:3347:9: error: 'CSR_LAST_WRITE'
undeclared (first use in this function); did you mean 'DMC_LAST_WRITE'?
3347 | MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS);
| ^~
../drivers/gpu/drm/i915/gvt/handlers.c:2120:48: note: in definition of
macro 'MMIO_F'
2120 | ret = new_mmio_info(gvt, i915_mmio_reg_offset(reg), \
|^~~
../drivers/gpu/drm/i915/gvt/handlers.c:3347:2: note: in expansion of
macro 'MMIO_D'
3347 | MMIO_D(CSR_LAST_WRITE, D_SKL_PLUS);
| ^~
CC [M] drivers/gpu/drm/via/via_mm.o
CC [M] drivers/gpu/drm/via/via_dma.o
In file included from ../drivers/gpu/drm/i915/i915_drv.h:64,
from ../drivers/gpu/drm/i915/gvt/handlers.c:39:
../drivers/gpu/drm/i915/gvt/handlers.c: At top level:
../drivers/gpu/drm/i915/gvt/handlers.c:3658:21: error:
'CSR_MMIO_START_RANGE' undeclared here (not in a function); did you mean
'DMC_MMIO_START_RANGE'?
3658 | {D_SKL_PLUS, _MMIO(CSR_MMIO_START_RANGE), 0x3000, NULL, NULL},
| ^~~~
../drivers/gpu/drm/i915/i915_reg.h:185:47: note: in definition of macro
'_MMIO'
185 | #define _MMIO(r) ((const i915_reg_t){ .reg = (r) })
| ^
make[5]: *** [../scripts/Makefile.build:272:
drivers/gpu/drm/i915/gvt/handlers.o] Error 1
[1]
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=304ba5dca49a21e6f4040494c669134787145118
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/4] dma-buf: add dma_resv_get_singleton_rcu (v4)
Hi Jason,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc2 next-20210521]
[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-an-API-for-exporting-sync-files-v8/20210522-201251
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: x86_64-randconfig-a013-20210522 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
e84a9b9bb3051c35dea993cdad7b3d2575638f85)
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
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/925221f402201e7b1f665619dda2c5ee6d6324f1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jason-Ekstrand/dma-buf-Add-an-API-for-exporting-sync-files-v8/20210522-201251
git checkout 925221f402201e7b1f665619dda2c5ee6d6324f1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/dma-buf/dma-resv.c:550: warning: expecting prototype for
>> dma_resv_get_singleton(). Prototype was for dma_resv_get_singleton_rcu()
>> instead
vim +550 drivers/dma-buf/dma-resv.c
534
535 /**
536 * dma_resv_get_singleton - get a single fence for the dma_resv object
537 * @obj: the reservation object
538 * @extra: extra fence to add to the resulting array
539 * @result: resulting dma_fence
540 *
541 * Get a single fence representing all unsignaled fences in the
dma_resv object
542 * plus the given extra fence. If we got only one fence return a new
543 * reference to that, otherwise return a dma_fence_array object.
544 *
545 * RETURNS
546 * Returns -NOMEM if allocations fail, zero otherwise.
547 */
548 int dma_resv_get_singleton_rcu(struct dma_resv *obj, struct dma_fence
*extra,
549 struct dma_fence **result)
> 550 {
551 struct dma_fence **resv_fences, *fence, *chain, **fences;
552 struct dma_fence_array *array;
553 unsigned int num_resv_fences, num_fences;
554 unsigned int ret, i, j;
555
556 ret = dma_resv_get_fences_rcu(obj, NULL, _resv_fences,
_fences);
557 if (ret)
558 return ret;
559
560 num_fences = 0;
561 *result = NULL;
562
563 if (num_resv_fences == 0 && !extra)
564 return 0;
565
566 for (i = 0; i < num_resv_fences; ++i) {
567 dma_fence_deep_dive_for_each(fence, chain, j,
resv_fences[i]) {
568 if (dma_fence_is_signaled(fence))
569 continue;
570
571 *result = fence;
572 ++num_fences;
573 }
574 }
575
576 if (extra) {
577 dma_fence_deep_dive_for_each(fence, chain, j, extra) {
578 if (dma_fence_is_signaled(fence))
579 continue;
580
581 *result = fence;
582 ++num_fences;
583 }
584 }
585
586 if (num_fences <= 1) {
587 *result = dma_fence_get(*result);
588 goto put_resv_fences;
589 }
590
591 fences = kmalloc_array(num_fences, sizeof(struct dma_fence*),
592 GFP_KERNEL);
593 if (!fences) {
594 *result = NULL;
595 ret = -ENOMEM;
596 goto put_resv_fences;
597 }
598
599 num_fences = 0;
600 for (i = 0; i < num_resv_fences; ++i) {
601 dma_fence_deep_dive_for_each(fence, chain, j,
resv_fences[i]) {
602 if (!dma_fence_is_signaled(fence))
603 fences[num_fences++] =
dma_fence_get(fence);
604 }
605 }
606
607 if (extra) {
608 dma_fence_deep_dive_for_each(fence, chain, j, extra) {
609
Re: [PATCH 2/4] dma-buf: add dma_resv_get_singleton_rcu (v4)
Hi Jason,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc2 next-20210521]
[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-an-API-for-exporting-sync-files-v8/20210522-201251
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: x86_64-randconfig-s031-20210522 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-341-g8af24329-dirty
#
https://github.com/0day-ci/linux/commit/925221f402201e7b1f665619dda2c5ee6d6324f1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jason-Ekstrand/dma-buf-Add-an-API-for-exporting-sync-files-v8/20210522-201251
git checkout 925221f402201e7b1f665619dda2c5ee6d6324f1
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1
ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/dma-buf/dma-resv.c:550: warning: expecting prototype for
>> dma_resv_get_singleton(). Prototype was for dma_resv_get_singleton_rcu()
>> instead
vim +550 drivers/dma-buf/dma-resv.c
534
535 /**
536 * dma_resv_get_singleton - get a single fence for the dma_resv object
537 * @obj: the reservation object
538 * @extra: extra fence to add to the resulting array
539 * @result: resulting dma_fence
540 *
541 * Get a single fence representing all unsignaled fences in the
dma_resv object
542 * plus the given extra fence. If we got only one fence return a new
543 * reference to that, otherwise return a dma_fence_array object.
544 *
545 * RETURNS
546 * Returns -NOMEM if allocations fail, zero otherwise.
547 */
548 int dma_resv_get_singleton_rcu(struct dma_resv *obj, struct dma_fence
*extra,
549 struct dma_fence **result)
> 550 {
551 struct dma_fence **resv_fences, *fence, *chain, **fences;
552 struct dma_fence_array *array;
553 unsigned int num_resv_fences, num_fences;
554 unsigned int ret, i, j;
555
556 ret = dma_resv_get_fences_rcu(obj, NULL, _resv_fences,
_fences);
557 if (ret)
558 return ret;
559
560 num_fences = 0;
561 *result = NULL;
562
563 if (num_resv_fences == 0 && !extra)
564 return 0;
565
566 for (i = 0; i < num_resv_fences; ++i) {
567 dma_fence_deep_dive_for_each(fence, chain, j,
resv_fences[i]) {
568 if (dma_fence_is_signaled(fence))
569 continue;
570
571 *result = fence;
572 ++num_fences;
573 }
574 }
575
576 if (extra) {
577 dma_fence_deep_dive_for_each(fence, chain, j, extra) {
578 if (dma_fence_is_signaled(fence))
579 continue;
580
581 *result = fence;
582 ++num_fences;
583 }
584 }
585
586 if (num_fences <= 1) {
587 *result = dma_fence_get(*result);
588 goto put_resv_fences;
589 }
590
591 fences = kmalloc_array(num_fences, sizeof(struct dma_fence*),
592 GFP_KERNEL);
593 if (!fences) {
594 *result = NULL;
595 ret = -ENOMEM;
596 goto put_resv_fences;
597 }
598
599 num_fences = 0;
600 for (i = 0; i < num_resv_fences; ++i) {
601 dma_fence_deep_dive_for_each(fence, chain, j,
resv_fences[i]) {
602 if (!dma_fence_is_signaled(fence))
603 fences[num_fences++] =
dma_fence_get(fence);
604 }
605 }
606
607 if (extra) {
608 dma_fence_deep_dive_for_each(fence, chain, j, extra) {
609 if (dma_fence_is_signaled(fence))
610 fences[num_fences++] =
dma_fence_get(fence);
611 }
612 }
613
614 if (num_fences <= 1) {
615
Re: [PATCHv2 5/5] ARM: dts: imx6: Add GE B1x5v2
On Thu, Apr 29, 2021 at 12:29:53AM +0200, Sebastian Reichel wrote:
> This adds device tree files for the General Electric Healthcare
> (GEHC) B1x5v2 series. All models make use of Congatec's QMX6 module,
> which is described in its own device tree include, so that it can
> also be used by other boards.
>
> Signed-off-by: Sebastian Reichel
> ---
> arch/arm/boot/dts/Makefile| 5 +
> arch/arm/boot/dts/imx6dl-b105pv2.dts | 35 ++
> arch/arm/boot/dts/imx6dl-b105v2.dts | 35 ++
> arch/arm/boot/dts/imx6dl-b125pv2.dts | 33 ++
> arch/arm/boot/dts/imx6dl-b125v2.dts | 33 ++
> arch/arm/boot/dts/imx6dl-b155v2.dts | 36 ++
> arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++
> arch/arm/boot/dts/imx6dl-b1x5v2.dtsi | 61 +++
> arch/arm/boot/dts/imx6dl-qmx6.dtsi| 624 ++
> 9 files changed, 1296 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
> create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
> create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f8f09c5066e7..811f22ed1e37 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -515,6 +515,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-dms-ba16.dtb \
> imx6q-emcon-avari.dtb \
> imx6q-evi.dtb \
> + imx6dl-b105v2.dtb \
> + imx6dl-b105pv2.dtb \
'p' goes before 'v'.
> + imx6dl-b125v2.dtb \
> + imx6dl-b125pv2.dtb \
> + imx6dl-b155v2.dtb \
> imx6q-gk802.dtb \
> imx6q-gw51xx.dtb \
> imx6q-gw52xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-b105pv2.dts
> b/arch/arm/boot/dts/imx6dl-b105pv2.dts
> new file mode 100644
> index ..0d5be2f9471f
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-b105pv2.dts
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +//
> +// Device Tree Source for General Electric B105Pv2
> +//
> +// Copyright 2018-2021 General Electric Company
> +// Copyright 2018-2021 Collabora
> +
> +/dts-v1/;
> +#include "imx6dl-b1x5pv2.dtsi"
> +
> +/ {
> + model = "General Electric B105Pv2";
> + compatible = "ge,imx6dl-b105pv2", "congatec,qmx6", "fsl,imx6dl";
> +
> + panel {
> + compatible = "auo,g101evn010";
> + status = "okay";
Unneeded okay status.
> + };
> +};
> +
> + {
> + touchscreen@41 {
> + reg = <0x41>;
We generally start property list with 'compatible'.
> + compatible = "ilitek,ili251x";
> +
In general, we do not use newline in middle of property list.
> + pinctrl-names = "default";
> + pinctrl-0 =<_q7_gpio0>;
> + interrupt-parent = <>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = < 21 GPIO_ACTIVE_LOW>;
> +
> + touchscreen-size-x = <1280>;
> + touchscreen-size-y = <800>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6dl-b105v2.dts
> b/arch/arm/boot/dts/imx6dl-b105v2.dts
> new file mode 100644
> index ..72a085348304
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-b105v2.dts
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +//
> +// Device Tree Source for General Electric B105v2
> +//
> +// Copyright 2018-2021 General Electric Company
> +// Copyright 2018-2021 Collabora
> +
> +/dts-v1/;
> +#include "imx6dl-b1x5v2.dtsi"
> +
> +/ {
> + model = "General Electric B105v2";
> + compatible = "ge,imx6dl-b105v2", "congatec,qmx6", "fsl,imx6dl";
> +
> + panel {
> + compatible = "auo,g101evn010";
> + status = "okay";
> + };
> +};
> +
> + {
> + touchscreen@41 {
> + reg = <0x41>;
> + compatible = "ilitek,ili251x";
> +
> + pinctrl-names = "default";
> + pinctrl-0 =<_q7_gpio0>;
> + interrupt-parent = <>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = < 21 GPIO_ACTIVE_LOW>;
> +
> + touchscreen-size-x = <1280>;
> + touchscreen-size-y = <800>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6dl-b125pv2.dts
> b/arch/arm/boot/dts/imx6dl-b125pv2.dts
> new file mode 100644
> index ..8fd6c8ed6750
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-b125pv2.dts
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +//
> +// Device Tree Source for General Electric B125Pv2
> +//
> +// Copyright 2018-2021 General Electric Company
> +// Copyright 2018-2021 Collabora
> +
> +/dts-v1/;
> +#include "imx6dl-b1x5pv2.dtsi"
> +
> +/ {
> + model = "General Electric B125Pv2";
> + compatible = "ge,imx6dl-b125pv2",
Re: [PATCH v7 10/10] arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip
On Mon, May 17, 2021 at 10:09 PM Douglas Anderson wrote:
> Putting the panel under the bridge chip (under the aux-bus node)
> allows the panel driver to get access to the DP AUX bus, enabling all
> sorts of fabulous new features.
>
> While we're at this, get rid of a level of hierarchy for the panel
> node. It doesn't need "ports / port" and can just have a "port" child.
>
> For Linux, this patch has a hard requirement on the patches adding DP
> AUX bus support to the ti-sn65dsi86 bridge chip driver. See the patch
> ("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus").
>
> Signed-off-by: Douglas Anderson
This is really looking good.
Acked-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH v7 02/10] dt-bindings: display: simple: List hpd properties in panel-simple
On Tue, May 18, 2021 at 3:58 PM Doug Anderson wrote: > On Tue, May 18, 2021 at 5:42 AM Rob Herring wrote: > > On Mon, May 17, 2021 at 3:09 PM Douglas Anderson > > wrote: > > > > > > These are described in panel-common.yaml but if I don't list them in > > > panel-simple then I get yells when running 'dt_binding_check' in a > > > future patch. List them along with other properties that seem to be > > > listed in panel-simple for similar reasons. > > > > If you have HPD, is it still a simple panel? I don't see this as an > > omission because the use of these properties for simple panels was > > never documented IIRC. > > I would say so. It is currently supported by panel-simple in Linux. Of > course, you could make the argument that panel-simple is no longer > really "simple" because of things like this... I think it should be renamed panel-panacea at this point. I think I pointed it out before. But not my pick so I rest my case. Yours, Linus Walleij
Re: [PATCH v7 08/10] drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus
On Mon, May 17, 2021 at 10:09 PM Douglas Anderson wrote: > We want to provide our panel with access to the DP AUX channel. The > way to do this is to let our panel be a child of ours using the fancy > new DP AUX bus support. > > Signed-off-by: Douglas Anderson That's neat. Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v7 04/10] drm: Introduce the DP AUX bus
On Mon, May 17, 2021 at 10:09 PM Douglas Anderson wrote: > Historically "simple" eDP panels have been handled by panel-simple > which is a basic platform_device. In the device tree, the panel node > was at the top level and not connected to anything else. > > Let's change it so that, instead, panels can be represented as being > children of the "DP AUX bus". Essentially we're saying that the > hierarchy that we're going to represent is the "control" connections > between devices. The DP AUX bus is a control bus provided by an eDP > controller (the parent) and consumed by a device like a panel (the > child). > > The primary incentive here is to cleanly provide the panel driver the > ability to communicate over the AUX bus while handling lifetime issues > properly. The panel driver may want the AUX bus for controlling the > backlight or querying the panel's EDID. > > The idea for this bus's design was hashed out over IRC [1]. > > [1] > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel=2021-05-11 > > Cc: Laurent Pinchart > Cc: Lyude Paul > Cc: Rajeev Nandan > Suggested-by: Laurent Pinchart > Signed-off-by: Douglas Anderson I like the concept and the general idea behind this, clean and helpful design. Acked-by: Linus Walleij Yours, Linus Walleij
Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Am 21.05.21 um 20:31 schrieb Daniel Vetter: [SNIP] We could provide an IOCTL for the BO to change the flag. That's not the semantics we need. But could we first figure out the semantics we want to use here? Cause I'm pretty sure we don't actually need those changes at all and as said before I'm certainly NAKing things which break existing use cases. Please read how other drivers do this and at least _try_ to understand it. I'm really loosing my patience here with you NAKing patches you're not even understanding (or did you actually read and fully understand the entire story I typed up here, and your NAK is on the entire thing?). There's not much useful conversation to be had with that approach. And with drivers I mean kernel + userspace here. Well to be honest I did fully read that, but I was just to emotionally attached to answer more appropriately in that moment. And I'm sorry that I react emotional on that, but it is really frustrating that I'm not able to convince you that we have a major problem which affects all drivers and not just amdgpu. Regarding the reason why I'm NAKing this particular patch, you are breaking existing uAPI for RADV with that. And as a maintainer of the driver I have simply no other choice than saying halt, stop we can't do it like this. I'm perfectly aware that I've some holes in the understanding of how ANV or other Vulkan/OpenGL stacks work. But you should probably also admit that you have some holes how amdgpu works or otherwise I can't imagine why you suggest a patch which simply breaks RADV. I mean we are working together for years now and I think you know me pretty well, do you really think I scream bloody hell we can't do this without a good reason? So let's stop throwing halve backed solutions at each other and discuss what we can do to solve the different problems we are both seeing here. That's the other frustration part: You're trying to fix this purely in the kernel. This is exactly one of these issues why we require open source userspace, so that we can fix the issues correctly across the entire stack. And meanwhile you're steadfastily refusing to even look at that the userspace side of the picture. Well I do fully understand the userspace side of the picture for the AMD stack. I just don't think we should give userspace that much control over the fences in the dma_resv object without untangling them from resource management. And RADV is exercising exclusive sync for amdgpu already. You can do submission to both the GFX, Compute and SDMA queues in Vulkan and those currently won't over-synchronize. When you then send a texture generated by multiple engines to the Compositor the kernel will correctly inserts waits for all submissions of the other process. So this already works for RADV and completely without the IOCTL Jason proposed. IIRC we also have unit tests which exercised that feature for the video decoding use case long before RADV even existed. And yes I have to admit that I haven't thought about interaction with other drivers when I came up with this because the rules of that interaction wasn't clear to me at that time. Also I thought through your tlb issue, why are you even putting these tlb flush fences into the shard dma_resv slots? If you store them somewhere else in the amdgpu private part, the oversync issues goes away - in your ttm bo move callback, you can just make your bo copy job depend on them too (you have to anyway) - even for p2p there's not an issue here, because you have the ->move_notify callback, and can then lift the tlb flush fences from your private place to the shared slots so the exporter can see them. Because adding a shared fence requires that this shared fence signals after the exclusive fence. And this is a perfect example to explain why this is so problematic and also why why we currently stumble over that only in amdgpu. In TTM we have a feature which allows evictions to be pipelined and don't wait for the evicting DMA operation. Without that driver will stall waiting for their allocations to finish when we need to allocate memory. For certain use cases this gives you a ~20% fps increase under memory pressure, so it is a really important feature. This works by adding the fence of the last eviction DMA operation to BOs when their backing store is newly allocated. That's what the ttm_bo_add_move_fence() function you stumbled over is good for: https://elixir.bootlin.com/linux/v5.13-rc2/source/drivers/gpu/drm/ttm/ttm_bo.c#L692 Now the problem is it is possible that the application is terminated before it can complete it's command submission. But since resource management only waits for the shared fences when there are some there is a chance that we free up memory while it is still in use. Because of this we have some rather crude workarounds in amdgpu. For example IIRC we manual wait for any potential exclusive fence before freeing memory. We
Re: [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
Dne petek, 21. maj 2021 ob 11:09:54 CEST je Daniel Vetter napisal(a): > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev For sun4i: Acked-by: Jernej Skrabec Best regards, Jernej
Re: ttm_resource_manager::use_tt
Hi Zack, IIRC that was for the VMW_PL_GMR type, wasn't it? As far as I have seen that backend was just giving out unique numbers and it looked questionable that we allocated pages for that. E.g. when you set that flag then for each allocation we also allocate a TTM tt structure and a corresponding page. Regards, Christian. Am 21.05.21 um 20:17 schrieb Zack Rusin: Hi, Christian. I was just going over some old patches and I was just looking at your series introducing use_tt: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F80078%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C95b3c758592d4f0c247c08d91c84b48c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637572178561737650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5uZDVUi3W1WH29%2B2nE9uFUFZjQkKJyUxc6MwEce6SQ8%3Dreserved=0 and the change https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F382079%2F%3Fseries%3D80078%26rev%3D1data=04%7C01%7Cchristian.koenig%40amd.com%7C95b3c758592d4f0c247c08d91c84b48c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637572178561737650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5XWSt07%2FzlXDa0GH8hnwEulyCBNocB2fUJ6CLwzubbE%3Dreserved=0 Do you happen to remember what was the worry behind the /* TODO: This is most likely not correct */ in vmwgfx_ttm_buffer.c? I'm trying to figure out if we need to address it. z
