[PATCH v2] drm/panel: ili9341: Remove a superfluous else after return
Because the else clause after the return clause is not useful, remove it to get a better look. Reviewed-by: Jessica Zhang Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c index 3574681891e8..433572c4caf9 100644 --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c @@ -722,7 +722,8 @@ static int ili9341_probe(struct spi_device *spi) if (!strcmp(id->name, "sf-tc240t-9370-t")) return ili9341_dpi_probe(spi, dc, reset); - else if (!strcmp(id->name, "yx240qv29")) + + if (!strcmp(id->name, "yx240qv29")) return ili9341_dbi_probe(spi, dc, reset); return -1; -- 2.34.1
[PATCH v2] drm/debugfs: Drop conditionals around of_node pointers
Having conditional around the of_node pointer of the drm_bridge structure
is not necessary anymore, since drm_bridge structure always has the of_node
member since the commit d8dfccde2709 ("drm/bridge: Drop conditionals around
of_node pointers").
So drop the conditional, please also note that this patch is following the
convention used by driver core, see commit c9e358dfc4a8 ("driver-core:
remove conditionals around devicetree pointers").
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sui Jingfeng
---
v2: Update commit message
---
drivers/gpu/drm/drm_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 08fcefd804bc..28a471fe4bc8 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -597,10 +597,10 @@ static int bridges_show(struct seq_file *m, void *data)
drm_printf(, "\ttype: [%d] %s\n",
bridge->type,
drm_get_connector_type_name(bridge->type));
-#ifdef CONFIG_OF
+
if (bridge->of_node)
drm_printf(, "\tOF: %pOFfc\n", bridge->of_node);
-#endif
+
drm_printf(, "\tops: [0x%x]", bridge->ops);
if (bridge->ops & DRM_BRIDGE_OP_DETECT)
drm_puts(, " detect");
--
2.34.1
Re: drm/debugfs: Drop conditionals around of_node pointers
Hi,
On 2024/5/1 05:33, Doug Anderson wrote:
Hi,
On Mon, Apr 29, 2024 at 6:16 PM 隋景峰 wrote:
Hi,
-原始邮件-
发件人: "Maxime Ripard"
发送时间: 2024-04-29 19:30:24 (星期一)
收件人: "Sui Jingfeng"
抄送: "Sui Jingfeng" , "Maarten Lankhorst" , "Thomas Zimmermann" , "David
Airlie" , "Daniel Vetter" , "Douglas Anderson" , "Laurent Pinchart"
, "Biju Das" , dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org
主题: Re: drm/debugfs: Drop conditionals around of_node pointers
On Sun, Apr 28, 2024 at 04:52:13PM +0800, Sui Jingfeng wrote:
ping
在 2024/3/22 06:22, Sui Jingfeng 写道:
Having conditional around the of_node pointer of the drm_bridge structure
turns out to make driver code use ugly #ifdef blocks.
The code being ugly is an opinion, what problem is it causing exactly?
Drop the conditionals to simplify debugfs.
What does it simplifies?
Fixes: d8dfccde2709 ("drm/bridge: Drop conditionals around of_node pointers")
Signed-off-by: Sui Jingfeng
Why do we want to backport that patch to stable?
Technically it's not CCing stable and so it's not really incorrect.
...but I agree that this is a bit of a stretch to call it a "Fix".
Maybe drop the "Fixes" line?
OK, good idea, acceptable.
Originally, I add the fix tag to hint that my modification belongs to
the commit d8dfccde2709 ("drm/bridge: Drop conditionals around of_node
pointers") too.
But get missed.
My commit message is written based on commit of d8dfccde2709
$ git show c9e358dfc4a8
This patch is based on commit c9e358dfc4a8 ("driver-core: remove
conditionals around devicetree pointers").
Having conditional around the of_node pointer of the drm_bridge
structure turns out to make driver code use ugly #ifdef blocks. Drop the
conditionals to simplify drivers. While this slightly increases the size
of struct drm_bridge on non-OF system, the number of bridges used today
and foreseen tomorrow on those systems is very low, so this shouldn't be
an issue.
So drop #if conditionals by adding struct device_node forward declaration.
Maxime
I'm just start to contribute by mimic other people's tone, there seems no need
to over read.
I think the fact that you skipped the reference to commit c9e358dfc4a8
("driver-core: remove conditionals around devicetree pointers") was
relevant here. Referencing that commit makes it easy for the reader to
see that you are following convention used throughout the kernel and
not just asserting your own opinion about style.
If you add that reference into your commit message and send a v2, I'm
happy to apply it.
OK, thanks a lot.
-Doug
--
Best regards,
Sui
Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range
On Tue, Apr 30, 2024 at 08:57:48PM +0200, Daniel Vetter wrote: > On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote: > > On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote: > > > > > > Yes there is another common scheme where you bind a window of CPU to > > > > a > > > > window on the device and mirror a fixed range, but this is a quite > > > > different thing. It is not SVA, it has a fixed range, and it is > > > > probably bound to a single GPU VMA in a multi-VMA device page table. > > > > > > And this above here is exactly what we're implementing, and the GPU > > > page-tables are populated using device faults. Regions (large) of the > > > mirrored CPU mm need to coexist in the same GPU vm as traditional GPU > > > buffer objects. > > > > Well, not really, if that was the case you'd have a single VMA over > > the entire bound range, not dynamically create them. > > > > A single VMA that uses hmm_range_fault() to populate the VM is > > completely logical. > > > > Having a hidden range of mm binding and then creating/destroying 2M > > VMAs dynamicaly is the thing that doesn't make alot of sense. > > I only noticed this thread now but fyi I did dig around in the > implementation and it's summarily an absolute no-go imo for multiple > reasons. It starts with this approach of trying to mirror cpu vma (which I > think originated from amdkfd) leading to all kinds of locking fun, and > then it gets substantially worse when you dig into the details. :( Why does the DRM side struggle so much with hmm_range fault? I would have thought it should have a fairly straightforward and logical connection to the GPU page table. FWIW, it does make sense to have both a window and a full MM option for hmm_range_fault. ODP does both and it is fine.. > I think until something more solid shows up you can just ignore this. I do > fully agree that for sva the main mirroring primitive needs to be page > centric, so dma_map_sg. ^^ dma_map_page > There's a bit a question around how to make the > necessary batching efficient and the locking/mmu_interval_notifier scale > enough, but I had some long chats with Thomas and I think there's enough > option to spawn pretty much any possible upstream consensus. So I'm not > worried. Sure, the new DMA API will bring some more considerations to this as well. ODP uses a 512M granual scheme and it seems to be OK. By far the worst part of all this is the faulting performance. I've yet hear any complains about mmu notifier performance.. > But first this needs to be page-centric in the fundamental mirroring > approach. Yes Jason
Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
Hi Weishi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.9-rc6 next-20240430]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240430-132447
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240429030541.56702-1-liweishi%40kylinos.cn
patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
config: hexagon-randconfig-001-20240501
(https://download.01.org/0day-ci/archive/20240501/202405010653.utlwekew-...@intel.com/config)
compiler: clang version 15.0.7 (https://github.com/llvm/llvm-project.git
8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240501/202405010653.utlwekew-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202405010653.utlwekew-...@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/virtio/virtgpu_vq.c:29:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __raw_readb(PCI_IOBASE + addr);
~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from
macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
^
In file included from drivers/gpu/drm/virtio/virtgpu_vq.c:29:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~ ^
include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from
macro '__le32_to_cpu'
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
^
In file included from drivers/gpu/drm/virtio/virtgpu_vq.c:29:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/hexagon/include/asm/io.h:328:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writeb(value, PCI_IOBASE + addr);
~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
~~ ^
drivers/gpu/drm/virtio/virtgpu_vq.c:474:2: error: expected expression
else if (ret < 0) {
^
>> drivers/gpu/drm/virtio/virtgpu_vq.c:503:1: error: function definition is not
>> allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:523:1: error: function definition is not
allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:534:1: error: function definition is not
allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:556:1: error: function definition is not
allowed here
{
^
drivers/gpu/drm/virtio/virtgpu_vq.c:580:1: error: function definition is not
allowed here
{
^
drivers/gpu/drm/virt
Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Sun, 21 Apr 2024 23:30:33 -0700
Vivek Kasireddy wrote:
> From Jason Gunthorpe:
> "dma-buf has become a way to safely acquire a handle to non-struct page
> memory that can still have lifetime controlled by the exporter. Notably
> RDMA can now import dma-buf FDs and build them into MRs which allows for
> PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
> from PCI device BARs.
>
> The patch design loosely follows the pattern in commit
> db1a8dd916aa ("habanalabs: add support for dma-buf exporter") except this
> does not support pinning.
>
> Instead, this implements what, in the past, we've called a revocable
> attachment using move. In normal situations the attachment is pinned, as a
> BAR does not change physical address. However when the VFIO device is
> closed, or a PCI reset is issued, access to the MMIO memory is revoked.
>
> Revoked means that move occurs, but an attempt to immediately re-map the
> memory will fail. In the reset case a future move will be triggered when
> MMIO access returns. As both close and reset are under userspace control
> it is expected that userspace will suspend use of the dma-buf before doing
> these operations, the revoke is purely for kernel self-defense against a
> hostile userspace."
>
> Following enhancements are made to the original patch:
> - Use P2P DMA APIs to create pages (ZONE_DEVICE) instead of DMA addrs
> - Add a mmap handler to provide CPU access to the dmabuf
> - Add support for creating dmabuf from multiple areas (or ranges)
>
> Original-patch-by: Jason Gunthorpe
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/vfio/pci/Makefile | 1 +
> drivers/vfio/pci/dma_buf.c | 348 +
> drivers/vfio/pci/vfio_pci_config.c | 8 +-
> drivers/vfio/pci/vfio_pci_core.c | 28 ++-
> drivers/vfio/pci/vfio_pci_priv.h | 23 ++
> include/linux/vfio_pci_core.h | 1 +
> include/uapi/linux/vfio.h | 25 +++
> 7 files changed, 426 insertions(+), 8 deletions(-)
> create mode 100644 drivers/vfio/pci/dma_buf.c
>
> diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
> index ce7a61f1d912..b2374856ff62 100644
> --- a/drivers/vfio/pci/Makefile
> +++ b/drivers/vfio/pci/Makefile
> @@ -2,6 +2,7 @@
>
> vfio-pci-core-y := vfio_pci_core.o vfio_pci_intrs.o vfio_pci_rdwr.o
> vfio_pci_config.o
> vfio-pci-core-$(CONFIG_VFIO_PCI_ZDEV_KVM) += vfio_pci_zdev.o
> +vfio-pci-core-$(CONFIG_DMA_SHARED_BUFFER) += dma_buf.o
> obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o
>
> vfio-pci-y := vfio_pci.o
> diff --git a/drivers/vfio/pci/dma_buf.c b/drivers/vfio/pci/dma_buf.c
> new file mode 100644
> index ..7bf00fdee69b
> --- /dev/null
> +++ b/drivers/vfio/pci/dma_buf.c
> @@ -0,0 +1,348 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES.
> + */
> +#include
> +#include
> +#include
> +
> +#include "vfio_pci_priv.h"
> +
> +MODULE_IMPORT_NS(DMA_BUF);
> +
> +struct vfio_pci_dma_buf {
> + struct dma_buf *dmabuf;
> + struct vfio_pci_core_device *vdev;
> + struct list_head dmabufs_elm;
> + struct page **pages;
> + struct sg_table *sg;
> + unsigned int nr_pages;
> + bool revoked;
> +};
> +
> +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> + pgoff_t pgoff = vmf->pgoff;
> +
> + if (pgoff >= priv->nr_pages)
> + return VM_FAULT_SIGBUS;
> +
> + return vmf_insert_pfn(vma, vmf->address,
> + page_to_pfn(priv->pages[pgoff]));
> +}
How does this prevent the MMIO space from being mmap'd when disabled at
the device? How is the mmap revoked when the MMIO becomes disabled?
Is it part of the move protocol?
> +
> +static const struct vm_operations_struct vfio_pci_dma_buf_vmops = {
> + .fault = vfio_pci_dma_buf_fault,
> +};
> +
> +static int vfio_pci_dma_buf_mmap(struct dma_buf *dmabuf,
> + struct vm_area_struct *vma)
> +{
> + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> +
> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _pci_dma_buf_vmops;
> + vma->vm_private_data = priv;
> + vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> + return 0;
> +}
Does this need to include the new VM_ALLOW_ANY_UNCACHED flag?
> +
> +static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> +struct dma_buf_attachment *attachment)
> +{
> + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> + int rc;
> +
> + rc = pci_p2pdma_distance_many(priv->vdev->pdev, >dev, 1,
> + true);
> + if (rc < 0)
> + attachment->peer2peer = false;
> + return 0;
> +}
> +
> +static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> +{
> +}
Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive
On 4/30/2024 1:29 PM, Rodrigo Vivi wrote: > On Tue, Apr 30, 2024 at 05:38:02PM +, Easwar Hariharan wrote: >> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" >> with more appropriate terms. Inspired by and following on to Wolfram's >> series to fix drivers/i2c/[1], fix the terminology for users of >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists >> in the specification. >> >> Compile tested, no functionality changes intended >> >> [1]: >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ >> >> Signed-off-by: Easwar Hariharan > > I'm glad to see this change! > > Reviewed-by: Rodrigo Vivi > >> --- >> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - >> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- >> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- >> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- >> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- >> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- >> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- >> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- >> .../gpu/drm/i915/display/intel_display_core.h | 2 +- >> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- >> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- >> drivers/gpu/drm/i915/display/intel_dvo.c | 14 - >> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- >> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- >> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +-- >> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- >> drivers/gpu/drm/i915/gvt/edid.c | 28 - >> drivers/gpu/drm/i915/gvt/edid.h | 4 +-- >> drivers/gpu/drm/i915/gvt/opregion.c | 2 +- >> 19 files changed, 119 insertions(+), 119 deletions(-) > > The chances of conflicts are high with this many changes, > but should be easy enough to deal with later, so feel free > to move with this i915 patch on any other tree and we catch-up > later. > > Acked-by: Rodrigo Vivi > Thanks for the review and ack! I actually thought that this might end up going in as individual patches via the various respective trees since it's now completely independent of Wolfram's enabling series with the drop of the final patch that was treewide. What do you think? Thanks, Easwar
Re: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
Hi Weishi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.9-rc6
next-20240430]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Weishi-Li/drm-virtio-fix-memory-leak-of-vbuf/20240430-132447
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240429030541.56702-1-liweishi%40kylinos.cn
patch subject: [PATCH] [PATCH RESEND] drm/virtio: fix memory leak of vbuf
config: x86_64-defconfig
(https://download.01.org/0day-ci/archive/20240501/202405010502.1bwe3b2s-...@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240501/202405010502.1bwe3b2s-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202405010502.1bwe3b2s-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/virtio/virtgpu_vq.c: In function 'virtio_gpu_queue_cursor':
>> drivers/gpu/drm/virtio/virtgpu_vq.c:474:9: error: expected '}' before 'else'
474 | else if (ret < 0) {
| ^~~~
vim +474 drivers/gpu/drm/virtio/virtgpu_vq.c
448
449 static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
450 struct virtio_gpu_vbuffer *vbuf)
451 {
452 struct virtqueue *vq = vgdev->cursorq.vq;
453 struct scatterlist *sgs[1], ccmd;
454 int idx, ret, outcnt;
455 bool notify;
456
457 if (!drm_dev_enter(vgdev->ddev, )) {
458 free_vbuf(vgdev, vbuf);
459 return;
460 }
461
462 sg_init_one(, vbuf->buf, vbuf->size);
463 sgs[0] =
464 outcnt = 1;
465
466 spin_lock(>cursorq.qlock);
467 retry:
468 ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
469 if (ret == -ENOSPC) {
470 spin_unlock(>cursorq.qlock);
471 wait_event(vgdev->cursorq.ack_queue, vq->num_free >=
outcnt);
472 spin_lock(>cursorq.qlock);
473 goto retry;
> 474 else if (ret < 0) {
475 free_vbuf(vgdev, vbuf);
476 } else {
477 vbuf->seqno = ++vgdev->cursorq.seqno;
478 trace_virtio_gpu_cmd_queue(vq,
479 virtio_gpu_vbuf_ctrl_hdr(vbuf),
480 vbuf->seqno);
481
482 notify = virtqueue_kick_prepare(vq);
483 }
484
485 spin_unlock(>cursorq.qlock);
486
487 if (notify)
488 virtqueue_notify(vq);
489
490 drm_dev_exit(idx);
491 }
492
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: Re: drm/debugfs: Drop conditionals around of_node pointers
Hi,
On Mon, Apr 29, 2024 at 6:16 PM 隋景峰 wrote:
>
> Hi,
>
>
> > -原始邮件-
> > 发件人: "Maxime Ripard"
> > 发送时间: 2024-04-29 19:30:24 (星期一)
> > 收件人: "Sui Jingfeng"
> > 抄送: "Sui Jingfeng" , "Maarten Lankhorst"
> > , "Thomas Zimmermann"
> > , "David Airlie" , "Daniel Vetter"
> > , "Douglas Anderson" , "Laurent
> > Pinchart" , "Biju Das"
> > , dri-devel@lists.freedesktop.org,
> > linux-ker...@vger.kernel.org
> > 主题: Re: drm/debugfs: Drop conditionals around of_node pointers
> >
> > On Sun, Apr 28, 2024 at 04:52:13PM +0800, Sui Jingfeng wrote:
> > > ping
> > >
> > > 在 2024/3/22 06:22, Sui Jingfeng 写道:
> > > > Having conditional around the of_node pointer of the drm_bridge
> > > > structure
> > > > turns out to make driver code use ugly #ifdef blocks.
> >
> > The code being ugly is an opinion, what problem is it causing exactly?
> >
> > > Drop the conditionals to simplify debugfs.
> >
> > What does it simplifies?
> >
> > > >
> > > > Fixes: d8dfccde2709 ("drm/bridge: Drop conditionals around of_node
> > > > pointers")
> > > > Signed-off-by: Sui Jingfeng
> >
> > Why do we want to backport that patch to stable?
Technically it's not CCing stable and so it's not really incorrect.
...but I agree that this is a bit of a stretch to call it a "Fix".
Maybe drop the "Fixes" line?
> My commit message is written based on commit of d8dfccde2709
>
> $ git show c9e358dfc4a8
>
> This patch is based on commit c9e358dfc4a8 ("driver-core: remove
> conditionals around devicetree pointers").
>
> Having conditional around the of_node pointer of the drm_bridge
> structure turns out to make driver code use ugly #ifdef blocks. Drop the
> conditionals to simplify drivers. While this slightly increases the size
> of struct drm_bridge on non-OF system, the number of bridges used today
> and foreseen tomorrow on those systems is very low, so this shouldn't be
> an issue.
>
> So drop #if conditionals by adding struct device_node forward declaration.
>
> > Maxime
>
> I'm just start to contribute by mimic other people's tone, there seems no need
> to over read.
I think the fact that you skipped the reference to commit c9e358dfc4a8
("driver-core: remove conditionals around devicetree pointers") was
relevant here. Referencing that commit makes it easy for the reader to
see that you are following convention used throughout the kernel and
not just asserting your own opinion about style.
If you add that reference into your commit message and send a v2, I'm
happy to apply it.
-Doug
Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive
On Tue, Apr 30, 2024 at 05:38:02PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
>
> Compile tested, no functionality changes intended
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Signed-off-by: Easwar Hariharan
I'm glad to see this change!
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++---
> drivers/gpu/drm/i915/display/intel_dvo.c | 14 -
> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +--
> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +--
> drivers/gpu/drm/i915/gvt/edid.c | 28 -
> drivers/gpu/drm/i915/gvt/edid.h | 4 +--
> drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
> 19 files changed, 119 insertions(+), 119 deletions(-)
The chances of conflicts are high with this many changes,
but should be easy enough to deal with later, so feel free
to move with this i915 patch on any other tree and we catch-up
later.
Acked-by: Rodrigo Vivi
>
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> index d0c3880d7f80..493e730c685b 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> @@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo,
> u8 addr, u8 *val)
> {
> struct i2c_msg msgs[] = {
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 1,
> .buf = ,
> },
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = I2C_M_RD,
> .len = 1,
> .buf = val,
> @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> {
> u8 buf[2] = { addr, val };
> struct i2c_msg msg = {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 2,
> .buf = buf,
> @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> return i2c_transfer(dvo->i2c_bus, , 1) == 1;
> }
>
> -/** Probes for a CH7017 on the given bus and slave address. */
> +/** Probes for a CH7017 on the given bus and target address. */
> static bool ch7017_init(struct intel_dvo_device *dvo,
> struct i2c_adapter *adapter)
> {
> @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
> break;
> default:
> DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
> - "slave %d.\n",
> - val, adapter->name, dvo->slave_addr);
> + "target %d.\n",
> + val, adapter->name, dvo->target_addr);
> goto fail;
> }
>
> DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
> - str, adapter->name, dvo->slave_addr);
> + str, adapter->name, dvo->target_addr);
> return true;
>
> fail:
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> index 2e8e85da5a40..534b8544e0a4 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> @@ -153,13 +153,13 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo,
> int addr, u8 *ch)
>
> struct i2c_msg msgs[] = {
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 1,
> .buf = out_buf,
> },
[linux-next:master] BUILD REGRESSION d04466706db5e241ee026f17b5f920e50dee26b5
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: d04466706db5e241ee026f17b5f920e50dee26b5 Add linux-next specific files for 20240430 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404301738.j71xgyar-...@intel.com Unverified Error/Warning (likely false positive, please contact us if interested): drivers/virt/acrn/mm.c:217 acrn_vm_ram_map() error: uninitialized symbol 'start_pfn'. drivers/virt/acrn/mm.c:224 acrn_vm_ram_map() error: uninitialized symbol 'ret'. net/ipv6/route.c:5712 rt6_fill_node() error: we previously assumed 'dst' could be null (see line 5697) Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used |-- arc-allmodconfig | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used |-- arc-allyesconfig | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used |-- arc-randconfig-r121-20240430 | |-- drivers-hwmon-pmbus-xdp710.c:sparse:sparse:symbol-micro_ohm_rsense-was-not-declared.-Should-it-be-static | |-- fs-bcachefs-btree_cache.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-struct-task_struct-got-unsigned-long | `-- fs-ext4-orphan.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-restricted-__le32-_prev_-got-unsigned-long |-- arc-randconfig-r122-20240430 | |-- block-blk-mq.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-struct-request | |-- block-blk-mq.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-struct-request | |-- block-blk-mq.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-struct-request-got-unsigned-long | |-- drivers-dma-buf-dma-fence-chain.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-struct-dma_fence-noderef-__rcu | |-- drivers-dma-buf-dma-fence-chain.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-struct-dma_fence-noderef-__rcu | |-- drivers-dma-buf-dma-fence-chain.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-struct-dma_fence-noderef-__rcu-got-unsigned-long | |-- drivers-nvme-target-fabrics-cmd.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-struct-nvmet_ctrl | |-- drivers-nvme-target-fabrics-cmd.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-struct-nvmet_ctrl | |-- drivers-nvme-target-fabrics-cmd.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-struct-nvmet_ctrl-got-unsigned-long | |-- fs-btrfs-raid56.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-struct-btrfs_stripe_hash_table | |-- fs-btrfs-raid56.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-struct-btrfs_stripe_hash_table | |-- fs-btrfs-raid56.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-struct-btrfs_stripe_hash_table-got-unsigned-long | |-- fs-crypto-hooks.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-char | |-- fs-crypto-hooks.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-char | |-- fs-crypto-hooks.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-char-got-unsigned-long | |-- fs-crypto-keysetup.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-struct-fscrypt_inode_info | |-- fs-crypto-keysetup.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-struct-fscrypt_inode_info | |-- fs-crypto-keysetup.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-struct-fscrypt_inode_info-got-unsigned-long | |-- fs-debugfs-file.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-void | |-- fs-debugfs-file.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-void | |-- fs-debugfs-file.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-void-got-unsigned-long | |-- fs-ext4-orphan.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-new-got-restricted-__le32-_n_ | |-- fs-ext4-orphan.c:sparse:sparse:incorrect-type-in-argument-(different-base-types)-expected-unsigned-long-usertype-old-got-restricted-__le32-_o_ | |-- fs-libfs.c:sparse:sparse:incorrect-type-in-argument
[PULL] drm-intel-next
Hi Dave and Sima,
Here goes one extra, and really the last one targeting 6.10.
We have decided to do this extra one so we could include the
good clean-up on i915/xe's fbdev work done by Thomas Zimmermann.
And it looks like he has more work on top of that, so it would
be good to propagate this initial one sooner and sync our trees.
Thanks,
Rodrigo.
drm-intel-next-2024-04-30:
Core DRM:
- Export drm_client_dev_unregister (Thomas Zimmermann)
Display i915:
- More initial work to make display code more independent from i915 (Jani)
- Convert i915/xe fbdev to DRM client (Thomas Zimmermann)
- VLV/CHV DPIO register cleanup (Ville)
The following changes since commit 6068bc209ac8d07a5d04e93f168465195e22a4cc:
drm/i915/dsi: pass display to register macros instead of implicit variable
(2024-04-23 17:00:14 +0300)
are available in the Git repository at:
https://anongit.freedesktop.org/git/drm/drm-intel
tags/drm-intel-next-2024-04-30
for you to fetch changes up to 6f1923f54d77942376f47d05b08cddca19fc397f:
drm/i915/dpio: Extract vlv_dpio_phy_regs.h (2024-04-30 21:20:52 +0300)
Core DRM:
- Export drm_client_dev_unregister (Thomas Zimmermann)
Display i915:
- More initial work to make display code more independent from i915 (Jani)
- Convert i915/xe fbdev to DRM client (Thomas Zimmermann)
- VLV/CHV DPIO register cleanup (Ville)
Jani Nikula (13):
drm/i915: convert _MMIO_PIPE3()/_MMIO_PORT3() to accept base
drm/i915: pass dev_priv to _MMIO_PIPE2, _MMIO_TRANS2, _MMIO_CURSOR2
drm/i915/audio: move LPE audio regs to intel_audio_regs.h
drm/i915/color: move palette registers to intel_color_regs.h
drm/i915/display: split out intel_fbc_regs.h from i915_reg.h
drm/i915/display: split out intel_sprite_regs.h from i915_reg.h
drm/i915: pass dev_priv explicitly to PALETTE
drm/i915: pass dev_priv explicitly to PIPE_WGC_C01_C00
drm/i915: pass dev_priv explicitly to PIPE_WGC_C02
drm/i915: pass dev_priv explicitly to PIPE_WGC_C11_C10
drm/i915: pass dev_priv explicitly to PIPE_WGC_C12
drm/i915: pass dev_priv explicitly to PIPE_WGC_C21_C20
drm/i915: pass dev_priv explicitly to PIPE_WGC_C22
Thomas Zimmermann (6):
drm/client: Export drm_client_dev_unregister()
drm/i915: Move fbdev functions
drm/i915: Initialize fbdev DRM client with callback functions
drm/{i915,xe}: Unregister in-kernel clients
drm/{i915,xe}: Implement fbdev client callbacks
drm/{i915, xe}: Implement fbdev emulation as in-kernel client
Ville Syrjälä (14):
drm/i915/dpio: Remove pointless VLV_PCS01_DW8 read
drm/i915/dpio: s/VLV_REF_DW13/VLV_REF_DW11/
drm/i915/dpio: s/VLV_PLL_DW9_BCAST/VLV_PCS_DW17_BCAST/
drm/i915/dpio: Fix VLV DPIO PLL register dword numbering
drm/i915/dpio: Remove pointless variables from vlv/chv DPLL code
drm/i915/dpio: Rename some variables
drm/i915/dpio: s/port/ch/
drm/i915/dpio: s/pipe/ch/
drm/i915/dpio: Derive the phy from the port rather than pipe in encoder
hooks
drm/i915/dpio: Give VLV DPIO group register a clearer name
drm/i915/dpio: Rename a few CHV DPIO PHY registers
drm/i915/dpio: Clean up VLV/CHV DPIO PHY register defines
drm/i915/dpio: Clean up the vlv/chv PHY register bits
drm/i915/dpio: Extract vlv_dpio_phy_regs.h
drivers/gpu/drm/drm_client.c | 13 +
drivers/gpu/drm/i915/display/intel_audio_regs.h| 16 +
drivers/gpu/drm/i915/display/intel_color.c | 53 +-
drivers/gpu/drm/i915/display/intel_color_regs.h| 42 +-
drivers/gpu/drm/i915/display/intel_display.c |2 +-
.../gpu/drm/i915/display/intel_display_driver.c| 24 +-
.../drm/i915/display/intel_display_power_well.c| 16 +-
.../gpu/drm/i915/display/intel_display_reg_defs.h | 22 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 148 ++-
drivers/gpu/drm/i915/display/intel_dpll.c | 262 +++--
drivers/gpu/drm/i915/display/intel_fbc.c |1 +
drivers/gpu/drm/i915/display/intel_fbc_regs.h | 120 +++
drivers/gpu/drm/i915/display/intel_fbdev.c | 265 ++---
drivers/gpu/drm/i915/display/intel_fbdev.h | 29 +-
drivers/gpu/drm/i915/display/intel_lpe_audio.c |2 +-
drivers/gpu/drm/i915/display/intel_psr_regs.h | 38 +-
drivers/gpu/drm/i915/display/intel_sprite.c|1 +
drivers/gpu/drm/i915/display/intel_sprite_regs.h | 348 ++
drivers/gpu/drm/i915/display/vlv_dpio_phy_regs.h | 309 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c|2 +
drivers/gpu/drm/i915/gvt/cmd_parser.c |1 +
drivers/gpu/drm/i915/gvt/display.c |1 +
drivers/gpu/drm/i915/gvt/fb_decoder.c |5 +-
drivers/gpu/drm/i915/gvt/handlers.c|1 +
Re: [PATCH v3 2/7] drm/panel: himax-hx83102: Break out as separate driver
Hi,
On Tue, Apr 23, 2024 at 7:30 PM Cong Yang
wrote:
>
> The Starry HX83102 based mipi panel should never have been part of the boe
> tv101wum driver. Discussion with Doug and Linus in V1 [1], we need a
> separate driver to enable the hx83102 controller.
>
> In hx83102 driver, add DSI commands as macros. So it can add some panels
> with same control model in the future.
>
> [1]:
> https://lore.kernel.org/all/CACRpkdbzYZAS0=zbqjuc4cb2wj4s1h6n6asazqvdmv95r3z...@mail.gmail.com
>
> Signed-off-by: Cong Yang
> ---
> Chage since V3:
>
> - Drop excess flags and function, inital cmds use lowercasehex.
>
> V2:
> https://lore.kernel.org/all/20240422090310.3311429-3-yangco...@huaqin.corp-partner.google.com
>
> ---
> drivers/gpu/drm/panel/Kconfig | 9 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 99
> drivers/gpu/drm/panel/panel-himax-hx83102.c | 525 ++
> 4 files changed, 535 insertions(+), 99 deletions(-)
It probably makes sense to base your series upon mine that reduces
bloat / introduces a better way to do these init sequences. I'm going
to wait one more day in case anyone else has any more comments on my
v2 and then I'll post my v3. So far everyone has been on-board with
the overall goal and so all we need to do is iron out the small
details, so I don't expect it to take too long.
If you want to wait a day or two and then post your patches atop my v3
(once I post it) then that would be OK by me.
> @@ -0,0 +1,525 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for panels based on Himax HX83102 controller, such as:
> + *
> + * - Starry 10.51" WUXGA MIPI-DSI panel
> + *
> + * Based on drivers/gpu/drm/panel/panel-boe-tv101wum.c
The above file doesn't exist? Maybe you forgot the "-nl6" suffix? I
would also say that this driver appears to be more similar to
`panel-himax-hx8394.c` even if the data came from
`panel-boe-tv101wum-nl6.c`.
...also, since this is based on `panel-himax-hx8394.c`, it seems like
you're making pretty significant changes here. For instance, when this
code was part of `panel-boe-tv101wum-nl6.c` it used to do the "init
commands" as part of prepare. With the new driver it does it as part
of "enable". IMO even if the new code based on `panel-himax-hx8394.c`
is more correct, I'd rather see you change that in a separate change.
In this change, which is supposed to be more about code refactoring, I
think you should focus on keeping the behavior before and after your
patch identical.
> +/* Manufacturer specific DSI commands */
> +#define HX83102_SETPOWER 0xb1
> +#define HX83102_SETDISP0xb2
> +#define HX83102_SETCYC 0xb4
> +#define HX83102_SETEXTC0xb9
> +#define HX83102_SETMIPI0xba
> +#define HX83102_SETVDC 0xbc
> +#define HX83102_SETBANK0xbd
> +#define HX83102_UNKNOWN1 0xbe
I'm not sure that the "unknown" define helps much, but I guess it's
fine. One nit would be to call this UNKNOWN_BE based on the address so
that if we can later replace some of the unknowns then there won't be
gaps in the numbering.
> +#define HX83102_SETPTBA0xbf
> +#define HX83102_SETSTBA0xc0
> +#define HX83102_SETTCON0xc7
> +#define HX83102_SETRAMDMY 0xc8
> +#define HX83102_SETPWM 0xc9
> +#define HX83102_SETCLOCK 0xcb
> +#define HX83102_SETPANEL 0xcc
> +#define HX83102_SETCASCADE 0xd0
> +#define HX83102_SETPCTRL 0xd1
> +#define HX83102_UNKNOWN2 0xd2
> +#define HX83102_SETGIP00xd3
> +#define HX83102_SETGIP10xd5
> +#define HX83102_UNKNOWN3 0xd6
Given everything surrounding it and given a datasheet I have for a
similar panel, I'm going to guess UNKNOWN3 is "GIP2".
> +#define HX83102_SETGIP30xd8
> +#define HX83102_UNKNOWN4 0xe0
I think UNKNOWN4 is SETGMA to set the gamma curve.
> +static int starry_init_cmd(struct hx83102 *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi;
> +
> + mipi_dsi_dcs_write_seq(dsi, HX83102_SETEXTC, 0x83, 0x10, 0x21, 0x55,
> 0x00);
As far as I can tell from looking at a different (but similar)
datasheet, the above means "enable extended command set". Assuming I'm
correct, maybe you could abstract out:
static int hx83102_enable_extended_cmds(struct hx83102 *ctx, bool enable)
{
if (enable)
mipi_dsi_dcs_write_seq(dsi, HX83102_SETEXTC, 0x83, 0x10, 0x21, 0x55, 0x00);
else
mipi_dsi_dcs_write_seq(dsi, HX83102_SETEXTC, 0x00, 0x00, 0x00);
}
Then your panel-specific init functions could call that?
Speaking of which, some of the panels that you add to this driver seem
to disable extended commands at the end of their init sequence, but
this one doesn't. Should it?
> + mipi_dsi_dcs_write_seq(dsi, HX83102_SETPOWER, 0x2c, 0xb5, 0xb5, 0x31,
> 0xf1, 0x31, 0xd7, 0x2f,
> +
Re: [RFC PATCH net-next v8 07/14] page_pool: devmem support
On Tue, Apr 30, 2024 at 11:55 AM Jens Axboe wrote:
>
> On 4/30/24 12:29 PM, Mina Almasry wrote:
> > On Tue, Apr 30, 2024 at 6:46?AM Jens Axboe wrote:
> >>
> >> On 4/26/24 8:11 PM, Mina Almasry wrote:
> >>> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
>
> On 2024-04-02 5:20 pm, Mina Almasry wrote:
> > @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
> > */
> > typedef unsigned long __bitwise netmem_ref;
> >
> > +static inline bool netmem_is_net_iov(const netmem_ref netmem)
> > +{
> > +#if defined(CONFIG_PAGE_POOL) && defined(CONFIG_DMA_SHARED_BUFFER)
>
> I am guessing you added this to try and speed up the fast path? It's
> overly restrictive for us since we do not need dmabuf necessarily. I
> spent a bit too much time wondering why things aren't working only to
> find this :(
> >>>
> >>> My apologies, I'll try to put the changelog somewhere prominent, or
> >>> notify you when I do something that I think breaks you.
> >>>
> >>> Yes, this is a by-product of a discussion with regards to the
> >>> page_pool benchmark regressions due to adding devmem. There is some
> >>> background on why this was added and the impact on the
> >>> bench_page_pool_simple tests in the cover letter.
> >>>
> >>> For you, I imagine you want to change this to something like:
> >>>
> >>> #if defined(CONFIG_PAGE_POOL)
> >>> #if defined(CONFIG_DMA_SHARED_BUFFER) || defined(CONFIG_IOURING)
> >>>
> >>> or something like that, right? Not sure if this is something I should
> >>> do here or if something more appropriate to be in the patches you
> >>> apply on top.
> >>
> >> In general, attempting to hide overhead behind config options is always
> >> a losing proposition. It merely serves to say "look, if these things
> >> aren't enabled, the overhead isn't there", while distros blindly enable
> >> pretty much everything and then you're back where you started.
> >>
> >
> > The history there is that this check adds 1 cycle regression to the
> > page_pool fast path benchmark. The regression last I measured is 8->9
> > cycles, so in % wise it's a quite significant 12.5% (more details in
> > the cover letter[1]). I doubt I can do much better than that to be
> > honest.
>
> I'm all for cycle counting, and do it myself too, but is that even
> measurable in anything that isn't a super targeted microbenchmark? Or
> even in that?
>
Not as far as I can tell, no. This was purely to improve the page_pool
benchmark.
> > There was a desire not to pay this overhead in setups that will likely
> > not care about devmem, like embedded devices maybe, or setups without
> > GPUs. Adding a CONFIG check here seemed like very low hanging fruit,
> > but yes it just hides the overhead in some configs, not really removes
> > it.
> >
> > There was a discussion about adding this entire netmem/devmem work
> > under a new CONFIG. There was pushback particularly from Willem that
> > at the end of the day what is enabled on most distros is what matters
> > and we added code churn and CONFIG churn for little value.
> >
> > If there is significant pushback to the CONFIG check I can remove it.
> > I don't feel like it's critical, it just mirco-optimizes some setups
> > that doesn't really care about this work area.
>
> That is true, but in practice it'll be enabled anyway. Seems like it's
> not really worth it in this scenario.
>
OK, no pushback from me. I'll remove the CONFIG check in the next iteration.
--
Thanks,
Mina
Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range
On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote: > On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote: > > > > Yes there is another common scheme where you bind a window of CPU to > > > a > > > window on the device and mirror a fixed range, but this is a quite > > > different thing. It is not SVA, it has a fixed range, and it is > > > probably bound to a single GPU VMA in a multi-VMA device page table. > > > > And this above here is exactly what we're implementing, and the GPU > > page-tables are populated using device faults. Regions (large) of the > > mirrored CPU mm need to coexist in the same GPU vm as traditional GPU > > buffer objects. > > Well, not really, if that was the case you'd have a single VMA over > the entire bound range, not dynamically create them. > > A single VMA that uses hmm_range_fault() to populate the VM is > completely logical. > > Having a hidden range of mm binding and then creating/destroying 2M > VMAs dynamicaly is the thing that doesn't make alot of sense. I only noticed this thread now but fyi I did dig around in the implementation and it's summarily an absolute no-go imo for multiple reasons. It starts with this approach of trying to mirror cpu vma (which I think originated from amdkfd) leading to all kinds of locking fun, and then it gets substantially worse when you dig into the details. I think until something more solid shows up you can just ignore this. I do fully agree that for sva the main mirroring primitive needs to be page centric, so dma_map_sg. There's a bit a question around how to make the necessary batching efficient and the locking/mmu_interval_notifier scale enough, but I had some long chats with Thomas and I think there's enough option to spawn pretty much any possible upstream consensus. So I'm not worried. But first this needs to be page-centric in the fundamental mirroring approach. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC PATCH net-next v8 07/14] page_pool: devmem support
On 4/30/24 12:29 PM, Mina Almasry wrote:
> On Tue, Apr 30, 2024 at 6:46?AM Jens Axboe wrote:
>>
>> On 4/26/24 8:11 PM, Mina Almasry wrote:
>>> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
On 2024-04-02 5:20 pm, Mina Almasry wrote:
> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
> */
> typedef unsigned long __bitwise netmem_ref;
>
> +static inline bool netmem_is_net_iov(const netmem_ref netmem)
> +{
> +#if defined(CONFIG_PAGE_POOL) && defined(CONFIG_DMA_SHARED_BUFFER)
I am guessing you added this to try and speed up the fast path? It's
overly restrictive for us since we do not need dmabuf necessarily. I
spent a bit too much time wondering why things aren't working only to
find this :(
>>>
>>> My apologies, I'll try to put the changelog somewhere prominent, or
>>> notify you when I do something that I think breaks you.
>>>
>>> Yes, this is a by-product of a discussion with regards to the
>>> page_pool benchmark regressions due to adding devmem. There is some
>>> background on why this was added and the impact on the
>>> bench_page_pool_simple tests in the cover letter.
>>>
>>> For you, I imagine you want to change this to something like:
>>>
>>> #if defined(CONFIG_PAGE_POOL)
>>> #if defined(CONFIG_DMA_SHARED_BUFFER) || defined(CONFIG_IOURING)
>>>
>>> or something like that, right? Not sure if this is something I should
>>> do here or if something more appropriate to be in the patches you
>>> apply on top.
>>
>> In general, attempting to hide overhead behind config options is always
>> a losing proposition. It merely serves to say "look, if these things
>> aren't enabled, the overhead isn't there", while distros blindly enable
>> pretty much everything and then you're back where you started.
>>
>
> The history there is that this check adds 1 cycle regression to the
> page_pool fast path benchmark. The regression last I measured is 8->9
> cycles, so in % wise it's a quite significant 12.5% (more details in
> the cover letter[1]). I doubt I can do much better than that to be
> honest.
I'm all for cycle counting, and do it myself too, but is that even
measurable in anything that isn't a super targeted microbenchmark? Or
even in that?
> There was a desire not to pay this overhead in setups that will likely
> not care about devmem, like embedded devices maybe, or setups without
> GPUs. Adding a CONFIG check here seemed like very low hanging fruit,
> but yes it just hides the overhead in some configs, not really removes
> it.
>
> There was a discussion about adding this entire netmem/devmem work
> under a new CONFIG. There was pushback particularly from Willem that
> at the end of the day what is enabled on most distros is what matters
> and we added code churn and CONFIG churn for little value.
>
> If there is significant pushback to the CONFIG check I can remove it.
> I don't feel like it's critical, it just mirco-optimizes some setups
> that doesn't really care about this work area.
That is true, but in practice it'll be enabled anyway. Seems like it's
not really worth it in this scenario.
--
Jens Axboe
Re: [PATCH v8 29/35] dyndbg: add __counted_by annotations
On Mon, Apr 29, 2024 at 1:39 PM Jim Cromie wrote: > > Tell the compiler about our vectors (array,length), in 2 places: > these are not flex-arrays, using counted-by is wrong here. Ive dropped this commit, series rebases clean wo it. > h: struct _ddebug_info, which keeps refs to the __dyndbg_* ELF/DATA > sections, these are all vectors with a length. >
Re: [PATCH v2] drm/amd/display: re-indent dc_power_down_on_boot()
On 2024-04-25 07:21, Dan Carpenter wrote:
> These lines are indented too far. Clean the whitespace.
>
Thanks.
Reviewed-by: Harry Wentland
In the process of merging it into amd-staging-drm-next.
Harry
> Signed-off-by: Dan Carpenter
> ---
> v2: Delete another blank line (checkpatch.pl --strict).
>
> drivers/gpu/drm/amd/display/dc/core/dc.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 3e16041bf4f9..5a0835f884a8 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -5192,11 +5192,9 @@ void dc_interrupt_ack(struct dc *dc, enum
> dc_irq_source src)
> void dc_power_down_on_boot(struct dc *dc)
> {
> if (dc->ctx->dce_environment != DCE_ENV_VIRTUAL_HW &&
> - dc->hwss.power_down_on_boot) {
> -
> - if (dc->caps.ips_support)
> - dc_exit_ips_for_hw_access(dc);
> -
> + dc->hwss.power_down_on_boot) {
> + if (dc->caps.ips_support)
> + dc_exit_ips_for_hw_access(dc);
> dc->hwss.power_down_on_boot(dc);
> }
> }
Re: [PATCH][next] drm/amd/display: Fix spelling various spelling mistakes
On 2024-04-24 12:28, Colin Ian King wrote:
> There are various spelling mistakes in dml2_printf messages, fix them.
>
Thanks.
Reviewed-by: Harry Wentland
In the process of merging it into amd-staging-drm-next.
Harry
> Signed-off-by: Colin Ian King
> ---
> .../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 6 +++---
> .../display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
>
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> index 846b0ae48596..2dea5965d02f 100644
> ---
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> +++
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> @@ -5566,7 +5566,7 @@ static bool CalculatePrefetchSchedule(struct
> dml2_core_internal_scratch *scratch
> dml2_printf("DML: Tvm: %fus - time to fetch vm\n",
> s->TimeForFetchingVM);
> dml2_printf("DML: Tr0: %fus - time to fetch first row of data
> pagetables\n", s->TimeForFetchingRowInVBlank);
> dml2_printf("DML: Tsw: %fus = time to fetch enough pixel data
> and cursor data to feed the scalers init position and detile\n",
> (double)s->LinesToRequestPrefetchPixelData * s->LineTime);
> - dml2_printf("DML: To: %fus - time for propogation from scaler
> to optc\n", (*p->DSTYAfterScaler + ((double)(*p->DSTXAfterScaler) /
> (double)p->myPipe->HTotal)) * s->LineTime);
> + dml2_printf("DML: To: %fus - time for propagation from scaler
> to optc\n", (*p->DSTYAfterScaler + ((double)(*p->DSTXAfterScaler) /
> (double)p->myPipe->HTotal)) * s->LineTime);
> dml2_printf("DML: Tvstartup - TSetup - Tcalc - TWait - Tpre -
> To > 0\n");
> dml2_printf("DML: Tslack(pre): %fus - time left over in
> schedule\n", p->VStartup * s->LineTime - s->TimeForFetchingVM - 2 *
> s->TimeForFetchingRowInVBlank - (*p->DSTYAfterScaler +
> ((double)(*p->DSTXAfterScaler) / (double)p->myPipe->HTotal)) * s->LineTime -
> p->TWait - p->TCalc - *p->TSetup);
> dml2_printf("DML: row_bytes = dpte_row_bytes (per_pipe) =
> PixelPTEBytesPerRow = : %u\n", p->PixelPTEBytesPerRow);
> @@ -7825,7 +7825,7 @@ static bool dml_core_mode_support(struct
> dml2_core_calcs_mode_support_ex *in_out
> dml2_printf("DML::%s: mode_lib->ms.FabricClock = %f\n", __func__,
> mode_lib->ms.FabricClock);
> dml2_printf("DML::%s: mode_lib->ms.uclk_freq_mhz = %f\n", __func__,
> mode_lib->ms.uclk_freq_mhz);
> dml2_printf("DML::%s: max_urgent_latency_us = %f\n", __func__,
> mode_lib->ms.support.max_urgent_latency_us);
> - dml2_printf("DML::%s: urgent latency tolarance = %f\n", __func__,
> ((mode_lib->ip.rob_buffer_size_kbytes - mode_lib->ip.pixel_chunk_size_kbytes)
> * 1024 / (mode_lib->ms.DCFCLK * mode_lib->soc.return_bus_width_bytes)));
> + dml2_printf("DML::%s: urgent latency tolerance = %f\n", __func__,
> ((mode_lib->ip.rob_buffer_size_kbytes - mode_lib->ip.pixel_chunk_size_kbytes)
> * 1024 / (mode_lib->ms.DCFCLK * mode_lib->soc.return_bus_width_bytes)));
> dml2_printf("DML::%s: ROBSupport = %u\n", __func__,
> mode_lib->ms.support.ROBSupport);
> #endif
>
> @@ -10603,7 +10603,7 @@ static bool dml_core_mode_programming(struct
> dml2_core_calcs_mode_programming_ex
> if
> (display_cfg->plane_descriptors[k].immediate_flip &&
> mode_lib->mp.ImmediateFlipSupportedForPipe[k] == false) {
> mode_lib->mp.ImmediateFlipSupported =
> false;
> #ifdef __DML_VBA_DEBUG__
> - dml2_printf("DML::%s: Pipe %0d not
> supporing iflip!\n", __func__, k);
> + dml2_printf("DML::%s: Pipe %0d not
> supporting iflip!\n", __func__, k);
> #endif
> }
> }
> diff --git
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> index 0ef77a89d984..d1d4fe062d4e 100644
> ---
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> +++
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> @@ -2023,7 +2023,7 @@ bool dml2_core_shared_mode_support(struct
> dml2_core_calcs_mode_support_ex *in_ou
> dml2_printf("DML::%s: mode_lib->ms.FabricClock = %f\n", __func__,
> mode_lib->ms.FabricClock);
> dml2_printf("DML::%s: mode_lib->ms.uclk_freq_mhz = %f\n", __func__,
> mode_lib->ms.uclk_freq_mhz);
> dml2_printf("DML::%s: max_urgent_latency_us = %f\n", __func__,
> mode_lib->ms.support.max_urgent_latency_us);
> - dml2_printf("DML::%s: urgent latency tolarance = %f\n", __func__,
> ((mode_lib->ip.rob_buffer_size_kbytes -
Re: [PATCH] drm/amd/display: Avoid -Wenum-float-conversion in add_margin_and_round_to_dfs_grainularity()
On 2024-04-24 12:14, Nathan Chancellor wrote:
> When building with clang 19 or newer (which strengthened some of the
> enum conversion warnings for C), there is a warning (or error with
> CONFIG_WERROR=y) around doing arithmetic with an enumerated type and a
> floating point expression.
>
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c:181:58:
> error: arithmetic between enumeration type 'enum dentist_divider_range' and
> floating-point type 'double' [-Werror,-Wenum-float-conversion]
> 181 | divider = (unsigned int)(DFS_DIVIDER_RANGE_SCALE_FACTOR *
> (vco_freq_khz / clock_khz));
> | ~~ ^
> ~~
> 1 error generated.
>
> This conversion is expected due to the nature of the enumerated value
> and definition, so silence the warning by casting the enumeration to an
> integer explicitly to make it clear to the compiler.
>
> Fixes: 3df48ddedee4 ("drm/amd/display: Add new DCN401 sources")
Thanks.
Reviewed-by: Harry Wentland
In the process of merging it into amd-staging-drm-next.
Harry
> Signed-off-by: Nathan Chancellor
> ---
> Alternatively, perhaps the potential truncation could happen before the
> multiplication?
>
> divider = DFS_DIVIDER_RANGE_SCALE_FACTOR * (unsigned int)(vco_freq_khz /
> clock_khz);
>
> I suspect the result of the division is probably not very large
> (certainly not within UINT_MAX / 4), so I would not expect the
> multiplication to overflow, but I was not sure so I decided to take the
> safer, NFC change. I am happy to respin as necessary.
> ---
> .../gpu/drm/amd/display/dc/dml2/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c| 2
> +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c
> index e6698ee65843..65eb0187e965 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_dpmm/dml2_dpmm_dcn4.c
> @@ -178,7 +178,7 @@ static bool
> add_margin_and_round_to_dfs_grainularity(double clock_khz, double ma
>
> clock_khz *= 1.0 + margin;
>
> - divider = (unsigned int)(DFS_DIVIDER_RANGE_SCALE_FACTOR * (vco_freq_khz
> / clock_khz));
> + divider = (unsigned int)((int)DFS_DIVIDER_RANGE_SCALE_FACTOR *
> (vco_freq_khz / clock_khz));
>
> /* we want to floor here to get higher clock than required rather than
> lower */
> if (divider < DFS_DIVIDER_RANGE_2_START) {
>
> ---
> base-commit: d60dc4dd72412d5d9566fdf391e4202b05f88912
> change-id: 20240424-amdgpu-display-dcn401-enum-float-conversion-c09cc1826ea2
>
> Best regards,
Re: [RFC PATCH net-next v8 07/14] page_pool: devmem support
On Tue, Apr 30, 2024 at 6:46 AM Jens Axboe wrote:
>
> On 4/26/24 8:11 PM, Mina Almasry wrote:
> > On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
> >>
> >> On 2024-04-02 5:20 pm, Mina Almasry wrote:
> >>> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
> >>> */
> >>> typedef unsigned long __bitwise netmem_ref;
> >>>
> >>> +static inline bool netmem_is_net_iov(const netmem_ref netmem)
> >>> +{
> >>> +#if defined(CONFIG_PAGE_POOL) && defined(CONFIG_DMA_SHARED_BUFFER)
> >>
> >> I am guessing you added this to try and speed up the fast path? It's
> >> overly restrictive for us since we do not need dmabuf necessarily. I
> >> spent a bit too much time wondering why things aren't working only to
> >> find this :(
> >
> > My apologies, I'll try to put the changelog somewhere prominent, or
> > notify you when I do something that I think breaks you.
> >
> > Yes, this is a by-product of a discussion with regards to the
> > page_pool benchmark regressions due to adding devmem. There is some
> > background on why this was added and the impact on the
> > bench_page_pool_simple tests in the cover letter.
> >
> > For you, I imagine you want to change this to something like:
> >
> > #if defined(CONFIG_PAGE_POOL)
> > #if defined(CONFIG_DMA_SHARED_BUFFER) || defined(CONFIG_IOURING)
> >
> > or something like that, right? Not sure if this is something I should
> > do here or if something more appropriate to be in the patches you
> > apply on top.
>
> In general, attempting to hide overhead behind config options is always
> a losing proposition. It merely serves to say "look, if these things
> aren't enabled, the overhead isn't there", while distros blindly enable
> pretty much everything and then you're back where you started.
>
The history there is that this check adds 1 cycle regression to the
page_pool fast path benchmark. The regression last I measured is 8->9
cycles, so in % wise it's a quite significant 12.5% (more details in
the cover letter[1]). I doubt I can do much better than that to be
honest.
There was a desire not to pay this overhead in setups that will likely
not care about devmem, like embedded devices maybe, or setups without
GPUs. Adding a CONFIG check here seemed like very low hanging fruit,
but yes it just hides the overhead in some configs, not really removes
it.
There was a discussion about adding this entire netmem/devmem work
under a new CONFIG. There was pushback particularly from Willem that
at the end of the day what is enabled on most distros is what matters
and we added code churn and CONFIG churn for little value.
If there is significant pushback to the CONFIG check I can remove it.
I don't feel like it's critical, it just mirco-optimizes some setups
that doesn't really care about this work area.
[1]
https://lore.kernel.org/netdev/20240403002053.2376017-1-almasrym...@google.com/
--
Thanks,
Mina
Re: [PATCH] drm/uapi: Move drm_color_ctm_3x4 out from drm_mode.h
On 2024-04-22 04:58, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_color_ctm_3x4 is some undocumented amgdpu private
> uapi and thus has no business being in drm_mode.h.
> At least move it to some amdgpu specific header, albeit
> with the wrong namespace as maybe something somewhere
> is using this already?
>
> Cc: Harry Wentland
> Cc: Joshua Ashton
> Cc: Alex Deucher
> Fixes: 6872a189be50 ("drm/amd/display: Add 3x4 CTM support for plane CTM")
> Signed-off-by: Ville Syrjälä
We'll bring this back with the color pipeline stuff but for now it doesn't
need to sit in drm_mode.h and probably shouldn't.
Reviewed-by: Harry Wentland
Harry
> ---
> include/uapi/drm/amdgpu_drm.h | 9 +
> include/uapi/drm/drm_mode.h | 8
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> index 96e32dafd4f0..d5ebafacdd70 100644
> --- a/include/uapi/drm/amdgpu_drm.h
> +++ b/include/uapi/drm/amdgpu_drm.h
> @@ -1269,6 +1269,15 @@ struct drm_amdgpu_info_gpuvm_fault {
> #define AMDGPU_FAMILY_GC_10_3_7 151 /* GC 10.3.7 */
> #define AMDGPU_FAMILY_GC_11_5_0 150 /* GC 11.5.0 */
>
> +/* FIXME wrong namespace! */
> +struct drm_color_ctm_3x4 {
> + /*
> + * Conversion matrix with 3x4 dimensions in S31.32 sign-magnitude
> + * (not two's complement!) format.
> + */
> + __u64 matrix[12];
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 1ca5c7e418fd..d390011b89b4 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -846,14 +846,6 @@ struct drm_color_ctm {
> __u64 matrix[9];
> };
>
> -struct drm_color_ctm_3x4 {
> - /*
> - * Conversion matrix with 3x4 dimensions in S31.32 sign-magnitude
> - * (not two's complement!) format.
> - */
> - __u64 matrix[12];
> -};
> -
> struct drm_color_lut {
> /*
>* Values are mapped linearly to 0.0 - 1.0 range, with 0x0 == 0.0 and
[PATCH v1 12/12] fbdev/viafb: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/video/fbdev/via/chip.h| 8
drivers/video/fbdev/via/dvi.c | 24
drivers/video/fbdev/via/lcd.c | 6 +++---
drivers/video/fbdev/via/via_aux.h | 2 +-
drivers/video/fbdev/via/via_i2c.c | 12 ++--
drivers/video/fbdev/via/vt1636.c | 6 +++---
6 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/via/chip.h b/drivers/video/fbdev/via/chip.h
index f0a19cbcb9e5..1ea6d4ce79e7 100644
--- a/drivers/video/fbdev/via/chip.h
+++ b/drivers/video/fbdev/via/chip.h
@@ -69,7 +69,7 @@
#define VT1632_TMDS 0x01
#define INTEGRATED_TMDS 0x42
-/* Definition TMDS Trasmitter I2C Slave Address */
+/* Definition TMDS Trasmitter I2C Client Address */
#define VT1632_TMDS_I2C_ADDR0x10
/**/
@@ -88,21 +88,21 @@
#define TX_DATA_DDR_MODE0x04
#define TX_DATA_SDR_MODE0x08
-/* Definition LVDS Trasmitter I2C Slave Address */
+/* Definition LVDS Trasmitter I2C Client Address */
#define VT1631_LVDS_I2C_ADDR0x70
#define VT3271_LVDS_I2C_ADDR0x80
#define VT1636_LVDS_I2C_ADDR0x80
struct tmds_chip_information {
int tmds_chip_name;
- int tmds_chip_slave_addr;
+ int tmds_chip_client_addr;
int output_interface;
int i2c_port;
};
struct lvds_chip_information {
int lvds_chip_name;
- int lvds_chip_slave_addr;
+ int lvds_chip_client_addr;
int output_interface;
int i2c_port;
};
diff --git a/drivers/video/fbdev/via/dvi.c b/drivers/video/fbdev/via/dvi.c
index 13147e3066eb..db7db26416c3 100644
--- a/drivers/video/fbdev/via/dvi.c
+++ b/drivers/video/fbdev/via/dvi.c
@@ -70,7 +70,7 @@ bool viafb_tmds_trasmitter_identify(void)
/* Check for VT1632: */
viaparinfo->chip_info->tmds_chip_info.tmds_chip_name = VT1632_TMDS;
viaparinfo->chip_info->
- tmds_chip_info.tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR;
+ tmds_chip_info.tmds_chip_client_addr = VT1632_TMDS_I2C_ADDR;
viaparinfo->chip_info->tmds_chip_info.i2c_port = VIA_PORT_31;
if (check_tmds_chip(VT1632_DEVICE_ID_REG, VT1632_DEVICE_ID)) {
/*
@@ -128,14 +128,14 @@ bool viafb_tmds_trasmitter_identify(void)
viaparinfo->chip_info->
tmds_chip_info.tmds_chip_name = NON_TMDS_TRANSMITTER;
viaparinfo->chip_info->tmds_chip_info.
- tmds_chip_slave_addr = VT1632_TMDS_I2C_ADDR;
+ tmds_chip_client_addr = VT1632_TMDS_I2C_ADDR;
return false;
}
static void tmds_register_write(int index, u8 data)
{
viafb_i2c_writebyte(viaparinfo->chip_info->tmds_chip_info.i2c_port,
-
viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr,
+
viaparinfo->chip_info->tmds_chip_info.tmds_chip_client_addr,
index, data);
}
@@ -144,7 +144,7 @@ static int tmds_register_read(int index)
u8 data;
viafb_i2c_readbyte(viaparinfo->chip_info->tmds_chip_info.i2c_port,
- (u8)
viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr,
+ (u8)
viaparinfo->chip_info->tmds_chip_info.tmds_chip_client_addr,
(u8) index, );
return data;
}
@@ -152,7 +152,7 @@ static int tmds_register_read(int index)
static int tmds_register_read_bytes(int index, u8 *buff, int buff_len)
{
viafb_i2c_readbytes(viaparinfo->chip_info->tmds_chip_info.i2c_port,
- (u8)
viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr,
+ (u8)
viaparinfo->chip_info->tmds_chip_info.tmds_chip_client_addr,
(u8) index, buff, buff_len);
return 0;
}
@@ -256,14 +256,14 @@ static int viafb_dvi_query_EDID(void)
DEBUG_MSG(KERN_INFO "viafb_dvi_query_EDID!!\n");
- restore = viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr;
- viaparinfo->chip_info->tmds_chip_info.tmds_chip_slave_addr = 0xA0;
+ restore = viaparinfo->chip_info->tmds_chip_info.tmds_chip_client_addr;
+ viaparinfo->chip_info->tmds_chip_info.tmds_chip_client_addr = 0xA0;
data0 = (u8) tmds_register_read(0x00);
data1 = (u8) tmds_register_read(0x01);
if ((data0 == 0) && (data1 == 0xFF)) {
viaparinfo->chip_info->
-
[PATCH v1 11/12] fbdev/smscufx: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/video/fbdev/smscufx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 35d682b110c4..1c80c1a3d516 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1292,7 +1292,7 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev,
struct fb_info *info)
return 0;
}
-/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, master,
+/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, host,
* restart enabled, but no start byte, enable controller */
static int ufx_i2c_init(struct ufx_data *dev)
{
@@ -1321,7 +1321,7 @@ static int ufx_i2c_init(struct ufx_data *dev)
/* 7-bit (not 10-bit) addressing */
tmp &= ~(0x10);
- /* enable restart conditions and master mode */
+ /* enable restart conditions and host mode */
tmp |= 0x21;
status = ufx_reg_write(dev, 0x1000, tmp);
--
2.34.1
[PATCH v1 10/12] sfc: falcon: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Reviewed-by: Martin Habets
Reviewed-by: Simon Horman
Signed-off-by: Easwar Hariharan
---
drivers/net/ethernet/sfc/falcon/falcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/falcon/falcon.c
b/drivers/net/ethernet/sfc/falcon/falcon.c
index 7a1c9337081b..36114ce88034 100644
--- a/drivers/net/ethernet/sfc/falcon/falcon.c
+++ b/drivers/net/ethernet/sfc/falcon/falcon.c
@@ -367,7 +367,7 @@ static const struct i2c_algo_bit_data
falcon_i2c_bit_operations = {
.getsda = falcon_getsda,
.getscl = falcon_getscl,
.udelay = 5,
- /* Wait up to 50 ms for slave to let us pull SCL high */
+ /* Wait up to 50 ms for target to let us pull SCL high */
.timeout= DIV_ROUND_UP(HZ, 20),
};
--
2.34.1
[PATCH v1 09/12] media: cx23885: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/media/pci/cx23885/cx23885-f300.c | 8
drivers/media/pci/cx23885/cx23885-i2c.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/pci/cx23885/cx23885-f300.c
b/drivers/media/pci/cx23885/cx23885-f300.c
index ac1c434e8e24..5f937c281793 100644
--- a/drivers/media/pci/cx23885/cx23885-f300.c
+++ b/drivers/media/pci/cx23885/cx23885-f300.c
@@ -92,7 +92,7 @@ static u8 f300_xfer(struct dvb_frontend *fe, u8 *buf)
f300_set_line(dev, F300_RESET, 0);/* begin to send data */
msleep(1);
- f300_send_byte(dev, 0xe0);/* the slave address is 0xe0, write */
+ f300_send_byte(dev, 0xe0);/* the client address is 0xe0, write */
msleep(1);
temp = buf[0];
@@ -112,10 +112,10 @@ static u8 f300_xfer(struct dvb_frontend *fe, u8 *buf)
}
if (i > 7) {
- pr_err("%s: timeout, the slave no response\n",
+ pr_err("%s: timeout, the client no response\n",
__func__);
- ret = 1; /* timeout, the slave no response */
- } else { /* the slave not busy, prepare for getting data */
+ ret = 1; /* timeout, the client no response */
+ } else { /* the client not busy, prepare for getting data */
f300_set_line(dev, F300_RESET, 0);/*ready...*/
msleep(1);
f300_send_byte(dev, 0xe1);/* 0xe1 is Read */
diff --git a/drivers/media/pci/cx23885/cx23885-i2c.c
b/drivers/media/pci/cx23885/cx23885-i2c.c
index f51fad33dc04..385af2a893b4 100644
--- a/drivers/media/pci/cx23885/cx23885-i2c.c
+++ b/drivers/media/pci/cx23885/cx23885-i2c.c
@@ -34,7 +34,7 @@ MODULE_PARM_DESC(i2c_scan, "scan i2c bus at insmod time");
#define I2C_EXTEND (1 << 3)
#define I2C_NOSTOP (1 << 4)
-static inline int i2c_slave_did_ack(struct i2c_adapter *i2c_adap)
+static inline int i2c_client_did_ack(struct i2c_adapter *i2c_adap)
{
struct cx23885_i2c *bus = i2c_adap->algo_data;
struct cx23885_dev *dev = bus->dev;
@@ -84,7 +84,7 @@ static int i2c_sendbytes(struct i2c_adapter *i2c_adap,
cx_write(bus->reg_ctrl, bus->i2c_period | (1 << 2));
if (!i2c_wait_done(i2c_adap))
return -EIO;
- if (!i2c_slave_did_ack(i2c_adap))
+ if (!i2c_client_did_ack(i2c_adap))
return -ENXIO;
dprintk(1, "%s() returns 0\n", __func__);
@@ -163,7 +163,7 @@ static int i2c_readbytes(struct i2c_adapter *i2c_adap,
cx_write(bus->reg_ctrl, bus->i2c_period | (1 << 2) | 1);
if (!i2c_wait_done(i2c_adap))
return -EIO;
- if (!i2c_slave_did_ack(i2c_adap))
+ if (!i2c_client_did_ack(i2c_adap))
return -ENXIO;
--
2.34.1
[PATCH v1 06/12] media: cx18: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
I2S specification has also updated the terms in v.3 to use "controller"
and "target" respectively. Make those changes in the relevant spaces as
well.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/media/pci/cx18/cx18-av-firmware.c | 8
drivers/media/pci/cx18/cx18-cards.c | 6 +++---
drivers/media/pci/cx18/cx18-cards.h | 4 ++--
drivers/media/pci/cx18/cx18-gpio.c| 6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/media/pci/cx18/cx18-av-firmware.c
b/drivers/media/pci/cx18/cx18-av-firmware.c
index 61aeb8c9af7f..906e0b33cffc 100644
--- a/drivers/media/pci/cx18/cx18-av-firmware.c
+++ b/drivers/media/pci/cx18/cx18-av-firmware.c
@@ -140,22 +140,22 @@ int cx18_av_loadfw(struct cx18 *cx)
cx18_av_and_or4(cx, CXADEC_PIN_CTRL1, ~0, 0x78000);
/* Audio input control 1 set to Sony mode */
- /* Audio output input 2 is 0 for slave operation input */
+ /* Audio output input 2 is 0 for target operation input */
/* 0xC4000914[5]: 0 = left sample on WS=0, 1 = left sample on WS=1 */
/* 0xC4000914[7]: 0 = Philips mode, 1 = Sony mode (1st SCK rising edge
after WS transition for first bit of audio word. */
cx18_av_write4(cx, CXADEC_I2S_IN_CTL, 0x00A0);
/* Audio output control 1 is set to Sony mode */
- /* Audio output control 2 is set to 1 for master mode */
+ /* Audio output control 2 is set to 1 for controller mode */
/* 0xC4000918[5]: 0 = left sample on WS=0, 1 = left sample on WS=1 */
/* 0xC4000918[7]: 0 = Philips mode, 1 = Sony mode (1st SCK rising edge
after WS transition for first bit of audio word. */
- /* 0xC4000918[8]: 0 = slave operation, 1 = master (SCK_OUT and WS_OUT
+ /* 0xC4000918[8]: 0 = target operation, 1 = controller (SCK_OUT and
WS_OUT
are generated) */
cx18_av_write4(cx, CXADEC_I2S_OUT_CTL, 0x01A0);
- /* set alt I2s master clock to /0x16 and enable alt divider i2s
+ /* set alt I2s controller clock to /0x16 and enable alt divider i2s
passthrough */
cx18_av_write4(cx, CXADEC_PIN_CFG3, 0x5600B687);
diff --git a/drivers/media/pci/cx18/cx18-cards.c
b/drivers/media/pci/cx18/cx18-cards.c
index f5a30959a367..d9b859ee4b1b 100644
--- a/drivers/media/pci/cx18/cx18-cards.c
+++ b/drivers/media/pci/cx18/cx18-cards.c
@@ -82,7 +82,7 @@ static const struct cx18_card cx18_card_hvr1600_esmt = {
},
.gpio_init.initial_value = 0x3001,
.gpio_init.direction = 0x3001,
- .gpio_i2c_slave_reset = {
+ .gpio_i2c_client_reset = {
.active_lo_mask = 0x3001,
.msecs_asserted = 10,
.msecs_recovery = 40,
@@ -129,7 +129,7 @@ static const struct cx18_card cx18_card_hvr1600_s5h1411 = {
},
.gpio_init.initial_value = 0x3801,
.gpio_init.direction = 0x3801,
- .gpio_i2c_slave_reset = {
+ .gpio_i2c_client_reset = {
.active_lo_mask = 0x3801,
.msecs_asserted = 10,
.msecs_recovery = 40,
@@ -176,7 +176,7 @@ static const struct cx18_card cx18_card_hvr1600_samsung = {
},
.gpio_init.initial_value = 0x3001,
.gpio_init.direction = 0x3001,
- .gpio_i2c_slave_reset = {
+ .gpio_i2c_client_reset = {
.active_lo_mask = 0x3001,
.msecs_asserted = 10,
.msecs_recovery = 40,
diff --git a/drivers/media/pci/cx18/cx18-cards.h
b/drivers/media/pci/cx18/cx18-cards.h
index ae9cf5bfdd59..86f41ec6ca2f 100644
--- a/drivers/media/pci/cx18/cx18-cards.h
+++ b/drivers/media/pci/cx18/cx18-cards.h
@@ -69,7 +69,7 @@ struct cx18_gpio_init { /* set initial GPIO DIR and OUT
values */
u32 initial_value;
};
-struct cx18_gpio_i2c_slave_reset {
+struct cx18_gpio_i2c_client_reset {
u32 active_lo_mask; /* GPIO outputs that reset i2c chips when low */
u32 active_hi_mask; /* GPIO outputs that reset i2c chips when high */
int msecs_asserted; /* time period reset must remain asserted */
@@ -121,7 +121,7 @@ struct cx18_card {
/* GPIO card-specific settings */
u8 xceive_pin; /* XCeive tuner GPIO reset pin */
struct cx18_gpio_initgpio_init;
- struct cx18_gpio_i2c_slave_reset gpio_i2c_slave_reset;
+ struct cx18_gpio_i2c_client_reset gpio_i2c_client_reset;
struct cx18_gpio_audio_inputgpio_audio_input;
struct cx18_card_tuner tuners[CX18_CARD_MAX_TUNERS];
diff
[PATCH v1 04/12] media: au0828: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/media/usb/au0828/au0828-i2c.c | 4 ++--
drivers/media/usb/au0828/au0828-input.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-i2c.c
b/drivers/media/usb/au0828/au0828-i2c.c
index 749f90d73b5b..3e66d42bf134 100644
--- a/drivers/media/usb/au0828/au0828-i2c.c
+++ b/drivers/media/usb/au0828/au0828-i2c.c
@@ -23,7 +23,7 @@ MODULE_PARM_DESC(i2c_scan, "scan i2c bus at insmod time");
#define I2C_WAIT_DELAY 25
#define I2C_WAIT_RETRY 1000
-static inline int i2c_slave_did_read_ack(struct i2c_adapter *i2c_adap)
+static inline int i2c_client_did_read_ack(struct i2c_adapter *i2c_adap)
{
struct au0828_dev *dev = i2c_adap->algo_data;
return au0828_read(dev, AU0828_I2C_STATUS_201) &
@@ -35,7 +35,7 @@ static int i2c_wait_read_ack(struct i2c_adapter *i2c_adap)
int count;
for (count = 0; count < I2C_WAIT_RETRY; count++) {
- if (!i2c_slave_did_read_ack(i2c_adap))
+ if (!i2c_client_did_read_ack(i2c_adap))
break;
udelay(I2C_WAIT_DELAY);
}
diff --git a/drivers/media/usb/au0828/au0828-input.c
b/drivers/media/usb/au0828/au0828-input.c
index 3d3368202cd0..98a57b6e02e2 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -30,7 +30,7 @@ struct au0828_rc {
int polling;
struct delayed_work work;
- /* i2c slave address of external device (if used) */
+ /* i2c client address of external device (if used) */
u16 i2c_dev_addr;
int (*get_key_i2c)(struct au0828_rc *ir);
--
2.34.1
[PATCH v1 05/12] media: cobalt: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/media/pci/cobalt/cobalt-i2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cobalt/cobalt-i2c.c
b/drivers/media/pci/cobalt/cobalt-i2c.c
index 10c9ee33f73e..d2963370f949 100644
--- a/drivers/media/pci/cobalt/cobalt-i2c.c
+++ b/drivers/media/pci/cobalt/cobalt-i2c.c
@@ -45,10 +45,10 @@ struct cobalt_i2c_regs {
/* I2C stop condition */
#define M00018_CR_BITMAP_STO_MSK (1 << 6)
-/* I2C read from slave */
+/* I2C read from client */
#define M00018_CR_BITMAP_RD_MSK(1 << 5)
-/* I2C write to slave */
+/* I2C write to client */
#define M00018_CR_BITMAP_WR_MSK(1 << 4)
/* I2C ack */
@@ -59,7 +59,7 @@ struct cobalt_i2c_regs {
/* SR[7:0] - Status register */
-/* Receive acknowledge from slave */
+/* Receive acknowledge from client */
#define M00018_SR_BITMAP_RXACK_MSK (1 << 7)
/* Busy, I2C bus busy (as defined by start / stop bits) */
--
2.34.1
[PATCH v1 08/12] media: ivtv: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/media/pci/ivtv/ivtv-i2c.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c
b/drivers/media/pci/ivtv/ivtv-i2c.c
index c052c57c6dce..967e6a025020 100644
--- a/drivers/media/pci/ivtv/ivtv-i2c.c
+++ b/drivers/media/pci/ivtv/ivtv-i2c.c
@@ -33,14 +33,14 @@
Some more general comments about what we are doing:
The i2c bus is a 2 wire serial bus, with clock (SCL) and data (SDA)
-lines. To communicate on the bus (as a master, we don't act as a slave),
+lines. To communicate on the bus (as a host, we don't act as a client),
we first initiate a start condition (ivtv_start). We then write the
address of the device that we want to communicate with, along with a flag
-that indicates whether this is a read or a write. The slave then issues
+that indicates whether this is a read or a write. The client then issues
an ACK signal (ivtv_ack), which tells us that it is ready for reading /
writing. We then proceed with reading or writing (ivtv_read/ivtv_write),
and finally issue a stop condition (ivtv_stop) to make the bus available
-to other masters.
+to other hosts.
There is an additional form of transaction where a write may be
immediately followed by a read. In this case, there is no intervening
@@ -379,7 +379,7 @@ static int ivtv_waitsda(struct ivtv *itv, int val)
return 0;
}
-/* Wait for the slave to issue an ACK */
+/* Wait for the client to issue an ACK */
static int ivtv_ack(struct ivtv *itv)
{
int ret = 0;
@@ -407,7 +407,7 @@ static int ivtv_ack(struct ivtv *itv)
return ret;
}
-/* Write a single byte to the i2c bus and wait for the slave to ACK */
+/* Write a single byte to the i2c bus and wait for the client to ACK */
static int ivtv_sendbyte(struct ivtv *itv, unsigned char byte)
{
int i, bit;
@@ -471,7 +471,7 @@ static int ivtv_readbyte(struct ivtv *itv, unsigned char
*byte, int nack)
return 0;
}
-/* Issue a start condition on the i2c bus to alert slaves to prepare for
+/* Issue a start condition on the i2c bus to alert clients to prepare for
an address write */
static int ivtv_start(struct ivtv *itv)
{
@@ -534,7 +534,7 @@ static int ivtv_stop(struct ivtv *itv)
return 0;
}
-/* Write a message to the given i2c slave. do_stop may be 0 to prevent
+/* Write a message to the given i2c client. do_stop may be 0 to prevent
issuing the i2c stop condition (when following with a read) */
static int ivtv_write(struct ivtv *itv, unsigned char addr, unsigned char
*data, u32 len, int do_stop)
{
@@ -558,7 +558,7 @@ static int ivtv_write(struct ivtv *itv, unsigned char addr,
unsigned char *data,
return ret;
}
-/* Read data from the given i2c slave. A stop condition is always issued. */
+/* Read data from the given i2c client. A stop condition is always issued. */
static int ivtv_read(struct ivtv *itv, unsigned char addr, unsigned char
*data, u32 len)
{
int retry, ret = -EREMOTEIO;
--
2.34.1
[PATCH v1 07/12] media: cx25821: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/media/pci/cx25821/cx25821-i2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cx25821/cx25821-i2c.c
b/drivers/media/pci/cx25821/cx25821-i2c.c
index 0ef4cd6528a0..bad8fb9f5319 100644
--- a/drivers/media/pci/cx25821/cx25821-i2c.c
+++ b/drivers/media/pci/cx25821/cx25821-i2c.c
@@ -33,7 +33,7 @@ do {
\
#define I2C_EXTEND (1 << 3)
#define I2C_NOSTOP (1 << 4)
-static inline int i2c_slave_did_ack(struct i2c_adapter *i2c_adap)
+static inline int i2c_client_did_ack(struct i2c_adapter *i2c_adap)
{
struct cx25821_i2c *bus = i2c_adap->algo_data;
struct cx25821_dev *dev = bus->dev;
@@ -85,7 +85,7 @@ static int i2c_sendbytes(struct i2c_adapter *i2c_adap,
if (!i2c_wait_done(i2c_adap))
return -EIO;
- if (!i2c_slave_did_ack(i2c_adap))
+ if (!i2c_client_did_ack(i2c_adap))
return -EIO;
dprintk(1, "%s(): returns 0\n", __func__);
@@ -174,7 +174,7 @@ static int i2c_readbytes(struct i2c_adapter *i2c_adap,
cx_write(bus->reg_ctrl, bus->i2c_period | (1 << 2) | 1);
if (!i2c_wait_done(i2c_adap))
return -EIO;
- if (!i2c_slave_did_ack(i2c_adap))
+ if (!i2c_client_did_ack(i2c_adap))
return -EIO;
dprintk(1, "%s(): returns 0\n", __func__);
--
2.34.1
[PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
.../gpu/drm/i915/display/intel_display_core.h | 2 +-
drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++---
drivers/gpu/drm/i915/display/intel_dvo.c | 14 -
drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +-
drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +--
drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +--
drivers/gpu/drm/i915/gvt/edid.c | 28 -
drivers/gpu/drm/i915/gvt/edid.h | 4 +--
drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
19 files changed, 119 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
b/drivers/gpu/drm/i915/display/dvo_ch7017.c
index d0c3880d7f80..493e730c685b 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
@@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo, u8
addr, u8 *val)
{
struct i2c_msg msgs[] = {
{
- .addr = dvo->slave_addr,
+ .addr = dvo->target_addr,
.flags = 0,
.len = 1,
.buf = ,
},
{
- .addr = dvo->slave_addr,
+ .addr = dvo->target_addr,
.flags = I2C_M_RD,
.len = 1,
.buf = val,
@@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
addr, u8 val)
{
u8 buf[2] = { addr, val };
struct i2c_msg msg = {
- .addr = dvo->slave_addr,
+ .addr = dvo->target_addr,
.flags = 0,
.len = 2,
.buf = buf,
@@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
addr, u8 val)
return i2c_transfer(dvo->i2c_bus, , 1) == 1;
}
-/** Probes for a CH7017 on the given bus and slave address. */
+/** Probes for a CH7017 on the given bus and target address. */
static bool ch7017_init(struct intel_dvo_device *dvo,
struct i2c_adapter *adapter)
{
@@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
break;
default:
DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
- "slave %d.\n",
- val, adapter->name, dvo->slave_addr);
+ "target %d.\n",
+ val, adapter->name, dvo->target_addr);
goto fail;
}
DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
- str, adapter->name, dvo->slave_addr);
+ str, adapter->name, dvo->target_addr);
return true;
fail:
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
index 2e8e85da5a40..534b8544e0a4 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
@@ -153,13 +153,13 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo,
int addr, u8 *ch)
struct i2c_msg msgs[] = {
{
- .addr = dvo->slave_addr,
+ .addr = dvo->target_addr,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
- .addr = dvo->slave_addr,
+ .addr = dvo->target_addr,
.flags = I2C_M_RD,
.len = 1,
.buf = in_buf,
@@ -176,7 +176,7 @@ static bool ch7xxx_readb(struct intel_dvo_device *dvo, int
addr, u8 *ch)
if (!ch7xxx->quiet) {
DRM_DEBUG_KMS("Unable to read register 0x%02x from %s:%02x.\n",
-
[PATCH v1 02/12] drm/gma500: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +-
drivers/gpu/drm/gma500/intel_bios.c | 22 ++---
drivers/gpu/drm/gma500/intel_bios.h | 4 ++--
drivers/gpu/drm/gma500/intel_gmbus.c| 2 +-
drivers/gpu/drm/gma500/psb_drv.h| 2 +-
drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 4 ++--
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 26 -
8 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index f08a6803dc18..c7652a02b42e 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -565,7 +565,7 @@ void cdv_intel_lvds_init(struct drm_device *dev,
dev->dev, "I2C bus registration failed.\n");
goto err_encoder_cleanup;
}
- gma_encoder->i2c_bus->slave_addr = 0x2C;
+ gma_encoder->i2c_bus->target_addr = 0x2C;
dev_priv->lvds_i2c_bus = gma_encoder->i2c_bus;
/*
diff --git a/drivers/gpu/drm/gma500/intel_bios.c
b/drivers/gpu/drm/gma500/intel_bios.c
index 8245b5603d2c..d5924ca3ed05 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -14,8 +14,8 @@
#include "psb_intel_drv.h"
#include "psb_intel_reg.h"
-#defineSLAVE_ADDR1 0x70
-#defineSLAVE_ADDR2 0x72
+#defineTARGET_ADDR10x70
+#defineTARGET_ADDR20x72
static void *find_section(struct bdb_header *bdb, int section_id)
{
@@ -357,10 +357,10 @@ parse_sdvo_device_mapping(struct drm_psb_private
*dev_priv,
/* skip the device block if device type is invalid */
continue;
}
- if (p_child->slave_addr != SLAVE_ADDR1 &&
- p_child->slave_addr != SLAVE_ADDR2) {
+ if (p_child->target_addr != TARGET_ADDR1 &&
+ p_child->target_addr != TARGET_ADDR2) {
/*
-* If the slave address is neither 0x70 nor 0x72,
+* If the target address is neither 0x70 nor 0x72,
* it is not a SDVO device. Skip it.
*/
continue;
@@ -371,22 +371,22 @@ parse_sdvo_device_mapping(struct drm_psb_private
*dev_priv,
DRM_DEBUG_KMS("Incorrect SDVO port. Skip it\n");
continue;
}
- DRM_DEBUG_KMS("the SDVO device with slave addr %2x is found on"
+ DRM_DEBUG_KMS("the SDVO device with target addr %2x is found on"
" %s port\n",
- p_child->slave_addr,
+ p_child->target_addr,
(p_child->dvo_port == DEVICE_PORT_DVOB) ?
"SDVOB" : "SDVOC");
p_mapping = &(dev_priv->sdvo_mappings[p_child->dvo_port - 1]);
if (!p_mapping->initialized) {
p_mapping->dvo_port = p_child->dvo_port;
- p_mapping->slave_addr = p_child->slave_addr;
+ p_mapping->target_addr = p_child->target_addr;
p_mapping->dvo_wiring = p_child->dvo_wiring;
p_mapping->ddc_pin = p_child->ddc_pin;
p_mapping->i2c_pin = p_child->i2c_pin;
p_mapping->initialized = 1;
DRM_DEBUG_KMS("SDVO device: dvo=%x, addr=%x, wiring=%d,
ddc_pin=%d, i2c_pin=%d\n",
p_mapping->dvo_port,
- p_mapping->slave_addr,
+ p_mapping->target_addr,
p_mapping->dvo_wiring,
p_mapping->ddc_pin,
p_mapping->i2c_pin);
@@ -394,10 +394,10 @@ parse_sdvo_device_mapping(struct drm_psb_private
*dev_priv,
DRM_DEBUG_KMS("Maybe one SDVO port is shared by "
"two SDVO device.\n");
}
- if (p_child->slave2_addr) {
+ if (p_child->target2_addr) {
/* Maybe this is a SDVO device with multiple inputs */
/* And the mapping info is not added */
[PATCH v1 01/12] drm/amdgpu, drm/radeon: Make I2C terminology more inclusive
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specification.
Compile tested, no functionality changes intended
[1]:
https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
Signed-off-by: Easwar Hariharan
---
.../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 8 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 10 +++
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 8 +++---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++---
.../gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +-
.../drm/amd/display/dc/bios/bios_parser2.c| 2 +-
.../drm/amd/display/dc/core/dc_link_exports.c | 4 +--
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c | 4 +--
.../display/include/grph_object_ctrl_defs.h | 2 +-
drivers/gpu/drm/amd/include/atombios.h| 2 +-
drivers/gpu/drm/amd/include/atomfirmware.h| 26 -
.../powerplay/hwmgr/vega20_processpptables.c | 4 +--
.../amd/pm/powerplay/inc/smu11_driver_if.h| 2 +-
.../inc/pmfw_if/smu11_driver_if_arcturus.h| 2 +-
.../inc/pmfw_if/smu11_driver_if_navi10.h | 2 +-
.../pmfw_if/smu11_driver_if_sienna_cichlid.h | 2 +-
.../inc/pmfw_if/smu13_driver_if_aldebaran.h | 2 +-
.../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 2 +-
.../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 2 +-
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 +--
.../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 +++---
drivers/gpu/drm/radeon/atombios.h | 2 +-
drivers/gpu/drm/radeon/atombios_i2c.c | 4 +--
drivers/gpu/drm/radeon/radeon_combios.c | 28 +--
drivers/gpu/drm/radeon/radeon_i2c.c | 10 +++
drivers/gpu/drm/radeon/radeon_mode.h | 6 ++--
27 files changed, 85 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
index 6857c586ded7..37f50fc5d496 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
@@ -614,7 +614,7 @@ bool amdgpu_atomfirmware_ras_rom_addr(struct amdgpu_device
*adev,
if ((frev == 3 && crev >= 4) || (frev > 3)) {
firmware_info = (union firmware_info *)
(mode_info->atom_context->bios + data_offset);
- /* The ras_rom_i2c_slave_addr should ideally
+ /* The ras_rom_i2c_target_addr should ideally
* be a 19-bit EEPROM address, which would be
* used as is by the driver; see top of
* amdgpu_eeprom.c.
@@ -625,13 +625,13 @@ bool amdgpu_atomfirmware_ras_rom_addr(struct
amdgpu_device *adev,
* leave the check for the pointer.
*
* The reason this works right now is because
-* ras_rom_i2c_slave_addr contains the EEPROM
+* ras_rom_i2c_target_addr contains the EEPROM
* device type qualifier 1010b in the top 4
* bits.
*/
- if (firmware_info->v34.ras_rom_i2c_slave_addr) {
+ if (firmware_info->v34.ras_rom_i2c_target_addr) {
if (i2c_address)
- *i2c_address =
firmware_info->v34.ras_rom_i2c_slave_addr;
+ *i2c_address =
firmware_info->v34.ras_rom_i2c_target_addr;
return true;
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
index d79cb13e1aa8..070049c92e2b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
@@ -280,7 +280,7 @@ amdgpu_i2c_lookup(struct amdgpu_device *adev,
}
static void amdgpu_i2c_get_byte(struct amdgpu_i2c_chan *i2c_bus,
-u8 slave_addr,
+u8 target_addr,
u8 addr,
u8 *val)
{
@@ -288,13 +288,13 @@ static void amdgpu_i2c_get_byte(struct amdgpu_i2c_chan
*i2c_bus,
u8 in_buf[2];
struct i2c_msg msgs[] = {
{
- .addr = slave_addr,
+ .addr = target_addr,
.flags = 0,
.len = 1,
.buf = out_buf,
},
{
- .addr = slave_addr,
+ .addr =
[PATCH v1 00/12] Make I2C terminology more inclusive for I2C Algobit and consumers
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by and following on to Wolfram's series to fix drivers/i2c/[1], fix the terminology for users of the I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Compile tested, no functionality changes intended Please chime in with your opinions and suggestions. This series is based on v6.9-rc1. [1]: https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ changelog: v0->v1: - Link: https://lore.kernel.org/all/20240329170038.3863998-1-eahar...@linux.microsoft.com/ - Drop drivers/infiniband patches [Leon, Dennis] - Switch to specification verbiage master->controller, slave->target, drop usage of client [Andi, Ville, Jani, Christian] - Add I3C specification version in commit messages [Andi] - Pick up Reviewed-bys from Martin and Simon [sfc] - Drop i2c/treewide patch to make this series independent from Wolfram's ([1]) [Wolfram] - Split away drm/nouveau patch to allow expansion into non-I2C non-inclusive terms Easwar Hariharan (12): drm/amdgpu, drm/radeon: Make I2C terminology more inclusive drm/gma500: Make I2C terminology more inclusive drm/i915: Make I2C terminology more inclusive media: au0828: Make I2C terminology more inclusive media: cobalt: Make I2C terminology more inclusive media: cx18: Make I2C terminology more inclusive media: cx25821: Make I2C terminology more inclusive media: ivtv: Make I2C terminology more inclusive media: cx23885: Make I2C terminology more inclusive sfc: falcon: Make I2C terminology more inclusive fbdev/smscufx: Make I2C terminology more inclusive fbdev/viafb: Make I2C terminology more inclusive .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 8 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 10 +++ drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 8 ++--- drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c| 20 ++--- .../gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +- .../drm/amd/display/dc/bios/bios_parser2.c| 2 +- .../drm/amd/display/dc/core/dc_link_exports.c | 4 +-- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c | 4 +-- .../display/include/grph_object_ctrl_defs.h | 2 +- drivers/gpu/drm/amd/include/atombios.h| 2 +- drivers/gpu/drm/amd/include/atomfirmware.h| 26 .../powerplay/hwmgr/vega20_processpptables.c | 4 +-- .../amd/pm/powerplay/inc/smu11_driver_if.h| 2 +- .../inc/pmfw_if/smu11_driver_if_arcturus.h| 2 +- .../inc/pmfw_if/smu11_driver_if_navi10.h | 2 +- .../pmfw_if/smu11_driver_if_sienna_cichlid.h | 2 +- .../inc/pmfw_if/smu13_driver_if_aldebaran.h | 2 +- .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 2 +- .../inc/pmfw_if/smu13_driver_if_v13_0_7.h | 2 +- .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 4 +-- .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 ++--- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/intel_bios.c | 22 +++--- drivers/gpu/drm/gma500/intel_bios.h | 4 +-- drivers/gpu/drm/gma500/intel_gmbus.c | 2 +- drivers/gpu/drm/gma500/psb_drv.h | 2 +- drivers/gpu/drm/gma500/psb_intel_drv.h| 2 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 4 +-- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 26 drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- .../gpu/drm/i915/display/intel_display_core.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- drivers/gpu/drm/i915/display/intel_dvo.c | 14 - drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +-- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- drivers/gpu/drm/i915/gvt/edid.c | 28 - drivers/gpu/drm/i915/gvt/edid.h | 4 +-- drivers/gpu/drm/i915/gvt/opregion.c | 2 +- drivers/gpu/drm/radeon/atombios.h | 2 +- drivers/gpu/drm/radeon/atombios_i2c.c | 4 +-- drivers/gpu/drm/radeon/radeon_combios.c | 28 - drivers/gpu/drm/radeon/radeon_i2c.c | 10 +++ drivers/gpu/drm/radeon/radeon_mode.h | 6 ++-- drivers/media/pci/cobalt/cobalt-i2c.c
Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range
On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote: > > Yes there is another common scheme where you bind a window of CPU to > > a > > window on the device and mirror a fixed range, but this is a quite > > different thing. It is not SVA, it has a fixed range, and it is > > probably bound to a single GPU VMA in a multi-VMA device page table. > > And this above here is exactly what we're implementing, and the GPU > page-tables are populated using device faults. Regions (large) of the > mirrored CPU mm need to coexist in the same GPU vm as traditional GPU > buffer objects. Well, not really, if that was the case you'd have a single VMA over the entire bound range, not dynamically create them. A single VMA that uses hmm_range_fault() to populate the VM is completely logical. Having a hidden range of mm binding and then creating/destroying 2M VMAs dynamicaly is the thing that doesn't make alot of sense. Jason
Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs
Hi,
On 2024/4/30 22:32, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
On 2024/4/26 03:10, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
On 2024/4/25 22:26, Andy Shevchenko wrote:
It seems driver missed the point of proper use of device property APIs.
Correct this by updating headers and calls respectively.
You are using the 'seems' here exactly saying that you are not 100% sure.
To add here, "seems" is used to show that I have no knowledge on what was
the idea behind this implementation by the original author. Plus my knowledge
in the firmware node / device property APIs and use cases in Linux kernel.
Please allow me to tell you the truth: This patch again has ZERO effect.
It fix nothing. And this patch is has the risks to be wrong.
Huh?! Really, stop commenting the stuff you do not understand.
I'm actually a professional display drivers developer at the downstream
in the past, despite my contribution to upstream is less. But I believe
that all panel driver developers know what I'm talking about. So please
have take a look at my replies.
Okay.
Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
is DT dependent.
First of all, the devm_of_find_backlight() is called in ili9341_dbi_probe()
under *non-DT* environment, devm_of_find_backlight() is just a just a
no-op and will return NULL. NULL is not an error code, so ili9341_dbi_probe()
won't rage quit. But the several side effect is that the backlight will
NOT works at all.
Is it a problem?
Yes, it is.
The core problem is that the driver you are modifying has *implicit*
*dependency* on DT.
The implicit dependency is due to the calling of devm_of_find_backlight(). This
function
is a no-op under non-DT systems.
Okay.
Therefore, before the devm_of_find_backlight() and
the device_get_match_data() function can truly DT independent.
True for the first part, not true for the second.
Removing the "OF" dependency just let the tigers run out from the jail.
It is not really meant to targeting at you, but I thinks, all of drm_panel
drivers
that has the devm_of_find_backlight() invoked will suffer such concerns.
In short, the reason is that the *implicit* *dependency* populates and
the undefined behavior gets triggered.
Still no problem statement. My hardware works nicely on non-DT environment.
(And since it's Arduino-based one, I assume it will work on DT environments
the very same way.)
I'm sure you know that device_get_match_data() is same with
of_device_get_match_data()
for DT based systems. For non DT based systems, device_get_match_data() is just
*undefined*
Note that ACPI is not in the scope of the discussion here, as all of the drm
bridges and
panels driver under drivers/gpu/drm/ hasn't the ACPI support yet.
This patch shows exactly how to bring back the ACPI support to one of them
(as it's done for tinyDRM cases).
Therefore, at present,
it safe to say that device_get_match_data() is *undefined* under no-DT
environment.
This is not true.
Removing the "OF" dependency hints to us that it allows the driver to be probed
as a
pure SPI device under non DT systems. When device_get_match_data() is called,
it returns
NULL to us now. As a result, the drm driver being modified will tears down.
See bellow code snippet extracted frompanel-ilitek-ili9341.c:
```
ili->conf = of_device_get_match_data(dev);
if (!ili->conf) {
dev_err(dev, "missing device configuration\n");
return -ENODEV;
}
```
It is actually considered as fatal bug for *panels* if the backlight of
it is not light up, at least the brightness of *won't* be able to adjust.
What's worse, if there is no sane platform setup code at the firmware
or boot loader stage to set a proper initial state. The screen is complete
dark. Even though the itself panel is refreshing framebuffers, it can not
be seen by human's eye. Simple because of no backlight.
Can you imagine that I may have different hardware that considered
this is non-fatal error?
Yes, I can imagine.
I believe you have the hardware which make you patch correct to run
in 99.9% of all cases. But as long as there one bug happened, you patch
are going to be blamed.
Because its your patch that open the door, both from the perceptive of
practice and from the perceptive of the concept (static analysis).
Second, the ili9341_dbi_probe() requires additional device properties to
be able to works very well on the rotation screen case. See the calling
of "device_property_read_u32(dev, "rotation", )" in
ili9341_dbi_probe() function.
Yes, exactly, and how does it object the purpose of this patch?
Because under *non-DT* environment, your commit message do not give a
valid description, how does the additional device property can be acquired
is not demonstrated.
And it is exactly your patch open the non-DT code path (way or possibility).
It isn't has such risks before your
Re: [PATCH] drm: drm_of.c: Using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
Hi, On 2024/4/30 17:26, Maxime Ripard wrote: Hi, On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote: Linux kernel puts strict limits on which functions and data structures are available to loadable kernel modules; only those that have been explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare a GPL-compatible license will be able to see the symbol. Since the whole drm_of.c file is declared with GPL-2.0-only license, so let us keep functions in that source file consistently. You're conflating two things: the license of the code itself (GPL2 here), and the license of the users of the symbols exported in that file (anything). There's no relationship between the two, and you have to make an argument for changing the latter other than just because the license is GPL because, again, those are two different things. Yeah, I think you might be correct. It seems that it is valid to have EXPORT_SYMBOL() in GPL-2.0-only licensed file. Maxime -- Best regards, Sui
Re: [PATCH v2 4/4] drm/panthor: Fix an off-by-one in the heap context retrieval logic
On Tue, 30 Apr 2024 17:40:54 +0100
Liviu Dudau wrote:
> On Tue, Apr 30, 2024 at 01:28:52PM +0200, Boris Brezillon wrote:
> > ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
> > [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
> > in the [0:MAX_HEAPS_PER_POOL-1] when we want to access the context object.
> >
> > v2:
> > - New patch
> >
> > Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> > Reported-by: Eric Smith
> > Signed-off-by: Boris Brezillon
> > Tested-by: Eric Smith
> > ---
> > drivers/gpu/drm/panthor/panthor_heap.c | 35 +++---
> > 1 file changed, 26 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> > b/drivers/gpu/drm/panthor/panthor_heap.c
> > index 683bb94761bc..b1a7dbf25fb2 100644
> > --- a/drivers/gpu/drm/panthor/panthor_heap.c
> > +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> > @@ -109,7 +109,11 @@ static int panthor_heap_ctx_stride(struct
> > panthor_device *ptdev)
> >
> > static int panthor_get_heap_ctx_offset(struct panthor_heap_pool *pool, int
> > id)
>
> Can we make id and the return type here u32? I keep thinking about returning
> large negative
> values here and how they can end up being exploited.
Actually, I had the prototype changed to take/return an u32 locally, but
decided to drop it to both keep the amount of changes minimal and keep
prototype consistent with the new helper. I'm fine switching to u32s
though.
>
> > {
> > - return panthor_heap_ctx_stride(pool->ptdev) * id;
> > + /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
> > +* is [1:MAX_HEAPS_PER_POOL], which we need to turn into a
> > +* [0:MAX_HEAPS_PER_POOL-1] context index, hence the minus one here.
> > +*/
> > + return panthor_heap_ctx_stride(pool->ptdev) * (id - 1);
> > }
> >
> > static void *panthor_get_heap_ctx(struct panthor_heap_pool *pool, int id)
> > @@ -118,6 +122,21 @@ static void *panthor_get_heap_ctx(struct
> > panthor_heap_pool *pool, int id)
> >panthor_get_heap_ctx_offset(pool, id);
> > }
> >
> > +static int panthor_get_heap_ctx_id(struct panthor_heap_pool *pool,
> > + u64 heap_ctx_gpu_va)
> > +{
> > + u64 offset = heap_ctx_gpu_va -
> > panthor_kernel_bo_gpuva(pool->gpu_contexts);
> > + u32 heap_idx = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> > +
> > + if (offset > U32_MAX || heap_idx >= MAX_HEAPS_PER_POOL)
> > + return -EINVAL;
> > +
> > + /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
> > +* is [1:MAX_HEAPS_PER_POOL], hence the plus one here.
> > +*/
> > + return heap_idx + 1;
> > +}
> > +
> > static void panthor_free_heap_chunk(struct panthor_vm *vm,
> > struct panthor_heap *heap,
> > struct panthor_heap_chunk *chunk)
> > @@ -364,14 +383,13 @@ int panthor_heap_return_chunk(struct
> > panthor_heap_pool *pool,
> > u64 heap_gpu_va,
> > u64 chunk_gpu_va)
> > {
> > - u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
> > - u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> > + int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
>
> I would keep heap_id here u32. Why do we need to change it? Also, I don't see
> how
> panthor_get_heap_ctx_id() can ever return negative values unless we expect
> MAX_HEAPS_PER_POOL
> to be S32_MAX at some moment.
The reason I made it a signed value is so we could return an error code
too
- > 0 => valid
- < 0 error, with the value encoding the error
though we're likely to always return EINVAL anyway.
>
> > struct panthor_heap_chunk *chunk, *tmp, *removed = NULL;
> > struct panthor_heap *heap;
> > int ret;
> >
> > - if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
> > - return -EINVAL;
> > + if (heap_id < 0)
> > + return heap_id;
>
> This can then be removed if heap_id is u32.
We need to replace that by an extra check on the VA, and given this is
done in two different places, I thought having an helper that does both
the VA to offset and the offset consistency check was simpler. I mean,
I could make this helper return an u32, and consider 0 as the
'no-context-found' special-value, but I can't drop this check.
Re: [PATCH] drm/panel: ili9341: Remove a superfluous else after return
Hi, On 2024/4/30 07:10, Jessica Zhang wrote: On 4/29/2024 10:12 AM, Sui Jingfeng wrote: The else clause after the ruturn clause is not useful. Hi Sui, Spelling nit: ruturn --> return Thanks for pointed out, will be fixed. Besides that, Reviewed-by: Jessica Zhang Thanks, Jessica Zhang Thanks, Jessica.
Re: [PATCH] drm/vmwgfx: Remove duplicate vmwgfx_vkms.h header
On Tue, Apr 16, 2024 at 9:29 PM Jiapeng Chong wrote: > > ./drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c: vmwgfx_vkms.h is included more than > once. > > Reported-by: Abaci Robot > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8772 > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c > index 7e93a45948f7..3bfcf671fcd5 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c > @@ -31,7 +31,6 @@ > #include "vmwgfx_bo.h" > #include "vmwgfx_drv.h" > #include "vmwgfx_kms.h" > -#include "vmwgfx_vkms.h" > > #include "vmw_surface_cache.h" > > -- > 2.20.1.7.g153144c Thanks. I pushed it to drm-misc-next. z
Re: [v1,3/3] drm/panel: ili9341: Use predefined error codes
On 2024/4/25 22:26, Andy Shevchenko wrote:
In one case the -1 is returned which is quite confusing code for
the wrong device ID, in another the ret is returning instead of
plain 0 that also confusing as readed may ask the possible meaning
of positive codes, which are never the case there. Convert both
to use explicit predefined error codes to make it clear what's going
on there.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
Reviewed-by: Neil Armstrong
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
Re: [PATCH] drm/amd/display: fix documentation warnings for mpc.h
Hi Marcelo,
First of all, thanks a lot for your patch! Please check some of my
inline comments.
On 4/27/24 10:05 AM, Marcelo Mendes Spessoto Junior wrote:
Fix most of the display documentation compile warnings by
documenting struct mpc_funcs functions in dc/inc/hw/mpc.h file.
Could you add the warnings that you fixed in the commit message?
I think some of your changes in this patch address some of the issues
reported by Stephan Rothwell:
https://lore.kernel.org/all/20240130134954.04fcf...@canb.auug.org.au/
Please include Stephan in the new version of this patch.
Also, use the Fixes tags pointing to:
b8c1c3a82e75 ("Documentation/gpu: Add kernel doc entry for MPC")
Signed-off-by: Marcelo Mendes Spessoto Junior
---
drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 372 +++-
1 file changed, 369 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
index 34a398f23..388b96c32 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
@@ -1,4 +1,5 @@
-/* Copyright 2012-15 Advanced Micro Devices, Inc.
+/*
+ * Copyright 2012-15 Advanced Micro Devices, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -282,6 +283,21 @@ struct mpcc_state {
* struct mpc_funcs - funcs
*/
struct mpc_funcs {
+ /**
+ * @read_mpcc_state:
+ *
+ * Read register content from given MPCC physical instance.
It looks like your text editor left some extra spaces at the end of the
string in many parts of this patch. Remove this extra space at the end
of some of the strings in this patch for the next version. If you use
git log -p after applying your patch, you can visually see where the
extra space is at the end of each line.
+ *
+ * Parameters:
+ *
+ * - [in/out] mpc - MPC context
+ * - [in] mpcc_instance - MPC context instance
+ * - [in] mpcc_state - MPC context state
+ *
+ * Return:
+ *
+ * void
+ */
Use the same indentation as the field/functions that you are documenting.
Finally, ensure you are using the latest amd-staging-drm-next to base
your patch. I believe you have some merge conflicts since mpc.h has some
changes.
Thanks
Siqueira
void (*read_mpcc_state)(
struct mpc *mpc,
int mpcc_inst,
@@ -346,12 +362,22 @@ struct mpc_funcs {
* Parameters:
*
* - [in/out] mpc - MPC context.
-*
+*
* Return:
*
* void
*/
void (*mpc_init)(struct mpc *mpc);
+
+ /**
+ * @mpc_init_single_inst:
+ *
+ * Initialize given MPCC physical instance.
+ *
+ * Parameters:
+ * - [in/out] mpc - MPC context.
+ * - [in] mpcc_id - The MPCC physical instance to be initialized.
+ */
void (*mpc_init_single_inst)(
struct mpc *mpc,
unsigned int mpcc_id);
@@ -449,62 +475,282 @@ struct mpc_funcs {
struct mpc_tree *tree,
struct mpcc *mpcc);
+ /**
+ * @get_mpcc_for_dpp_from_secondary:
+ *
+ * Find, if it exists, a MPCC from a given 'secondary' MPC tree that
+ * is associated with specified plane.
+ *
+ * Parameters:
+ * - [in/out] tree - MPC tree structure to search for plane.
+ * - [in] dpp_id - DPP to be searched.
+ *
+ * Return:
+ *
+ * struct mpcc* - pointer to plane or NULL if no plane found.
+ */
struct mpcc* (*get_mpcc_for_dpp_from_secondary)(
struct mpc_tree *tree,
int dpp_id);
+ /**
+ * @get_mpcc_for_dpp:
+ *
+ * Find, if it exists, a MPCC from a given MPC tree that
+ * is associated with specified plane.
+ *
+ * Parameters:
+ * - [in/out] tree - MPC tree structure to search for plane.
+ * - [in] dpp_id - DPP to be searched.
+ *
+ * Return:
+ *
+ * struct mpcc* - pointer to plane or NULL if no plane found.
+ */
struct mpcc* (*get_mpcc_for_dpp)(
struct mpc_tree *tree,
int dpp_id);
+ /**
+ * @wait_for_idle:
+ *
+ * Wait for a MPCC in MPC context to enter idle state.
+ *
+ * Parameters:
+ * - [in/out] mpc - MPC Context.
+ * - [in] id - MPCC to wait for idle state.
+ *
+ * Return:
+ *
+ * void
+ */
void (*wait_for_idle)(struct mpc *mpc, int id);
+ /**
+ * @assert_mpcc_idle_before_connect:
+ *
+ * Assert if MPCC in MPC context is in idle state.
+ *
+ * Parameters:
+ * - [in/out] mpc - MPC context.
+ * - [in] id - MPCC to assert idle state.
+ *
+ * Return:
+ *
+ * void
+ */
void (*assert_mpcc_idle_before_connect)(struct mpc *mpc, int mpcc_id);
+ /**
+ * @init_mpcc_list_from_hw:
+ *
+ * Iterate through the MPCC array from a given MPC context
Re: [v1,2/3] drm/panel: ili9341: Respect deferred probe
Hi,
On 2024/4/25 22:26, Andy Shevchenko wrote:
GPIO controller might not be available when driver is being probed.
There are plenty of reasons why, one of which is deferred probe.
Since GPIOs are optional, return any error code we got to the upper
layer, including deferred probe. With that in mind, use dev_err_probe()
in order to avoid spamming the logs.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
Reviewed-by: Neil Armstrong
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
Re: [PATCH v2 4/4] drm/panthor: Fix an off-by-one in the heap context retrieval logic
On Tue, Apr 30, 2024 at 01:28:52PM +0200, Boris Brezillon wrote:
> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
> [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
> in the [0:MAX_HEAPS_PER_POOL-1] when we want to access the context object.
>
> v2:
> - New patch
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Reported-by: Eric Smith
> Signed-off-by: Boris Brezillon
> Tested-by: Eric Smith
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 35 +++---
> 1 file changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 683bb94761bc..b1a7dbf25fb2 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -109,7 +109,11 @@ static int panthor_heap_ctx_stride(struct panthor_device
> *ptdev)
>
> static int panthor_get_heap_ctx_offset(struct panthor_heap_pool *pool, int
> id)
Can we make id and the return type here u32? I keep thinking about returning
large negative
values here and how they can end up being exploited.
> {
> - return panthor_heap_ctx_stride(pool->ptdev) * id;
> + /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
> + * is [1:MAX_HEAPS_PER_POOL], which we need to turn into a
> + * [0:MAX_HEAPS_PER_POOL-1] context index, hence the minus one here.
> + */
> + return panthor_heap_ctx_stride(pool->ptdev) * (id - 1);
> }
>
> static void *panthor_get_heap_ctx(struct panthor_heap_pool *pool, int id)
> @@ -118,6 +122,21 @@ static void *panthor_get_heap_ctx(struct
> panthor_heap_pool *pool, int id)
> panthor_get_heap_ctx_offset(pool, id);
> }
>
> +static int panthor_get_heap_ctx_id(struct panthor_heap_pool *pool,
> +u64 heap_ctx_gpu_va)
> +{
> + u64 offset = heap_ctx_gpu_va -
> panthor_kernel_bo_gpuva(pool->gpu_contexts);
> + u32 heap_idx = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> +
> + if (offset > U32_MAX || heap_idx >= MAX_HEAPS_PER_POOL)
> + return -EINVAL;
> +
> + /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
> + * is [1:MAX_HEAPS_PER_POOL], hence the plus one here.
> + */
> + return heap_idx + 1;
> +}
> +
> static void panthor_free_heap_chunk(struct panthor_vm *vm,
> struct panthor_heap *heap,
> struct panthor_heap_chunk *chunk)
> @@ -364,14 +383,13 @@ int panthor_heap_return_chunk(struct panthor_heap_pool
> *pool,
> u64 heap_gpu_va,
> u64 chunk_gpu_va)
> {
> - u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
> - u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> + int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
I would keep heap_id here u32. Why do we need to change it? Also, I don't see
how
panthor_get_heap_ctx_id() can ever return negative values unless we expect
MAX_HEAPS_PER_POOL
to be S32_MAX at some moment.
> struct panthor_heap_chunk *chunk, *tmp, *removed = NULL;
> struct panthor_heap *heap;
> int ret;
>
> - if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
> - return -EINVAL;
> + if (heap_id < 0)
> + return heap_id;
This can then be removed if heap_id is u32.
>
> down_read(>lock);
> heap = xa_load(>xa, heap_id);
> @@ -427,14 +445,13 @@ int panthor_heap_grow(struct panthor_heap_pool *pool,
> u32 pending_frag_count,
> u64 *new_chunk_gpu_va)
> {
> - u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
> - u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> + int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
Again, keep u32 unless you have good reasons ...
> struct panthor_heap_chunk *chunk;
> struct panthor_heap *heap;
> int ret;
>
> - if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
> - return -EINVAL;
> + if (heap_id < 0)
> + return heap_id;
... and we will not need this.
Best regards,
Liviu
>
> down_read(>lock);
> heap = xa_load(>xa, heap_id);
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs
On 2024/4/30 22:13, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
On 2024/4/26 03:12, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
On 2024/4/26 02:08, Sui Jingfeng wrote:
...
Are you speaking to yourself? I'm totally lost.
Please, if you want to give a constructive feedback, try to understand
the topic from different aspects and then clearly express it.
OK,
The previous email analysis the non-DT cases exhaustively, this email intend to
demonstrate the more frequently use case.
That is, in the *DT('OF')* based systems,
device_get_match_data() is completely equivalent to
of_device_get_match_data().
So the net results of applying this patch are "no gains and no lost".
This is not true.
Yes, I'm true.
I have mentionedin previous(earlier) paragraph with "in the DT(OF) based
systems" or similar words.
It's only part of the cases, i.e. DT. So, I assume you meant
"So the net results of applying this patch are "no gains and no lost" in DT
case".
Yeah,it is true that this patch are "no gains and no lost" in DT case.
Things will become clear if we divide the whole problem into two cases(DT and
non-DT)
to discuss, that's it. That's all I can tell.
Not really.
I'm very clear before our conversation, really!
non-DT cases can also be divided to "fwnode backed or not",
For non fwnode backed case of non-DT cases, there is not decent way to acquire
large set of device properties. And is out of the scope of "Correct use of
device property APIs".
and
the former might be subdivided to "is it swnode backed or real fwnode one?"
Yeah,
On non-DT cases, it can be subdivided to swnode backed case and ACPI fwnode
backed case.
- For swnode backed case: the device_get_match_data() don't has a implemented
backend.
- For ACPI fwnode backed case: the device_get_match_data() has a implemented
backend.
But the driver has *neither* software node support nor ACPI support, so that
the rotation
property can not get and ili9341_dpi_probe() will fails. So in total, this is
not a 100%
correct use of device property APIs.
But I'm fine that if you want to leave(ignore) those less frequent use cases
temporarily,
there may have programmers want to post patches, to complete the missing in the
future.
So, there do have some gains on non-DT cases.
- As you make it be able to compiled on X86 with the drm-misc-defconfig.
- You cleanup the code up (at least patch 2 in this series is no obvious
problem).
- You allow people to modprobe it, and maybe half right and half undefined.
But you do helps moving something forward, so congratulations for the wake up.
--
Best regards,
Sui
Re: [PATCH v2 3/4] drm/panthor: Relax the constraints on the tiler chunk size
On Tue, Apr 30, 2024 at 01:28:51PM +0200, Boris Brezillon wrote:
> The field used to store the chunk size if 12 bits wide, and the encoding
> is chunk_size = chunk_header.chunk_size << 12, which gives us a
> theoretical [4k:8M] range. This range is further limited by
> implementation constraints, and all known implementations seem to
> impose a [128k:8M] range, so do the same here.
>
> We also relax the power-of-two constraint, which doesn't seem to
> exist on v10. This will allow userspace to fine-tune initial/max
> tiler memory on memory-constrained devices.
>
> v2:
> - Turn the power-of-two constraint into a page-aligned constraint to allow
> fine-tune of the initial/max heap memory size
> - Fix the panthor_heap_create() kerneldoc
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
With the typo that Adrián mentioned fixed,
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 8
> include/uapi/drm/panthor_drm.h | 6 +-
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 3be86ec383d6..683bb94761bc 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -253,8 +253,8 @@ int panthor_heap_destroy(struct panthor_heap_pool *pool,
> u32 handle)
> * @pool: Pool to instantiate the heap context from.
> * @initial_chunk_count: Number of chunk allocated at initialization time.
> * Must be at least 1.
> - * @chunk_size: The size of each chunk. Must be a power of two between 256k
> - * and 2M.
> + * @chunk_size: The size of each chunk. Must be page-aligned and lie in the
> + * [128k:2M] range.
> * @max_chunks: Maximum number of chunks that can be allocated.
> * @target_in_flight: Maximum number of in-flight render passes.
> * @heap_ctx_gpu_va: Pointer holding the GPU address of the allocated heap
> @@ -284,8 +284,8 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
> if (initial_chunk_count > max_chunks)
> return -EINVAL;
>
> - if (hweight32(chunk_size) != 1 ||
> - chunk_size < SZ_256K || chunk_size > SZ_2M)
> + if (!IS_ALIGNED(chunk_size, PAGE_SIZE) ||
> + chunk_size < SZ_128K || chunk_size > SZ_8M)
> return -EINVAL;
>
> down_read(>lock);
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index 5db80a0682d5..b8220d2e698f 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -898,7 +898,11 @@ struct drm_panthor_tiler_heap_create {
> /** @initial_chunk_count: Initial number of chunks to allocate. Must be
> at least one. */
> __u32 initial_chunk_count;
>
> - /** @chunk_size: Chunk size. Must be a power of two at least 256KB
> large. */
> + /**
> + * @chunk_size: Chunk size.
> + *
> + * Must be page-aligned and lie in the [128k:8M] range.
> + */
> __u32 chunk_size;
>
> /**
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
[PATCH RFC v2] drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
Allows PTE kind and tile mode on BO create with VM_BIND, as well as adds a
GETPARAM to indicate this change. This is needed to support modifiers in NVK
and ensure correctness when dealing with the nouveau GL driver.
---
v2 of the VMA PTE kind and tile mode patch. This one adds the kind and tile
mode handling code in the common path and also adds a GETPARAM to indicate the
change. The userspace implementation is still a WIP but should be ready within
the next week.
Thanks in advance,
Mohamed
drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++
drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +++--
include/uapi/drm/nouveau_drm.h | 7
3 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 80f74ee0f..47e53e17b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -272,6 +272,9 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
getparam->value = (u64)ttm_resource_manager_usage(vram_mgr);
break;
}
+ case NOUVEAU_GETPARAM_HAS_VMA_TILEMODE:
+ getparam->value = 1;
+ break;
default:
NV_PRINTK(dbg, cli, "unknown parameter %lld\n",
getparam->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index db8cbf615..583c962ef 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -241,28 +241,29 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
}
nvbo->contig = !(tile_flags & NOUVEAU_GEM_TILE_NONCONTIG);
- if (!nouveau_cli_uvmm(cli) || internal) {
- /* for BO noVM allocs, don't assign kinds */
- if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
- nvbo->kind = (tile_flags & 0xff00) >> 8;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
- }
- nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
- } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
- nvbo->kind = (tile_flags & 0x7f00) >> 8;
- nvbo->comp = (tile_flags & 0x0003) >> 16;
- if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
- kfree(nvbo);
- return ERR_PTR(-EINVAL);
- }
- } else {
- nvbo->zeta = (tile_flags & 0x0007);
+ /* for BO allocs, don't assign kinds */
+ if (cli->device.info.family >= NV_DEVICE_INFO_V0_FERMI) {
+ nvbo->kind = (tile_flags & 0xff00) >> 8;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
+ }
+
+ nvbo->comp = mmu->kind[nvbo->kind] != nvbo->kind;
+ } else if (cli->device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
+ nvbo->kind = (tile_flags & 0x7f00) >> 8;
+ nvbo->comp = (tile_flags & 0x0003) >> 16;
+ if (!nvif_mmu_kind_valid(mmu, nvbo->kind)) {
+ kfree(nvbo);
+ return ERR_PTR(-EINVAL);
}
- nvbo->mode = tile_mode;
+ } else {
+ nvbo->zeta = (tile_flags & 0x0007);
+ }
+ nvbo->mode = tile_mode;
+ if (!nouveau_cli_uvmm(cli) || internal) {
/* Determine the desirable target GPU page size for the buffer.
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
@@ -304,12 +305,6 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
}
nvbo->page = vmm->page[pi].shift;
} else {
- /* reject other tile flags when in VM mode. */
- if (tile_mode)
- return ERR_PTR(-EINVAL);
- if (tile_flags & ~NOUVEAU_GEM_TILE_NONCONTIG)
- return ERR_PTR(-EINVAL);
-
/* Determine the desirable target GPU page size for the buffer.
*/
for (i = 0; i < vmm->page_nr; i++) {
/* Because we cannot currently allow VMM maps to fail
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index cd84227f1..5402f77ee 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -68,6 +68,13 @@ extern "C" {
*/
#define NOUVEAU_GETPARAM_VRAM_USED 19
+/*
+ * NOUVEAU_GETPARAM_HAS_VMA_TILEMODE
+ *
+ * Query whether tile mode and PTE kind are accepted
Re: [PATCH v2 2/4] drm/panthor: Make sure the tiler initial/max chunks are consistent
On Tue, Apr 30, 2024 at 01:28:50PM +0200, Boris Brezillon wrote:
> It doesn't make sense to have a maximum number of chunks smaller than
> the initial number of chunks attached to the context.
>
> Fix the uAPI header to reflect the new constraint, and mention the
> undocumented "initial_chunk_count > 0" constraint while at it.
>
> v2:
> - Fix the check
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 3 +++
> include/uapi/drm/panthor_drm.h | 8 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index c3c0ba744937..3be86ec383d6 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -281,6 +281,9 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
> if (initial_chunk_count == 0)
> return -EINVAL;
>
> + if (initial_chunk_count > max_chunks)
> + return -EINVAL;
> +
Is is just me that feels like a lost opportunity to merge the check with the
one above?
if (!initial_chunk_count || initial_chunk_count > max_chunks)
return -EINVAL;
Otherwise, Reviewed-by: Liviu Dudau
Best regards,
Liviu
> if (hweight32(chunk_size) != 1 ||
> chunk_size < SZ_256K || chunk_size > SZ_2M)
> return -EINVAL;
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index dadb05ab1235..5db80a0682d5 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -895,13 +895,17 @@ struct drm_panthor_tiler_heap_create {
> /** @vm_id: VM ID the tiler heap should be mapped to */
> __u32 vm_id;
>
> - /** @initial_chunk_count: Initial number of chunks to allocate. */
> + /** @initial_chunk_count: Initial number of chunks to allocate. Must be
> at least one. */
> __u32 initial_chunk_count;
>
> /** @chunk_size: Chunk size. Must be a power of two at least 256KB
> large. */
> __u32 chunk_size;
>
> - /** @max_chunks: Maximum number of chunks that can be allocated. */
> + /**
> + * @max_chunks: Maximum number of chunks that can be allocated.
> + *
> + * Must be at least @initial_chunk_count.
> + */
> __u32 max_chunks;
>
> /**
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/i915: fix missing linux/debugfs.h includes
On 4/30/24 16:53, Jani Nikula wrote:
On Tue, 30 Apr 2024, Danilo Krummrich wrote:
After dropping linux/debugfs.h include from drm/drm_print.h the following
files in i915 miss the linux/debugfs.h include: i915_debugfs.c,
i915_debugfs_params.c and i915_gpu_error.c.
Add the include to fix the corresponding build errors.
Reported-by: kernel test robot
Fixes: 33d5ae6cacf4 ("drm/print: drop include debugfs.h and include where
needed")
Closes:
https://lore.kernel.org/oe-kbuild-all/202404260726.nyguvl59-...@intel.com/
Signed-off-by: Danilo Krummrich
Thanks, but it's already fixed by commit 7fa043eafdb7 ("drm/i915: fix
build with missing debugfs includes") in drm-next.
Even better, note that drm-misc-next is still broken though.
- Danilo
BR,
Jani.
---
drivers/gpu/drm/i915/i915_debugfs.c| 1 +
drivers/gpu/drm/i915/i915_debugfs_params.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24c78873b3cf..b552e27cdcd5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,6 +26,7 @@
*
*/
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 8bca02025e09..295486b8ceb1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -3,6 +3,7 @@
* Copyright © 2019 Intel Corporation
*/
+#include
#include
#include "i915_debugfs_params.h"
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2594eb10c559..625b3c024540 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -28,6 +28,7 @@
*/
#include
+#include
#include
#include
#include
base-commit: 4a9a567ab101e659a4fafb7a691ff6b84531a10a
Re: [PATCH v2 1/4] drm/panthor: Fix tiler OOM handling to allow incremental rendering
On Tue, Apr 30, 2024 at 01:28:49PM +0200, Boris Brezillon wrote:
> From: Antonino Maniscalco
>
> If the kernel couldn't allocate memory because we reached the maximum
> number of chunks but no render passes are in flight
> (panthor_heap_grow() returning -ENOMEM), we should defer the OOM
> handling to the FW by returning a NULL chunk. The FW will then call
> the tiler OOM exception handler, which is supposed to implement
> incremental rendering (execute an intermediate fragment job to flush
> the pending primitives, release the tiler memory that was used to
> store those primitives, and start over from where it stopped).
>
> Instead of checking for both ENOMEM and EBUSY, make panthor_heap_grow()
> return ENOMEM no matter the reason of this allocation failure, the FW
> doesn't care anyway.
>
> v2:
> - Make panthor_heap_grow() return -ENOMEM for all kind of allocation
> failures
> - Document the panthor_heap_grow() semantics
>
> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> Signed-off-by: Antonino Maniscalco
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 12
> drivers/gpu/drm/panthor/panthor_sched.c | 7 ++-
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 143fa35f2e74..c3c0ba744937 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -410,6 +410,13 @@ int panthor_heap_return_chunk(struct panthor_heap_pool
> *pool,
> * @renderpasses_in_flight: Number of render passes currently in-flight.
> * @pending_frag_count: Number of fragment jobs waiting for
> execution/completion.
> * @new_chunk_gpu_va: Pointer used to return the chunk VA.
> + *
> + * Return:
> + * - 0 if a new heap was allocated
> + * - -ENOMEM if the tiler context reached the maximum number of chunks
> + * or if too many render passes are in-flight
> + * or if the allocation failed
> + * - -EINVAL if any of the arguments passed to panthor_heap_grow() is invalid
> */
> int panthor_heap_grow(struct panthor_heap_pool *pool,
> u64 heap_gpu_va,
> @@ -439,10 +446,7 @@ int panthor_heap_grow(struct panthor_heap_pool *pool,
>* handler provided by the userspace driver, if any).
>*/
> if (renderpasses_in_flight > heap->target_in_flight ||
> - (pending_frag_count > 0 && heap->chunk_count >= heap->max_chunks)) {
> - ret = -EBUSY;
> - goto out_unlock;
> - } else if (heap->chunk_count >= heap->max_chunks) {
> + heap->chunk_count >= heap->max_chunks) {
> ret = -ENOMEM;
> goto out_unlock;
> }
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index b3a51a6de523..fd928362d45e 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -1354,7 +1354,12 @@ static int group_process_tiler_oom(struct
> panthor_group *group, u32 cs_id)
> pending_frag_count, _chunk_va);
> }
>
> - if (ret && ret != -EBUSY) {
> + /* If the heap context doesn't have memory for us, we want to let the
> + * FW try to reclaim memory by waiting for fragment jobs to land or by
> + * executing the tiler OOM exception handler, which is supposed to
> + * implement incremental rendering.
> + */
> + if (ret && ret != -ENOMEM) {
> drm_warn(>base, "Failed to extend the tiler heap\n");
> group->fatal_queues |= BIT(cs_id);
> sched_queue_delayed_work(sched, tick, 0);
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/i915: fix missing linux/debugfs.h includes
On Tue, 30 Apr 2024, Danilo Krummrich wrote:
> After dropping linux/debugfs.h include from drm/drm_print.h the following
> files in i915 miss the linux/debugfs.h include: i915_debugfs.c,
> i915_debugfs_params.c and i915_gpu_error.c.
>
> Add the include to fix the corresponding build errors.
>
> Reported-by: kernel test robot
> Fixes: 33d5ae6cacf4 ("drm/print: drop include debugfs.h and include where
> needed")
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202404260726.nyguvl59-...@intel.com/
> Signed-off-by: Danilo Krummrich
Thanks, but it's already fixed by commit 7fa043eafdb7 ("drm/i915: fix
build with missing debugfs includes") in drm-next.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 1 +
> drivers/gpu/drm/i915/i915_debugfs_params.c | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 24c78873b3cf..b552e27cdcd5 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -26,6 +26,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
> b/drivers/gpu/drm/i915/i915_debugfs_params.c
> index 8bca02025e09..295486b8ceb1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs_params.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
> @@ -3,6 +3,7 @@
> * Copyright © 2019 Intel Corporation
> */
>
> +#include
> #include
>
> #include "i915_debugfs_params.h"
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 2594eb10c559..625b3c024540 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -28,6 +28,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
>
> base-commit: 4a9a567ab101e659a4fafb7a691ff6b84531a10a
--
Jani Nikula, Intel
Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs
On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:10, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > It seems driver missed the point of proper use of device property APIs.
> > > > Correct this by updating headers and calls respectively.
> > > You are using the 'seems' here exactly saying that you are not 100% sure.
To add here, "seems" is used to show that I have no knowledge on what was
the idea behind this implementation by the original author. Plus my knowledge
in the firmware node / device property APIs and use cases in Linux kernel.
> > > Please allow me to tell you the truth: This patch again has ZERO effect.
> > > It fix nothing. And this patch is has the risks to be wrong.
> > Huh?! Really, stop commenting the stuff you do not understand.
>
> I'm actually a professional display drivers developer at the downstream
> in the past, despite my contribution to upstream is less. But I believe
> that all panel driver developers know what I'm talking about. So please
> have take a look at my replies.
Okay.
> > > Simple because the "ili9341_probe() ---> ili9341_dbi_prob()" code path
> > > is DT dependent.
> > >
> > > First of all, the devm_of_find_backlight() is called in
> > > ili9341_dbi_probe()
> > > under *non-DT* environment, devm_of_find_backlight() is just a just a
> > > no-op and will return NULL. NULL is not an error code, so
> > > ili9341_dbi_probe()
> > > won't rage quit. But the several side effect is that the backlight will
> > > NOT works at all.
> > Is it a problem?
>
> Yes, it is.
>
> The core problem is that the driver you are modifying has *implicit*
> *dependency* on DT.
> The implicit dependency is due to the calling of devm_of_find_backlight().
> This function
> is a no-op under non-DT systems.
Okay.
> Therefore, before the devm_of_find_backlight() and
> the device_get_match_data() function can truly DT independent.
True for the first part, not true for the second.
> Removing the "OF" dependency just let the tigers run out from the jail.
>
> It is not really meant to targeting at you, but I thinks, all of drm_panel
> drivers
> that has the devm_of_find_backlight() invoked will suffer such concerns.
> In short, the reason is that the *implicit* *dependency* populates and
> the undefined behavior gets triggered.
Still no problem statement. My hardware works nicely on non-DT environment.
(And since it's Arduino-based one, I assume it will work on DT environments
the very same way.)
> I'm sure you know that device_get_match_data() is same with
> of_device_get_match_data()
> for DT based systems. For non DT based systems, device_get_match_data() is
> just *undefined*
> Note that ACPI is not in the scope of the discussion here, as all of the drm
> bridges and
> panels driver under drivers/gpu/drm/ hasn't the ACPI support yet.
This patch shows exactly how to bring back the ACPI support to one of them
(as it's done for tinyDRM cases).
> Therefore, at present,
> it safe to say that device_get_match_data() is *undefined* under no-DT
> environment.
This is not true.
> Removing the "OF" dependency hints to us that it allows the driver to be
> probed as a
> pure SPI device under non DT systems. When device_get_match_data() is called,
> it returns
> NULL to us now. As a result, the drm driver being modified will tears down.
>
> See bellow code snippet extracted frompanel-ilitek-ili9341.c:
>
>
> ```
> ili->conf = of_device_get_match_data(dev);
> if (!ili->conf) {
> dev_err(dev, "missing device configuration\n");
> return -ENODEV;
> }
> ```
>
> > > It is actually considered as fatal bug for *panels* if the backlight of
> > > it is not light up, at least the brightness of *won't* be able to adjust.
> > > What's worse, if there is no sane platform setup code at the firmware
> > > or boot loader stage to set a proper initial state. The screen is complete
> > > dark. Even though the itself panel is refreshing framebuffers, it can not
> > > be seen by human's eye. Simple because of no backlight.
> > Can you imagine that I may have different hardware that considered
> > this is non-fatal error?
> >
> Yes, I can imagine.
>
> I believe you have the hardware which make you patch correct to run
> in 99.9% of all cases. But as long as there one bug happened, you patch
> are going to be blamed.
>
> Because its your patch that open the door, both from the perceptive of
> practice and from the perceptive of the concept (static analysis).
>
> > > Second, the ili9341_dbi_probe() requires additional device properties to
> > > be able to works very well on the rotation screen case. See the calling
> > > of "device_property_read_u32(dev, "rotation", )" in
> > > ili9341_dbi_probe() function.
> > Yes, exactly, and how does it object the purpose of this patch?
>
> Because under *non-DT* environment, your commit
Re: [PATCH v1 5/5] drm/ci: update xfails for the new testlist
On 30/04/2024 06:11, Vignesh Raman wrote: Now the testlist is used from IGT build, so update xfails with the new testlist. Signed-off-by: Vignesh Raman --- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++ .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 8 +- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 15 drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 22 - .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 8 ++ drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 8 ++ drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 45 +- drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 5 ++ drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 12 +++ drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 6 ++ drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 8 ++ drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 28 +-- drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 12 +++ drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 39 - drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 10 ++- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 21 + drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 75 + drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 13 +++ drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 46 +-- drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 8 ++ .../drm/ci/xfails/mediatek-mt8173-fails.txt | 47 +++ .../drm/ci/xfails/mediatek-mt8183-fails.txt | 17 +--- .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 20 + .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 26 ++ .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 5 +- .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 67 +++ .../msm-sc7180-trogdor-kingoftown-fails.txt | 34 .../msm-sc7180-trogdor-kingoftown-flakes.txt | 5 ++ ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 34 ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 75 - .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 26 ++ .../drm/ci/xfails/rockchip-rk3288-fails.txt | 54 .../drm/ci/xfails/rockchip-rk3399-fails.txt | 80 ++ .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 7 -- .../drm/ci/xfails/virtio_gpu-none-fails.txt | 82 +-- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 3 + 42 files changed, 574 insertions(+), 495 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-fails.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index ea87dc46bc2b..a48df7880ec5 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,27 +1,46 @@ -kms_addfb_basic@bad-pitch-65536,Fail +amdgpu/amd_assr@assr-links,Fail +amdgpu/amd_assr@assr-links-dpms,Fail +amdgpu/amd_deadlock@amdgpu-deadlock-compute,Timeout +amdgpu/amd_ilr@ilr-policy,Fail +amdgpu/amd_mall@static-screen,Crash +amdgpu/amd_mode_switch@mode-switch-first-last-pipe-2,Crash +amdgpu/amd_pci_unplug@amdgpu_hotunplug_simple,Fail +amdgpu/amd_pci_unplug@amdgpu_hotunplug_with_cs,Fail +amdgpu/amd_pci_unplug@amdgpu_hotunplug_with_exported_bo,Fail +amdgpu/amd_plane@mpo-pan-nv12,Fail +amdgpu/amd_plane@mpo-pan-p010,Fail +amdgpu/amd_plane@mpo-pan-rgb,Crash +amdgpu/amd_plane@mpo-scale-nv12,Fail +amdgpu/amd_plane@mpo-scale-p010,Fail +amdgpu/amd_plane@mpo-scale-rgb,Crash +amdgpu/amd_plane@mpo-swizzle-toggle,Fail +amdgpu/amd_uvd_dec@amdgpu_uvd_decode,Fail +amdgpu/amd_vce_dec@amdgpu_cs_vce_destroy,Fail +amdgpu/amd_vce_dec@amdgpu_cs_vce_encode,Fail +amdgpu/amd_vm@amdgpu-vm-unaligned-map,Fail +amdgpu/amd_vrr_range@freesync-parsing,Timeout +device_reset@unbind-cold-reset-rebind,Fail +dumb_buffer@invalid-bpp,Fail kms_addfb_basic@bo-too-small,Fail kms_addfb_basic@too-high,Fail kms_async_flips@async-flip-with-page-flip-events,Fail
Re: [PATCH v1 4/5] drm/ci: skip driver specific tests
On 30/04/2024 06:11, Vignesh Raman wrote: Skip driver specific tests and skip kms tests for panfrost driver since it is not a kms driver. Signed-off-by: Vignesh Raman --- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +- drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 14 +- drivers/gpu/drm/ci/xfails/i915-apl-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-cml-skips.txt| 12 drivers/gpu/drm/ci/xfails/i915-glk-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-whl-skips.txt| 14 +- .../gpu/drm/ci/xfails/mediatek-mt8173-skips.txt | 12 .../gpu/drm/ci/xfails/mediatek-mt8183-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/msm-apq8096-skips.txt | 14 +- .../msm-sc7180-trogdor-kingoftown-skips.txt | 15 +++ .../msm-sc7180-trogdor-lazor-limozeen-skips.txt | 15 +++ drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt | 15 +++ .../gpu/drm/ci/xfails/rockchip-rk3288-skips.txt | 17 - .../gpu/drm/ci/xfails/rockchip-rk3399-skips.txt | 15 +++ .../gpu/drm/ci/xfails/virtio_gpu-none-skips.txt | 15 ++- 19 files changed, 260 insertions(+), 10 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt index e2c538a0f954..70e2f925d06f 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt @@ -1,2 +1,14 @@ # Suspend to RAM seems to be broken on this machine -.*suspend.* \ No newline at end of file +.*suspend.* + +# Skip driver specific tests +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# Skip intel specific tests +gem_.* +i915_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt b/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt index fe55540a3f9a..59f8acfaa5ba 100644 --- a/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt @@ -1,4 +1,16 @@ # Suspend to RAM seems to be broken on this machine .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No newline at end of file +kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt b/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt index 3430b215c06e..d97bc038b63a 100644 --- a/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt @@ -3,4 +3,16 @@ # This is generating kernel oops with divide error kms_plane_scaling@invalid-parameters # This is cascading issues -kms_3d \ No newline at end of file +kms_3d + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt b/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt index 6d3d7ddc377f..92c0ffee8283 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt @@ -1,2 +1,14 @@ # This is generating kernel oops with divide error kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt b/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt index 4c7d00ce14bc..a168722caf13 100644 --- a/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt @@ -2,4 +2,16 @@ .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No newline at end of file +kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt b/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt index 4c7d00ce14bc..a168722caf13 100644 --- a/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt @@ -2,4 +2,16 @@
Re: [PATCH v1 3/5] drm/ci: build virtual GPU driver as module
On 30/04/2024 06:11, Vignesh Raman wrote:
With latest IGT, the tests tries to load the module and it
fails. So build the virtual GPU driver for virtio as module.
Signed-off-by: Vignesh Raman
Acked-by: Helen Koike
---
drivers/gpu/drm/ci/build.sh | 1 -
drivers/gpu/drm/ci/igt_runner.sh | 6 +++---
drivers/gpu/drm/ci/image-tags.yml | 4 ++--
drivers/gpu/drm/ci/test.yml | 1 +
drivers/gpu/drm/ci/x86_64.config | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 8a3baa003904..95493df9cdc2 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -156,7 +156,6 @@ fi
mkdir -p artifacts/install/lib
mv install/* artifacts/install/.
-rm -rf artifacts/install/modules
ln -s common artifacts/install/ci-common
cp .config artifacts/${CI_JOB_NAME}_config
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index 20026612a9bd..55532f79fbdc 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -30,10 +30,10 @@ case "$DRIVER_NAME" in
export IGT_FORCE_DRIVER="panfrost"
fi
;;
-amdgpu)
+amdgpu|virtio_gpu)
# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the
module in /lib
-mv /install/modules/lib/modules/* /lib/modules/.
-modprobe amdgpu
+mv /install/modules/lib/modules/* /lib/modules/. || true
+modprobe --first-time $DRIVER_NAME
;;
esac
diff --git a/drivers/gpu/drm/ci/image-tags.yml b/drivers/gpu/drm/ci/image-tags.yml
index d8f72b82c938..fd1cb6061166 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,9 +4,9 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "2023-10-08-config"
+ DEBIAN_BUILD_TAG: "2024-04-22-virtio"
- KERNEL_ROOTFS_TAG: "2023-10-06-amd"
+ KERNEL_ROOTFS_TAG: "2024-04-22-virtio"
PKG_REPO_REV: "3cc12a2a"
DEBIAN_X86_64_TEST_BASE_IMAGE: "debian/x86_64_test-base"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 612c9ede3507..864ac3809d84 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -350,6 +350,7 @@ virtio_gpu:none:
script:
- ln -sf $CI_PROJECT_DIR/install /install
- mv install/bzImage /lava-files/bzImage
+- mkdir -p /lib/modules
- mkdir -p $CI_PROJECT_DIR/results
- ln -sf $CI_PROJECT_DIR/results /results
- install/crosvm-runner.sh install/igt_runner.sh
diff --git a/drivers/gpu/drm/ci/x86_64.config b/drivers/gpu/drm/ci/x86_64.config
index 1cbd49a5b23a..78479f063e8e 100644
--- a/drivers/gpu/drm/ci/x86_64.config
+++ b/drivers/gpu/drm/ci/x86_64.config
@@ -91,7 +91,7 @@ CONFIG_KVM=y
CONFIG_KVM_GUEST=y
CONFIG_VIRT_DRIVERS=y
CONFIG_VIRTIO_FS=y
-CONFIG_DRM_VIRTIO_GPU=y
+CONFIG_DRM_VIRTIO_GPU=m
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
Re: [PATCH v1 1/5] drm/ci: uprev mesa version
On 30/04/2024 06:11, Vignesh Raman wrote:
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa to latest version which includes a fix for this issue.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/908f444e
Also copy helper scripts to install, so that the ci jobs can
use these scripts for logging.
Signed-off-by: Vignesh Raman
Acked-by: Helen Koike
---
drivers/gpu/drm/ci/build.sh | 1 +
drivers/gpu/drm/ci/container.yml | 12
drivers/gpu/drm/ci/gitlab-ci.yml | 11 ---
drivers/gpu/drm/ci/image-tags.yml | 3 ++-
drivers/gpu/drm/ci/test.yml | 2 ++
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 106f2d40d222..8a3baa003904 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -128,6 +128,7 @@ fi
# Pass needed files to the test stage
mkdir -p install
cp -rfv .gitlab-ci/* install/.
+cp -rfv ci/* install/.
cp -rfv install/common install/ci-common
cp -rfv drivers/gpu/drm/ci/* install/.
diff --git a/drivers/gpu/drm/ci/container.yml b/drivers/gpu/drm/ci/container.yml
index 9764e7921a4f..d6edf3635b23 100644
--- a/drivers/gpu/drm/ci/container.yml
+++ b/drivers/gpu/drm/ci/container.yml
@@ -36,15 +36,15 @@ debian/android_build:
rules:
- when: never
-debian/x86_64_test-android:
+.debian/x86_64_test-android:
rules:
- when: never
-windows_build_vs2019:
+windows_build_msvc:
rules:
- when: never
-windows_test_vs2019:
+windows_test_msvc:
rules:
- when: never
@@ -56,10 +56,6 @@ rustfmt:
rules:
- when: never
-windows_vs2019:
- rules:
-- when: never
-
-clang-format:
+windows_msvc:
rules:
- when: never
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 084e3ff8e3f4..9bf5190604a7 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
variables:
DRM_CI_PROJECT_PATH: mesa/mesa
- DRM_CI_COMMIT_SHA:
9d162de9a05155e1c4041857a5848842749164cf
+ DRM_CI_COMMIT_SHA:
e5f133ccc426a197c48a4e88f5377f943f078180
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -26,10 +26,13 @@ variables:
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
# default kernel for rootfs before injecting the current kernel tree
KERNEL_REPO: "gfx-ci/linux"
- KERNEL_TAG: "v6.6.4-for-mesa-ci-e4f4c500f7fb"
+ KERNEL_TAG: "v6.6.21-mesa-19fc"
KERNEL_IMAGE_BASE: https://${S3_HOST}/mesa-lava/${KERNEL_REPO}/${KERNEL_TAG}
LAVA_TAGS: subset-1-gfx
LAVA_JOB_PRIORITY: 30
+ ARTIFACTS_BASE_URL:
https://${CI_PROJECT_ROOT_NAMESPACE}.${CI_PAGES_DOMAIN}/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts
+ # Python scripts for structured logger
+ PYTHONPATH: "$PYTHONPATH:$CI_PROJECT_DIR/install"
default:
before_script:
@@ -46,6 +49,7 @@ default:
- cd $CI_PROJECT_DIR
- curl --output -
$DRM_CI_PROJECT_URL/-/archive/$DRM_CI_COMMIT_SHA/mesa-$DRM_CI_COMMIT_SHA.tar.gz
| tar -xz
- mv mesa-$DRM_CI_COMMIT_SHA/.gitlab-ci* .
+- mv mesa-$DRM_CI_COMMIT_SHA/bin/ci .
- rm -rf mesa-$DRM_CI_COMMIT_SHA/
- echo -e "\e[0Ksection_end:$(date +%s):drm_ci_download_section\r\e[0K"
@@ -98,6 +102,7 @@ include:
stages:
- sanity
- container
+ - code-validation
- git-archive
- build
- amdgpu
@@ -107,7 +112,6 @@ stages:
- msm
- rockchip
- virtio-gpu
- - lint
# YAML anchors for rule conditions
#
@@ -218,6 +222,7 @@ make git archive:
script:
# Remove drm-ci files we just added
- rm -rf .gitlab-ci.*
+- rm -rf ci
# Compactify the .git directory
- git gc --aggressive
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index 7ab4f2514da8..d8f72b82c938 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -1,5 +1,5 @@
variables:
- CONTAINER_TAG: "2023-10-11-mesa-uprev"
+ CONTAINER_TAG: "2024-04-22-mesa-uprev"
DEBIAN_X86_64_BUILD_BASE_IMAGE: "debian/x86_64_build-base"
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
@@ -7,6 +7,7 @@ variables:
DEBIAN_BUILD_TAG: "2023-10-08-config"
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
+ PKG_REPO_REV: "3cc12a2a"
DEBIAN_X86_64_TEST_BASE_IMAGE: "debian/x86_64_test-base"
DEBIAN_X86_64_TEST_IMAGE_GL_PATH: "debian/x86_64_test-gl"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 8bc63912fddb..612c9ede3507 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -150,6 +150,8 @@ msm:sdm845:
BM_KERNEL:
Re: [PATCH] drm/fb_dma: Add checks in drm_fb_dma_get_scanout_buffer()
On 29/04/2024 09:24, Thomas Zimmermann wrote:
Am 26.04.24 um 14:10 schrieb Jocelyn Falempe:
plane->state and plane->state->fb can be NULL, so add a check before
dereferencing them.
Found by testing with the imx driver.
Fixes: 879b3b6511fe9 ("drm/fb_dma: Add generic get_scanout_buffer()
for drm_panic")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_fb_dma_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c
b/drivers/gpu/drm/drm_fb_dma_helper.c
index 96e5ab960f12..d7bffde94cc5 100644
--- a/drivers/gpu/drm/drm_fb_dma_helper.c
+++ b/drivers/gpu/drm/drm_fb_dma_helper.c
@@ -167,6 +167,9 @@ int drm_fb_dma_get_scanout_buffer(struct drm_plane
*plane,
struct drm_gem_dma_object *dma_obj;
struct drm_framebuffer *fb;
+ if (!plane->state || !plane->state->fb)
+ return -ENODEV;
+
It's EINVAL here. With that fixed, free free to add
Thanks, I just merged it to drm-misc-next with that fixed.
Reviewed-by: Thomas Zimmermann
Best regards
Thomas
fb = plane->state->fb;
/* Only support linear modifier */
if (fb->modifier != DRM_FORMAT_MOD_LINEAR)
base-commit: 2e3f08a1ac99cb9a19a5cb151593d4f9df5cc6a7
--
Jocelyn
Re: [PATCH] nouveau: Add missing break statement
On 4/30/24 15:18, Chaitanya Kumar Borah wrote:
Add the missing break statement that causes the following build error
CC [M] drivers/gpu/drm/i915/display/intel_display_device.o
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
‘build_registry’:
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1266:3: error: label
at end of compound statement
1266 | default:
| ^~~
CC [M] drivers/gpu/drm/amd/amdgpu/gfx_v10_0.o
HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg.h
CC [M] drivers/gpu/drm/amd/amdgpu/imu_v11_0.o
make[7]: *** [../scripts/Makefile.build:244:
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.o] Error 1
make[7]: *** Waiting for unfinished jobs
Fixes: b58a0bc904ff ("nouveau: add command-line GSP-RM registry support")
Closes:
https://lore.kernel.org/all/913052ca6c0988db1bab293cfae38529251b4594.ca...@nvidia.com/T/#m3c9acebac754f2e74a85b76c858c093bb1aacaf0
Signed-off-by: Chaitanya Kumar Borah
Applied to drm-misc-next, thanks!
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 0b46db5c77b8..63619512e7f6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1264,6 +1264,7 @@ static void build_registry(struct nvkm_gsp *gsp,
PACKED_REGISTRY_TABLE *registry
str_offset += reg->vlen;
break;
default:
+ break;
}
i++;
[PATCH] drm/i915: fix missing linux/debugfs.h includes
After dropping linux/debugfs.h include from drm/drm_print.h the following
files in i915 miss the linux/debugfs.h include: i915_debugfs.c,
i915_debugfs_params.c and i915_gpu_error.c.
Add the include to fix the corresponding build errors.
Reported-by: kernel test robot
Fixes: 33d5ae6cacf4 ("drm/print: drop include debugfs.h and include where
needed")
Closes:
https://lore.kernel.org/oe-kbuild-all/202404260726.nyguvl59-...@intel.com/
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/i915/i915_debugfs.c| 1 +
drivers/gpu/drm/i915/i915_debugfs_params.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24c78873b3cf..b552e27cdcd5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,6 +26,7 @@
*
*/
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 8bca02025e09..295486b8ceb1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -3,6 +3,7 @@
* Copyright © 2019 Intel Corporation
*/
+#include
#include
#include "i915_debugfs_params.h"
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2594eb10c559..625b3c024540 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -28,6 +28,7 @@
*/
#include
+#include
#include
#include
#include
base-commit: 4a9a567ab101e659a4fafb7a691ff6b84531a10a
--
2.44.0
Re: [PATCH] drm: deprecate driver date
On Tue, Apr 30, 2024 at 04:38:55PM +0300, Jani Nikula wrote: > On Tue, 30 Apr 2024, Daniel Vetter wrote: > > Might also be a good idea to wait a bit in case there's any regression > > reports for really old userspace. But I guess there's not a high chance > > for that to happen here, so imo fine to just go ahead right away. > > This small bit is definitely easier to revert if needed than the whole > shebang. So the reason I'm not super worried is that most likely it's going to be a an old driver for a specific .ko that falls over. So as long as you split it up per-driver it should still be a fairly minimal revert. But entirely up to you. -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:12, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 02:08, Sui Jingfeng wrote:
...
> > Are you speaking to yourself? I'm totally lost.
> >
> > Please, if you want to give a constructive feedback, try to understand
> > the topic from different aspects and then clearly express it.
>
> OK,
>
> The previous email analysis the non-DT cases exhaustively, this email intend
> to
> demonstrate the more frequently use case.
>
> That is, in the *DT('OF')* based systems,
> device_get_match_data() is completely equivalent to
> of_device_get_match_data().
> So the net results of applying this patch are "no gains and no lost".
This is not true. It's only part of the cases, i.e. DT. So, I assume you meant
"So the net results of applying this patch are "no gains and no lost" in DT
case".
> Things will become clear if we divide the whole problem into two cases(DT and
> non-DT)
> to discuss, that's it. That's all I can tell.
Not really. non-DT cases can also be divided to "fwnode backed or not", and
the former might be subdivided to "is it swnode backed or real fwnode one?"
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] nouveau: Add missing break statement
On Tue, Apr 30, 2024 at 06:48:40PM GMT, Chaitanya Kumar Borah wrote:
Add the missing break statement that causes the following build error
CC [M] drivers/gpu/drm/i915/display/intel_display_device.o
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
‘build_registry’:
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1266:3: error: label
at end of compound statement
1266 | default:
| ^~~
CC [M] drivers/gpu/drm/amd/amdgpu/gfx_v10_0.o
HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg.h
CC [M] drivers/gpu/drm/amd/amdgpu/imu_v11_0.o
make[7]: *** [../scripts/Makefile.build:244:
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.o] Error 1
make[7]: *** Waiting for unfinished jobs
Fixes: b58a0bc904ff ("nouveau: add command-line GSP-RM registry support")
Closes:
https://lore.kernel.org/all/913052ca6c0988db1bab293cfae38529251b4594.ca...@nvidia.com/T/#m3c9acebac754f2e74a85b76c858c093bb1aacaf0
Just found a previous bug report, so we can add here:
Closes:
https://lore.kernel.org/all/ca+g9fyu7ug0k8h9qjt0wbtwh_ll9juc+vc0wmu_z_vsspdn...@mail.gmail.com/
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 0b46db5c77b8..63619512e7f6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1264,6 +1264,7 @@ static void build_registry(struct nvkm_gsp *gsp,
PACKED_REGISTRY_TABLE *registry
str_offset += reg->vlen;
break;
default:
+ break;
since reg->type is an enum and we are handling all the values, another
possible approach is to remove the default handling and then the
compiler will warn you of missing cases if built with -Wswitch.
Any of the approaches seem good to me.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
}
i++;
--
2.25.1
Re: [RFC PATCH net-next v8 07/14] page_pool: devmem support
On 4/26/24 8:11 PM, Mina Almasry wrote:
> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
>>
>> On 2024-04-02 5:20 pm, Mina Almasry wrote:
>>> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
>>> */
>>> typedef unsigned long __bitwise netmem_ref;
>>>
>>> +static inline bool netmem_is_net_iov(const netmem_ref netmem)
>>> +{
>>> +#if defined(CONFIG_PAGE_POOL) && defined(CONFIG_DMA_SHARED_BUFFER)
>>
>> I am guessing you added this to try and speed up the fast path? It's
>> overly restrictive for us since we do not need dmabuf necessarily. I
>> spent a bit too much time wondering why things aren't working only to
>> find this :(
>
> My apologies, I'll try to put the changelog somewhere prominent, or
> notify you when I do something that I think breaks you.
>
> Yes, this is a by-product of a discussion with regards to the
> page_pool benchmark regressions due to adding devmem. There is some
> background on why this was added and the impact on the
> bench_page_pool_simple tests in the cover letter.
>
> For you, I imagine you want to change this to something like:
>
> #if defined(CONFIG_PAGE_POOL)
> #if defined(CONFIG_DMA_SHARED_BUFFER) || defined(CONFIG_IOURING)
>
> or something like that, right? Not sure if this is something I should
> do here or if something more appropriate to be in the patches you
> apply on top.
In general, attempting to hide overhead behind config options is always
a losing proposition. It merely serves to say "look, if these things
aren't enabled, the overhead isn't there", while distros blindly enable
pretty much everything and then you're back where you started.
--
Jens Axboe
Re: [PATCH] drm: deprecate driver date
On Tue, 30 Apr 2024, Daniel Vetter wrote: > Might also be a good idea to wait a bit in case there's any regression > reports for really old userspace. But I guess there's not a high chance > for that to happen here, so imo fine to just go ahead right away. This small bit is definitely easier to revert if needed than the whole shebang. BR, Jani. -- Jani Nikula, Intel
Re: [RFC PATCH net-next v8 07/14] page_pool: devmem support
On 4/27/24 03:11, Mina Almasry wrote:
On Fri, Apr 26, 2024 at 5:18 PM David Wei wrote:
On 2024-04-02 5:20 pm, Mina Almasry wrote:
@@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
*/
typedef unsigned long __bitwise netmem_ref;
+static inline bool netmem_is_net_iov(const netmem_ref netmem)
+{
+#if defined(CONFIG_PAGE_POOL) && defined(CONFIG_DMA_SHARED_BUFFER)
I am guessing you added this to try and speed up the fast path? It's
overly restrictive for us since we do not need dmabuf necessarily. I
spent a bit too much time wondering why things aren't working only to
find this :(
My apologies, I'll try to put the changelog somewhere prominent, or
notify you when I do something that I think breaks you.
Yes, this is a by-product of a discussion with regards to the
page_pool benchmark regressions due to adding devmem. There is some
background on why this was added and the impact on the
bench_page_pool_simple tests in the cover letter.
For you, I imagine you want to change this to something like:
#if defined(CONFIG_PAGE_POOL)
#if defined(CONFIG_DMA_SHARED_BUFFER) || defined(CONFIG_IOURING)
or something like that, right? Not sure if this is something I should
Feels a bit flimsy, if the argument is that you want to be able
to disable netmem overhead, then adding a netmem config option
sounds like a better way forward.
I have doubts this conditional handling is desirable in the first
place, but perhaps I missed the discussion.
do here or if something more appropriate to be in the patches you
apply on top.
I additionally think you may also need to run the
page_pool_benchmark_simple tests like I do in the cover letter to see
if you're affecting those.
--
Pavel Begunkov
drmm vs devm (was Re: [PATCH 2/8] drm/xe: covert sysfs over to devm)
Adding dri-devel because this is kinda more important. On Mon, Apr 29, 2024 at 04:28:42PM -0500, Lucas De Marchi wrote: > On Mon, Apr 29, 2024 at 02:45:26PM GMT, Rodrigo Vivi wrote: > > On Mon, Apr 29, 2024 at 04:17:54PM +0100, Matthew Auld wrote: > > > On 29/04/2024 14:52, Lucas De Marchi wrote: > > > > On Mon, Apr 29, 2024 at 09:28:00AM GMT, Rodrigo Vivi wrote: > > > > > On Mon, Apr 29, 2024 at 01:14:38PM +0100, Matthew Auld wrote: > > > > > > Hotunplugging the device seems to result in stuff like: > > > > > > > > > > > > kobject_add_internal failed for tile0 with -EEXIST, don't try to > > > > > > register things with the same name in the same directory. > > > > > > > > > > > > We only remove the sysfs as part of drmm, however that is tied to > > > > > > the > > > > > > lifetime of the driver instance and not the device underneath. > > > > > > Attempt > > > > > > to fix by using devm for all of the remaining sysfs stuff related > > > > > > to the > > > > > > device. > > > > > > > > > > hmmm... so basically we should use the drmm only for the global module > > > > > stuff and the devm for things that are per device? > > > > > > > > that doesn't make much sense. drmm is supposed to run when the driver > > > > unbinds from the device... basically when all refcounts are gone with > > > > drm_dev_put(). Are we keeping a ref we shouldn't? > > > > > > It's run when all refcounts are dropped for that particular drm_device, > > > but > > > that is separate from the physical device underneath (struct device). For > > > example if something has an open driver fd the drmm release action is not > > > going to be called until after that is also closed. But in the meantime we > > > might have already removed the pci device and re-attached it to a newly > > > allocated drm_device/xe_driver instance, like with hotunplug. > > > > > > For example, currently we don't even call basic stuff like guc_fini() etc. > > > when removing the pci device, but rather when the drm_device is released, > > > which sounds quite broken. > > > > > > So roughly drmm is for drm_device software level stuff and devm is for > > > stuff > > > that needs to happen when removing the device. See also the doc for drmm: > > > https://elixir.bootlin.com/linux/v6.8-rc1/source/drivers/gpu/drm/drm_managed.c#L23 > > > > > > Also: https://docs.kernel.org/gpu/drm-uapi.html#device-hot-unplug > > yeah... I think you convinced me So rule of thumb: - devm is for hardware stuff, so like removeing pci mmaps, releasing interrupt handlers, cleaning up anything hw related. Because after devm respective driver unbind, all that stuff is gone, _even_ when you hold onto a struct device reference. Because all that struct device reference guarantees is that the software structure stays around as a valid memory reference. - devm is also for remove uapi. Unfortunately we're not quite at the world where devm_drm_dev_register is possible, because on the unload side that must be done first, and there's still a few things drivers need to do after that which isn't fully devm/drmm-ified. - drmm is for anything software related, so data structures and stuff like that. If you have a devm_kmalloc, you very, very likely have a bug. This is were you tear down all your software datastructures, which means if you have that interleaved with the hw teardown in e.g. guc_fini you have some serious work cut out for you. drmm stuff is tied to the drm_device lifetime as the core drm uapi interface thing which might stick around for much longer than the drm_dev_unregister. - Finally, when going from the sw side to hw side you must wrap such access with drm_dev_enter/exit, or you have races. This is also where using drmm and devm for everything really helps, because it gives you a very strong hint when you're going from the sw world to the hw world. As an example, all the callbacks on the various kms objects are in the sw world (so need to be cleaned up with drmm), but the moment you access hw (e.g. any mmio) you need to protect that with a drm_dev_enter/exit Using devm for everything means you have a use-after-free on the sw side, otoh using devm means you have use-after-free on the hw side (like a physical hotunplug might reallocate your mmio range to another thunderbolt device that has been plugged in meanwhile). It's definitely big time fun all around :-/ Oh also, please help improve the docs on this stuff, I'm trying to make sure it's all there and ideally the various pieces link to the other parts, but it's tricky and I understand this stuff to much to spot the gaps ... Cheers, Sima > > > > > Cc: Aravind and Michal since this likely relates to the FLR discussion... > > > > but it looks to me that we should move more towards the devm_ and limit > > the usage of drmm_ to some very specific cases... > > agreed, > > Lucas De Marchi > > > > > > > > > > > > > > Lucas De Marchi -- Daniel Vetter Software Engineer, Intel
[PATCH] nouveau: Add missing break statement
Add the missing break statement that causes the following build error
CC [M] drivers/gpu/drm/i915/display/intel_display_device.o
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
‘build_registry’:
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1266:3: error: label
at end of compound statement
1266 | default:
| ^~~
CC [M] drivers/gpu/drm/amd/amdgpu/gfx_v10_0.o
HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg.h
CC [M] drivers/gpu/drm/amd/amdgpu/imu_v11_0.o
make[7]: *** [../scripts/Makefile.build:244:
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.o] Error 1
make[7]: *** Waiting for unfinished jobs
Fixes: b58a0bc904ff ("nouveau: add command-line GSP-RM registry support")
Closes:
https://lore.kernel.org/all/913052ca6c0988db1bab293cfae38529251b4594.ca...@nvidia.com/T/#m3c9acebac754f2e74a85b76c858c093bb1aacaf0
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index 0b46db5c77b8..63619512e7f6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -1264,6 +1264,7 @@ static void build_registry(struct nvkm_gsp *gsp,
PACKED_REGISTRY_TABLE *registry
str_offset += reg->vlen;
break;
default:
+ break;
}
i++;
--
2.25.1
Re: [PATCH] [v7] nouveau: add command-line GSP-RM registry support
On 4/30/24 15:06, Lucas De Marchi wrote: On Fri, Apr 26, 2024 at 06:08:19PM GMT, Danilo Krummrich wrote: On 4/25/24 18:38, Timur Tabi wrote: On Thu, 2024-04-25 at 15:22 +0200, Danilo Krummrich wrote: + size_t length; + + /* Remove any whitespace from the parameter string */ + length = strip(p, " \t\n"); With that, I see the following warning compiling this patch. warning: variable ‘length’ set but not used [-Wunused-but-set-variable] Did you intend to use the length for anything? No, and I could have sworn I fixed that before sending out v7. I think I originally intended 'length' to determine when I finished parsing the string. Also, looking at the warning made me aware of 'p' potentially being NULL. If you agree, I can fix the warning and add the corresponding NULL check when applying the patch. Yes, that would be great. You can just delete 'length'. The NULL check for 'p' should call clean_registry() before returning -ENOMEM. Applied to drm-misc-next, thanks! since this commit our CI is failing to build with the following error: CC [M] drivers/gpu/drm/i915/display/intel_display_device.o ../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function ‘build_registry’: ../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1266:3: error: label at end of compound statement 1266 | default: | ^~~ CC [M] drivers/gpu/drm/amd/amdgpu/gfx_v10_0.o HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg.h CC [M] drivers/gpu/drm/amd/amdgpu/imu_v11_0.o make[7]: *** [../scripts/Makefile.build:244: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.o] Error 1 make[7]: *** Waiting for unfinished jobs you are missing a `break;` after that default. @Timur, do you want to send a quick fix for this yourself? Otherwise, I can send one as well. We should fix this asap. - Danilo Thanks for catching this.
Re: [PATCH v2 3/4] drm/panthor: Relax the constraints on the tiler chunk size
Hi Boris,
On 30.04.2024 13:28, Boris Brezillon wrote:
> The field used to store the chunk size if 12 bits wide, and the encoding
> is chunk_size = chunk_header.chunk_size << 12, which gives us a
> theoretical [4k:8M] range. This range is further limited by
> implementation constraints, and all known implementations seem to
> impose a [128k:8M] range, so do the same here.
>
> We also relax the power-of-two constraint, which doesn't seem to
> exist on v10. This will allow userspace to fine-tune initial/max
> tiler memory on memory-constrained devices.
>
> v2:
> - Turn the power-of-two constraint into a page-aligned constraint to allow
> fine-tune of the initial/max heap memory size
> - Fix the panthor_heap_create() kerneldoc
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 8
> include/uapi/drm/panthor_drm.h | 6 +-
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 3be86ec383d6..683bb94761bc 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -253,8 +253,8 @@ int panthor_heap_destroy(struct panthor_heap_pool *pool,
> u32 handle)
> * @pool: Pool to instantiate the heap context from.
> * @initial_chunk_count: Number of chunk allocated at initialization time.
> * Must be at least 1.
> - * @chunk_size: The size of each chunk. Must be a power of two between 256k
> - * and 2M.
> + * @chunk_size: The size of each chunk. Must be page-aligned and lie in the
> + * [128k:2M] range.
Probably a typo, but I guess this should be [128k:8M] ?
> * @max_chunks: Maximum number of chunks that can be allocated.
> * @target_in_flight: Maximum number of in-flight render passes.
> * @heap_ctx_gpu_va: Pointer holding the GPU address of the allocated heap
> @@ -284,8 +284,8 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
> if (initial_chunk_count > max_chunks)
> return -EINVAL;
>
> - if (hweight32(chunk_size) != 1 ||
> - chunk_size < SZ_256K || chunk_size > SZ_2M)
> + if (!IS_ALIGNED(chunk_size, PAGE_SIZE) ||
> + chunk_size < SZ_128K || chunk_size > SZ_8M)
> return -EINVAL;
>
> down_read(>lock);
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index 5db80a0682d5..b8220d2e698f 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -898,7 +898,11 @@ struct drm_panthor_tiler_heap_create {
> /** @initial_chunk_count: Initial number of chunks to allocate. Must be
> at least one. */
> __u32 initial_chunk_count;
>
> - /** @chunk_size: Chunk size. Must be a power of two at least 256KB
> large. */
> + /**
> + * @chunk_size: Chunk size.
> + *
> + * Must be page-aligned and lie in the [128k:8M] range.
> + */
> __u32 chunk_size;
>
> /**
> --
> 2.44.0
Adrian Larumbe
Re: [PATCH] drm: deprecate driver date
On Mon, Apr 29, 2024 at 08:53:15PM +0300, Jani Nikula wrote: > On Mon, 29 Apr 2024, Hamza Mahfooz wrote: > > On 4/29/24 12:43, Jani Nikula wrote: > >> The driver date serves no useful purpose, because it's hardly ever > >> updated. The information is misleading at best. > >> > >> As described in Documentation/gpu/drm-internals.rst: > >> > >>The driver date, formatted as MMDD, is meant to identify the date > >>of the latest modification to the driver. However, as most drivers > >>fail to update it, its value is mostly useless. The DRM core prints it > >>to the kernel log at initialization time and passes it to userspace > >>through the DRM_IOCTL_VERSION ioctl. > >> > >> Stop printing the driver date at init, and start returning the empty > >> string "" as driver date through the DRM_IOCTL_VERSION ioctl. > >> > >> The driver date initialization in drivers and the struct drm_driver date > >> member can be removed in follow-up. > >> > >> Signed-off-by: Jani Nikula > > > > I would prefer if it was dropped entirely in this patch, but if you feel > > that would require too much back and forth, I'm okay with what is > > currently proposed. > > I can if that's what people prefer, but decided to start with this for > the inevitable discussion before putting in the effort. ;) Might also be a good idea to wait a bit in case there's any regression reports for really old userspace. But I guess there's not a high chance for that to happen here, so imo fine to just go ahead right away. -Sima > > > Reviewed-by: Hamza Mahfooz > > Thanks, > Jani. > > > -- > Jani Nikula, Intel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] [v7] nouveau: add command-line GSP-RM registry support
On Fri, Apr 26, 2024 at 06:08:19PM GMT, Danilo Krummrich wrote: On 4/25/24 18:38, Timur Tabi wrote: On Thu, 2024-04-25 at 15:22 +0200, Danilo Krummrich wrote: + size_t length; + + /* Remove any whitespace from the parameter string */ + length = strip(p, " \t\n"); With that, I see the following warning compiling this patch. warning: variable ‘length’ set but not used [-Wunused-but-set-variable] Did you intend to use the length for anything? No, and I could have sworn I fixed that before sending out v7. I think I originally intended 'length' to determine when I finished parsing the string. Also, looking at the warning made me aware of 'p' potentially being NULL. If you agree, I can fix the warning and add the corresponding NULL check when applying the patch. Yes, that would be great. You can just delete 'length'. The NULL check for 'p' should call clean_registry() before returning -ENOMEM. Applied to drm-misc-next, thanks! since this commit our CI is failing to build with the following error: CC [M] drivers/gpu/drm/i915/display/intel_display_device.o ../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function ‘build_registry’: ../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1266:3: error: label at end of compound statement 1266 | default: | ^~~ CC [M] drivers/gpu/drm/amd/amdgpu/gfx_v10_0.o HDRTEST drivers/gpu/drm/xe/compat-i915-headers/i915_reg.h CC [M] drivers/gpu/drm/amd/amdgpu/imu_v11_0.o make[7]: *** [../scripts/Makefile.build:244: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.o] Error 1 make[7]: *** Waiting for unfinished jobs you are missing a `break;` after that default. Thanks for catching this.
Re: [PATCH] lib/fonts: Allow to select fonts for drm_panic
On Fri, Apr 19, 2024 at 03:20:19PM +0200, Jocelyn Falempe wrote: > drm_panic has been introduced recently, and uses the same fonts as > FRAMEBUFFER_CONSOLE. > > Signed-off-by: Jocelyn Falempe Acked-by: Daniel Vetter lib/fonts/ doesn't seem to have a designated maintainer, so please push this through drm-misc. Thanks, Sima > --- > lib/fonts/Kconfig | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig > index 7e945fdcbf11..befcb463f738 100644 > --- a/lib/fonts/Kconfig > +++ b/lib/fonts/Kconfig > @@ -10,7 +10,7 @@ if FONT_SUPPORT > > config FONTS > bool "Select compiled-in fonts" > - depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE || DRM_PANIC > help > Say Y here if you would like to use fonts other than the default > your frame buffer console usually use. > @@ -23,7 +23,7 @@ config FONTS > > config FONT_8x8 > bool "VGA 8x8 font" if FONTS > - depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE || DRM_PANIC > default y if !SPARC && !FONTS > help > This is the "high resolution" font for the VGA frame buffer (the one > @@ -46,7 +46,7 @@ config FONT_8x16 > > config FONT_6x11 > bool "Mac console 6x11 font (not supported by all drivers)" if FONTS > - depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE || DRM_PANIC > default y if !SPARC && !FONTS && MAC > help > Small console font with Macintosh-style high-half glyphs. Some Mac > @@ -54,7 +54,7 @@ config FONT_6x11 > > config FONT_7x14 > bool "console 7x14 font (not supported by all drivers)" if FONTS > - depends on FRAMEBUFFER_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || DRM_PANIC > help > Console font with characters just a bit smaller than the default. > If the standard 8x16 font is a little too big for you, say Y. > @@ -62,7 +62,7 @@ config FONT_7x14 > > config FONT_PEARL_8x8 > bool "Pearl (old m68k) console 8x8 font" if FONTS > - depends on FRAMEBUFFER_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || DRM_PANIC > default y if !SPARC && !FONTS && AMIGA > help > Small console font with PC-style control-character and high-half > @@ -70,7 +70,7 @@ config FONT_PEARL_8x8 > > config FONT_ACORN_8x8 > bool "Acorn console 8x8 font" if FONTS > - depends on FRAMEBUFFER_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || DRM_PANIC > default y if !SPARC && !FONTS && ARM && ARCH_ACORN > help > Small console font with PC-style control characters and high-half > @@ -90,7 +90,7 @@ config FONT_6x10 > > config FONT_10x18 > bool "console 10x18 font (not supported by all drivers)" if FONTS > - depends on FRAMEBUFFER_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || DRM_PANIC > help > This is a high resolution console font for machines with very > big letters. It fits between the sun 12x22 and the normal 8x16 font. > @@ -105,7 +105,7 @@ config FONT_SUN8x16 > > config FONT_SUN12x22 > bool "Sparc console 12x22 font (not supported by all drivers)" > - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC) > + depends on (FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)) || > DRM_PANIC > help > This is the high resolution console font for Sun machines with very > big letters (like the letters used in the SPARC PROM). If the > @@ -113,7 +113,7 @@ config FONT_SUN12x22 > > config FONT_TER16x32 > bool "Terminus 16x32 font (not supported by all drivers)" > - depends on FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC) > + depends on (FRAMEBUFFER_CONSOLE && (!SPARC && FONTS || SPARC)) || > DRM_PANIC > help > Terminus Font is a clean, fixed width bitmap font, designed > for long (8 and more hours per day) work with computers. > @@ -122,7 +122,7 @@ config FONT_TER16x32 > > config FONT_6x8 > bool "OLED 6x8 font" if FONTS > - depends on FRAMEBUFFER_CONSOLE > + depends on FRAMEBUFFER_CONSOLE || DRM_PANIC > help > This font is useful for small displays (OLED). > > > base-commit: a35e92ef04c07bd473404b9b73d489aea19a60a8 > -- > 2.44.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [bug-report] task info hung problem in fb_deferred_io_work()
On Fri, Apr 19, 2024 at 5:34 PM Nam Cao wrote: > > On 2024-04-19 Patrik Jakobsson wrote: > > Neither cancel_delayed_work_sync() or flush_delayed_work() prevent new > > work from being scheduled after they return. > > flush_delayed_work() is called during device closing. And because no > writes are performed after the device has been closed, no new work > should be queued after flush_delayed_work(). Yes, nothing should write after the device is closed but the events are asynchronous so in theory the order is not guaranteed. I also find it unlikely but I have no other theory at this point. > > > But > > cancel_delayed_work_sync() at least makes sure the queue is empty so > > the problem becomes less apparent. > > > > Could this explain what we're seeing? > > I suspect that cancel_delayed_work_sync() is only treating the symptoms > by preventing the deferred work from running. The real bug is "someone" > giving fb_deferred_io_work() invalid pages to work with. But that's > just a blind guess. Trying to figure out when the page goes away in relation to when the work is triggered might be a good place to start. > > Best regards, > Nam
[PATCH] drm/panthor: Fix the FW reset logic
In the post_reset function, if the fast reset didn't succeed, we
are not clearing the fast_reset flag, which prevents firmware
sections from being reloaded. While at it, use panthor_fw_stop()
instead of manually writing DISABLE to the MCU_CONTROL register.
Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_fw.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
b/drivers/gpu/drm/panthor/panthor_fw.c
index 181395e2859a..fedf9627453f 100644
--- a/drivers/gpu/drm/panthor/panthor_fw.c
+++ b/drivers/gpu/drm/panthor/panthor_fw.c
@@ -1083,10 +1083,11 @@ int panthor_fw_post_reset(struct panthor_device *ptdev)
if (!ret)
goto out;
- /* Force a disable, so we get a fresh boot on the next
-* panthor_fw_start() call.
+ /* Forcibly reset the MCU and force a slow reset, so we get a
+* fresh boot on the next panthor_fw_start() call.
*/
- gpu_write(ptdev, MCU_CONTROL, MCU_CONTROL_DISABLE);
+ panthor_fw_stop(ptdev);
+ ptdev->fw->fast_reset = false;
drm_err(>base, "FW fast reset failed, trying a slow
reset");
}
--
2.44.0
Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs
Il 30/04/24 12:17, Alexandre Mergnat ha scritto:
Hi Angelo,
On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).
Is that make sense for you to add the DTS changes of these boards into this
serie ?
I asked because, IMHO, that could help to understand the serie.
Yes and no... but I imagine that you're asking this because you're trying to
prepare something with a different SoC+board(s) combination :-)
In that case, I'm preventively sorry because what follows here is not 100%
perfectly tidy yet as I didn't mean to send the devicetree commits upstream
before this series got picked
... but there you go - I'm sure that you won't mind and that the example will
be more than good enough for you.
Please note that one of the reasons why I didn't want to add this to the series
is that the following changes show only a mere 50% of the reasons why we want OF
graph support on mediatek-drm (but mainly, it's because I didn't have time to
actually rebase etc :-P )
Cheers!
Angelo
.../boot/dts/mediatek/mt8195-cherry.dtsi | 65 +++-
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 153 +-
.../dts/mediatek/mt8395-radxa-nio-12l.dts | 24 +++
3 files changed, 231 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 86d283ffe807..b05b6bbd457c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -267,12 +267,29 @@ {
status = "okay";
};
+_out {
+ remote-endpoint = <_in>;
+};
+
_intf0 {
status = "okay";
- port {
- dp_intf0_out: endpoint {
- remote-endpoint = <_in>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_intf0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_intf0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
};
};
};
@@ -287,6 +304,27 @@ dp_intf1_out: endpoint {
};
};
+ {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsc0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsc0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
_tx {
status = "okay";
@@ -481,6 +519,27 @@ pmic@34 {
};
};
+ {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ merge0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ merge0_out: endpoint {
+ remote-endpoint = <_intf0_in>;
+ };
+ };
+ };
+};
+
{
domain-supply = <_7_vbuck1>;
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index 88a0035a31a5..982572d7bfd8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -3077,14 +3077,6 @@ vencsys_core1: clock-controller@1b00 {
#clock-cells = <1>;
};
- vdosys0: syscon@1c01a000 {
- compatible = "mediatek,mt8195-vdosys0", "mediatek,mt8195-mmsys",
"syscon";
- reg = <0 0x1c01a000 0 0x1000>;
- mboxes = < 0 CMDQ_THR_PRIO_4>;
- #clock-cells = <1>;
- };
-
-
jpgenc-master {
compatible = "mediatek,mt8195-jpgenc";
power-domains = < MT8195_POWER_DOMAIN_VENC_CORE1>;
@@ -3143,6 +3135,38 @@ ovl0: ovl@1c00 {
clocks = < CLK_VDO0_DISP_OVL0>;
iommus = <_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>;
mediatek,gce-client-reg = < SUBSYS_1c00 0x
0x1000>;
+
+ ports {
+ #address-cells = <1>;
+
[PATCH v2 3/4] drm/panthor: Relax the constraints on the tiler chunk size
The field used to store the chunk size if 12 bits wide, and the encoding
is chunk_size = chunk_header.chunk_size << 12, which gives us a
theoretical [4k:8M] range. This range is further limited by
implementation constraints, and all known implementations seem to
impose a [128k:8M] range, so do the same here.
We also relax the power-of-two constraint, which doesn't seem to
exist on v10. This will allow userspace to fine-tune initial/max
tiler memory on memory-constrained devices.
v2:
- Turn the power-of-two constraint into a page-aligned constraint to allow
fine-tune of the initial/max heap memory size
- Fix the panthor_heap_create() kerneldoc
Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_heap.c | 8
include/uapi/drm/panthor_drm.h | 6 +-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
b/drivers/gpu/drm/panthor/panthor_heap.c
index 3be86ec383d6..683bb94761bc 100644
--- a/drivers/gpu/drm/panthor/panthor_heap.c
+++ b/drivers/gpu/drm/panthor/panthor_heap.c
@@ -253,8 +253,8 @@ int panthor_heap_destroy(struct panthor_heap_pool *pool,
u32 handle)
* @pool: Pool to instantiate the heap context from.
* @initial_chunk_count: Number of chunk allocated at initialization time.
* Must be at least 1.
- * @chunk_size: The size of each chunk. Must be a power of two between 256k
- * and 2M.
+ * @chunk_size: The size of each chunk. Must be page-aligned and lie in the
+ * [128k:2M] range.
* @max_chunks: Maximum number of chunks that can be allocated.
* @target_in_flight: Maximum number of in-flight render passes.
* @heap_ctx_gpu_va: Pointer holding the GPU address of the allocated heap
@@ -284,8 +284,8 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
if (initial_chunk_count > max_chunks)
return -EINVAL;
- if (hweight32(chunk_size) != 1 ||
- chunk_size < SZ_256K || chunk_size > SZ_2M)
+ if (!IS_ALIGNED(chunk_size, PAGE_SIZE) ||
+ chunk_size < SZ_128K || chunk_size > SZ_8M)
return -EINVAL;
down_read(>lock);
diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
index 5db80a0682d5..b8220d2e698f 100644
--- a/include/uapi/drm/panthor_drm.h
+++ b/include/uapi/drm/panthor_drm.h
@@ -898,7 +898,11 @@ struct drm_panthor_tiler_heap_create {
/** @initial_chunk_count: Initial number of chunks to allocate. Must be
at least one. */
__u32 initial_chunk_count;
- /** @chunk_size: Chunk size. Must be a power of two at least 256KB
large. */
+ /**
+* @chunk_size: Chunk size.
+*
+* Must be page-aligned and lie in the [128k:8M] range.
+*/
__u32 chunk_size;
/**
--
2.44.0
[PATCH v2 4/4] drm/panthor: Fix an off-by-one in the heap context retrieval logic
ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
[1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
in the [0:MAX_HEAPS_PER_POOL-1] when we want to access the context object.
v2:
- New patch
Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
Reported-by: Eric Smith
Signed-off-by: Boris Brezillon
Tested-by: Eric Smith
---
drivers/gpu/drm/panthor/panthor_heap.c | 35 +++---
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
b/drivers/gpu/drm/panthor/panthor_heap.c
index 683bb94761bc..b1a7dbf25fb2 100644
--- a/drivers/gpu/drm/panthor/panthor_heap.c
+++ b/drivers/gpu/drm/panthor/panthor_heap.c
@@ -109,7 +109,11 @@ static int panthor_heap_ctx_stride(struct panthor_device
*ptdev)
static int panthor_get_heap_ctx_offset(struct panthor_heap_pool *pool, int id)
{
- return panthor_heap_ctx_stride(pool->ptdev) * id;
+ /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
+* is [1:MAX_HEAPS_PER_POOL], which we need to turn into a
+* [0:MAX_HEAPS_PER_POOL-1] context index, hence the minus one here.
+*/
+ return panthor_heap_ctx_stride(pool->ptdev) * (id - 1);
}
static void *panthor_get_heap_ctx(struct panthor_heap_pool *pool, int id)
@@ -118,6 +122,21 @@ static void *panthor_get_heap_ctx(struct panthor_heap_pool
*pool, int id)
panthor_get_heap_ctx_offset(pool, id);
}
+static int panthor_get_heap_ctx_id(struct panthor_heap_pool *pool,
+ u64 heap_ctx_gpu_va)
+{
+ u64 offset = heap_ctx_gpu_va -
panthor_kernel_bo_gpuva(pool->gpu_contexts);
+ u32 heap_idx = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
+
+ if (offset > U32_MAX || heap_idx >= MAX_HEAPS_PER_POOL)
+ return -EINVAL;
+
+ /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
+* is [1:MAX_HEAPS_PER_POOL], hence the plus one here.
+*/
+ return heap_idx + 1;
+}
+
static void panthor_free_heap_chunk(struct panthor_vm *vm,
struct panthor_heap *heap,
struct panthor_heap_chunk *chunk)
@@ -364,14 +383,13 @@ int panthor_heap_return_chunk(struct panthor_heap_pool
*pool,
u64 heap_gpu_va,
u64 chunk_gpu_va)
{
- u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
- u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
+ int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
struct panthor_heap_chunk *chunk, *tmp, *removed = NULL;
struct panthor_heap *heap;
int ret;
- if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
- return -EINVAL;
+ if (heap_id < 0)
+ return heap_id;
down_read(>lock);
heap = xa_load(>xa, heap_id);
@@ -427,14 +445,13 @@ int panthor_heap_grow(struct panthor_heap_pool *pool,
u32 pending_frag_count,
u64 *new_chunk_gpu_va)
{
- u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
- u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
+ int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
struct panthor_heap_chunk *chunk;
struct panthor_heap *heap;
int ret;
- if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
- return -EINVAL;
+ if (heap_id < 0)
+ return heap_id;
down_read(>lock);
heap = xa_load(>xa, heap_id);
--
2.44.0
[PATCH v2 2/4] drm/panthor: Make sure the tiler initial/max chunks are consistent
It doesn't make sense to have a maximum number of chunks smaller than
the initial number of chunks attached to the context.
Fix the uAPI header to reflect the new constraint, and mention the
undocumented "initial_chunk_count > 0" constraint while at it.
v2:
- Fix the check
Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_heap.c | 3 +++
include/uapi/drm/panthor_drm.h | 8 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
b/drivers/gpu/drm/panthor/panthor_heap.c
index c3c0ba744937..3be86ec383d6 100644
--- a/drivers/gpu/drm/panthor/panthor_heap.c
+++ b/drivers/gpu/drm/panthor/panthor_heap.c
@@ -281,6 +281,9 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
if (initial_chunk_count == 0)
return -EINVAL;
+ if (initial_chunk_count > max_chunks)
+ return -EINVAL;
+
if (hweight32(chunk_size) != 1 ||
chunk_size < SZ_256K || chunk_size > SZ_2M)
return -EINVAL;
diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
index dadb05ab1235..5db80a0682d5 100644
--- a/include/uapi/drm/panthor_drm.h
+++ b/include/uapi/drm/panthor_drm.h
@@ -895,13 +895,17 @@ struct drm_panthor_tiler_heap_create {
/** @vm_id: VM ID the tiler heap should be mapped to */
__u32 vm_id;
- /** @initial_chunk_count: Initial number of chunks to allocate. */
+ /** @initial_chunk_count: Initial number of chunks to allocate. Must be
at least one. */
__u32 initial_chunk_count;
/** @chunk_size: Chunk size. Must be a power of two at least 256KB
large. */
__u32 chunk_size;
- /** @max_chunks: Maximum number of chunks that can be allocated. */
+ /**
+* @max_chunks: Maximum number of chunks that can be allocated.
+*
+* Must be at least @initial_chunk_count.
+*/
__u32 max_chunks;
/**
--
2.44.0
[PATCH v2 1/4] drm/panthor: Fix tiler OOM handling to allow incremental rendering
From: Antonino Maniscalco
If the kernel couldn't allocate memory because we reached the maximum
number of chunks but no render passes are in flight
(panthor_heap_grow() returning -ENOMEM), we should defer the OOM
handling to the FW by returning a NULL chunk. The FW will then call
the tiler OOM exception handler, which is supposed to implement
incremental rendering (execute an intermediate fragment job to flush
the pending primitives, release the tiler memory that was used to
store those primitives, and start over from where it stopped).
Instead of checking for both ENOMEM and EBUSY, make panthor_heap_grow()
return ENOMEM no matter the reason of this allocation failure, the FW
doesn't care anyway.
v2:
- Make panthor_heap_grow() return -ENOMEM for all kind of allocation
failures
- Document the panthor_heap_grow() semantics
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Signed-off-by: Antonino Maniscalco
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_heap.c | 12
drivers/gpu/drm/panthor/panthor_sched.c | 7 ++-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
b/drivers/gpu/drm/panthor/panthor_heap.c
index 143fa35f2e74..c3c0ba744937 100644
--- a/drivers/gpu/drm/panthor/panthor_heap.c
+++ b/drivers/gpu/drm/panthor/panthor_heap.c
@@ -410,6 +410,13 @@ int panthor_heap_return_chunk(struct panthor_heap_pool
*pool,
* @renderpasses_in_flight: Number of render passes currently in-flight.
* @pending_frag_count: Number of fragment jobs waiting for
execution/completion.
* @new_chunk_gpu_va: Pointer used to return the chunk VA.
+ *
+ * Return:
+ * - 0 if a new heap was allocated
+ * - -ENOMEM if the tiler context reached the maximum number of chunks
+ * or if too many render passes are in-flight
+ * or if the allocation failed
+ * - -EINVAL if any of the arguments passed to panthor_heap_grow() is invalid
*/
int panthor_heap_grow(struct panthor_heap_pool *pool,
u64 heap_gpu_va,
@@ -439,10 +446,7 @@ int panthor_heap_grow(struct panthor_heap_pool *pool,
* handler provided by the userspace driver, if any).
*/
if (renderpasses_in_flight > heap->target_in_flight ||
- (pending_frag_count > 0 && heap->chunk_count >= heap->max_chunks)) {
- ret = -EBUSY;
- goto out_unlock;
- } else if (heap->chunk_count >= heap->max_chunks) {
+ heap->chunk_count >= heap->max_chunks) {
ret = -ENOMEM;
goto out_unlock;
}
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
b/drivers/gpu/drm/panthor/panthor_sched.c
index b3a51a6de523..fd928362d45e 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -1354,7 +1354,12 @@ static int group_process_tiler_oom(struct panthor_group
*group, u32 cs_id)
pending_frag_count, _chunk_va);
}
- if (ret && ret != -EBUSY) {
+ /* If the heap context doesn't have memory for us, we want to let the
+* FW try to reclaim memory by waiting for fragment jobs to land or by
+* executing the tiler OOM exception handler, which is supposed to
+* implement incremental rendering.
+*/
+ if (ret && ret != -ENOMEM) {
drm_warn(>base, "Failed to extend the tiler heap\n");
group->fatal_queues |= BIT(cs_id);
sched_queue_delayed_work(sched, tick, 0);
--
2.44.0
[PATCH v2 0/4] drm/panthor: Collection of tiler heap related fixes
This is a collection of tiler heap fixes for bugs/oddities found while looking at incremental rendering. Ideally, we want to land those before 6.10 is released, so we don't need to increment the driver version to reflect the ABI changes. Regards, Boris Antonino Maniscalco (1): drm/panthor: Fix tiler OOM handling to allow incremental rendering Boris Brezillon (3): drm/panthor: Make sure the tiler initial/max chunks are consistent drm/panthor: Relax the constraints on the tiler chunk size drm/panthor: Fix an off-by-one in the heap context retrieval logic drivers/gpu/drm/panthor/panthor_heap.c | 58 + drivers/gpu/drm/panthor/panthor_sched.c | 7 ++- include/uapi/drm/panthor_drm.h | 14 -- 3 files changed, 58 insertions(+), 21 deletions(-) -- 2.44.0
[PATCH 5.15 47/80] drm/vmwgfx: Fix crtcs atomic check conditional
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
[ Upstream commit a60ccade88f926e871a57176e86a34bbf0db0098 ]
The conditional was supposed to prevent enabling of a crtc state
without a set primary plane. Accidently it also prevented disabling
crtc state with a set primary plane. Neither is correct.
Fix the conditional and just driver-warn when a crtc state has been
enabled without a primary plane which will help debug broken userspace.
Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.
Signed-off-by: Zack Rusin
Fixes: 06ec41909e31 ("drm/vmwgfx: Add and connect CRTC helper functions")
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.12+
Reviewed-by: Ian Forbes
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-5-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 01d5a01af2594..e2a52b5de1733 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -537,6 +537,7 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane
*plane,
int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
+ struct vmw_private *vmw = vmw_priv(crtc->dev);
struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state,
crtc);
struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
@@ -544,9 +545,13 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
bool has_primary = new_state->plane_mask &
drm_plane_mask(crtc->primary);
- /* We always want to have an active plane with an active CRTC */
- if (has_primary != new_state->enable)
- return -EINVAL;
+ /*
+* This is fine in general, but broken userspace might expect
+* some actual rendering so give a clue as why it's blank.
+*/
+ if (new_state->enable && !has_primary)
+ drm_dbg_driver(>drm,
+ "CRTC without a primary plane will be blank.\n");
if (new_state->connector_mask != connector_mask &&
--
2.43.0
Re: [PATCH 10/10] arm64: dts: qcom: Add AYN Odin 2
On 24.04.2024 5:29 PM, Xilin Wu via B4 Relay wrote:
> From: Xilin Wu
>
> AYN Odin 2 is a gaming handheld based on QCS8550, which is derived
> from SM8550 but without modem RF system.
>
> This commit brings support for:
> * Remoteprocs
> * UFS storage
> * SD Card
> * Type-C with USB3 10Gbps and DisplayPort (4-lane requires a pending
> patch)
> * PCIe0 (Wi-Fi requires the pending pwrseq series)
> * Bluetooth
> * Regulators
> * Integrated fan with automatic speed control based on CPU temperature
> * Power and volume keys
> * M1, M2 buttons
> * HDMI output up to 1080p 60hz
> * four groups of RGB lights
> * GPU
> * Internal DSI display with touchscreen
>
> Signed-off-by: Xilin Wu
> ---
[...]
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 86>;
> + brightness-levels = <1023 0>;
Huh? Is min/max swapped?
> + num-interpolated-steps = <1023>;
> + default-brightness-level = <600>;
> + power-supply = <_pwr>;
> + enable-gpios = <_gpios 5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_backlight_default>;
property-n
property-names
[...]
> + cooling-maps {
> + map0 {
> + trip = <_active0>;
> + cooling-device = < 0 1>;
> + };
Please adda a newline between each subnode
[...]
> + /* Setting regulator-allow-set-load here will crash the device
> */
??
> + vreg_l17b_2p5: ldo17 {
> + regulator-name = "vreg_l17b_2p5";
> + regulator-min-microvolt = <2504000>;
> + regulator-max-microvolt = <2504000>;
> + regulator-initial-mode = ;
> + };
> + };
> +
[...]
> +
> + backlight = <>;
> + /* touchscreen and display panel share the same reset gpio! */
> + reset-gpios = < 133 GPIO_ACTIVE_LOW>;
Perhaps you would be interested in drm_panel_follower
[...]
> +
> +_2 {
> + cd-gpios = <_gpios 12 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_default _card_det_n>;
> + pinctrl-1 = <_sleep _card_det_n>;
> + vmmc-supply = <_l9b_2p9>;
> + vqmmc-supply = <_l8b_1p8>;
> + bus-width = <4>;
> + no-sdio;
> + no-mmc;
> +
> + /* SDR104 does seem to be working on this device*/
> + /delete-property/ sdhci-caps-mask;
Eeeh.. I'm not sure about this. Maybe it still has some issues that
don't manifest immediately.
[...]
> + {
> + status = "okay";
> +
> +/* Gamepad controlled by onboard MCU */
As in, that MCU is connected to 8550 through this UART port?
Konrad
Re: [PATCH v1 2/3] drm/panel: ili9341: Respect deferred probe
On Thu, Apr 25, 2024 at 05:26:18PM +0300, Andy Shevchenko wrote:
> GPIO controller might not be available when driver is being probed.
> There are plenty of reasons why, one of which is deferred probe.
>
> Since GPIOs are optional, return any error code we got to the upper
> layer, including deferred probe. With that in mind, use dev_err_probe()
> in order to avoid spamming the logs.
>
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v1 1/3] drm/panel: ili9341: Correct use of device property APIs
On Thu, Apr 25, 2024 at 05:26:17PM +0300, Andy Shevchenko wrote:
> It seems driver missed the point of proper use of device property APIs.
> Correct this by updating headers and calls respectively.
>
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/panel/Kconfig| 2 +-
> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 5 +++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v2 0/3] drm/mediatek: Add support for OF graphs
Hi Angelo, On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote: This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa NIO-12L with both hardcoded paths, OF graph support and partially hardcoded paths (meaning main display through OF graph and external display hardcoded, because of OVL_ADAPTOR). Is that make sense for you to add the DTS changes of these boards into this serie ? I asked because, IMHO, that could help to understand the serie. -- Regards, Alexandre
Re: [PATCH v1 2/5] drm/ci: generate testlist from build
On Tue, Apr 30, 2024 at 02:41:18PM +0530, Vignesh Raman wrote:
> Stop vendoring the testlist into the kernel. Instead, use the
> testlist from the IGT build to ensure we do not miss renamed
> or newly added tests.
>
> Signed-off-by: Vignesh Raman
> ---
> drivers/gpu/drm/ci/build-igt.sh | 23 +
> drivers/gpu/drm/ci/igt_runner.sh |9 +-
> drivers/gpu/drm/ci/testlist.txt | 2761 --
> 3 files changed, 28 insertions(+), 2765 deletions(-)
> delete mode 100644 drivers/gpu/drm/ci/testlist.txt
>
> diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
> index 500fa4f5c30a..cedc62baba1e 100644
> --- a/drivers/gpu/drm/ci/build-igt.sh
> +++ b/drivers/gpu/drm/ci/build-igt.sh
> @@ -26,6 +26,29 @@ meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
> ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
> ninja -C build install
>
> +set +ex
> +export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/igt/lib64
> +while read -r line; do
> +if [ "$line" = "TESTLIST" ] || [ "$line" = "END TESTLIST" ]; then
> +continue
> +fi
> +
> +tests=$(echo "$line" | tr ' ' '\n')
> +
> +for test in $tests; do
> +output=$(/igt/libexec/igt-gpu-tools/"$test" --list-subtests)
> +
> +if [ -z "$output" ]; then
> +echo "$test"
> +else
> +echo "$output" | while read -r subtest; do
> +echo "$test@$subtest"
> +done
> +fi
> +done
> +done < /igt/libexec/igt-gpu-tools/test-list.txt >
> /igt/libexec/igt-gpu-tools/testlist.txt
> +set -ex
Is the list in sync between x86 and arm/arm64 IGT builds? Is there a
chance of having a safety net here?
> +
> mkdir -p artifacts/
> tar -cf artifacts/igt.tar /igt
>
> diff --git a/drivers/gpu/drm/ci/igt_runner.sh
> b/drivers/gpu/drm/ci/igt_runner.sh
> index f1a08b9b146f..20026612a9bd 100755
> --- a/drivers/gpu/drm/ci/igt_runner.sh
> +++ b/drivers/gpu/drm/ci/igt_runner.sh
> @@ -59,25 +59,26 @@ fi
>
> curl -L --retry 4 -f --retry-all-errors --retry-delay 60 -s
> ${FDO_HTTP_CACHE_URI:-}$PIPELINE_ARTIFACTS_BASE/$ARCH/igt.tar.gz | tar --zstd
> -v -x -C /
>
> +TESTLIST="/igt/libexec/igt-gpu-tools/testlist.txt"
>
> # If the job is parallel at the gitab job level, take the corresponding
> fraction
> # of the caselist.
> if [ -n "$CI_NODE_INDEX" ]; then
> -sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" /install/testlist.txt
> +sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" $TESTLIST
> fi
>
> # core_getversion checks if the driver is loaded and probed correctly
> # so run it in all shards
> -if ! grep -q "core_getversion" /install/testlist.txt; then
> +if ! grep -q "core_getversion" $TESTLIST; then
> # Add the line to the file
> -echo "core_getversion" >> /install/testlist.txt
> +echo "core_getversion" >> $TESTLIST
> fi
>
> set +e
> igt-runner \
> run \
> --igt-folder /igt/libexec/igt-gpu-tools \
> ---caselist /install/testlist.txt \
> +--caselist $TESTLIST \
> --output /results \
> $IGT_SKIPS \
> $IGT_FLAKES \
--
With best wishes
Dmitry
Re: [PATCH v1 5/5] drm/ci: update xfails for the new testlist
On Tue, Apr 30, 2024 at 02:41:21PM +0530, Vignesh Raman wrote: > Now the testlist is used from IGT build, so update > xfails with the new testlist. > > Signed-off-by: Vignesh Raman > --- > .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++ > .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 8 +- > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 15 > drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 22 - > .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 8 ++ > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 8 ++ > drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 45 +- > drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 5 ++ > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 12 +++ > drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 26 +- > drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 6 ++ > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 8 ++ > drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 28 +-- > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 12 +++ > drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 39 - > drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 10 ++- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 21 + > drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 75 + > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 13 +++ > drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 46 +-- > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 8 ++ > .../drm/ci/xfails/mediatek-mt8173-fails.txt | 47 +++ > .../drm/ci/xfails/mediatek-mt8183-fails.txt | 17 +--- > .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 20 + > .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 26 ++ > .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 5 +- > .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 67 +++ > .../msm-sc7180-trogdor-kingoftown-fails.txt | 34 > .../msm-sc7180-trogdor-kingoftown-flakes.txt | 5 ++ > ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 34 > ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 75 - > .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 26 ++ > .../drm/ci/xfails/rockchip-rk3288-fails.txt | 54 > .../drm/ci/xfails/rockchip-rk3399-fails.txt | 80 ++ > .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 7 -- > .../drm/ci/xfails/virtio_gpu-none-fails.txt | 82 +-- > .../drm/ci/xfails/virtio_gpu-none-skips.txt | 3 + > 42 files changed, 574 insertions(+), 495 deletions(-) > create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt > delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-fails.txt > delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt > [skipped] > diff --git a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > index 44a5c62dedad..96e9faf0e607 100644 > --- a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > +++ b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > @@ -1,19 +1,9 @@ > +core_setmaster_vs_auth,Fail > +device_reset,Fail > +dumb_buffer,Fail This doesn't look correct, core tests should be passing. > kms_3d,Fail > -kms_addfb_basic@addfb25-bad-modifier,Fail > -kms_cursor_legacy@all-pipes-forked-bo,Fail > -kms_cursor_legacy@all-pipes-forked-move,Fail > -kms_cursor_legacy@all-pipes-single-bo,Fail > -kms_cursor_legacy@all-pipes-single-move,Fail > -kms_cursor_legacy@all-pipes-torture-bo,Fail > -kms_cursor_legacy@all-pipes-torture-move,Fail > -kms_cursor_legacy@pipe-A-forked-bo,Fail > -kms_cursor_legacy@pipe-A-forked-move,Fail > -kms_cursor_legacy@pipe-A-single-bo,Fail > -kms_cursor_legacy@pipe-A-single-move,Fail > -kms_cursor_legacy@pipe-A-torture-bo,Fail > -kms_cursor_legacy@pipe-A-torture-move,Fail > -kms_force_connector_basic@force-edid,Fail > -kms_hdmi_inject@inject-4k,Fail > -kms_selftest@drm_format,Timeout > -kms_selftest@drm_format_helper,Timeout Fine, kms_cursor_legacy tests were migrated to -flakes. But what happened with the rest of the failures? > -msm_mapping@ring,Fail >
Re: [PATCH v1 4/5] drm/ci: skip driver specific tests
On Tue, Apr 30, 2024 at 02:41:20PM +0530, Vignesh Raman wrote: > Skip driver specific tests and skip kms tests for > panfrost driver since it is not a kms driver. > > Signed-off-by: Vignesh Raman > --- > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +- > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 14 +- > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt| 12 > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt| 14 +- > .../gpu/drm/ci/xfails/mediatek-mt8173-skips.txt | 12 > .../gpu/drm/ci/xfails/mediatek-mt8183-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/msm-apq8096-skips.txt | 14 +- Reviewed-by: Dmitry Baryshkov # msm skips > .../msm-sc7180-trogdor-kingoftown-skips.txt | 15 +++ > .../msm-sc7180-trogdor-lazor-limozeen-skips.txt | 15 +++ > drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt | 15 +++ > .../gpu/drm/ci/xfails/rockchip-rk3288-skips.txt | 17 - > .../gpu/drm/ci/xfails/rockchip-rk3399-skips.txt | 15 +++ > .../gpu/drm/ci/xfails/virtio_gpu-none-skips.txt | 15 ++- > 19 files changed, 260 insertions(+), 10 deletions(-) > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt > create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt > -- With best wishes Dmitry
Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs
On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote: > On 2024/4/29 19:55, Maxime Ripard wrote: > > On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote: > > > On 2024/4/26 14:23, Maxime Ripard wrote: > > > > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote: > > > > > On 2024/4/26 03:10, Andy Shevchenko wrote: > > > > > > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote: > > > > > > > On 2024/4/25 22:26, Andy Shevchenko wrote: > > > > > > > > It seems driver missed the point of proper use of device > > > > > > > > property APIs. > > > > > > > > Correct this by updating headers and calls respectively. > > > > > > > You are using the 'seems' here exactly saying that you are not > > > > > > > 100% sure. > > > > > > > > > > > > > > Please allow me to tell you the truth: This patch again has ZERO > > > > > > > effect. > > > > > > > It fix nothing. And this patch is has the risks to be wrong. > > > > > > Huh?! Really, stop commenting the stuff you do not understand. > > > > > I'm actually a professional display drivers developer at the > > > > > downstream > > > > > in the past, despite my contribution to upstream is less. But I > > > > > believe > > > > > that all panel driver developers know what I'm talking about. So > > > > > please > > > > > have take a look at my replies. > > > > Most of the interactions you had in this series has been uncalled for. > > > > You might be against a patch, but there's no need to go to such length. > > > > > > > > As far as I'm concerned, this patch is fine to me in itself, and I don't > > > > see anything that would prevent us from merging it. > > > No one is preventing you, as long as don't misunderstanding what other > > > people's technical replies intentionally. I'm just a usual and normal > > > contributor, I hope the world will better than yesterday. > > You should seriously consider your tone when replying then. > > > > > Saying such thing to me may not proper, I guess you may want to talk > > > to peoples who has the push rights > > I think you misunderstood me. My point was that your several rants were > > uncalled for and aren't the kind of things we're doing here. > > > > I know very well how to get a patch merged, thanks. > > > > > just make sure it isn't a insult to the professionalism of drm bridge > > > community itself though. > > I'm not sure why you're bringing the bridge community or its > > professionalism. It's a panel, not a bridge, and I never doubted the > > professionalism of anyone. > > > I means that the code itself could be adopted, as newer and younger > programmer (like Andy) need to be encouraged to contribute. Andy has thousands of commits in Linux. He's *very* far from being a new contributor. > I express no obvious objections, just hints him that something else > probably should also be taken into consideration as well. That might be what you wanted to express, but you definitely didn't express it that way. > On the other hand, we probably should allow other people participate > in discussion so that it is sufficient discussed and ensure that it > won't be reverted by someone in the future for some reasons. Backing > to out case happens here, we may need to move things forward. Therefore, > it definitely deserve to have a try. It is not a big deal even though > it gets reverted someday. > > In the end, I don't mind if you think there is nothing that could > prevent you from merge it, but I still suggest you have a glance at > peoples siting at the Cc list. I'm busy now and I have a lot of other > tasks to do, and may not be able to reply you emails on time. So it up > to you and other maintainers to decide. > Thank you. So far, you're the only one who reviewed those patches. I'm not sure what you're talking about here. Maxime signature.asc Description: PGP signature
Re: [PATCH] drm: drm_of.c: Using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
Hi, On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote: > Linux kernel puts strict limits on which functions and data structures > are available to loadable kernel modules; only those that have been > explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are > accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare > a GPL-compatible license will be able to see the symbol. > > Since the whole drm_of.c file is declared with GPL-2.0-only license, so > let us keep functions in that source file consistently. You're conflating two things: the license of the code itself (GPL2 here), and the license of the users of the symbols exported in that file (anything). There's no relationship between the two, and you have to make an argument for changing the latter other than just because the license is GPL because, again, those are two different things. Maxime signature.asc Description: PGP signature
[PATCH v1 5/5] drm/ci: update xfails for the new testlist
Now the testlist is used from IGT build, so update xfails with the new testlist. Signed-off-by: Vignesh Raman --- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++ .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 8 +- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 15 drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 22 - .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 8 ++ drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 8 ++ drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 45 +- drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 5 ++ drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 12 +++ drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 6 ++ drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 8 ++ drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 28 +-- drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 12 +++ drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 39 - drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 10 ++- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 21 + drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 75 + drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 13 +++ drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 46 +-- drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 8 ++ .../drm/ci/xfails/mediatek-mt8173-fails.txt | 47 +++ .../drm/ci/xfails/mediatek-mt8183-fails.txt | 17 +--- .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 20 + .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 26 ++ .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 5 +- .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 67 +++ .../msm-sc7180-trogdor-kingoftown-fails.txt | 34 .../msm-sc7180-trogdor-kingoftown-flakes.txt | 5 ++ ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 34 ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 5 ++ .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 75 - .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 26 ++ .../drm/ci/xfails/rockchip-rk3288-fails.txt | 54 .../drm/ci/xfails/rockchip-rk3399-fails.txt | 80 ++ .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 7 -- .../drm/ci/xfails/virtio_gpu-none-fails.txt | 82 +-- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 3 + 42 files changed, 574 insertions(+), 495 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-fails.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index ea87dc46bc2b..a48df7880ec5 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,27 +1,46 @@ -kms_addfb_basic@bad-pitch-65536,Fail +amdgpu/amd_assr@assr-links,Fail +amdgpu/amd_assr@assr-links-dpms,Fail +amdgpu/amd_deadlock@amdgpu-deadlock-compute,Timeout +amdgpu/amd_ilr@ilr-policy,Fail +amdgpu/amd_mall@static-screen,Crash +amdgpu/amd_mode_switch@mode-switch-first-last-pipe-2,Crash +amdgpu/amd_pci_unplug@amdgpu_hotunplug_simple,Fail +amdgpu/amd_pci_unplug@amdgpu_hotunplug_with_cs,Fail +amdgpu/amd_pci_unplug@amdgpu_hotunplug_with_exported_bo,Fail +amdgpu/amd_plane@mpo-pan-nv12,Fail +amdgpu/amd_plane@mpo-pan-p010,Fail +amdgpu/amd_plane@mpo-pan-rgb,Crash +amdgpu/amd_plane@mpo-scale-nv12,Fail +amdgpu/amd_plane@mpo-scale-p010,Fail +amdgpu/amd_plane@mpo-scale-rgb,Crash +amdgpu/amd_plane@mpo-swizzle-toggle,Fail +amdgpu/amd_uvd_dec@amdgpu_uvd_decode,Fail +amdgpu/amd_vce_dec@amdgpu_cs_vce_destroy,Fail +amdgpu/amd_vce_dec@amdgpu_cs_vce_encode,Fail +amdgpu/amd_vm@amdgpu-vm-unaligned-map,Fail +amdgpu/amd_vrr_range@freesync-parsing,Timeout +device_reset@unbind-cold-reset-rebind,Fail +dumb_buffer@invalid-bpp,Fail kms_addfb_basic@bo-too-small,Fail kms_addfb_basic@too-high,Fail kms_async_flips@async-flip-with-page-flip-events,Fail -kms_async_flips@crc,Fail -kms_async_flips@invalid-async-flip,Fail
[PATCH v1 4/5] drm/ci: skip driver specific tests
Skip driver specific tests and skip kms tests for panfrost driver since it is not a kms driver. Signed-off-by: Vignesh Raman --- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +- drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 14 +- drivers/gpu/drm/ci/xfails/i915-apl-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-cml-skips.txt| 12 drivers/gpu/drm/ci/xfails/i915-glk-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt| 14 +- drivers/gpu/drm/ci/xfails/i915-whl-skips.txt| 14 +- .../gpu/drm/ci/xfails/mediatek-mt8173-skips.txt | 12 .../gpu/drm/ci/xfails/mediatek-mt8183-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt | 14 ++ drivers/gpu/drm/ci/xfails/msm-apq8096-skips.txt | 14 +- .../msm-sc7180-trogdor-kingoftown-skips.txt | 15 +++ .../msm-sc7180-trogdor-lazor-limozeen-skips.txt | 15 +++ drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt | 15 +++ .../gpu/drm/ci/xfails/rockchip-rk3288-skips.txt | 17 - .../gpu/drm/ci/xfails/rockchip-rk3399-skips.txt | 15 +++ .../gpu/drm/ci/xfails/virtio_gpu-none-skips.txt | 15 ++- 19 files changed, 260 insertions(+), 10 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt index e2c538a0f954..70e2f925d06f 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt @@ -1,2 +1,14 @@ # Suspend to RAM seems to be broken on this machine -.*suspend.* \ No newline at end of file +.*suspend.* + +# Skip driver specific tests +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# Skip intel specific tests +gem_.* +i915_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt b/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt index fe55540a3f9a..59f8acfaa5ba 100644 --- a/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-amly-skips.txt @@ -1,4 +1,16 @@ # Suspend to RAM seems to be broken on this machine .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No newline at end of file +kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt b/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt index 3430b215c06e..d97bc038b63a 100644 --- a/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-apl-skips.txt @@ -3,4 +3,16 @@ # This is generating kernel oops with divide error kms_plane_scaling@invalid-parameters # This is cascading issues -kms_3d \ No newline at end of file +kms_3d + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt b/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt index 6d3d7ddc377f..92c0ffee8283 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-skips.txt @@ -1,2 +1,14 @@ # This is generating kernel oops with divide error kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt b/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt index 4c7d00ce14bc..a168722caf13 100644 --- a/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-glk-skips.txt @@ -2,4 +2,16 @@ .*suspend.* # This is generating kernel oops with divide error -kms_plane_scaling@invalid-parameters \ No newline at end of file +kms_plane_scaling@invalid-parameters + +# Skip driver specific tests +^amdgpu.* +msm_.* +nouveau_.* +panfrost_.* +^v3d.* +^vc4.* +^vmwgfx* + +# GEM tests takes ~1000 hours, so skip it +gem_.* diff --git a/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt b/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt index 4c7d00ce14bc..a168722caf13 100644 --- a/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt +++ b/drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt @@ -2,4 +2,16 @@ .*suspend.* # This is generating kernel oops with divide error
[PATCH v1 3/5] drm/ci: build virtual GPU driver as module
With latest IGT, the tests tries to load the module and it
fails. So build the virtual GPU driver for virtio as module.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/build.sh | 1 -
drivers/gpu/drm/ci/igt_runner.sh | 6 +++---
drivers/gpu/drm/ci/image-tags.yml | 4 ++--
drivers/gpu/drm/ci/test.yml | 1 +
drivers/gpu/drm/ci/x86_64.config | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 8a3baa003904..95493df9cdc2 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -156,7 +156,6 @@ fi
mkdir -p artifacts/install/lib
mv install/* artifacts/install/.
-rm -rf artifacts/install/modules
ln -s common artifacts/install/ci-common
cp .config artifacts/${CI_JOB_NAME}_config
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index 20026612a9bd..55532f79fbdc 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -30,10 +30,10 @@ case "$DRIVER_NAME" in
export IGT_FORCE_DRIVER="panfrost"
fi
;;
-amdgpu)
+amdgpu|virtio_gpu)
# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the
module in /lib
-mv /install/modules/lib/modules/* /lib/modules/.
-modprobe amdgpu
+mv /install/modules/lib/modules/* /lib/modules/. || true
+modprobe --first-time $DRIVER_NAME
;;
esac
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index d8f72b82c938..fd1cb6061166 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,9 +4,9 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "2023-10-08-config"
+ DEBIAN_BUILD_TAG: "2024-04-22-virtio"
- KERNEL_ROOTFS_TAG: "2023-10-06-amd"
+ KERNEL_ROOTFS_TAG: "2024-04-22-virtio"
PKG_REPO_REV: "3cc12a2a"
DEBIAN_X86_64_TEST_BASE_IMAGE: "debian/x86_64_test-base"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 612c9ede3507..864ac3809d84 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -350,6 +350,7 @@ virtio_gpu:none:
script:
- ln -sf $CI_PROJECT_DIR/install /install
- mv install/bzImage /lava-files/bzImage
+- mkdir -p /lib/modules
- mkdir -p $CI_PROJECT_DIR/results
- ln -sf $CI_PROJECT_DIR/results /results
- install/crosvm-runner.sh install/igt_runner.sh
diff --git a/drivers/gpu/drm/ci/x86_64.config b/drivers/gpu/drm/ci/x86_64.config
index 1cbd49a5b23a..78479f063e8e 100644
--- a/drivers/gpu/drm/ci/x86_64.config
+++ b/drivers/gpu/drm/ci/x86_64.config
@@ -91,7 +91,7 @@ CONFIG_KVM=y
CONFIG_KVM_GUEST=y
CONFIG_VIRT_DRIVERS=y
CONFIG_VIRTIO_FS=y
-CONFIG_DRM_VIRTIO_GPU=y
+CONFIG_DRM_VIRTIO_GPU=m
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
--
2.40.1
[PATCH v1 2/5] drm/ci: generate testlist from build
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/build-igt.sh | 23 +
drivers/gpu/drm/ci/igt_runner.sh |9 +-
drivers/gpu/drm/ci/testlist.txt | 2761 --
3 files changed, 28 insertions(+), 2765 deletions(-)
delete mode 100644 drivers/gpu/drm/ci/testlist.txt
diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
index 500fa4f5c30a..cedc62baba1e 100644
--- a/drivers/gpu/drm/ci/build-igt.sh
+++ b/drivers/gpu/drm/ci/build-igt.sh
@@ -26,6 +26,29 @@ meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
ninja -C build install
+set +ex
+export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/igt/lib64
+while read -r line; do
+if [ "$line" = "TESTLIST" ] || [ "$line" = "END TESTLIST" ]; then
+continue
+fi
+
+tests=$(echo "$line" | tr ' ' '\n')
+
+for test in $tests; do
+output=$(/igt/libexec/igt-gpu-tools/"$test" --list-subtests)
+
+if [ -z "$output" ]; then
+echo "$test"
+else
+echo "$output" | while read -r subtest; do
+echo "$test@$subtest"
+done
+fi
+done
+done < /igt/libexec/igt-gpu-tools/test-list.txt >
/igt/libexec/igt-gpu-tools/testlist.txt
+set -ex
+
mkdir -p artifacts/
tar -cf artifacts/igt.tar /igt
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index f1a08b9b146f..20026612a9bd 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -59,25 +59,26 @@ fi
curl -L --retry 4 -f --retry-all-errors --retry-delay 60 -s
${FDO_HTTP_CACHE_URI:-}$PIPELINE_ARTIFACTS_BASE/$ARCH/igt.tar.gz | tar --zstd
-v -x -C /
+TESTLIST="/igt/libexec/igt-gpu-tools/testlist.txt"
# If the job is parallel at the gitab job level, take the corresponding
fraction
# of the caselist.
if [ -n "$CI_NODE_INDEX" ]; then
-sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" /install/testlist.txt
+sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" $TESTLIST
fi
# core_getversion checks if the driver is loaded and probed correctly
# so run it in all shards
-if ! grep -q "core_getversion" /install/testlist.txt; then
+if ! grep -q "core_getversion" $TESTLIST; then
# Add the line to the file
-echo "core_getversion" >> /install/testlist.txt
+echo "core_getversion" >> $TESTLIST
fi
set +e
igt-runner \
run \
--igt-folder /igt/libexec/igt-gpu-tools \
---caselist /install/testlist.txt \
+--caselist $TESTLIST \
--output /results \
$IGT_SKIPS \
$IGT_FLAKES \
diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt
deleted file mode 100644
index 3377f002f8c5..
--- a/drivers/gpu/drm/ci/testlist.txt
+++ /dev/null
@@ -1,2761 +0,0 @@
-core_auth@getclient-simple
-core_auth@getclient-master-drop
-core_auth@basic-auth
-core_auth@many-magics
-core_getclient
-core_getstats
-core_getversion
-core_setmaster_vs_auth
-drm_read@invalid-buffer
-drm_read@fault-buffer
-drm_read@empty-block
-drm_read@empty-nonblock
-drm_read@short-buffer-block
-drm_read@short-buffer-nonblock
-drm_read@short-buffer-wakeup
-gem_eio@throttle
-gem_eio@create
-gem_eio@create-ext
-gem_eio@context-create
-gem_eio@execbuf
-gem_eio@banned
-gem_eio@suspend
-gem_eio@hibernate
-gem_eio@in-flight-external
-gem_eio@in-flight-suspend
-gem_eio@reset-stress
-gem_eio@unwedge-stress
-gem_eio@wait-immediate
-gem_eio@wait-wedge-immediate
-gem_eio@in-flight-immediate
-gem_eio@in-flight-contexts-immediate
-gem_eio@in-flight-internal-immediate
-gem_eio@wait-1us
-gem_eio@wait-wedge-1us
-gem_eio@in-flight-1us
-gem_eio@in-flight-contexts-1us
-gem_eio@in-flight-internal-1us
-gem_eio@wait-10ms
-gem_eio@wait-wedge-10ms
-gem_eio@in-flight-10ms
-gem_eio@in-flight-contexts-10ms
-gem_eio@in-flight-internal-10ms
-gem_eio@kms
-kms_3d
-kms_addfb_basic@unused-handle
-kms_addfb_basic@unused-pitches
-kms_addfb_basic@unused-offsets
-kms_addfb_basic@unused-modifier
-kms_addfb_basic@clobberred-modifier
-kms_addfb_basic@invalid-smem-bo-on-discrete
-kms_addfb_basic@legacy-format
-kms_addfb_basic@no-handle
-kms_addfb_basic@basic
-kms_addfb_basic@bad-pitch-0
-kms_addfb_basic@bad-pitch-32
-kms_addfb_basic@bad-pitch-63
-kms_addfb_basic@bad-pitch-128
-kms_addfb_basic@bad-pitch-256
-kms_addfb_basic@bad-pitch-1024
-kms_addfb_basic@bad-pitch-999
-kms_addfb_basic@bad-pitch-65536
-kms_addfb_basic@invalid-get-prop-any
-kms_addfb_basic@invalid-get-prop
-kms_addfb_basic@invalid-set-prop-any
-kms_addfb_basic@invalid-set-prop
-kms_addfb_basic@master-rmfb
-kms_addfb_basic@addfb25-modifier-no-flag
-kms_addfb_basic@addfb25-bad-modifier
-kms_addfb_basic@addfb25-x-tiled-mismatch-legacy
-kms_addfb_basic@addfb25-x-tiled-legacy
-kms_addfb_basic@addfb25-framebuffer-vs-set-tiling
-kms_addfb_basic@basic-x-tiled-legacy
[PATCH v1 1/5] drm/ci: uprev mesa version
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa to latest version which includes a fix for this issue.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/908f444e
Also copy helper scripts to install, so that the ci jobs can
use these scripts for logging.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/build.sh | 1 +
drivers/gpu/drm/ci/container.yml | 12
drivers/gpu/drm/ci/gitlab-ci.yml | 11 ---
drivers/gpu/drm/ci/image-tags.yml | 3 ++-
drivers/gpu/drm/ci/test.yml | 2 ++
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 106f2d40d222..8a3baa003904 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -128,6 +128,7 @@ fi
# Pass needed files to the test stage
mkdir -p install
cp -rfv .gitlab-ci/* install/.
+cp -rfv ci/* install/.
cp -rfv install/common install/ci-common
cp -rfv drivers/gpu/drm/ci/* install/.
diff --git a/drivers/gpu/drm/ci/container.yml b/drivers/gpu/drm/ci/container.yml
index 9764e7921a4f..d6edf3635b23 100644
--- a/drivers/gpu/drm/ci/container.yml
+++ b/drivers/gpu/drm/ci/container.yml
@@ -36,15 +36,15 @@ debian/android_build:
rules:
- when: never
-debian/x86_64_test-android:
+.debian/x86_64_test-android:
rules:
- when: never
-windows_build_vs2019:
+windows_build_msvc:
rules:
- when: never
-windows_test_vs2019:
+windows_test_msvc:
rules:
- when: never
@@ -56,10 +56,6 @@ rustfmt:
rules:
- when: never
-windows_vs2019:
- rules:
-- when: never
-
-clang-format:
+windows_msvc:
rules:
- when: never
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 084e3ff8e3f4..9bf5190604a7 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
variables:
DRM_CI_PROJECT_PATH: mesa/mesa
- DRM_CI_COMMIT_SHA:
9d162de9a05155e1c4041857a5848842749164cf
+ DRM_CI_COMMIT_SHA:
e5f133ccc426a197c48a4e88f5377f943f078180
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -26,10 +26,13 @@ variables:
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
# default kernel for rootfs before injecting the current kernel tree
KERNEL_REPO: "gfx-ci/linux"
- KERNEL_TAG: "v6.6.4-for-mesa-ci-e4f4c500f7fb"
+ KERNEL_TAG: "v6.6.21-mesa-19fc"
KERNEL_IMAGE_BASE: https://${S3_HOST}/mesa-lava/${KERNEL_REPO}/${KERNEL_TAG}
LAVA_TAGS: subset-1-gfx
LAVA_JOB_PRIORITY: 30
+ ARTIFACTS_BASE_URL:
https://${CI_PROJECT_ROOT_NAMESPACE}.${CI_PAGES_DOMAIN}/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts
+ # Python scripts for structured logger
+ PYTHONPATH: "$PYTHONPATH:$CI_PROJECT_DIR/install"
default:
before_script:
@@ -46,6 +49,7 @@ default:
- cd $CI_PROJECT_DIR
- curl --output -
$DRM_CI_PROJECT_URL/-/archive/$DRM_CI_COMMIT_SHA/mesa-$DRM_CI_COMMIT_SHA.tar.gz
| tar -xz
- mv mesa-$DRM_CI_COMMIT_SHA/.gitlab-ci* .
+- mv mesa-$DRM_CI_COMMIT_SHA/bin/ci .
- rm -rf mesa-$DRM_CI_COMMIT_SHA/
- echo -e "\e[0Ksection_end:$(date +%s):drm_ci_download_section\r\e[0K"
@@ -98,6 +102,7 @@ include:
stages:
- sanity
- container
+ - code-validation
- git-archive
- build
- amdgpu
@@ -107,7 +112,6 @@ stages:
- msm
- rockchip
- virtio-gpu
- - lint
# YAML anchors for rule conditions
#
@@ -218,6 +222,7 @@ make git archive:
script:
# Remove drm-ci files we just added
- rm -rf .gitlab-ci.*
+- rm -rf ci
# Compactify the .git directory
- git gc --aggressive
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index 7ab4f2514da8..d8f72b82c938 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -1,5 +1,5 @@
variables:
- CONTAINER_TAG: "2023-10-11-mesa-uprev"
+ CONTAINER_TAG: "2024-04-22-mesa-uprev"
DEBIAN_X86_64_BUILD_BASE_IMAGE: "debian/x86_64_build-base"
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
@@ -7,6 +7,7 @@ variables:
DEBIAN_BUILD_TAG: "2023-10-08-config"
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
+ PKG_REPO_REV: "3cc12a2a"
DEBIAN_X86_64_TEST_BASE_IMAGE: "debian/x86_64_test-base"
DEBIAN_X86_64_TEST_IMAGE_GL_PATH: "debian/x86_64_test-gl"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 8bc63912fddb..612c9ede3507 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -150,6 +150,8 @@ msm:sdm845:
BM_KERNEL: https://${PIPELINE_ARTIFACTS_BASE}/arm64/cheza-kernel
GPU_VERSION: sdm845
RUNNER_TAG: google-freedreno-cheza
+DEVICE_TYPE: sdm845-cheza-r3
+FARM: google
script:
-
[PATCH v1 0/5] drm/ci: uprev mesa and generate testlist
Uprev mesa to the latest version and stop vendoring the testlist into the kernel. Instead, use the testlist from the IGT build to ensure we do not miss renamed or newly added tests. Update the xfails with the latest testlist run. Also build virtual GPU driver for virtio as module. The flakes list needs to be reported upsteam. Will send it after this series is reviewed. https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1166575 Vignesh Raman (5): drm/ci: uprev mesa version drm/ci: generate testlist from build drm/ci: build virtual GPU driver as module drm/ci: skip driver specific tests drm/ci: update xfails for the new testlist drivers/gpu/drm/ci/build-igt.sh | 23 + drivers/gpu/drm/ci/build.sh |2 +- drivers/gpu/drm/ci/container.yml | 12 +- drivers/gpu/drm/ci/gitlab-ci.yml | 11 +- drivers/gpu/drm/ci/igt_runner.sh | 15 +- drivers/gpu/drm/ci/image-tags.yml |7 +- drivers/gpu/drm/ci/test.yml |3 + drivers/gpu/drm/ci/testlist.txt | 2761 - drivers/gpu/drm/ci/x86_64.config |2 +- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +- .../drm/ci/xfails/amdgpu-stoney-flakes.txt|8 +- .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 29 +- drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 22 +- .../gpu/drm/ci/xfails/i915-amly-flakes.txt|8 + drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 22 +- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 45 +- drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt |5 + drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt |6 + drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 20 + drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 28 +- drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 26 +- drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 39 +- drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 10 +- drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 35 +- drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 75 +- drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 27 +- drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 46 +- drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 22 +- .../drm/ci/xfails/mediatek-mt8173-fails.txt | 47 +- .../drm/ci/xfails/mediatek-mt8173-skips.txt | 12 + .../drm/ci/xfails/mediatek-mt8183-fails.txt | 17 +- .../drm/ci/xfails/mediatek-mt8183-flakes.txt |5 + .../drm/ci/xfails/mediatek-mt8183-skips.txt | 14 + .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 20 +- .../gpu/drm/ci/xfails/meson-g12b-flakes.txt |5 + .../gpu/drm/ci/xfails/meson-g12b-skips.txt| 14 + .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 26 +- .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt |5 + .../gpu/drm/ci/xfails/msm-apq8016-skips.txt | 14 + .../gpu/drm/ci/xfails/msm-apq8096-fails.txt |5 +- .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt |5 + .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 81 +- .../msm-sc7180-trogdor-kingoftown-fails.txt | 34 +- .../msm-sc7180-trogdor-kingoftown-flakes.txt |5 + .../msm-sc7180-trogdor-kingoftown-skips.txt | 15 + ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 34 +- ...m-sc7180-trogdor-lazor-limozeen-flakes.txt |5 + ...sm-sc7180-trogdor-lazor-limozeen-skips.txt | 15 + .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 75 +- .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 26 +- .../gpu/drm/ci/xfails/msm-sdm845-skips.txt| 15 + .../drm/ci/xfails/rockchip-rk3288-fails.txt | 54 - .../drm/ci/xfails/rockchip-rk3288-skips.txt | 17 +- .../drm/ci/xfails/rockchip-rk3399-fails.txt | 80 +- .../drm/ci/xfails/rockchip-rk3399-flakes.txt |7 - .../drm/ci/xfails/rockchip-rk3399-skips.txt | 15 + .../drm/ci/xfails/virtio_gpu-none-fails.txt | 82 +- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 18 +- 60 files changed, 886 insertions(+), 3289 deletions(-) delete mode 100644 drivers/gpu/drm/ci/testlist.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt create mode 100644
Re: [PATCH] drm: deprecate driver date
On Tue, 30 Apr 2024, Simon Ser wrote:
> On Monday, April 29th, 2024 at 18:43, Jani Nikula
> wrote:
>
>> The driver date serves no useful purpose, because it's hardly ever
>> updated. The information is misleading at best.
>>
>> As described in Documentation/gpu/drm-internals.rst:
>>
>> The driver date, formatted as MMDD, is meant to identify the date
>> of the latest modification to the driver. However, as most drivers
>> fail to update it, its value is mostly useless. The DRM core prints it
>> to the kernel log at initialization time and passes it to userspace
>> through the DRM_IOCTL_VERSION ioctl.
>>
>> Stop printing the driver date at init, and start returning the empty
>> string "" as driver date through the DRM_IOCTL_VERSION ioctl.
>
> Sounds good to me.
>
> Acked-by: Simon Ser
Thanks!
> BTW, I wonder if the driver version number (major/minor/patch) is useful?
> Do drivers update it?
I think most things these days should depend on capabilities rather than
versions.
i915 is at 1.6.0 and the last change was commit 2228ed67223f ("drm: i915
updates"). 18 years ago. From that perspective, I'd be happy to drop
them too.
However, amdgpu is at 3.57.0, with an elaborate changelog in
amdgpu_drv.c, and the last change was commit 91963397c49a ("drm/amdgpu:
Enable tunneling on high-priority compute queues"). Less than six months
ago.
I wonder if we could stop initializing and printing the version for
drivers that don't care, and leave it for drivers that do? Obviously
feels more risky than the date.
BR,
Jani.
--
Jani Nikula, Intel
Re: [PATCH] drm: deprecate driver date
Jani Nikula writes: > The driver date serves no useful purpose, because it's hardly ever > updated. The information is misleading at best. > > As described in Documentation/gpu/drm-internals.rst: > > The driver date, formatted as MMDD, is meant to identify the date > of the latest modification to the driver. However, as most drivers > fail to update it, its value is mostly useless. The DRM core prints it > to the kernel log at initialization time and passes it to userspace > through the DRM_IOCTL_VERSION ioctl. > > Stop printing the driver date at init, and start returning the empty > string "" as driver date through the DRM_IOCTL_VERSION ioctl. > > The driver date initialization in drivers and the struct drm_driver date > member can be removed in follow-up. > > Signed-off-by: Jani Nikula > > --- I never understood the value of it and so this patch makes sense to me. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!
On Tue, Aug 29, 2023 at 05:30:52AM +, Brandon Pollack wrote: > Since Jim is busy with other work and I'm working on some things that > rely on this, I've taken up the task of doing the iterations. I've > addressed the comments as best I can (those replies are to each > individual change) and here is the patch set to go with those. > > I added my own signoff to each commit, but I've left jshargo@ as the > author of all the commits he wrote. I'm sure there is still more to > address and the ICT tests that were writtein parallel to this may also > need some additions, but I'm hoping we're in a good enough state to get > this in and iterate from there soon. > > Since V6: > > rmdirs for documentation examples > fix crtc mask for writebacks > > Since V5: > > Fixed some bad merge conflicts and locking behaviours as well as > clarified some documentation, should be good to go now :) > > Since V4: > > Fixed up some documentation as suggested by Marius > Fixed up some bad locking as suggested by Marius > Small fixes here and there (most have email responses to previous chain > emails) > > Since V3: > > I've added hotplug support in the latest patch. This has been reviewed some > and the notes from that review are addressed here as well. > > Relevant/Utilizing work: > === > I've built a while test framework based on this as proof it functions (though > I'm sure there may be lingering bugs!). You can check that out on > crrev.com if you are interested and need to get started yourself (but be > aware of any licensing that may differ from the kernel itself! Make > sure you understand the license: > > https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/tast-tests/LICENSE > > That said, you can see the changes in review on the crrev gerrit: > > https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/469 > > Outro: > = > I really appreciate everyone's input and tolerance in getting these > changes in. Jim's first patch series was this, and other than some > small cleanups and documentation, taking over it is also mine. Sorry for not having looked at this earlier. I think overall it's looking good, mostly just a bunch of comments on lifetime/locking questions. I'm also wondering a bit how much we want to go overboard with igt tests, since the lifetime fun is quite big here. I think at least some basic tests that trying to do nasty things like unbind the driver in sysfs and then try to use configfs, or keeping the vkms_device alive with an open fd and removing the configfs directory would be really good. One thing that's a bit tricky is that configfs is considered uapi, so must be stable forever. And I think that's actually the right thing for us, since we want compositors and other projects to use this for their testing. So unlike igt tests using special debugfs interfaces, which are ok to be very tightly coupled to kernel releases Cheers, Sima > > Thank you everyone :) > > Brandon Pollack (1): > drm/vkms Add hotplug support via configfs to VKMS. > > Jim Shargo (6): > drm/vkms: Back VKMS with DRM memory management instead of static > objects > drm/vkms: Support multiple DRM objects (crtcs, etc.) per VKMS device > drm/vkms: Provide platform data when creating VKMS devices > drm/vkms: Add ConfigFS scaffolding to VKMS > drm/vkms: Support enabling ConfigFS devices > drm/vkms: Add a module param to enable/disable the default device > > Documentation/gpu/vkms.rst| 20 +- > drivers/gpu/drm/Kconfig | 1 + > drivers/gpu/drm/vkms/Makefile | 1 + > drivers/gpu/drm/vkms/vkms_composer.c | 30 +- > drivers/gpu/drm/vkms/vkms_configfs.c | 723 ++ > drivers/gpu/drm/vkms/vkms_crtc.c | 102 ++-- > drivers/gpu/drm/vkms/vkms_drv.c | 206 +--- > drivers/gpu/drm/vkms/vkms_drv.h | 182 +-- > drivers/gpu/drm/vkms/vkms_output.c| 404 -- > drivers/gpu/drm/vkms/vkms_plane.c | 44 +- > drivers/gpu/drm/vkms/vkms_writeback.c | 42 +- > 11 files changed, 1514 insertions(+), 241 deletions(-) > create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c > > -- > 2.42.0.rc2.253.gd59a3bf2b4-goog > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
