Re: [PATCH v4 3/7] accel/ivpu: Add GEM buffer object management
Hi,
On 18.12.2022 11:23, Oded Gabbay wrote:
> On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
> wrote:
>> Adds four types of GEM-based BOs for the VPU:
>> - shmem
>> - userptr
>> - internal
>> - prime
>>
>> All types are implemented as struct ivpu_bo, based on
>> struct drm_gem_object. VPU address is allocated when buffer is created
>> except for imported prime buffers that allocate it in BO_INFO IOCTL due
>> to missing file_priv arg in gem_prime_import callback.
>> Internal buffers are pinned on creation, the rest of buffers types
>> can be pinned on demand (in SUBMIT IOCTL).
>> Buffer VPU address, allocated pages and mappings are relased when the
>> buffer is destroyed.
>> Eviction mechism is planned for future versions.
>>
>> Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR
>>
>> Signed-off-by: Jacek Lawrynowicz
>> ---
>> drivers/accel/ivpu/Makefile | 1 +
>> drivers/accel/ivpu/ivpu_drv.c | 31 +-
>> drivers/accel/ivpu/ivpu_drv.h | 1 +
>> drivers/accel/ivpu/ivpu_gem.c | 820 ++
>> drivers/accel/ivpu/ivpu_gem.h | 128 ++
>> include/uapi/drm/ivpu_drm.h | 127 ++
>> 6 files changed, 1106 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/accel/ivpu/ivpu_gem.c
>> create mode 100644 drivers/accel/ivpu/ivpu_gem.h
>>
>> diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
>> index 37b8bf1d3247..1b4b24ebf5ea 100644
>> --- a/drivers/accel/ivpu/Makefile
>> +++ b/drivers/accel/ivpu/Makefile
>> @@ -3,6 +3,7 @@
>>
>> intel_vpu-y := \
>> ivpu_drv.o \
>> + ivpu_gem.o \
>> ivpu_hw_mtl.o \
>> ivpu_mmu.o \
>> ivpu_mmu_context.o
>> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
>> index a22d41ca5a4b..29e78c5ec7c5 100644
>> --- a/drivers/accel/ivpu/ivpu_drv.c
>> +++ b/drivers/accel/ivpu/ivpu_drv.c
>> @@ -12,8 +12,10 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "ivpu_drv.h"
>> +#include "ivpu_gem.h"
>> #include "ivpu_hw.h"
>> #include "ivpu_mmu.h"
>> #include "ivpu_mmu_context.h"
>> @@ -49,6 +51,24 @@ struct ivpu_file_priv *ivpu_file_priv_get(struct
>> ivpu_file_priv *file_priv)
>> return file_priv;
>> }
>>
>> +struct ivpu_file_priv *ivpu_file_priv_get_by_ctx_id(struct ivpu_device
>> *vdev, unsigned long id)
>> +{
>> + struct ivpu_file_priv *file_priv;
>> +
>> + xa_lock_irq(&vdev->context_xa);
>> + file_priv = xa_load(&vdev->context_xa, id);
>> + /* file_priv may still be in context_xa during file_priv_release() */
>> + if (file_priv && !kref_get_unless_zero(&file_priv->ref))
>> + file_priv = NULL;
>> + xa_unlock_irq(&vdev->context_xa);
>> +
>> + if (file_priv)
>> + ivpu_dbg(vdev, KREF, "file_priv get by id: ctx %u refcount
>> %u\n",
>> +file_priv->ctx.id, kref_read(&file_priv->ref));
>> +
>> + return file_priv;
>> +}
>> +
>> static void file_priv_release(struct kref *ref)
>> {
>> struct ivpu_file_priv *file_priv = container_of(ref, struct
>> ivpu_file_priv, ref);
>> @@ -57,7 +77,7 @@ static void file_priv_release(struct kref *ref)
>> ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n",
>> file_priv->ctx.id);
>>
>> ivpu_mmu_user_context_fini(vdev, &file_priv->ctx);
>> - WARN_ON(xa_erase_irq(&vdev->context_xa, file_priv->ctx.id) !=
>> file_priv);
>> + drm_WARN_ON(&vdev->drm, xa_erase_irq(&vdev->context_xa,
>> file_priv->ctx.id) != file_priv);
>> kfree(file_priv);
>> }
>>
>> @@ -66,7 +86,7 @@ void ivpu_file_priv_put(struct ivpu_file_priv **link)
>> struct ivpu_file_priv *file_priv = *link;
>> struct ivpu_device *vdev = file_priv->vdev;
>>
>> - WARN_ON(!file_priv);
>> + drm_WARN_ON(&vdev->drm, !file_priv);
>>
>> ivpu_dbg(vdev, KREF, "file_priv put: ctx %u refcount %u\n",
>> file_priv->ctx.id, kref_read(&file_priv->ref));
>> @@ -200,6 +220,9 @@ static void ivpu_postclose(struct drm_device *dev,
>> struct drm_file *file)
>> static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(IVPU_GET_PARAM, ivpu_get_param_ioctl, 0),
>> DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl, 0),
>> + DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl, 0),
>> + DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, 0),
>> + DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl, 0),
>> };
>>
>> int ivpu_shutdown(struct ivpu_device *vdev)
>> @@ -233,6 +256,10 @@ static const struct drm_driver driver = {
>>
>> .open = ivpu_open,
>> .postclose = ivpu_postclose,
>> + .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> + .gem_prime_import = ivpu_gem_prime_import,
>> + .gem_prime_mmap = drm_gem_prime_mmap,
>>
>> .ioctls = ivpu_drm_ioctls,
>> .num_ioctls = ARRAY_SIZE(ivpu_drm
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
Hi Zhi, Thanks again for your reply and clear explaination about the function. I still have some doubt about the fix. Here is a invoke chain : ppgtt_populate_spt ->ppgtt_populate_shadow_entry ->split_2MB_gtt_entry As far as I'm concerned, when something error happens in DMA mapping, which will make intel_gvt_dma_map_guest_page return none-zero code, It will invoke ppgtt_invalidate_spt and call ppgtt_free_spt,which will finally free spt by kfree. But the caller doesn't notice that and frees spt by calling ppgtt_free_spt again. This is a typical UAF/Double Free vulnerability. So I think the key point is about how to handle spt properly. The handle newly allocated spt (aka sub_spt) is not the root cause of this issue. Could you please give me more advice about how to fix this security bug? Besides, I'm not sure if there are more similar problems in othe location. Best regards, Zheng Wang -- 2.25.1
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
On 12/19/2022 9:57 AM, Zheng Wang wrote: > Hi Zhi, > > Thanks again for your reply and clear explaination about the function. > I still have some doubt about the fix. Here is a invoke chain : > ppgtt_populate_spt >->ppgtt_populate_shadow_entry > ->split_2MB_gtt_entry > As far as I'm concerned, when something error happens in DMA mapping, > which will make intel_gvt_dma_map_guest_page return none-zero code, > It will invoke ppgtt_invalidate_spt and call ppgtt_free_spt,which will > finally free spt by kfree. But the caller doesn't notice that and frees > spt by calling ppgtt_free_spt again. This is a typical UAF/Double Free > vulnerability. So I think the key point is about how to handle spt properly. > The handle newly allocated spt (aka sub_spt) is not the root cause of this > issue. Could you please give me more advice about how to fix this security > bug? Besides, I'm not sure if there are more similar problems in othe > location. > > Best regards, > Zheng Wang > I think it is a case-by-case thing. For example: The current scenario in this function looks like below: caller pass spt a function alloc spt b something error free spt a return error The problem is: the function wrongly frees the spt a instead free what it allocates. A proper fix should be: caller pass spt a function alloc spt b something error *free spt b* return error Thanks, Zhi.
Re: DRM scheduler & amdgpu splats followed by GPU hang
Hi Michel, yeah that's a known issue. I'm already working on that, looks like I've just forgotten to add a dma_fence_get() somewhere. Going to send around a bug fix later today. Thanks for the report, Christian. Am 17.12.22 um 13:12 schrieb Michel Dänzer: With the drm-next-2022-12-13 changes for 6.2 merged on top of a 6.1.0 kernel, I hit a GPU (Picasso APU) hang in the menu of Trackmania (free-to-play Windows game, running via Wine). After rebooting, I noticed the attached splats in the journal. I can't be sure that the GPU hang was directly related to these, but it seems plausible. Do these ring any bells?
Re: [PATCH v6] drm: Optimise for continuous memory allocation
Am 18.12.22 um 07:57 schrieb xinhui pan:
Optimise a little when continuous memory request fails.
There are memory holes and continuous memory request usually fails when
order is too big.
Currently buddy only look for exactly order memory for such request.
Now we can try again to look for several smaller continuous memory on
failure.
I'm still pretty sure that this is illegal.
See the order is not only the minimum we need for linear allocation, but
also the minimum alignment we need.
So if you look at some block combination like 010 when searching for an
order 2 allocation you satisfy the contiguous constrain, but not the
alignment constrain and that's illegal.
Additional to that we have a huge additional CPU overhead for contiguous
allocations with that.
Regards,
Christian.
Signed-off-by: xinhui pan
---
change from v5:
reworked
---
drivers/gpu/drm/drm_buddy.c | 161 ++--
1 file changed, 154 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 11bb59399471..6c795e1b3247 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -386,6 +386,140 @@ alloc_range_bias(struct drm_buddy *mm,
return ERR_PTR(err);
}
+static void __continuous_block_in_tree(struct drm_buddy_block *top_block,
+ struct list_head *fbl,
+ int left,
+ int min_order)
+{
+ /*
+* Look for continuous memory of
+* [top_block) when left is true or (top_block] when left is false.
+* The list of fbl looks like (top_block1][free_block][...][top_blockX).
+* Memory offset is in ascending order.
+*/
+ while (top_block) {
+ struct drm_buddy_block *block = top_block;
+ int order;
+
+ while (drm_buddy_block_is_split(block))
+ block = left ? block->left : block->right;
+
+ order = drm_buddy_block_order(block);
+ if (order < min_order || !drm_buddy_block_is_free(block))
+ return;
+
+ if (left)
+ list_add_tail(&block->tmp_link, fbl);
+ else
+ list_add(&block->tmp_link, fbl);
+
+ if (order == min_order)
+ return;
+ top_block = __get_buddy(block);
+ }
+}
+
+static bool __free_block_in_order(struct list_head *fbl,
+ struct drm_buddy_block *cur,
+ int order,
+ struct drm_buddy_block **first,
+ struct drm_buddy_block **last)
+{
+ struct drm_buddy_block *fb = cur, *lb = list_next_entry(cur, tmp_link);
+ u64 pages = BIT(order);
+ u64 cur_pages = 0;
+
+ /*
+* Look for continuous memory which satisfy requested order.
+* Memory in list fbl are already in below order.
+* 1) Memory offset are in ascending order.
+* 2) Memory size are in ascending order from left to middle and
+* descending order from middle to right.
+* So walk through the list of fbl from middle to both sides to
+* choose the bigger memory.
+* This is because one memory with order X are composed with 2 of order
X-1
+* or 1 of order X-1 and 2 of order X-2, etc. Looks like below.
+* n
+*{∑(X - y)} + {2 * (X-n-1))}
+* 1
+* And the last 2 memory of order (X-n-1) are at the two sides of list.
+*/
+ list_for_each_entry_from_reverse(fb, fbl, tmp_link) {
+ int prev_order = drm_buddy_block_order(fb);
+
+ list_for_each_entry_from(lb, fbl, tmp_link) {
+ int next_order = drm_buddy_block_order(lb);
+
+ if (prev_order <= next_order)
+ cur_pages += BIT(next_order);
+ else
+ break;
+ }
+
+ cur_pages += BIT(prev_order);
+ if (pages == cur_pages) {
+ *first = fb;
+ *last = list_prev_entry(lb, tmp_link);
+ return true;
+ }
+ BUG_ON(pages < cur_pages);
+ }
+
+ *first = *last = NULL;
+ return false;
+}
+
+static struct drm_buddy_block *
+find_continuous_blocks(struct drm_buddy *mm,
+ int order,
+ unsigned long flags,
+ struct drm_buddy_block **lb)
+{
+ struct list_head *head = &mm->free_list[order - 1];
+ struct drm_buddy_block *free_block, *first = NULL, *last = NULL;
+
+ /*
+* Look for continuous free memory in buddy and buddy-in-law.
+* IOW, the most left blocks at right of free block and the most right
+
[PATCH v3] drm: Only select I2C_ALGOBIT for drivers that actually need it
While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even though only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by: Uwe Kleine-König --- drivers/gpu/drm/Kconfig | 1 - drivers/gpu/drm/amd/amdgpu/Kconfig | 2 ++ drivers/gpu/drm/ast/Kconfig | 2 ++ drivers/gpu/drm/gma500/Kconfig | 2 ++ drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 ++ drivers/gpu/drm/i915/Kconfig| 2 ++ drivers/gpu/drm/mgag200/Kconfig | 2 ++ drivers/gpu/drm/nouveau/Kconfig | 2 ++ drivers/gpu/drm/radeon/Kconfig | 2 ++ 9 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 315cbdf61979..93c732a8f870 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -12,7 +12,6 @@ menuconfig DRM select HDMI select FB_CMDLINE select I2C - select I2C_ALGOBIT select DMA_SHARED_BUFFER select SYNC_FILE # gallium uses SYS_kcmp for os_same_file_description() to de-duplicate diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 5fcd510f1abb..5341b6b242c3 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -13,6 +13,8 @@ config DRM_AMDGPU select DRM_TTM_HELPER select POWER_SUPPLY select HWMON + select I2C + select I2C_ALGOBIT select BACKLIGHT_CLASS_DEVICE select INTERVAL_TREE select DRM_BUDDY diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig index d367a90cd3de..563fa7a3b546 100644 --- a/drivers/gpu/drm/ast/Kconfig +++ b/drivers/gpu/drm/ast/Kconfig @@ -4,6 +4,8 @@ config DRM_AST depends on DRM && PCI && MMU select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT help Say yes for experimental AST GPU driver. Do not enable this driver without having a working -modesetting, diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 807b989e3c77..2efc0eb41c64 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -3,6 +3,8 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig index 4e41c144a290..126504318a4f 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig @@ -7,6 +7,8 @@ config DRM_HISI_HIBMC select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Choose this option if you have a Hisilicon Hibmc soc chipset. If M is selected the module will be called hibmc-drm. diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 3efce05d7b57..c6e3792622f2 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -18,6 +18,8 @@ config DRM_I915 select DRM_PANEL select DRM_MIPI_DSI select RELAY + select I2C + select I2C_ALGOBIT select IRQ_WORK # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig index eec59658a938..b28c5e4828f4 100644 --- a/drivers/gpu/drm/mgag200/Kconfig +++ b/drivers/gpu/drm/mgag200/Kconfig @@ -4,6 +4,8 @@ config DRM_MGAG200 depends on DRM && PCI && MMU select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT help This is a KMS driver for Matrox G200 chips. It supports the original MGA G200 desktop chips and the server variants. It requires 0.3.0 diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 03d12caf9e26..a0bb3987bf63 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -10,6 +10,8 @@ config DRM_NOUVEAU select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT select X86_PLATFORM_DEVICES if ACPI && X86 select ACPI_WMI if ACPI && X86 diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 97a277f9a25e..62a596d3a891 100644 ---
[PATCH] drm/vc4: dsi: Drop unused i2c include
The driver doesn't make use of any symbol provided by . So drop the include. Signed-off-by: Uwe Kleine-König --- drivers/gpu/drm/vc4/vc4_dsi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c index 878e05d79e81..08e95c1d4a04 100644 --- a/drivers/gpu/drm/vc4/vc4_dsi.c +++ b/drivers/gpu/drm/vc4/vc4_dsi.c @@ -24,7 +24,6 @@ #include #include #include -#include #include #include #include -- 2.38.1
Re: [PATCH v3] drm: Only select I2C_ALGOBIT for drivers that actually need it
Hello Uwe, On 12/19/22 09:36, Uwe Kleine-König wrote: > While working on a drm driver that doesn't need the i2c algobit stuff I > noticed that DRM selects this code even though only 8 drivers actually use > it. While also only some drivers use i2c, keep the select for I2C for the > next cleanup patch. Still prepare this already by also selecting I2C for > the individual drivers. > > Signed-off-by: Uwe Kleine-König > --- Thanks for sending a v3 of this. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH] drm/vc4: dsi: Drop unused i2c include
On 12/19/22 09:40, Uwe Kleine-König wrote: > The driver doesn't make use of any symbol provided by . So > drop the include. > > Signed-off-by: Uwe Kleine-König > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH] MAINTAINERS: drm/hisilicon: Drop Chen Feng
The listed address doesn't work any more: puck.c...@hisilicon.com host mx5.hisilicon.com [124.71.93.234] SMTP error from remote mail server after RCPT TO:: 551 5.1.1 : Recipient address rejected: Failed recipient validation check.: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 recipient verify from ldap failed (in reply to RCPT TO command) Signed-off-by: Uwe Kleine-König --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 30e032abd196..d693d77e715f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7009,7 +7009,6 @@ M:Xinliang Liu M: Tian Tao R: John Stultz R: Xinwei Kong -R: Chen Feng L: dri-devel@lists.freedesktop.org S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -- 2.38.1
Re: [PATCH] MAINTAINERS: drm/hisilicon: Drop Chen Feng
On 12/19/22 09:53, Uwe Kleine-König wrote: > The listed address doesn't work any more: > > puck.c...@hisilicon.com > host mx5.hisilicon.com [124.71.93.234] > SMTP error from remote mail server after RCPT > TO:: > 551 5.1.1 : Recipient address rejected: > Failed recipient validation check.: host 127.0.0.1[127.0.0.1] said: > 554 5.7.1 recipient verify from ldap failed (in reply to RCPT TO command) > > Signed-off-by: Uwe Kleine-König > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 5/9] drm/format-helper: Add conversion from XRGB8888 to 15-bit RGB555 formats
Hi Thomas,
Thanks for CCing me.
There are some issues with this helpers on big endian architectures, you can
run the test on big endian with this command:
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \
--arch=powerpc --cross_compile=powerpc64-linux-gnu- drm_format_helper_test
The problem is in the drm_fb_xrgb_to_*_line() functions, see the fixes
inlined:
On Tue, Dec 13, 2022 at 09:12:29PM +0100, Thomas Zimmermann wrote:
> Add conversion from XRGB to XRGB1555, ARGB1555 and RGBA5551, which
> are the formats currently supported by the simplefb infrastructure. The
> new helpers allow the output of XRGB framebuffers to firmware
> scanout buffers in one of the 15-bit formats.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 164 +++
> .../gpu/drm/tests/drm_format_helper_test.c| 186 ++
> include/drm/drm_format_helper.h | 9 +
> 3 files changed, 359 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index e562a3cefb89..aa6138756458 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -395,6 +395,161 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst,
> const unsigned int *dst_pi
> }
> EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
>
> +static void drm_fb_xrgb_to_xrgb1555_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +{
> + u16 *dbuf16 = dbuf;
> + const __le32 *sbuf32 = sbuf;
> + unsigned int x;
> + u16 val16;
> + u32 pix;
> +
> + for (x = 0; x < pixels; x++) {
> + pix = le32_to_cpu(sbuf32[x]);
> + val16 = ((pix & 0x00f8) >> 9) |
> + ((pix & 0xf800) >> 6) |
> + ((pix & 0x00f8) >> 3);
> + dbuf16[x] = cpu_to_le16(val16);
You don't need the extra cpu_to_le16() here:
- dbuf16[x] = cpu_to_le16(val16);
+ dbuf16[x] = val16;
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_xrgb1555 - Convert XRGB to XRGB1555 clip buffer
> + * @dst: Array of XRGB1555 destination buffers
> + * @dst_pitch: Array of numbers of bytes between the start of two
> consecutive scanlines
> + * within @dst; can be NULL if scanlines are stored next to each
> other.
> + * @src: Array of XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory and converts
> + * the color format during the process. The parameters @dst, @dst_pitch and
> + * @src refer to arrays. Each array must have at least as many entries as
> + * there are planes in @fb's format. Each entry stores the value for the
> + * format's respective color plane at the same index.
> + *
> + * This function does not apply clipping on @dst (i.e. the destination is at
> the
> + * top-left corner).
> + *
> + * Drivers can use this function for XRGB1555 devices that don't support
> + * XRGB natively.
> + */
> +void drm_fb_xrgb_to_xrgb1555(struct iosys_map *dst, const unsigned int
> *dst_pitch,
> + const struct iosys_map *src, const struct
> drm_framebuffer *fb,
> + const struct drm_rect *clip)
> +{
> + static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
> + 2,
> + };
> +
> + drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
> + drm_fb_xrgb_to_xrgb1555_line);
> +}
> +EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb1555);
> +
> +static void drm_fb_xrgb_to_argb1555_line(void *dbuf, const void *sbuf,
> unsigned int pixels)
> +{
> + u16 *dbuf16 = dbuf;
> + const __le32 *sbuf32 = sbuf;
> + unsigned int x;
> + u16 val16;
> + u32 pix;
> +
> + for (x = 0; x < pixels; x++) {
> + pix = le32_to_cpu(sbuf32[x]);
> + val16 = BIT(15) | /* set alpha bit */
> + ((pix & 0x00f8) >> 9) |
> + ((pix & 0xf800) >> 6) |
> + ((pix & 0x00f8) >> 3);
> + dbuf16[x] = cpu_to_le16(val16);
The same here:
- dbuf16[x] = cpu_to_le16(val16);
+ dbuf16[x] = val16;
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_argb1555 - Convert XRGB to ARGB1555 clip buffer
> + * @dst: Array of ARGB1555 destination buffers
> + * @dst_pitch: Array of numbers of bytes between the start of two
> consecutive scanlines
> + * within @dst; can be NULL if scanlines are stored next to each
> other.
> + * @src: Array of XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * This function copies parts of a framebuffer to display memory and converts
> + * the color format during the process. The parameters @dst, @dst_pitch and
> + * @src refer to arrays. Each array must have at least as many entries as
> + * there are planes in @fb's
Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
Wang, Zhi A 于2022年12月19日周一 16:22写道： > > I think it is a case-by-case thing. For example: > > The current scenario in this function looks like below: > > caller pass spt a > function > alloc spt b > something error > free spt a > return error > > The problem is: the function wrongly frees the spt a instead free what > it allocates. Thanks for your clear explaination. It’s really helpfult to me. I think I might know how to fix now. > A proper fix should be: > > caller pass spt a > function > alloc spt b > something error > *free spt b* > return error > As it's a case-by-case thing, I'll extract the un-done-mapping-dma part from ppgtt_invalidate_spt and put it in error path. Then I'll add the code of freeing new allocated spt. If I misunderstand your meaning, feel free to let me know. Working on a new fix now. Best regards, Zheng Wang
Re: [PATCH v3 2/2] drm/imx/lcdc: Implement DRM driver for imx21
On Fr, 2022-12-16 at 22:00 +0100, Uwe Kleine-König wrote:
> Hallo Philipp,
>
> On Fri, Dec 16, 2022 at 07:05:13PM +0100, Philipp Zabel wrote:
> > On Fr, 2022-12-16 at 18:50 +0100, Uwe Kleine-König wrote:
> > > From: Marian Cichy
> > >
> > > Add support for the LCD Controller found on i.MX21 and i.MX25.
> > >
> > > It targets to be a drop in replacement for the imx-fb driver.
> > >
> > > Signed-off-by: Marian Cichy
> > > [ukl: Rebase to v6.1, various smaller fixes]
> > > Signed-off-by: Uwe Kleine-König
> > > ---
> > > drivers/gpu/drm/imx/Kconfig | 1 +
> > > drivers/gpu/drm/imx/Makefile| 1 +
> >
> > I miss drivers/gpu/drm/imx/lcdc/{Kconfig,Makefile}.
>
> Their content is:
>
> - Kconfig -
> config DRM_IMX_LCDC
> tristate "Freescale i.MX LCDC displays"
> depends on DRM && (ARCH_MXC || COMPILE_TEST)
> select DRM_GEM_DMA_HELPER
> select DRM_KMS_HELPER
> help
> Found on i.MX1, i.MX21, i.MX25 and i.MX27.
> - Makefile -
> obj-y += imx-lcdc.o
> - >8 ---
>
> will resend the series once both dependent patches are in Linus' tree.
> Until then this v3 should be good enough to give reviewers a chance to
> look.
Please also rebase past 8ab59da26bc0 ("drm/fb-helper: Move generic
fbdev emulation into separate source file") and 00b5497d642b
("drm/simple-kms: Remove drm_gem_simple_display_pipe_prepare_fb()").
These changes let me compile imx-lcdc.c on top of drm-misc-next:
--8<--
diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
index 79fbb7956374..1bb46a346377 100644
--- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
+++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
@@ -4,7 +4,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -368,7 +368,6 @@ static const struct drm_simple_display_pipe_funcs
imx_lcdc_pipe_funcs = {
.disable = imx_lcdc_pipe_disable,
.check = imx_lcdc_pipe_check,
.update = imx_lcdc_pipe_update,
- .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
};
static const struct drm_mode_config_funcs imx_lcdc_mode_config_funcs = {
-->8--
regards
Philipp
Re: [PATCH v3 2/2] drm/imx/lcdc: Implement DRM driver for imx21
On Fr, 2022-12-16 at 18:50 +0100, Uwe Kleine-König wrote:
[...]
> +static int imx_lcdc_pipe_check(struct drm_simple_display_pipe *pipe,
> +struct drm_plane_state *plane_state,
> +struct drm_crtc_state *crtc_state)
> +{
> + const struct drm_display_mode *mode = &crtc_state->mode;
> + const struct drm_display_mode *old_mode = &pipe->crtc.state->mode;
> +
> + if (mode->hdisplay < LCDC_MIN_XRES || mode->hdisplay > LCDC_MAX_XRES ||
> + mode->vdisplay < LCDC_MIN_YRES || mode->vdisplay > LCDC_MAX_YRES ||
> + mode->hdisplay & 0x10) { /* must be multiple of 16 */
> + drm_err(pipe->crtc.dev, "unsupported display mode (%u x %u)\n",
> + mode->hdisplay, mode->vdisplay);
^^
Nitpick: now superfluous whitespace.
regards
Philipp
[PATCH 0/2] TLB invalidation cleanup
From: Tvrtko Ursulin First patch to make the platform check not catch all due current lack of automated testing. Second patch to consolidate the code a bit and move invariant setup at engine init time. Don't think I want to merge this one until some test coverage can be had. Tvrtko Ursulin (2): drm/i915: Do not cover all future platforms in TLB invalidation drm/i915: Consolidate TLB invalidation flow drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 ++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++ drivers/gpu/drm/i915/gt/intel_gt.c | 124 +++ 3 files changed, 128 insertions(+), 104 deletions(-) -- 2.34.1
[PATCH 1/2] drm/i915: Do not cover all future platforms in TLB invalidation
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 75a7cb33..854841a731cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1070,7 +1070,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
unsigned int num = 0;
unsigned long flags;
- if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
regs = NULL;
num = ARRAY_SIZE(xehp_regs);
} else if (GRAPHICS_VER(i915) == 12) {
--
2.34.1
[PATCH 2/2] drm/i915: Consolidate TLB invalidation flow
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++
drivers/gpu/drm/i915/gt/intel_gt.c | 135 +++
3 files changed, 128 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER(i915) == 12) {
+ regs = gen12_regs;
+ num = ARRAY_SIZE(gen12_regs);
+ } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
+ regs = gen8_regs;
+ num = ARRAY_SIZE(gen8_regs);
+ } else if (GRAPHICS_VER(i915) < 8) {
+ return 0;
+ }
+
+ if (drm_WARN_ONCE(&i915->drm, !num,
+ "Platform does not implement TLB invalidation!"))
+ return -ENODEV;
+
+ if (drm_WARN_ON_ONCE(&i915->drm,
+class >= num ||
+(!regs[class].reg.reg &&
+ !regs[class].mcr_reg.reg)))
+ return -ERANGE;
+
+ reg = regs[class];
+
+ if (GRAPHICS_VER(i915) == 8 && class == VIDEO_DECODE_CLASS) {
+ reg.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
+ val = 0;
+ } else {
+ val = engine->instance;
+ }
+
+ val = BIT(val);
+
+ engine->tlb_inv.mcr = regs == xehp_regs;
+ engine->tlb_inv.reg = reg;
+ engine->tlb_inv.done = val;
+
+ if (GRAPHICS_VER(i915) >= 12 &&
+ (engine->class == VIDEO_DECODE_CLASS ||
+engine->class == VIDEO_ENHANCEMENT_CLASS ||
+engine->class == COMPUTE_CLASS))
+ engine->tlb_inv.request = _MASKED_BIT_ENABLE(val);
+ else
+ engine->tlb_inv.request = val;
+
+ return 0;
+}
+
static int engine_setup_common(struct intel_engine_cs *engine)
{
int err;
init_llist_head(&engine->barrier_tasks);
+ err = intel_e
[PATCH] drm/i915/mtl: implement wa 14015076503
The WA states that before doing a GSC engine reset we need to alert the
GSC FW and then wait for 200ms for the FW to get ready for it. The GuC
will take care of this for engine reset, but i915 is still responsible
for the full GT reset scenario.
Given that we do full GT resets in the resume paths to cleanup the HW
state and that waiting 200ms in those scenarios would not be acceptable,
a faster path has been introduced where, if there are no pending
submissions to the GSC engine, we first try to individually reset the
GuC and all engines except the GSC and only fall back to full reset if
that fails.
Note that the 200ms wait is based on the worst case scenario and it
should be possible to limit the wait to a shorter time if the GSC FW
is idle when we alert it. However, the GSC FW team has advised against
this approach as the shorter wait time in that case would depend on the
actual power state of the microcontroller, because suspend exit time
might have to be added in. The GSC engine is very rarely active anyway,
so we should take the faster path in the great majority of cases.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/intel_reset.c | 74 +--
drivers/gpu/drm/i915/i915_reg.h | 5 +-
2 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ffde89c5835a..7cf84b0b72e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -14,6 +14,8 @@
#include "gt/intel_gt_regs.h"
+#include "gt/uc/intel_gsc_fw.h"
+
#include "i915_drv.h"
#include "i915_file_private.h"
#include "i915_gpu_error.h"
@@ -668,6 +670,64 @@ static reset_func intel_get_gpu_reset(const struct
intel_gt *gt)
return NULL;
}
+static int __reset_guc(struct intel_gt *gt)
+{
+ u32 guc_domain =
+ GRAPHICS_VER(gt->i915) >= 11 ? GEN11_GRDOM_GUC : GEN9_GRDOM_GUC;
+
+ return gen6_hw_domain_reset(gt, guc_domain);
+}
+
+static bool needs_wa_14015076503(struct intel_gt *gt, intel_engine_mask_t
engine_mask)
+{
+ if (!IS_METEORLAKE(gt->i915) || !HAS_ENGINE(gt, GSC0))
+ return false;
+
+ if (!__HAS_ENGINE(engine_mask, GSC0))
+ return false;
+
+ return intel_gsc_uc_fw_init_done(>->uc.gsc);
+}
+
+static intel_engine_mask_t
+wa_14015076503_start(struct intel_gt *gt, intel_engine_mask_t engine_mask,
bool first)
+{
+ if (!needs_wa_14015076503(gt, engine_mask))
+ return engine_mask;
+
+ /*
+* wa_14015076503: if the GSC FW is loaded, we need to alert it that
+* we're going to do a GSC engine reset and then wait for 200ms for the
+* FW to get ready for it. However, if this the first ALL_ENGINES reset
+* attempt and the GSC is not busy, we can try to instead reset the GuC
+* and all the other engines individually to avoid the 200ms wait.
+*/
+ if (engine_mask == ALL_ENGINES && first &&
intel_engine_is_idle(gt->engine[GSC0])) {
+ __reset_guc(gt);
+ engine_mask = gt->info.engine_mask & ~BIT(GSC0);
+ } else {
+ intel_uncore_write(gt->uncore,
+ HECI_GENERAL_STATUS(MTL_GSC_HECI2_BASE),
+ BIT(0));
+ intel_uncore_write(gt->uncore,
+ HECI_CONTROL_AND_STATUS(MTL_GSC_HECI2_BASE),
+ BIT(2));
+ msleep(200);
+ }
+
+ return engine_mask;
+}
+
+static void
+wa_14015076503_end(struct intel_gt *gt, intel_engine_mask_t engine_mask)
+{
+ if (!needs_wa_14015076503(gt, engine_mask))
+ return;
+
+ intel_uncore_write(gt->uncore,
+ HECI_GENERAL_STATUS(MTL_GSC_HECI2_BASE), 0);
+}
+
int __intel_gt_reset(struct intel_gt *gt, intel_engine_mask_t engine_mask)
{
const int retries = engine_mask == ALL_ENGINES ? RESET_MAX_RETRIES : 1;
@@ -685,10 +745,16 @@ int __intel_gt_reset(struct intel_gt *gt,
intel_engine_mask_t engine_mask)
*/
intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_ALL);
for (retry = 0; ret == -ETIMEDOUT && retry < retries; retry++) {
- GT_TRACE(gt, "engine_mask=%x\n", engine_mask);
+ intel_engine_mask_t reset_mask;
+
+ reset_mask = wa_14015076503_start(gt, engine_mask, !retry);
+
+ GT_TRACE(gt, "engine_mask=%x\n", reset_mask);
preempt_disable();
- ret = reset(gt, engine_mask, retry);
+ ret = reset(gt, reset_mask, retry);
preempt_enable();
+
+ wa_14015076503_end(gt, reset_mask);
}
intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_ALL);
@@ -713,14 +779,12 @@ bool intel_has_reset_engine(const struct intel_gt *gt)
int intel_reset_guc(struct intel
Re: [PATCH 5/9] drm/format-helper: Add conversion from XRGB8888 to 15-bit RGB555 formats
Hi
Am 19.12.22 um 10:23 schrieb José Expósito:
Hi Thomas,
Thanks for CCing me.
There are some issues with this helpers on big endian architectures, you can
run the test on big endian with this command:
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \
--arch=powerpc --cross_compile=powerpc64-linux-gnu- drm_format_helper_test
The problem is in the drm_fb_xrgb_to_*_line() functions, see the fixes
inlined:
On Tue, Dec 13, 2022 at 09:12:29PM +0100, Thomas Zimmermann wrote:
Add conversion from XRGB to XRGB1555, ARGB1555 and RGBA5551, which
are the formats currently supported by the simplefb infrastructure. The
new helpers allow the output of XRGB framebuffers to firmware
scanout buffers in one of the 15-bit formats.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 164 +++
.../gpu/drm/tests/drm_format_helper_test.c| 186 ++
include/drm/drm_format_helper.h | 9 +
3 files changed, 359 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index e562a3cefb89..aa6138756458 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -395,6 +395,161 @@ void drm_fb_xrgb_to_rgb565(struct iosys_map *dst,
const unsigned int *dst_pi
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
+static void drm_fb_xrgb_to_xrgb1555_line(void *dbuf, const void *sbuf, unsigned int pixels)
+{
+ u16 *dbuf16 = dbuf;
+ const __le32 *sbuf32 = sbuf;
+ unsigned int x;
+ u16 val16;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf32[x]);
+ val16 = ((pix & 0x00f8) >> 9) |
+ ((pix & 0xf800) >> 6) |
+ ((pix & 0x00f8) >> 3);
+ dbuf16[x] = cpu_to_le16(val16);
You don't need the extra cpu_to_le16() here:
- dbuf16[x] = cpu_to_le16(val16);
+ dbuf16[x] = val16;
Thanks for testing this. The DRM formats are defined to be in little
endian (unless the DRM_FORMAT_BIG_ENDIAN flag has been set). So we have
to convert the result from host to LE endianess.
I'm pretty sure that the hardcoded output in the testcases needs to be
adapted instead. But did this never happen with the older tests?
Best regards
Thomas
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb1555 - Convert XRGB to XRGB1555 clip buffer
+ * @dst: Array of XRGB1555 destination buffers
+ * @dst_pitch: Array of numbers of bytes between the start of two consecutive
scanlines
+ * within @dst; can be NULL if scanlines are stored next to each
other.
+ * @src: Array of XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * This function copies parts of a framebuffer to display memory and converts
+ * the color format during the process. The parameters @dst, @dst_pitch and
+ * @src refer to arrays. Each array must have at least as many entries as
+ * there are planes in @fb's format. Each entry stores the value for the
+ * format's respective color plane at the same index.
+ *
+ * This function does not apply clipping on @dst (i.e. the destination is at
the
+ * top-left corner).
+ *
+ * Drivers can use this function for XRGB1555 devices that don't support
+ * XRGB natively.
+ */
+void drm_fb_xrgb_to_xrgb1555(struct iosys_map *dst, const unsigned int
*dst_pitch,
+const struct iosys_map *src, const struct
drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+ static const u8 dst_pixsize[DRM_FORMAT_MAX_PLANES] = {
+ 2,
+ };
+
+ drm_fb_xfrm(dst, dst_pitch, dst_pixsize, src, fb, clip, false,
+ drm_fb_xrgb_to_xrgb1555_line);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb1555);
+
+static void drm_fb_xrgb_to_argb1555_line(void *dbuf, const void *sbuf,
unsigned int pixels)
+{
+ u16 *dbuf16 = dbuf;
+ const __le32 *sbuf32 = sbuf;
+ unsigned int x;
+ u16 val16;
+ u32 pix;
+
+ for (x = 0; x < pixels; x++) {
+ pix = le32_to_cpu(sbuf32[x]);
+ val16 = BIT(15) | /* set alpha bit */
+ ((pix & 0x00f8) >> 9) |
+ ((pix & 0xf800) >> 6) |
+ ((pix & 0x00f8) >> 3);
+ dbuf16[x] = cpu_to_le16(val16);
The same here:
- dbuf16[x] = cpu_to_le16(val16);
+ dbuf16[x] = val16;
+ }
+}
+
+/**
+ * drm_fb_xrgb_to_argb1555 - Convert XRGB to ARGB1555 clip buffer
+ * @dst: Array of ARGB1555 destination buffers
+ * @dst_pitch: Array of numbers of bytes between the start of two consecutive
scanlines
+ * within @dst; can be NULL if scanlines are stored next to each
other.
+ * @src: Array of XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+
Re: [PATCH] drm/meson: Reduce the FIFO lines held when AFBC is not used
Hi Carlo, On Mon, Dec 19, 2022 at 9:43 AM Carlo Caione wrote: > > Having a bigger number of FIFO lines held after vsync is only useful to > SoCs using AFBC to give time to the AFBC decoder to be reset, configured > and enabled again. > > For SoCs not using AFBC this, on the contrary, is causing on some > displays issues and a few pixels vertical offset in the displayed image. On the 32-bit SoCs (for which VPU support is not upstream yet) it has caused screen tearing instead of shifting the image. > Conditionally increase the number of lines held after vsync only for > SoCs using AFBC, leaving the default value for all the others. That was also my approach (for a not-yet-upstream patch). Since it's affecting already supported SoCs I suggest adding "Fixed-by: 24e0d4058eff ..." (maybe Neil can do so when he agrees and is applying the patch). Acked-by: Martin Blumenstingl
Re: [PATCH v2] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On 17/12/2022 16:23, Johan Jonker wrote:
> Convert rockchip-lvds.txt to YAML.
>
> Changed:
> Add power-domains property.
> Requirements between PX30 and RK3288
>
> Signed-off-by: Johan Jonker
> ---
>
> Changed V2:
> Fix title
> ---
> .../display/rockchip/rockchip-lvds.txt| 92 --
> .../display/rockchip/rockchip-lvds.yaml | 157 ++
> 2 files changed, 157 insertions(+), 92 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> create mode 100644
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> deleted file mode 100644
> index aaf8c44cf..0
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -Rockchip RK3288 LVDS interface
> -
> -
> -Required properties:
> -- compatible: matching the soc type, one of
> - - "rockchip,rk3288-lvds";
> - - "rockchip,px30-lvds";
> -
> -- reg: physical base address of the controller and length
> - of memory mapped region.
> -- clocks: must include clock specifiers corresponding to entries in the
> - clock-names property.
> -- clock-names: must contain "pclk_lvds"
> -
> -- avdd1v0-supply: regulator phandle for 1.0V analog power
> -- avdd1v8-supply: regulator phandle for 1.8V analog power
> -- avdd3v3-supply: regulator phandle for 3.3V analog power
> -
> -- rockchip,grf: phandle to the general register files syscon
> -- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output
> interface
> -
> -- phys: LVDS/DSI DPHY (px30 only)
> -- phy-names: name of the PHY, must be "dphy" (px30 only)
> -
> -Optional properties:
> -- pinctrl-names: must contain a "lcdc" entry.
> -- pinctrl-0: pin control group to be used for this controller.
> -
> -Required nodes:
> -
> -The lvds has two video ports as described by
> - Documentation/devicetree/bindings/media/video-interfaces.txt
> -Their connections are modeled using the OF graph bindings specified in
> - Documentation/devicetree/bindings/graph.txt.
> -
> -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
> -- video port 1 for either a panel or subsequent encoder
> -
> -Example:
> -
> -lvds_panel: lvds-panel {
> - compatible = "auo,b101ean01";
> - enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
> - data-mapping = "jeida-24";
> -
> - ports {
> - panel_in_lvds: endpoint {
> - remote-endpoint = <&lvds_out_panel>;
> - };
> - };
> -};
> -
> -For Rockchip RK3288:
> -
> - lvds: lvds@ff96c000 {
> - compatible = "rockchip,rk3288-lvds";
> - rockchip,grf = <&grf>;
> - reg = <0xff96c000 0x4000>;
> - clocks = <&cru PCLK_LVDS_PHY>;
> - clock-names = "pclk_lvds";
> - pinctrl-names = "lcdc";
> - pinctrl-0 = <&lcdc_ctl>;
> - avdd1v0-supply = <&vdd10_lcd>;
> - avdd1v8-supply = <&vcc18_lcd>;
> - avdd3v3-supply = <&vcca_33>;
> - rockchip,output = "rgb";
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - lvds_in: port@0 {
> - reg = <0>;
> -
> - lvds_in_vopb: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <&vopb_out_lvds>;
> - };
> - lvds_in_vopl: endpoint@1 {
> - reg = <1>;
> - remote-endpoint = <&vopl_out_lvds>;
> - };
> - };
> -
> - lvds_out: port@1 {
> - reg = <1>;
> -
> - lvds_out_panel: endpoint {
> - remote-endpoint = <&panel_in_lvds>;
> - };
> - };
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
> new file mode 100644
> index 0..f05901633
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml
Filename matching compatible style, so: "rockchip,lvds.yaml"
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/rockchip/rockchip-lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip low-voltage differential signal (LVDS) transmitter
> +
> +maintainers:
> + - Sandy Huang
> + - Heik
[PATCH v4 1/7] drm/debugfs: create device-centered debugfs functions
Introduce the ability to track requests for the addition of DRM debugfs
files at any time and have them added all at once during
drm_dev_register().
Drivers can add DRM debugfs files to a device-managed list and, during
drm_dev_register(), all added files will be created at once.
Now, the drivers can use the functions drm_debugfs_add_file() and
drm_debugfs_add_files() to create DRM debugfs files instead of using the
drm_debugfs_create_files() function.
Co-developed-by: Wambui Karuga
Signed-off-by: Wambui Karuga
Reviewed-by: Maxime Ripard
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 70 +++
drivers/gpu/drm/drm_drv.c | 3 ++
include/drm/drm_debugfs.h | 41
include/drm/drm_device.h | 15
4 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index ee445f4605ba..988fc07b94b4 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -151,6 +152,21 @@ static int drm_debugfs_open(struct inode *inode, struct
file *file)
return single_open(file, node->info_ent->show, node);
}
+static int drm_debugfs_entry_open(struct inode *inode, struct file *file)
+{
+ struct drm_debugfs_entry *entry = inode->i_private;
+ struct drm_debugfs_info *node = &entry->file;
+
+ return single_open(file, node->show, entry);
+}
+
+static const struct file_operations drm_debugfs_entry_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_debugfs_entry_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
static const struct file_operations drm_debugfs_fops = {
.owner = THIS_MODULE,
@@ -207,6 +223,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
struct drm_device *dev = minor->dev;
+ struct drm_debugfs_entry *entry, *tmp;
char name[64];
INIT_LIST_HEAD(&minor->debugfs_list);
@@ -230,6 +247,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
+ list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
+ debugfs_create_file(entry->file.name, S_IFREG | S_IRUGO,
+ minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
+ list_del(&entry->list);
+ }
+
return 0;
}
@@ -281,6 +304,53 @@ void drm_debugfs_cleanup(struct drm_minor *minor)
minor->debugfs_root = NULL;
}
+/**
+ * drm_debugfs_add_file - Add a given file to the DRM device debugfs file list
+ * @dev: drm device for the ioctl
+ * @name: debugfs file name
+ * @show: show callback
+ * @data: driver-private data, should not be device-specific
+ *
+ * Add a given file entry to the DRM device debugfs file list to be created on
+ * drm_debugfs_init.
+ */
+void drm_debugfs_add_file(struct drm_device *dev, const char *name,
+ int (*show)(struct seq_file*, void*), void *data)
+{
+ struct drm_debugfs_entry *entry = drmm_kzalloc(dev, sizeof(*entry),
GFP_KERNEL);
+
+ if (!entry)
+ return;
+
+ entry->file.name = name;
+ entry->file.show = show;
+ entry->file.data = data;
+ entry->dev = dev;
+
+ mutex_lock(&dev->debugfs_mutex);
+ list_add(&entry->list, &dev->debugfs_list);
+ mutex_unlock(&dev->debugfs_mutex);
+}
+EXPORT_SYMBOL(drm_debugfs_add_file);
+
+/**
+ * drm_debugfs_add_files - Add an array of files to the DRM device debugfs
file list
+ * @dev: drm device for the ioctl
+ * @files: The array of files to create
+ * @count: The number of files given
+ *
+ * Add a given set of debugfs files represented by an array of
+ * &struct drm_debugfs_info in the DRM device debugfs file list.
+ */
+void drm_debugfs_add_files(struct drm_device *dev, const struct
drm_debugfs_info *files, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++)
+ drm_debugfs_add_file(dev, files[i].name, files[i].show,
files[i].data);
+}
+EXPORT_SYMBOL(drm_debugfs_add_files);
+
static int connector_show(struct seq_file *m, void *data)
{
struct drm_connector *connector = m->private;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..c287488c776f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -575,6 +575,7 @@ static void drm_dev_init_release(struct drm_device *dev,
void *res)
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
mutex_destroy(&dev->struct_mutex);
+ mutex_destroy(&dev->debugfs_mutex);
drm_legacy_destroy_members(dev);
}
@@ -608,12 +609,14 @@ static int drm_dev_init(struct drm_device *dev,
[PATCH v4 0/7] Introduce debugfs device-centered functions
This series introduces the initial structure to make DRM debugfs more device-centered and it is the first step to drop the drm_driver->debugfs_init hooks in the future [1]. Currently, DRM debugfs files are created using drm_debugfs_create_files() on request. The first patch of this series makes it possible for DRM devices for creating debugfs files during drm_dev_register(). For it, it introduces two new functions that can be used by the drivers: drm_debugfs_add_files() and drm_debugfs_add_file(). The requests are added to a list and are created all at once during drm_dev_register(). Moreover, the first patch was based on this RFC series [2]. The main difference between the RFC series and the current series is the creation of a new fops structure to accommodate the new structs and, also, the creation of a new drm_debugfs_open. Moreover, the new series uses device-managed allocation, returns memory allocation errors, and converts more drivers to the new structure. Moreover, since v3, the ability to create debugfs files at late_register hooks was added. In previous versions, modeset components weren't able to create debugfs files at late_register hooks as the registration of drm_minor happens before the registration of the modeset abstractions. So, the third patch fixes this problem by adding a drm_debugfs_late_register() function. Thanks to Melissa Wen for catching this problem! Apart from the third patch, the series looks similiar from its last version. [1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n506 [2] https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ Best Regards, - Maíra Canal --- v1 -> v2: https://lore.kernel.org/dri-devel/20221122190314.185015-1-mca...@igalia.com/T/#t - Fix compilation errors in the second patch (kernel test robot). - Drop debugfs_init hook from vkms (Maíra Canal). - Remove return values and error handling to debugfs related functions (Jani Nikula). - Remove entry from list after the file is created, so that drm_debugfs_init can be called more than once (Maíra Canal). v2 -> v3: https://lore.kernel.org/dri-devel/20221123220725.1272155-1-mca...@igalia.com/ - Rebase on top of drm-misc-next v3 -> v4: https://lore.kernel.org/dri-devel/20221207132325.140393-1-mca...@igalia.com/ - Add Maxime's Reviewed-by tags - Add the ability to create debugfs files at late_register hooks (Melissa Wen). --- Maíra Canal (7): drm/debugfs: create device-centered debugfs functions drm: use new debugfs device-centered functions on DRM core files drm/debugfs: create debugfs late register functions drm/vc4: use new debugfs device-centered functions drm/v3d: use new debugfs device-centered functions drm/vkms: use new debugfs device-centered functions drm/todo: update the debugfs clean up task Documentation/gpu/todo.rst| 9 +-- drivers/gpu/drm/drm_atomic.c | 11 ++- drivers/gpu/drm/drm_client.c | 11 ++- drivers/gpu/drm/drm_debugfs.c | 102 +++--- drivers/gpu/drm/drm_drv.c | 3 + drivers/gpu/drm/drm_framebuffer.c | 11 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++- drivers/gpu/drm/drm_internal.h| 5 ++ drivers/gpu/drm/drm_mode_config.c | 2 + drivers/gpu/drm/v3d/v3d_debugfs.c | 22 +++--- drivers/gpu/drm/vc4/vc4_bo.c | 10 +-- drivers/gpu/drm/vc4/vc4_crtc.c| 7 +- drivers/gpu/drm/vc4/vc4_debugfs.c | 36 ++--- drivers/gpu/drm/vc4/vc4_dpi.c | 5 +- drivers/gpu/drm/vc4/vc4_drv.c | 1 - drivers/gpu/drm/vc4/vc4_drv.h | 32 ++-- drivers/gpu/drm/vc4/vc4_dsi.c | 6 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +-- drivers/gpu/drm/vc4/vc4_hvs.c | 24 ++ drivers/gpu/drm/vc4/vc4_v3d.c | 14 +--- drivers/gpu/drm/vc4/vc4_vec.c | 6 +- drivers/gpu/drm/vkms/vkms_drv.c | 17 ++--- include/drm/drm_debugfs.h | 41 +++ include/drm/drm_device.h | 15 24 files changed, 233 insertions(+), 180 deletions(-) -- 2.38.1
[PATCH v4 3/7] drm/debugfs: create debugfs late register functions
Although the device-centered debugfs functions can track requests for
the addition of DRM debugfs files at any time and have them added all
at once during drm_dev_register(), they are not able to create debugfs
files for modeset components, as they are registered after the primary
and the render drm_minor are registered.
So, create a drm_debugfs_late_register() function, which is responsible
for dealing with the creation of all the debugfs files for modeset
components at once. Therefore, the functions drm_debugfs_add_file()
and drm_debugfs_add_files() can be used in late_register hooks.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 14 ++
drivers/gpu/drm/drm_internal.h| 5 +
drivers/gpu/drm/drm_mode_config.c | 2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index d9d3ed7acc80..51e3772e2e2b 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -254,6 +254,20 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
return 0;
}
+void drm_debugfs_late_register(struct drm_device *dev)
+{
+ struct drm_minor *minor = dev->primary;
+ struct drm_debugfs_entry *entry, *tmp;
+
+ if (minor == NULL)
+ return;
+
+ list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
+ debugfs_create_file(entry->file.name, S_IFREG | S_IRUGO,
+ minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
+ list_del(&entry->list);
+ }
+}
int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
struct drm_minor *minor)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5ea5e260118c..ed2103ee272c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -186,6 +186,7 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
drm_device *dev,
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root);
void drm_debugfs_cleanup(struct drm_minor *minor);
+void drm_debugfs_late_register(struct drm_device *dev);
void drm_debugfs_connector_add(struct drm_connector *connector);
void drm_debugfs_connector_remove(struct drm_connector *connector);
void drm_debugfs_crtc_add(struct drm_crtc *crtc);
@@ -202,6 +203,10 @@ static inline void drm_debugfs_cleanup(struct drm_minor
*minor)
{
}
+static inline void drm_debugfs_late_register(struct drm_device *dev)
+{
+}
+
static inline void drm_debugfs_connector_add(struct drm_connector *connector)
{
}
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 8525ef851540..87eb591fe9b5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -54,6 +54,8 @@ int drm_modeset_register_all(struct drm_device *dev)
if (ret)
goto err_connector;
+ drm_debugfs_late_register(dev);
+
return 0;
err_connector:
--
2.38.1
[PATCH v4 2/7] drm: use new debugfs device-centered functions on DRM core files
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function in all DRM core files, centering the
debugfs files management on the drm_device instead of drm_minor.
Reviewed-by: Maxime Ripard
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_atomic.c | 11 +--
drivers/gpu/drm/drm_client.c | 11 +--
drivers/gpu/drm/drm_debugfs.c | 18 --
drivers/gpu/drm/drm_framebuffer.c | 11 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 11 +--
5 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e666799a46d5..5457c02ca1ab 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1756,8 +1756,8 @@ EXPORT_SYMBOL(drm_state_dump);
#ifdef CONFIG_DEBUG_FS
static int drm_state_info(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
__drm_state_dump(dev, &p, true);
@@ -1766,14 +1766,13 @@ static int drm_state_info(struct seq_file *m, void
*data)
}
/* any use in debugfs files to dump individual planes/crtc/etc? */
-static const struct drm_info_list drm_atomic_debugfs_list[] = {
+static const struct drm_debugfs_info drm_atomic_debugfs_list[] = {
{"state", drm_state_info, 0},
};
void drm_atomic_debugfs_init(struct drm_minor *minor)
{
- drm_debugfs_create_files(drm_atomic_debugfs_list,
-ARRAY_SIZE(drm_atomic_debugfs_list),
-minor->debugfs_root, minor);
+ drm_debugfs_add_files(minor->dev, drm_atomic_debugfs_list,
+ ARRAY_SIZE(drm_atomic_debugfs_list));
}
#endif
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index fd67efe37c63..262ec64d4397 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -480,8 +480,8 @@ EXPORT_SYMBOL(drm_client_framebuffer_flush);
#ifdef CONFIG_DEBUG_FS
static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
{
- struct drm_info_node *node = m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
struct drm_client_dev *client;
@@ -493,14 +493,13 @@ static int drm_client_debugfs_internal_clients(struct
seq_file *m, void *data)
return 0;
}
-static const struct drm_info_list drm_client_debugfs_list[] = {
+static const struct drm_debugfs_info drm_client_debugfs_list[] = {
{ "internal_clients", drm_client_debugfs_internal_clients, 0 },
};
void drm_client_debugfs_init(struct drm_minor *minor)
{
- drm_debugfs_create_files(drm_client_debugfs_list,
-ARRAY_SIZE(drm_client_debugfs_list),
-minor->debugfs_root, minor);
+ drm_debugfs_add_files(minor->dev, drm_client_debugfs_list,
+ ARRAY_SIZE(drm_client_debugfs_list));
}
#endif
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 988fc07b94b4..d9d3ed7acc80 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -51,9 +51,8 @@
static int drm_name_info(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_minor *minor = node->minor;
- struct drm_device *dev = minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct drm_master *master;
mutex_lock(&dev->master_mutex);
@@ -73,8 +72,8 @@ static int drm_name_info(struct seq_file *m, void *data)
static int drm_clients_info(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct drm_file *priv;
kuid_t uid;
@@ -125,8 +124,8 @@ static int drm_gem_one_name_info(int id, void *ptr, void
*data)
static int drm_gem_name_info(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
seq_printf(m, " name size handles refcount\n");
@@ -137,7 +136,7 @@ static int drm_gem_name_info(struct seq_file *m, void *data)
return 0;
}
-static const struct drm_info_list drm_debugfs_list[] = {
+static const struct
[PATCH v4 6/7] drm/vkms: use new debugfs device-centered functions
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on vkms_create(),
before drm_dev_register().
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_drv.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 69346906ec81..6d3a2d57d992 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -92,8 +92,8 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state
*old_state)
static int vkms_config_show(struct seq_file *m, void *data)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback);
@@ -103,24 +103,16 @@ static int vkms_config_show(struct seq_file *m, void
*data)
return 0;
}
-static const struct drm_info_list vkms_config_debugfs_list[] = {
+static const struct drm_debugfs_info vkms_config_debugfs_list[] = {
{ "vkms_config", vkms_config_show, 0 },
};
-static void vkms_config_debugfs_init(struct drm_minor *minor)
-{
- drm_debugfs_create_files(vkms_config_debugfs_list,
ARRAY_SIZE(vkms_config_debugfs_list),
-minor->debugfs_root, minor);
-}
-
static const struct drm_driver vkms_driver = {
.driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
.release= vkms_release,
.fops = &vkms_driver_fops,
DRM_GEM_SHMEM_DRIVER_OPS,
- .debugfs_init = vkms_config_debugfs_init,
-
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
@@ -202,6 +194,9 @@ static int vkms_create(struct vkms_config *config)
if (ret)
goto out_devres;
+ drm_debugfs_add_files(&vkms_device->drm, vkms_config_debugfs_list,
+ ARRAY_SIZE(vkms_config_debugfs_list));
+
ret = drm_dev_register(&vkms_device->drm, 0);
if (ret)
goto out_devres;
--
2.38.1
[PATCH v4 4/7] drm/vc4: use new debugfs device-centered functions
Currently, vc4 has its own debugfs infrastructure that adds the debugfs
files on drm_dev_register(). With the introduction of the new debugfs,
functions, replace the vc4 debugfs structure with the DRM debugfs
device-centered function, drm_debugfs_add_file().
Moreover, remove the explicit error handling of debugfs related functions,
considering that the only failure mode is -ENOMEM and also that error
handling is not recommended for debugfs functions, as pointed out in [1].
[1] https://lore.kernel.org/all/ywamzdrwnat6w...@kroah.com/
Reviewed-by: Maxime Ripard
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_bo.c | 10 +++--
drivers/gpu/drm/vc4/vc4_crtc.c| 7 ++
drivers/gpu/drm/vc4/vc4_debugfs.c | 36 ++-
drivers/gpu/drm/vc4/vc4_dpi.c | 5 +
drivers/gpu/drm/vc4/vc4_drv.c | 1 -
drivers/gpu/drm/vc4/vc4_drv.h | 32 ++-
drivers/gpu/drm/vc4/vc4_dsi.c | 6 +-
drivers/gpu/drm/vc4/vc4_hdmi.c| 12 ---
drivers/gpu/drm/vc4/vc4_hvs.c | 24 ++---
drivers/gpu/drm/vc4/vc4_v3d.c | 14
drivers/gpu/drm/vc4/vc4_vec.c | 6 +-
11 files changed, 37 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 43d9b3a6a352..c2b7573bd92b 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -69,8 +69,8 @@ static void vc4_bo_stats_print(struct drm_printer *p, struct
vc4_dev *vc4)
static int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_printer p = drm_seq_file_printer(m);
@@ -993,15 +993,11 @@ int vc4_bo_debugfs_init(struct drm_minor *minor)
{
struct drm_device *drm = minor->dev;
struct vc4_dev *vc4 = to_vc4_dev(drm);
- int ret;
if (!vc4->v3d)
return -ENODEV;
- ret = vc4_debugfs_add_file(minor, "bo_stats",
- vc4_bo_stats_debugfs, NULL);
- if (ret)
- return ret;
+ drm_debugfs_add_file(drm, "bo_stats", vc4_bo_stats_debugfs, NULL);
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index a1a3465948c4..35a6b5907278 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -1090,12 +1090,9 @@ int vc4_crtc_late_register(struct drm_crtc *crtc)
struct drm_device *drm = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
const struct vc4_crtc_data *crtc_data =
vc4_crtc_to_vc4_crtc_data(vc4_crtc);
- int ret;
- ret = vc4_debugfs_add_regset32(drm->primary, crtc_data->debugfs_name,
- &vc4_crtc->regset);
- if (ret)
- return ret;
+ vc4_debugfs_add_regset32(drm, crtc_data->debugfs_name,
+&vc4_crtc->regset);
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index 19cda4f91a82..fac624a663ea 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -34,9 +34,9 @@ vc4_debugfs_init(struct drm_minor *minor)
static int vc4_debugfs_regset32(struct seq_file *m, void *unused)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *drm = node->minor->dev;
- struct debugfs_regset32 *regset = node->info_ent->data;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *drm = entry->dev;
+ struct debugfs_regset32 *regset = entry->file.data;
struct drm_printer p = drm_seq_file_printer(m);
int idx;
@@ -50,31 +50,9 @@ static int vc4_debugfs_regset32(struct seq_file *m, void
*unused)
return 0;
}
-int vc4_debugfs_add_file(struct drm_minor *minor,
-const char *name,
-int (*show)(struct seq_file*, void*),
-void *data)
+void vc4_debugfs_add_regset32(struct drm_device *drm,
+ const char *name,
+ struct debugfs_regset32 *regset)
{
- struct drm_device *dev = minor->dev;
- struct dentry *root = minor->debugfs_root;
- struct drm_info_list *file;
-
- file = drmm_kzalloc(dev, sizeof(*file), GFP_KERNEL);
- if (!file)
- return -ENOMEM;
-
- file->name = name;
- file->show = show;
- file->data = data;
-
- drm_debugfs_create_files(file, 1, root, minor);
-
- return 0;
-}
-
-int vc4_debugfs_add_regset32(struct drm_minor *minor,
-const char *name,
-struct debugfs_
[PATCH v4 5/7] drm/v3d: use new debugfs device-centered functions
Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which centers the debugfs files
management on the drm_device instead of drm_minor.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index efbde124c296..330669f51fa7 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -79,8 +79,8 @@ static const struct v3d_reg_def v3d_csd_reg_defs[] = {
static int v3d_v3d_debugfs_regs(struct seq_file *m, void *unused)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
int i, core;
@@ -126,8 +126,8 @@ static int v3d_v3d_debugfs_regs(struct seq_file *m, void
*unused)
static int v3d_v3d_debugfs_ident(struct seq_file *m, void *unused)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
u32 ident0, ident1, ident2, ident3, cores;
int core;
@@ -188,8 +188,8 @@ static int v3d_v3d_debugfs_ident(struct seq_file *m, void
*unused)
static int v3d_debugfs_bo_stats(struct seq_file *m, void *unused)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
mutex_lock(&v3d->bo_lock);
@@ -204,8 +204,8 @@ static int v3d_debugfs_bo_stats(struct seq_file *m, void
*unused)
static int v3d_measure_clock(struct seq_file *m, void *unused)
{
- struct drm_info_node *node = (struct drm_info_node *)m->private;
- struct drm_device *dev = node->minor->dev;
+ struct drm_debugfs_entry *entry = m->private;
+ struct drm_device *dev = entry->dev;
struct v3d_dev *v3d = to_v3d_dev(dev);
uint32_t cycles;
int core = 0;
@@ -236,7 +236,7 @@ static int v3d_measure_clock(struct seq_file *m, void
*unused)
return 0;
}
-static const struct drm_info_list v3d_debugfs_list[] = {
+static const struct drm_debugfs_info v3d_debugfs_list[] = {
{"v3d_ident", v3d_v3d_debugfs_ident, 0},
{"v3d_regs", v3d_v3d_debugfs_regs, 0},
{"measure_clock", v3d_measure_clock, 0},
@@ -246,7 +246,5 @@ static const struct drm_info_list v3d_debugfs_list[] = {
void
v3d_debugfs_init(struct drm_minor *minor)
{
- drm_debugfs_create_files(v3d_debugfs_list,
-ARRAY_SIZE(v3d_debugfs_list),
-minor->debugfs_root, minor);
+ drm_debugfs_add_files(minor->dev, v3d_debugfs_list,
ARRAY_SIZE(v3d_debugfs_list));
}
--
2.38.1
[PATCH v4 7/7] drm/todo: update the debugfs clean up task
The structs drm_debugfs_info and drm_debugfs_entry introduced a new debugfs structure to DRM, centered on drm_device instead of drm_minor. Therefore, remove the tasks related to create a new device-centered debugfs structure and add a new task to replace the use of drm_debugfs_create_files() for the use of drm_debugfs_add_file() and drm_debugfs_add_files(). Signed-off-by: Maíra Canal --- Documentation/gpu/todo.rst | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index b2c6aaf1edf2..f64abf69f341 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -508,17 +508,14 @@ Clean up the debugfs support There's a bunch of issues with it: -- The drm_info_list ->show() function doesn't even bother to cast to the drm - structure for you. This is lazy. +- Convert drivers to support the drm_debugfs_add_files() function instead of + the drm_debugfs_create_files() function. - We probably want to have some support for debugfs files on crtc/connectors and maybe other kms objects directly in core. There's even drm_print support in the funcs for these objects to dump kms state, so it's all there. And then the ->show() functions should obviously give you a pointer to the right object. -- The drm_info_list stuff is centered on drm_minor instead of drm_device. For - anything we want to print drm_device (or maybe drm_file) is the right thing. - - The drm_driver->debugfs_init hooks we have is just an artifact of the old midlayered load sequence. DRM debugfs should work more like sysfs, where you can create properties/files for an object anytime you want, and the core @@ -527,8 +524,6 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. -Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ - Contact: Daniel Vetter Level: Intermediate -- 2.38.1
[PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
Convert rockchip-lvds.txt to YAML.
Changed:
Add power-domains property.
Requirements between PX30 and RK3288
Signed-off-by: Johan Jonker
---
Changed V3:
Filename matching compatible style
Drop "Regulator phandle for "
Specify properties and requirements per SoC
Sort order and restyle
Changed V2:
Fix title
---
.../display/rockchip/rockchip,lvds.yaml | 170 ++
.../display/rockchip/rockchip-lvds.txt| 92 --
2 files changed, 170 insertions(+), 92 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
new file mode 100644
index 0..03b002a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip low-voltage differential signal (LVDS) transmitter
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+enum:
+ - rockchip,px30-lvds
+ - rockchip,rk3288-lvds
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: pclk_lvds
+
+ avdd1v0-supply:
+description: 1.0V analog power.
+
+ avdd1v8-supply:
+description: 1.8V analog power.
+
+ avdd3v3-supply:
+description: 3.3V analog power.
+
+ rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Phandle to the general register files syscon.
+
+ rockchip,output:
+$ref: /schemas/types.yaml#/definitions/string
+enum: [rgb, lvds, duallvds]
+description: This describes the output interface.
+
+ phys:
+maxItems: 1
+
+ phy-names:
+const: dphy
+
+ pinctrl-names:
+const: lcdc
+
+ pinctrl-0: true
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Video port 0 for the VOP input.
+ The remote endpoint maybe vopb or vopl.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Video port 1 for either a panel or subsequent encoder.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - rockchip,grf
+ - rockchip,output
+ - ports
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: rockchip,px30-lvds
+
+then:
+ properties:
+reg: false
+clocks: false
+clock-names: false
+avdd1v0-supply: false
+avdd1v8-supply: false
+avdd3v3-supply: false
+
+ required:
+- phys
+- phy-names
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: rockchip,rk3288-lvds
+
+then:
+ properties:
+phys: false
+phy-names: false
+
+ required:
+- reg
+- clocks
+- clock-names
+- avdd1v0-supply
+- avdd1v8-supply
+- avdd3v3-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+lvds: lvds@ff96c000 {
+ compatible = "rockchip,rk3288-lvds";
+ reg = <0xff96c000 0x4000>;
+ clocks = <&cru PCLK_LVDS_PHY>;
+ clock-names = "pclk_lvds";
+ avdd1v0-supply = <&vdd10_lcd>;
+ avdd1v8-supply = <&vcc18_lcd>;
+ avdd3v3-supply = <&vcca_33>;
+ pinctrl-names = "lcdc";
+ pinctrl-0 = <&lcdc_ctl>;
+ rockchip,grf = <&grf>;
+ rockchip,output = "rgb";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lvds_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in_vopb: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&vopb_out_lvds>;
+ };
+ lvds_in_vopl: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&vopl_out_lvds>;
+ };
+};
+
+lvds_out: port@1 {
+ reg = <1>;
+
+ lvds_out_panel: endpoint {
+remote-endpoint = <&panel_in_lvds>;
+ };
+};
+ };
+};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
deleted file mode 100644
index aaf8c44cf..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Rockchip RK3288 LVDS interface
-
-
-Required properties:
-- compatible: matching the soc type, one of
- - "rockchip,rk32
Re: [RFC PATCH 0/4] Add RGB ttl connection on rockchip phy
Hi all
On Sun, Oct 2, 2022 at 8:45 AM Michael Trimarchi
wrote:
>
> The rockchip phy can be convigured in ttl mode. The phy is shared
> between lvds, dsi, ttl. The configuration that now I'm able to support
> has the display output on some set of pins on standard vop output
> and a set of pins using the ttl phy. The solution is not clean as I
> would like to have because some register that are used to enable
> the TTL, are in the same register area of the dsi controller.
> In order to test I must add the following
>
> dsi_dphy: phy@ff2e {
>
> reg = <0x0 0xff2e 0x0 0x1>,
> <0x0 0xff45 0x0 0x1>;
> ...
> }
>
> The problem here is the second region I have added is the same of
> dsi logic. Only one register is needed by the the phy driver
>
Is there anyone who has time to review it?
Michael
> Michael Trimarchi (4):
> phy: add PHY_MODE_TTL
> phy: rockchip: Add inno_is_valid_phy_mode
> phy: rockchip: Implement TTY phy mode
> drm/rockchip: rgb: Add dphy connection to rgb output
>
> drivers/gpu/drm/rockchip/rockchip_rgb.c | 18 +
> .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 72 +++
> include/linux/phy/phy.h | 3 +-
> 3 files changed, 92 insertions(+), 1 deletion(-)
>
> --
> 2.34.1
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
[PATCH v4] [PATCH v4] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt. But the caller does
not notice that, it will free spt again in error path.
Fix this by undoing the mapping of DMA address and freeing sub_spt.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Zheng Wang
---
v4:
- fix by undo the mapping of DMA address and free sub_spt suggested by Zhi
v3:
- correct spelling mistake and remove unused variable suggested by Greg
v2: https://lore.kernel.org/all/20221006165845.1735393-1-zyytlz...@163.com/
v1: https://lore.kernel.org/all/20220928033340.1063949-1-zyytlz...@163.com/
---
drivers/gpu/drm/i915/gvt/gtt.c | 58 +-
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 45271acc5038..b472e021e5a4 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1209,7 +1209,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
for_each_shadow_entry(sub_spt, &sub_se, sub_index) {
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
PAGE_SIZE, &dma_addr);
- if (ret)
+ if (ret)
goto err;
sub_se.val64 = se->val64;
@@ -1233,34 +1233,34 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
/* Undone the existing mappings of DMA addr. */
for_each_present_shadow_entry(spt, &e, parent_index) {
switch (e.type) {
- case GTT_TYPE_PPGTT_PTE_4K_ENTRY:
- gvt_vdbg_mm("invalidate 4K entry\n");
- ppgtt_invalidate_pte(spt, &e);
- break;
- case GTT_TYPE_PPGTT_PTE_64K_ENTRY:
- /* We don't setup 64K shadow entry so far. */
- WARN(1, "suspicious 64K gtt entry\n");
- continue;
- case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
- gvt_vdbg_mm("invalidate 2M entry\n");
- continue;
- case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
- WARN(1, "GVT doesn't support 1GB page\n");
- continue;
- case GTT_TYPE_PPGTT_PML4_ENTRY:
- case GTT_TYPE_PPGTT_PDP_ENTRY:
- case GTT_TYPE_PPGTT_PDE_ENTRY:
- gvt_vdbg_mm("invalidate PMUL4/PDP/PDE entry\n");
- ret1 = ppgtt_invalidate_spt_by_shadow_entry(
- spt->vgpu, &e);
- if (ret1) {
- gvt_vgpu_err("fail: shadow page %p
shadow entry 0x%llx type %d\n",
- spt, e.val64, e.type);
- goto free_spt;
- }
- break;
- default:
- GEM_BUG_ON(1);
+ case GTT_TYPE_PPGTT_PTE_4K_ENTRY:
+ gvt_vdbg_mm("invalidate 4K entry\n");
+ ppgtt_invalidate_pte(spt, &e);
+ break;
+ case GTT_TYPE_PPGTT_PTE_64K_ENTRY:
+ /* We don't setup 64K shadow entry so far. */
+ WARN(1, "suspicious 64K gtt entry\n");
+ continue;
+ case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
+ gvt_vdbg_mm("invalidate 2M entry\n");
+ continue;
+ case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
+ WARN(1, "GVT doesn't support 1GB page\n");
+ continue;
+ case GTT_TYPE_PPGTT_PML4_ENTRY:
+ case GTT_TYPE_PPGTT_PDP_ENTRY:
+ case GTT_TYPE_PPGTT_PDE_ENTRY:
+ gvt_vdbg_mm("invalidate PMUL4/PDP/PDE entry\n");
+ ret1 = ppgtt_invalidate_spt_by_shadow_entry(
+ spt->vgpu, &e);
+ if (ret1) {
+ gvt_vgpu_err("fail: shadow page %p shadow entry
0x%llx type %d\n",
+ spt, e.val64, e.type);
+ goto free_spt;
+ }
+ break;
+ default:
+ GEM_BUG_ON(1);
}
}
/* Release the new alloced apt. */
--
2.25.1
Re: [PATCH v4 0/7] Introduce debugfs device-centered functions
On 12/19, Maíra Canal wrote: > This series introduces the initial structure to make DRM debugfs more > device-centered and it is the first step to drop the > drm_driver->debugfs_init hooks in the future [1]. > > Currently, DRM debugfs files are created using drm_debugfs_create_files() > on request. The first patch of this series makes it possible for DRM devices > for creating debugfs files during drm_dev_register(). For it, it introduces > two new functions that can be used by the drivers: drm_debugfs_add_files() > and drm_debugfs_add_file(). The requests are added to a list and are created > all at once during drm_dev_register(). Moreover, the first patch was based on > this RFC series [2]. > > The main difference between the RFC series and the current series is the > creation of a new fops structure to accommodate the new structs and, also, > the creation of a new drm_debugfs_open. Moreover, the new series uses > device-managed allocation, returns memory allocation errors, and converts > more drivers to the new structure. > > Moreover, since v3, the ability to create debugfs files at late_register > hooks was > added. In previous versions, modeset components weren't able to create debugfs > files at late_register hooks as the registration of drm_minor happens before > the > registration of the modeset abstractions. So, the third patch fixes this > problem > by adding a drm_debugfs_late_register() function. Thanks to Melissa Wen for > catching this problem! > > Apart from the third patch, the series looks similiar from its last version. > > [1] https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n506 > [2] > https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ > > Best Regards, > - Maíra Canal > > --- > > v1 -> v2: > https://lore.kernel.org/dri-devel/20221122190314.185015-1-mca...@igalia.com/T/#t > > - Fix compilation errors in the second patch (kernel test robot). > - Drop debugfs_init hook from vkms (Maíra Canal). > - Remove return values and error handling to debugfs related > functions (Jani Nikula). > - Remove entry from list after the file is created, so that drm_debugfs_init > can be called more than once (Maíra Canal). > > v2 -> v3: > https://lore.kernel.org/dri-devel/20221123220725.1272155-1-mca...@igalia.com/ > > - Rebase on top of drm-misc-next > > v3 -> v4: > https://lore.kernel.org/dri-devel/20221207132325.140393-1-mca...@igalia.com/ > > - Add Maxime's Reviewed-by tags > - Add the ability to create debugfs files at late_register hooks (Melissa > Wen). Hi Maíra, Thanks for addressing all comments. Maybe Danvet has some inputs for the late_register approach. Anyway, LGTM and the entire series is: Reviewed-by: Melissa Wen > > --- > > Maíra Canal (7): > drm/debugfs: create device-centered debugfs functions > drm: use new debugfs device-centered functions on DRM core files > drm/debugfs: create debugfs late register functions > drm/vc4: use new debugfs device-centered functions > drm/v3d: use new debugfs device-centered functions > drm/vkms: use new debugfs device-centered functions > drm/todo: update the debugfs clean up task > > Documentation/gpu/todo.rst| 9 +-- > drivers/gpu/drm/drm_atomic.c | 11 ++- > drivers/gpu/drm/drm_client.c | 11 ++- > drivers/gpu/drm/drm_debugfs.c | 102 +++--- > drivers/gpu/drm/drm_drv.c | 3 + > drivers/gpu/drm/drm_framebuffer.c | 11 ++- > drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++- > drivers/gpu/drm/drm_internal.h| 5 ++ > drivers/gpu/drm/drm_mode_config.c | 2 + > drivers/gpu/drm/v3d/v3d_debugfs.c | 22 +++--- > drivers/gpu/drm/vc4/vc4_bo.c | 10 +-- > drivers/gpu/drm/vc4/vc4_crtc.c| 7 +- > drivers/gpu/drm/vc4/vc4_debugfs.c | 36 ++--- > drivers/gpu/drm/vc4/vc4_dpi.c | 5 +- > drivers/gpu/drm/vc4/vc4_drv.c | 1 - > drivers/gpu/drm/vc4/vc4_drv.h | 32 ++-- > drivers/gpu/drm/vc4/vc4_dsi.c | 6 +- > drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +-- > drivers/gpu/drm/vc4/vc4_hvs.c | 24 ++ > drivers/gpu/drm/vc4/vc4_v3d.c | 14 +--- > drivers/gpu/drm/vc4/vc4_vec.c | 6 +- > drivers/gpu/drm/vkms/vkms_drv.c | 17 ++--- > include/drm/drm_debugfs.h | 41 +++ > include/drm/drm_device.h | 15 > 24 files changed, 233 insertions(+), 180 deletions(-) > > -- > 2.38.1 > signature.asc Description: PGP signature
[RESEND PATCH v4] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt. But the caller does
not notice that, it will free spt again in error path.
Fix this by undoing the mapping of DMA address and freeing sub_spt.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Signed-off-by: Zheng Wang
---
v4:
- fix by undo the mapping of DMA address and free sub_spt suggested by Zhi
v3:
- correct spelling mistake and remove unused variable suggested by Greg
v2: https://lore.kernel.org/all/20221006165845.1735393-1-zyytlz...@163.com/
v1: https://lore.kernel.org/all/20220928033340.1063949-1-zyytlz...@163.com/
---
drivers/gpu/drm/i915/gvt/gtt.c | 53 +-
1 file changed, 46 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 51e5e8fb505b..b472e021e5a4 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1192,11 +1192,11 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
{
const struct intel_gvt_gtt_pte_ops *ops = vgpu->gvt->gtt.pte_ops;
struct intel_vgpu_ppgtt_spt *sub_spt;
- struct intel_gvt_gtt_entry sub_se;
+ struct intel_gvt_gtt_entry sub_se, e;
unsigned long start_gfn;
dma_addr_t dma_addr;
- unsigned long sub_index;
- int ret;
+ unsigned long sub_index, parent_index;
+ int ret, ret1;
gvt_dbg_mm("Split 2M gtt entry, index %lu\n", index);
@@ -1209,10 +1209,8 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
for_each_shadow_entry(sub_spt, &sub_se, sub_index) {
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
PAGE_SIZE, &dma_addr);
- if (ret) {
- ppgtt_invalidate_spt(spt);
- return ret;
- }
+ if (ret)
+ goto err;
sub_se.val64 = se->val64;
/* Copy the PAT field from PDE. */
@@ -1231,6 +1229,47 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
ops->set_pfn(se, sub_spt->shadow_page.mfn);
ppgtt_set_shadow_entry(spt, se, index);
return 0;
+err:
+ /* Undone the existing mappings of DMA addr. */
+ for_each_present_shadow_entry(spt, &e, parent_index) {
+ switch (e.type) {
+ case GTT_TYPE_PPGTT_PTE_4K_ENTRY:
+ gvt_vdbg_mm("invalidate 4K entry\n");
+ ppgtt_invalidate_pte(spt, &e);
+ break;
+ case GTT_TYPE_PPGTT_PTE_64K_ENTRY:
+ /* We don't setup 64K shadow entry so far. */
+ WARN(1, "suspicious 64K gtt entry\n");
+ continue;
+ case GTT_TYPE_PPGTT_PTE_2M_ENTRY:
+ gvt_vdbg_mm("invalidate 2M entry\n");
+ continue;
+ case GTT_TYPE_PPGTT_PTE_1G_ENTRY:
+ WARN(1, "GVT doesn't support 1GB page\n");
+ continue;
+ case GTT_TYPE_PPGTT_PML4_ENTRY:
+ case GTT_TYPE_PPGTT_PDP_ENTRY:
+ case GTT_TYPE_PPGTT_PDE_ENTRY:
+ gvt_vdbg_mm("invalidate PMUL4/PDP/PDE entry\n");
+ ret1 = ppgtt_invalidate_spt_by_shadow_entry(
+ spt->vgpu, &e);
+ if (ret1) {
+ gvt_vgpu_err("fail: shadow page %p shadow entry
0x%llx type %d\n",
+ spt, e.val64, e.type);
+ goto free_spt;
+ }
+ break;
+ default:
+ GEM_BUG_ON(1);
+ }
+ }
+ /* Release the new alloced apt. */
+free_spt:
+ trace_spt_change(sub_spt->vgpu->id, "release", sub_spt,
+ sub_spt->guest_page.gfn, sub_spt->shadow_page.type);
+ ppgtt_free_spt(sub_spt);
+ sub_spt = NULL;
+ return ret;
}
static int split_64KB_gtt_entry(struct intel_vgpu *vgpu,
--
2.25.1
Re: [PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On 19/12/2022 13:32, Johan Jonker wrote: > Convert rockchip-lvds.txt to YAML. > > Changed: > Add power-domains property. > Requirements between PX30 and RK3288 > > Signed-off-by: Johan Jonker > --- > > Changed V3: > Filename matching compatible style > Drop "Regulator phandle for " > Specify properties and requirements per SoC > Sort order and restyle > > Changed V2: > Fix title > --- > .../display/rockchip/rockchip,lvds.yaml | 170 ++ > .../display/rockchip/rockchip-lvds.txt| 92 -- > 2 files changed, 170 insertions(+), 92 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > new file mode 100644 > index 0..03b002a05 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > @@ -0,0 +1,170 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Rockchip low-voltage differential signal (LVDS) transmitter > + > +maintainers: > + - Sandy Huang > + - Heiko Stuebner > + > +properties: > + compatible: > +enum: > + - rockchip,px30-lvds > + - rockchip,rk3288-lvds > + > + reg: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > + > + clock-names: > +const: pclk_lvds > + > + avdd1v0-supply: > +description: 1.0V analog power. > + > + avdd1v8-supply: > +description: 1.8V analog power. > + > + avdd3v3-supply: > +description: 3.3V analog power. > + > + rockchip,grf: > +$ref: /schemas/types.yaml#/definitions/phandle > +description: Phandle to the general register files syscon. > + > + rockchip,output: > +$ref: /schemas/types.yaml#/definitions/string > +enum: [rgb, lvds, duallvds] > +description: This describes the output interface. > + > + phys: > +maxItems: 1 > + > + phy-names: > +const: dphy > + > + pinctrl-names: > +const: lcdc > + > + pinctrl-0: true > + > + power-domains: > +maxItems: 1 > + > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > + > +properties: > + port@0: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Video port 0 for the VOP input. > + The remote endpoint maybe vopb or vopl. > + > + port@1: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Video port 1 for either a panel or subsequent encoder. > + > +required: > + - port@0 > + - port@1 > + > +required: > + - compatible > + - rockchip,grf > + - rockchip,output > + - ports > + > +allOf: > + - if: > + properties: > +compatible: > + contains: > +const: rockchip,px30-lvds > + > +then: > + properties: > +reg: false > +clocks: false > +clock-names: false > +avdd1v0-supply: false > +avdd1v8-supply: false > +avdd3v3-supply: false > + I see one compatible expects regmap from parent (grf is the parent here) and other is directly on MMIO bus. Not the best combination... Maybe this should be just split to two separate bindings? Looking at driver, their code is also very different between these two variants. Best regards, Krzysztof
Re: [PATCH v4 2/7] accel/ivpu: Add Intel VPU MMU support
Hi,
On 18.12.2022 10:13, Oded Gabbay wrote:
> On Thu, Dec 8, 2022 at 1:08 PM Jacek Lawrynowicz
> wrote:
>>
>> VPU Memory Management Unit is based on ARM MMU-600.
>> It allows the creation of multiple virtual address spaces for
>> the device and map noncontinuous host memory (there is no dedicated
>> memory on the VPU).
>>
>> Address space is implemented as a struct ivpu_mmu_context, it has an ID,
>> drm_mm allocator for VPU addresses and struct ivpu_mmu_pgtable that
>> holds actual 3-level, 4KB page table.
>> Context with ID 0 (global context) is created upon driver initialization
>> and it's mainly used for mapping memory required to execute
>> the firmware.
>> Contexts with non-zero IDs are user contexts allocated each time
>> the devices is open()-ed and they map command buffers and other
>> workload-related memory.
>> Workloads executing in a given contexts have access only
>> to the memory mapped in this context.
>>
>> This patch is has to main files:
> This patch has two main files:
OK
>> - ivpu_mmu_context.c handles MMU page tables and memory mapping
>> - ivpu_mmu.c implements a driver that programs the MMU device
>>
>> Co-developed-by: Karol Wachowski
>> Signed-off-by: Karol Wachowski
>> Co-developed-by: Krystian Pradzynski
>> Signed-off-by: Krystian Pradzynski
>> Signed-off-by: Jacek Lawrynowicz
>> ---
>> drivers/accel/ivpu/Makefile | 4 +-
>> drivers/accel/ivpu/ivpu_drv.c | 83 ++-
>> drivers/accel/ivpu/ivpu_drv.h | 6 +
>> drivers/accel/ivpu/ivpu_hw_mtl.c | 10 +
>> drivers/accel/ivpu/ivpu_mmu.c | 875 ++
>> drivers/accel/ivpu/ivpu_mmu.h | 50 ++
>> drivers/accel/ivpu/ivpu_mmu_context.c | 385
>> drivers/accel/ivpu/ivpu_mmu_context.h | 49 ++
>> include/uapi/drm/ivpu_drm.h | 4 +
>> 9 files changed, 1463 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/accel/ivpu/ivpu_mmu.c
>> create mode 100644 drivers/accel/ivpu/ivpu_mmu.h
>> create mode 100644 drivers/accel/ivpu/ivpu_mmu_context.c
>> create mode 100644 drivers/accel/ivpu/ivpu_mmu_context.h
>>
>> diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
>> index 28330c04e52f..37b8bf1d3247 100644
>> --- a/drivers/accel/ivpu/Makefile
>> +++ b/drivers/accel/ivpu/Makefile
>> @@ -3,6 +3,8 @@
>>
>> intel_vpu-y := \
>> ivpu_drv.o \
>> - ivpu_hw_mtl.o
>> + ivpu_hw_mtl.o \
>> + ivpu_mmu.o \
>> + ivpu_mmu_context.o
>>
>> obj-$(CONFIG_DRM_ACCEL_IVPU) += intel_vpu.o
>> \ No newline at end of file
>> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
>> index 8fbccb8d888b..a22d41ca5a4b 100644
>> --- a/drivers/accel/ivpu/ivpu_drv.c
>> +++ b/drivers/accel/ivpu/ivpu_drv.c
>> @@ -15,6 +15,8 @@
>>
>> #include "ivpu_drv.h"
>> #include "ivpu_hw.h"
>> +#include "ivpu_mmu.h"
>> +#include "ivpu_mmu_context.h"
>>
>> #ifndef DRIVER_VERSION_STR
>> #define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
>> @@ -37,23 +39,38 @@ MODULE_PARM_DESC(pll_max_ratio, "Maximum PLL ratio used
>> to set VPU frequency");
>>
>> struct ivpu_file_priv *ivpu_file_priv_get(struct ivpu_file_priv *file_priv)
>> {
>> + struct ivpu_device *vdev = file_priv->vdev;
>> +
>> kref_get(&file_priv->ref);
>> +
>> + ivpu_dbg(vdev, KREF, "file_priv get: ctx %u refcount %u\n",
>> +file_priv->ctx.id, kref_read(&file_priv->ref));
>> +
>> return file_priv;
>> }
>>
>> static void file_priv_release(struct kref *ref)
>> {
>> struct ivpu_file_priv *file_priv = container_of(ref, struct
>> ivpu_file_priv, ref);
>> + struct ivpu_device *vdev = file_priv->vdev;
>>
>> + ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n",
>> file_priv->ctx.id);
>> +
>> + ivpu_mmu_user_context_fini(vdev, &file_priv->ctx);
>> + WARN_ON(xa_erase_irq(&vdev->context_xa, file_priv->ctx.id) !=
>> file_priv);
>> kfree(file_priv);
>> }
>>
>> void ivpu_file_priv_put(struct ivpu_file_priv **link)
>> {
>> struct ivpu_file_priv *file_priv = *link;
>> + struct ivpu_device *vdev = file_priv->vdev;
>>
>> WARN_ON(!file_priv);
>>
>> + ivpu_dbg(vdev, KREF, "file_priv put: ctx %u refcount %u\n",
>> +file_priv->ctx.id, kref_read(&file_priv->ref));
>> +
>> *link = NULL;
>> kref_put(&file_priv->ref, file_priv_release);
>> }
>> @@ -88,6 +105,9 @@ static int ivpu_get_param_ioctl(struct drm_device *dev,
>> void *data, struct drm_f
>> case DRM_IVPU_PARAM_CONTEXT_PRIORITY:
>> args->value = file_priv->priority;
>> break;
>> + case DRM_IVPU_PARAM_CONTEXT_ID:
>> + args->value = file_priv->ctx.id;
> Why is this needed ? Why does the user need to know its context ID ?
This is not really needed by the user space, we only use this as a debug
feature.
>> + break;
>> default:
>> ret = -EINVAL;
>>
Re: [PATCH v2] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On Sat, 17 Dec 2022 16:23:53 +0100, Johan Jonker wrote: > Convert rockchip-lvds.txt to YAML. > > Changed: > Add power-domains property. > Requirements between PX30 and RK3288 > > Signed-off-by: Johan Jonker > --- > > Changed V2: > Fix title > --- > .../display/rockchip/rockchip-lvds.txt| 92 -- > .../display/rockchip/rockchip-lvds.yaml | 157 ++ > 2 files changed, 157 insertions(+), 92 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): Documentation/devicetree/bindings/soc/rockchip/grf.yaml: Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/dea33013-ae1b-a8b2-5287-68a52f5ce...@gmail.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH] drm/meson: Reduce the FIFO lines held when AFBC is not used
On 19/12/2022 12:00, Martin Blumenstingl wrote: Hi Carlo, On Mon, Dec 19, 2022 at 9:43 AM Carlo Caione wrote: Having a bigger number of FIFO lines held after vsync is only useful to SoCs using AFBC to give time to the AFBC decoder to be reset, configured and enabled again. For SoCs not using AFBC this, on the contrary, is causing on some displays issues and a few pixels vertical offset in the displayed image. On the 32-bit SoCs (for which VPU support is not upstream yet) it has caused screen tearing instead of shifting the image. Conditionally increase the number of lines held after vsync only for SoCs using AFBC, leaving the default value for all the others. That was also my approach (for a not-yet-upstream patch). Since it's affecting already supported SoCs I suggest adding "Fixed-by: 24e0d4058eff ..." (maybe Neil can do so when he agrees and is applying the patch). Acked-by: Martin Blumenstingl Yep I'll add the Fixes tag when applying Thank Carlo ! Acked-by: Neil Armstrong
Re: [PATCH v4 0/2] Make ILI9486 driver working with 16-bits SPI controllers
Hi Kamlesh, On 19/12/2022 10:02, Carlo Caione wrote: This patchset is trying to fix problems seen on S905X boards when interfacing with an ILI9486 equipped SPI panel. I fully reviewed both patches, but I'd like a review from the maintainer, can you have a look ? Thanks, Neil To: Kamlesh Gurudasani To: David Airlie To: Daniel Vetter To: Mark Brown To: Neil Armstrong To: Kevin Hilman To: Jerome Brunet To: Martin Blumenstingl Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Signed-off-by: Carlo Caione --- Changes in v4: - Removed NAK-ed patch from patchset - Link to v3: https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v3-0-59c6b58cb...@baylibre.com Changes in v3: - Added trailers - Added new patch to use drm_aperture_remove_framebuffers() - Link to v2: https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v2-0-084c6e3cd...@baylibre.com Changes in v2: - Removed SPICC patch - Reworked commit message - Link to v1: https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v1-0-630401cb6...@baylibre.com --- Carlo Caione (2): drm/tiny: ili9486: Enable driver module autoloading drm/tiny: ili9486: Do not assume 8-bit only SPI controllers drivers/gpu/drm/tiny/ili9486.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) --- base-commit: 84e57d292203a45c96dbcb2e6be9dd80961d981a change-id: 20221116-s905x_spi_ili9486-aed54ff3cb21 Best regards,
Re: [PATCH] drm/panfrost: Fix GEM handle creation UAF
On 16/12/2022 23:33, Rob Clark wrote:
> From: Rob Clark
>
> Relying on an unreturned handle to hold a reference to an object we
> dereference is not safe. Userspace can guess the handle and race us
> by closing the handle from another thread. The _create_with_handle()
> that returns an object ptr is pretty much a pattern to avoid. And
> ideally creating the handle would be done after any needed dererencing.
> But in this case creation of the mapping is tied to the handle creation.
> Fortunately the mapping is refcnt'd and holds a reference to the object,
> so we can drop the handle's reference once we hold a mapping reference.
Thanks for spotting this, it's a small window but definitely a bug.
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +++
> drivers/gpu/drm/panfrost/panfrost_gem.c | 10 +++---
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 2fa5afe21288..aa5848de647c 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -98,6 +98,13 @@ static int panfrost_ioctl_create_bo(struct drm_device
> *dev, void *data,
> return PTR_ERR(bo);
>
> mapping = panfrost_gem_mapping_get(bo, priv);
> +
> + /*
> + * Now that the mapping holds a reference to the bo until we no longer
> + * need it, we can safely drop the handle's reference.
> + */
> + drm_gem_object_put(&bo->base.base);
> +
> if (!mapping) {
> drm_gem_object_put(&bo->base.base);
This !mapping call to drm_gem_object_put() is suspicious. It doesn't
make any sense and if it can be reached is going to drive the reference
count negative. So I don't think the bug is completely gone.
If user space does the trick of freeing the handle between the call to
panfrost_gem_create_with_handle() and panfrost_gem_mapping_get() then
even with the extra reference we now have the call to
panfrost_gem_mapping_get() will fail and two references are dropped.
I think the whole _create_with_handle() approach was a bad idea and it's
best to simply drop the _with_handle part. I'll post a patch tidying
this up along with removing the drm_gem_object_put() in the !mapping case.
Thanks,
Steve
> return -EINVAL;
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 293e799e2fe8..e3e21c500d24 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -234,6 +234,10 @@ struct drm_gem_object *panfrost_gem_create_object(struct
> drm_device *dev, size_t
> return &obj->base.base;
> }
>
> +/*
> + * NOTE: if this succeeds, both the handle and the returned object have
> + * an outstanding reference.
> + */
> struct panfrost_gem_object *
> panfrost_gem_create_with_handle(struct drm_file *file_priv,
> struct drm_device *dev, size_t size,
> @@ -261,10 +265,10 @@ panfrost_gem_create_with_handle(struct drm_file
> *file_priv,
>* and handle has the id what user can see.
>*/
> ret = drm_gem_handle_create(file_priv, &shmem->base, handle);
> - /* drop reference from allocate - handle holds it now. */
> - drm_gem_object_put(&shmem->base);
> - if (ret)
> + if (ret) {
> + drm_gem_object_put(&shmem->base);
> return ERR_PTR(ret);
> + }
>
> return bo;
> }
[PATCH] drm/panfrost: Fix GEM handle creation ref-counting
panfrost_gem_create_with_handle() previously returned a BO but with the
only reference being from the handle, which user space could in theory
guess and release, causing a use-after-free. Additionally if the call to
panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then
a(nother) reference on the BO was dropped.
The _create_with_handle() is a problematic pattern, so ditch it and
instead create the handle in panfrost_ioctl_create_bo(). If the call to
panfrost_gem_mapping_get() fails then this means that user space has
indeed gone behind our back and freed the handle. In which case just
return an error code.
Reported-by: Rob Clark
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 27 -
drivers/gpu/drm/panfrost/panfrost_gem.c | 16 +--
drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +
3 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index fa619fe72086..abb0dadd8f63 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -82,6 +82,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
struct panfrost_gem_mapping *mapping;
+ int ret;
if (!args->size || args->pad ||
(args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
@@ -92,21 +93,29 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
!(args->flags & PANFROST_BO_NOEXEC))
return -EINVAL;
- bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
-&args->handle);
+ bo = panfrost_gem_create(dev, args->size, args->flags);
if (IS_ERR(bo))
return PTR_ERR(bo);
+ ret = drm_gem_handle_create(file, &bo->base.base, &args->handle);
+ if (ret)
+ goto out;
+
mapping = panfrost_gem_mapping_get(bo, priv);
- if (!mapping) {
- drm_gem_object_put(&bo->base.base);
- return -EINVAL;
+ if (mapping) {
+ args->offset = mapping->mmnode.start << PAGE_SHIFT;
+ panfrost_gem_mapping_put(mapping);
+ } else {
+ /* This can only happen if the handle from
+* drm_gem_handle_create() has already been guessed and freed
+* by user space
+*/
+ ret = -EINVAL;
}
- args->offset = mapping->mmnode.start << PAGE_SHIFT;
- panfrost_gem_mapping_put(mapping);
-
- return 0;
+out:
+ drm_gem_object_put(&bo->base.base);
+ return ret;
}
/**
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 293e799e2fe8..3c812fbd126f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -235,12 +235,8 @@ struct drm_gem_object *panfrost_gem_create_object(struct
drm_device *dev, size_t
}
struct panfrost_gem_object *
-panfrost_gem_create_with_handle(struct drm_file *file_priv,
- struct drm_device *dev, size_t size,
- u32 flags,
- uint32_t *handle)
+panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags)
{
- int ret;
struct drm_gem_shmem_object *shmem;
struct panfrost_gem_object *bo;
@@ -256,16 +252,6 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,
bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
bo->is_heap = !!(flags & PANFROST_BO_HEAP);
- /*
-* Allocate an id of idr table where the obj is registered
-* and handle has the id what user can see.
-*/
- ret = drm_gem_handle_create(file_priv, &shmem->base, handle);
- /* drop reference from allocate - handle holds it now. */
- drm_gem_object_put(&shmem->base);
- if (ret)
- return ERR_PTR(ret);
-
return bo;
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index 8088d5fd8480..ad2877eeeccd 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -69,10 +69,7 @@ panfrost_gem_prime_import_sg_table(struct drm_device *dev,
struct sg_table *sgt);
struct panfrost_gem_object *
-panfrost_gem_create_with_handle(struct drm_file *file_priv,
- struct drm_device *dev, size_t size,
- u32 flags,
- uint32_t *handle);
+panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags);
int panfrost_gem_open(struct drm_gem_object *obj, struct
[PATCH] drm/amd/display: Remove the unused function dmub_outbox_irq_info_funcs
The function dmub_outbox_irq_info_funcs is defined in the
irq_service_dcn201.c file, but not called elsewhere, so remove this
unused function.
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:139:43:
warning: unused variable 'dmub_outbox_irq_info_funcs'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3520
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
.../gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
b/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
index 5f4f6dd79511..27dc8c9955f4 100644
--- a/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
+++ b/drivers/gpu/drm/amd/display/dc/irq/dcn201/irq_service_dcn201.c
@@ -136,11 +136,6 @@ static const struct irq_source_info_funcs
vupdate_no_lock_irq_info_funcs = {
.ack = NULL
};
-static const struct irq_source_info_funcs dmub_outbox_irq_info_funcs = {
- .set = NULL,
- .ack = NULL
-};
-
#undef BASE_INNER
#define BASE_INNER(seg) DMU_BASE__INST0_SEG ## seg
--
2.20.1.7.g153144c
Re: [PATCH v3] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On 12/19/22 14:04, Krzysztof Kozlowski wrote: > On 19/12/2022 13:32, Johan Jonker wrote: >> Convert rockchip-lvds.txt to YAML. >> >> Changed: >> Add power-domains property. >> Requirements between PX30 and RK3288 >> >> Signed-off-by: Johan Jonker >> --- >> >> Changed V3: >> Filename matching compatible style >> Drop "Regulator phandle for " >> Specify properties and requirements per SoC >> Sort order and restyle >> >> Changed V2: >> Fix title >> --- >> .../display/rockchip/rockchip,lvds.yaml | 170 ++ >> .../display/rockchip/rockchip-lvds.txt| 92 -- >> 2 files changed, 170 insertions(+), 92 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml >> delete mode 100644 >> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt >> >> diff --git >> a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml >> b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml >> new file mode 100644 >> index 0..03b002a05 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml >> @@ -0,0 +1,170 @@ >> +# SPDX-License-Identifier: GPL-2.0 >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Rockchip low-voltage differential signal (LVDS) transmitter >> + >> +maintainers: >> + - Sandy Huang >> + - Heiko Stuebner >> + >> +properties: >> + compatible: >> +enum: >> + - rockchip,px30-lvds >> + - rockchip,rk3288-lvds >> + >> + reg: >> +maxItems: 1 >> + >> + clocks: >> +maxItems: 1 >> + >> + clock-names: >> +const: pclk_lvds >> + >> + avdd1v0-supply: >> +description: 1.0V analog power. >> + >> + avdd1v8-supply: >> +description: 1.8V analog power. >> + >> + avdd3v3-supply: >> +description: 3.3V analog power. >> + >> + rockchip,grf: >> +$ref: /schemas/types.yaml#/definitions/phandle >> +description: Phandle to the general register files syscon. >> + >> + rockchip,output: >> +$ref: /schemas/types.yaml#/definitions/string >> +enum: [rgb, lvds, duallvds] >> +description: This describes the output interface. >> + >> + phys: >> +maxItems: 1 >> + >> + phy-names: >> +const: dphy >> + >> + pinctrl-names: >> +const: lcdc >> + >> + pinctrl-0: true >> + >> + power-domains: >> +maxItems: 1 >> + >> + ports: >> +$ref: /schemas/graph.yaml#/properties/ports >> + >> +properties: >> + port@0: >> +$ref: /schemas/graph.yaml#/properties/port >> +description: >> + Video port 0 for the VOP input. >> + The remote endpoint maybe vopb or vopl. >> + >> + port@1: >> +$ref: /schemas/graph.yaml#/properties/port >> +description: >> + Video port 1 for either a panel or subsequent encoder. >> + >> +required: >> + - port@0 >> + - port@1 >> + >> +required: >> + - compatible >> + - rockchip,grf >> + - rockchip,output >> + - ports >> + >> +allOf: >> + - if: >> + properties: >> +compatible: >> + contains: >> +const: rockchip,px30-lvds >> + >> +then: >> + properties: >> +reg: false >> +clocks: false >> +clock-names: false >> +avdd1v0-supply: false >> +avdd1v8-supply: false >> +avdd3v3-supply: false >> + > > I see one compatible expects regmap from parent (grf is the parent here) > and other is directly on MMIO bus. Not the best combination... Maybe > this should be just split to two separate bindings? Looking at driver, > their code is also very different between these two variants. Looking at the manufacturer tree we can expect the rest with grf parent, but also in the same driver combined with different registers and common probe. Due to common probe I prefer one common document. Johan === https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/gpu/drm/rockchip/rockchip_lvds.c#L671 rockchip,rk3126-lvds https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm/boot/dts/rk312x.dtsi#L914 rockchip,rk3368-lvds https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm64/boot/dts/rockchip/rk3368.dtsi#L1196 rockchip,rk3568-lvds https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3568.dtsi#L734 > > Best regards, > Krzysztof >
Re: [PATCH] drm: Replace DRM_INFO() with pr_info()
Hi
Am 19.12.22 um 15:23 schrieb Siddh Raman Pant:
Line 536 of drm_print.h says DRM_INFO() is deprecated
in favor of pr_info().
That's a misleading comment. DRM_INFO() is deprecated for drm_info().
pr_info() et al is only to be used of you don't have a dev pointer.
Best regards
Thomas
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 8
drivers/gpu/drm/drm_drv.c| 10 +-
drivers/gpu/drm/drm_edid_load.c | 14 +++---
drivers/gpu/drm/drm_pci.c| 2 +-
5 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..2e2891614c58 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -335,7 +335,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
- DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+ pr_info("[drm] kms: can't enable cloning when we probably wanted
to.\n");
return false;
}
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 61c29ce74b03..26a03b70e2c6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -165,14 +165,14 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
return;
if (mode->force) {
- DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+ pr_info("[drm] forcing %s connector %s\n", connector->name,
+ drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
- DRM_INFO("cmdline forces connector %s panel_orientation to
%d\n",
-connector->name, mode->panel_orientation);
+ pr_info("[drm] cmdline forces connector %s panel_orientation to
%d\n",
+ connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..1486df097908 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -898,11 +898,11 @@ int drm_dev_register(struct drm_device *dev, unsigned
long flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
- DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
-driver->name, driver->major, driver->minor,
-driver->patchlevel, driver->date,
-dev->dev ? dev_name(dev->dev) : "virtual device",
-dev->primary->index);
+ pr_info("[drm] Initialized %s %d.%d.%d %s for %s on minor %d\n",
+ driver->name, driver->major, driver->minor,
+ driver->patchlevel, driver->date,
+ dev->dev ? dev_name(dev->dev) : "virtual device",
+ dev->primary->index);
goto out_unlock;
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 37d8ba3ddb46..d3cb198380c5 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -242,9 +242,9 @@ static void *edid_load(struct drm_connector *connector,
const char *name,
u8 *new_edid;
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
- DRM_INFO("Found %d valid extensions instead of %d in EDID data "
- "\"%s\" for connector \"%s\"\n", valid_extensions,
- edid[0x7e], name, connector_name);
+ pr_info("[drm] Found %d valid extensions instead of %d in EDID data
"
+ "\"%s\" for connector \"%s\"\n", valid_extensions,
+ edid[0x7e], name, connector_name);
edid[0x7e] = valid_extensions;
new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
@@ -253,10 +253,10 @@ static void *edid_load(struct drm_connector *connector,
const char *name,
edid = new_edid;
}
- DRM_INFO("Got %s EDID base block and %d extension%s from "
- "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
- "external", valid_extensions, valid_extensions == 1 ? "" : "s",
- name, connector_name);
+ pr_info("[drm] Got %s EDID base block and %d extension%s from "
+ "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
+ "external", valid_extensions, valid_extensions == 1 ? "" : "s",
+ name, co
Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4
Quoting Tomi Valkeinen (2022-12-19 14:01:38)
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
s/Bumb/bump/
Reviewed-by: Kieran Bingham
> rcar_du_r8a779a0_info.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7799x_info = {
> };
>
> static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> - .gen = 3,
> + .gen = 4,
> .features = RCAR_DU_FEATURE_CRTC_IRQ
> | RCAR_DU_FEATURE_VSP1_SOURCE
> | RCAR_DU_FEATURE_NO_BLENDING,
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Do not cover all future platforms in TLB invalidation
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_gt.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 75a7cb33..854841a731cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1070,7 +1070,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
unsigned int num = 0;
unsigned long flags;
- if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
regs = NULL;
num = ARRAY_SIZE(xehp_regs);
} else if (GRAPHICS_VER(i915) == 12) {
[PATCH 02/18] Revert "fbcon: don't lose the console font across generic->chip driver switch"
This reverts commit ae1287865f5361fa138d4d3b1b6277908b54eac9.
Always free the console font when deinitializing the framebuffer
console. Subsequent framebuffer consoles will then use the default
font. Rely on userspace to load any user-configured font for these
consoles.
Commit ae1287865f53 ("fbcon: don't lose the console font across
generic->chip driver switch") was introduced to work around losing
the font during graphics-device handover. [1][2] It kept a dangling
pointer with the font data between loading the two consoles, which is
fairly adventurous hack. It also never covered cases when the other
consoles, such as VGA text mode, where involved.
The problem has meanwhile been solved in userspace. Systemd comes
with a udev rule that re-installs the configured font when a console
comes up. [3] So the kernel workaround can be removed.
This also removes one of the two special cases triggered by setting
FBINFO_MISC_FIRMWARE in an fbdev driver.
Tested during device handover from efifb and simpledrm to radeon. Udev
reloads the configured console font for the new driver's terminal.
Signed-off-by: Thomas Zimmermann
Link: https://bugzilla.redhat.com/show_bug.cgi?id=892340 # 1
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1074624 # 2
Link:
https://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/90-vconsole.rules.in?h=v222
# 3
---
drivers/video/fbdev/core/fbcon.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 500b26d652f6..90b36b3adfd0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -958,7 +958,7 @@ static const char *fbcon_startup(void)
set_blitting_type(vc, info);
/* Setup default font */
- if (!p->fontdata && !vc->vc_font.data) {
+ if (!p->fontdata) {
if (!fontname[0] || !(font = find_font(fontname)))
font = get_default_font(info->var.xres,
info->var.yres,
@@ -968,8 +968,6 @@ static const char *fbcon_startup(void)
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
vc->vc_font.charcount = font->charcount;
- } else {
- p->fontdata = vc->vc_font.data;
}
cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
@@ -1135,9 +1133,9 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->p = &fb_display[fg_console];
}
-static void fbcon_free_font(struct fbcon_display *p, bool freefont)
+static void fbcon_free_font(struct fbcon_display *p)
{
- if (freefont && p->userfont && p->fontdata && (--REFCOUNT(p->fontdata)
== 0))
+ if (p->userfont && p->fontdata && (--REFCOUNT(p->fontdata) == 0))
kfree(p->fontdata - FONT_EXTRA_WORDS * sizeof(int));
p->fontdata = NULL;
p->userfont = 0;
@@ -1172,8 +1170,8 @@ static void fbcon_deinit(struct vc_data *vc)
struct fb_info *info;
struct fbcon_ops *ops;
int idx;
- bool free_font = true;
+ fbcon_free_font(p);
idx = con2fb_map[vc->vc_num];
if (idx == -1)
@@ -1184,8 +1182,6 @@ static void fbcon_deinit(struct vc_data *vc)
if (!info)
goto finished;
- if (info->flags & FBINFO_MISC_FIRMWARE)
- free_font = false;
ops = info->fbcon_par;
if (!ops)
@@ -1197,9 +1193,8 @@ static void fbcon_deinit(struct vc_data *vc)
ops->initialized = false;
finished:
- fbcon_free_font(p, free_font);
- if (free_font)
- vc->vc_font.data = NULL;
+ fbcon_free_font(p);
+ vc->vc_font.data = NULL;
if (vc->vc_hi_font_mask && vc->vc_screenbuf)
set_vc_hi_font(vc, false);
--
2.39.0
[PATCH 04/18] drm/i915: Do not set struct fb_info.apertures
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in i915.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 03ed4607a46d..bbdb98d7c96e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -267,23 +267,16 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->fbops = &intelfb_ops;
- /* setup aperture base/size for vesafb takeover */
obj = intel_fb_obj(&intel_fb->base);
if (i915_gem_object_is_lmem(obj)) {
struct intel_memory_region *mem = obj->mm.region;
- info->apertures->ranges[0].base = mem->io_start;
- info->apertures->ranges[0].size = mem->io_size;
-
/* Use fbdev's framebuffer from lmem for discrete */
info->fix.smem_start =
(unsigned long)(mem->io_start +
i915_gem_object_get_dma_address(obj,
0));
info->fix.smem_len = obj->base.size;
} else {
- info->apertures->ranges[0].base = ggtt->gmadr.start;
- info->apertures->ranges[0].size = ggtt->mappable_end;
-
/* Our framebuffer is the entirety of fbdev's system memory */
info->fix.smem_start =
(unsigned long)(ggtt->gmadr.start +
i915_ggtt_offset(vma));
--
2.39.0
[PATCH 08/18] fbdev/hyperv-fb: Do not set struct fb_info.apertures
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in hyperv-fb.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/hyperv_fb.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index d8edb5635f77..1c7d6ff5a6c0 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -988,13 +988,10 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
struct pci_dev *pdev = NULL;
void __iomem *fb_virt;
int gen2vm = efi_enabled(EFI_BOOT);
+ resource_size_t base, size;
phys_addr_t paddr;
int ret;
- info->apertures = alloc_apertures(1);
- if (!info->apertures)
- return -ENOMEM;
-
if (!gen2vm) {
pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
@@ -1003,8 +1000,8 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
return -ENODEV;
}
- info->apertures->ranges[0].base = pci_resource_start(pdev, 0);
- info->apertures->ranges[0].size = pci_resource_len(pdev, 0);
+ base = pci_resource_start(pdev, 0);
+ size = pci_resource_len(pdev, 0);
/*
* For Gen 1 VM, we can directly use the contiguous memory
@@ -1027,8 +1024,8 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
}
pr_info("Unable to allocate enough contiguous physical memory
on Gen 1 VM. Using MMIO instead.\n");
} else {
- info->apertures->ranges[0].base = screen_info.lfb_base;
- info->apertures->ranges[0].size = screen_info.lfb_size;
+ base = screen_info.lfb_base;
+ size = screen_info.lfb_size;
}
/*
@@ -1070,9 +1067,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
fb_info *info)
info->screen_size = dio_fb_size;
getmem_done:
- aperture_remove_conflicting_devices(info->apertures->ranges[0].base,
- info->apertures->ranges[0].size,
- false, KBUILD_MODNAME);
+ aperture_remove_conflicting_devices(base, size, false, KBUILD_MODNAME);
if (gen2vm) {
/* framebuffer is reallocated, clear screen_info to avoid
misuse from kexec */
--
2.39.0
[PATCH 05/18] drm/radeon: Do not set struct fb_info.apertures
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in radeon.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_fb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index c1710ed1cab8..fe4087bfdb3c 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -277,10 +277,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
drm_fb_helper_fill_info(info, &rfbdev->helper, sizes);
- /* setup aperture base/size for vesafb takeover */
- info->apertures->ranges[0].base = rdev->mc.aper_base;
- info->apertures->ranges[0].size = rdev->mc.aper_size;
-
/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */
if (info->screen_base == NULL) {
--
2.39.0
[PATCH 11/18] fbdev/efifb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 694013f62781..a5779fb453a2 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -7,6 +7,7 @@
*
*/
+#include
#include
#include
#include
@@ -51,6 +52,8 @@ static struct pci_dev *efifb_pci_dev; /* dev with BAR
covering the efifb */
struct efifb_par {
u32 pseudo_palette[16];
+ resource_size_t base;
+ resource_size_t size;
};
static struct fb_var_screeninfo efifb_defined = {
@@ -253,6 +256,8 @@ static inline void efifb_show_boot_graphics(struct fb_info
*info) {}
*/
static void efifb_destroy(struct fb_info *info)
{
+ struct efifb_par *par = info->par;
+
if (efifb_pci_dev)
pm_runtime_put(&efifb_pci_dev->dev);
@@ -264,8 +269,7 @@ static void efifb_destroy(struct fb_info *info)
}
if (request_mem_succeeded)
- release_mem_region(info->apertures->ranges[0].base,
- info->apertures->ranges[0].size);
+ release_mem_region(par->base, par->size);
fb_dealloc_cmap(&info->cmap);
framebuffer_release(info);
@@ -461,13 +465,8 @@ static int efifb_probe(struct platform_device *dev)
par = info->par;
info->pseudo_palette = par->pseudo_palette;
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- err = -ENOMEM;
- goto err_release_fb;
- }
- info->apertures->ranges[0].base = efifb_fix.smem_start;
- info->apertures->ranges[0].size = size_remap;
+ par->base = efifb_fix.smem_start;
+ par->size = size_remap;
if (efi_enabled(EFI_MEMMAP) &&
!efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
@@ -556,7 +555,7 @@ static int efifb_probe(struct platform_device *dev)
info->fbops = &efifb_ops;
info->var = efifb_defined;
info->fix = efifb_fix;
- info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
+ info->flags = FBINFO_FLAG_DEFAULT;
orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
efifb_defined.yres);
@@ -589,6 +588,11 @@ static int efifb_probe(struct platform_device *dev)
if (efifb_pci_dev)
WARN_ON(pm_runtime_get_sync(&efifb_pci_dev->dev) < 0);
+ err = devm_aperture_acquire_for_platform_device(dev, par->base,
par->size);
+ if (err) {
+ pr_err("efifb: cannot acquire aperture\n");
+ goto err_put_rpm_ref;
+ }
err = register_framebuffer(info);
if (err < 0) {
pr_err("efifb: cannot register framebuffer\n");
--
2.39.0
[PATCH 18/18] drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE
There are no users left of struct fb_info.apertures and the flag
FBINFO_MISC_FIRMWARE. Remove both and the aperture-ownership code
in the fbdev core. All code for aperture ownership is now located
in the fbdev drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbmem.c | 33 --
drivers/video/fbdev/core/fbsysfs.c | 1 -
include/linux/fb.h | 22
3 files changed, 56 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 3a6c8458eb8d..02217c33d152 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -13,7 +13,6 @@
#include
-#include
#include
#include
#include
@@ -1653,32 +1652,6 @@ static void do_unregister_framebuffer(struct fb_info
*fb_info)
put_fb_info(fb_info);
}
-static int fb_aperture_acquire_for_platform_device(struct fb_info *fb_info)
-{
- struct apertures_struct *ap = fb_info->apertures;
- struct device *dev = fb_info->device;
- struct platform_device *pdev;
- unsigned int i;
- int ret;
-
- if (!ap)
- return 0;
-
- if (!dev_is_platform(dev))
- return 0;
-
- pdev = to_platform_device(dev);
-
- for (ret = 0, i = 0; i < ap->count; ++i) {
- ret = devm_aperture_acquire_for_platform_device(pdev,
ap->ranges[i].base,
-
ap->ranges[i].size);
- if (ret)
- break;
- }
-
- return ret;
-}
-
/**
* register_framebuffer - registers a frame buffer device
* @fb_info: frame buffer info structure
@@ -1693,12 +1666,6 @@ register_framebuffer(struct fb_info *fb_info)
{
int ret;
- if (fb_info->flags & FBINFO_MISC_FIRMWARE) {
- ret = fb_aperture_acquire_for_platform_device(fb_info);
- if (ret)
- return ret;
- }
-
mutex_lock(®istration_lock);
ret = do_register_framebuffer(fb_info);
mutex_unlock(®istration_lock);
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbsysfs.c
index 4d7f63892dcc..0c33c4adcd79 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -88,7 +88,6 @@ void framebuffer_release(struct fb_info *info)
mutex_destroy(&info->bl_curve_mutex);
#endif
- kfree(info->apertures);
kfree(info);
}
EXPORT_SYMBOL(framebuffer_release);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 96b96323e9cb..30183fd259ae 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -423,8 +423,6 @@ struct fb_tile_ops {
*/
#define FBINFO_MISC_ALWAYS_SETPAR 0x4
-/* where the fb is a firmware driver, and can be replaced with a proper one */
-#define FBINFO_MISC_FIRMWARE0x8
/*
* Host and GPU endianness differ.
*/
@@ -499,30 +497,10 @@ struct fb_info {
void *fbcon_par;/* fbcon use-only private area */
/* From here on everything is device dependent */
void *par;
- /* we need the PCI or similar aperture base/size not
- smem_start/size as smem_start may just be an object
- allocated inside the aperture so may not actually overlap */
- struct apertures_struct {
- unsigned int count;
- struct aperture {
- resource_size_t base;
- resource_size_t size;
- } ranges[0];
- } *apertures;
bool skip_vt_switch; /* no VT switch on suspend/resume required */
};
-static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
- struct apertures_struct *a;
-
- a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
- if (!a)
- return NULL;
- a->count = max_num;
- return a;
-}
-
#define FBINFO_FLAG_DEFAULTFBINFO_DEFAULT
/* This will go away
--
2.39.0
[PATCH 00/18] drm, fbdev: Remove apertures structure and FBINFO_MISC_FIRMWARE
Remove struct fb_info.apertures and FBINFO_MISC_FIRMWARE from fbdev and handle the aperture ownership without involving the fbdev core. The apertures field in struct fb_info is a remnant from earlier ownership management for framebuffer apertures. When fbdev core code still handled ownership of the framebuffer among fbdev device drivers, generic drivers set the aperture ranges to claim the firmware scanout buffer for themselves. Now that we have a module with helpers that manage aperture and framebuffer ownership among drivers, the aperture field is not needed any longer. In fact, several drivers set this field, even though they are not generic fbdev drivers. Only drivers that set FBINFO_MISC_FIRMWARE can use apertures in a meaningful way. To remove FBINFO_MISC_FIRMWARE, patches 1 and 2 remove it from fbcon. It was used to work around issues with font loading. That is now all handled in userspace. Patches 3 to 9 remove aperture setup from all non-generic drivers. These drivers are not for firmware graphics and do not have to set the values. For DRM, we do not need to allocate the apertures field any longer. Patches 10 to 17 update all generic fbdev drivers to manage aperture ownership by themselves by called Linux aperture helpers. The setup of the apertures field and setting FBINFO_MISC_FIRMWARE is being removed as a result of that. With all of its users gone, patch 18 removes FBINFO_MISC_FIRMWARE, struct fb_info.apertures and the fbdev core's aperture code. Tested with handover combinations of efifb, simpledrm and radeon. Thomas Zimmermann (18): fbcon: Remove trailing whitespaces Revert "fbcon: don't lose the console font across generic->chip driver switch" drm/gma500: Do not set struct fb_info.apertures drm/i915: Do not set struct fb_info.apertures drm/radeon: Do not set struct fb_info.apertures drm/fb-helper: Do not allocate unused apertures structure fbdev/clps711x-fb: Do not set struct fb_info.apertures fbdev/hyperv-fb: Do not set struct fb_info.apertures vfio-mdev/mdpy-fb: Do not set struct fb_info.apertures fbdev/efifb: Add struct efifb_par for driver data fbdev/efifb: Do not use struct fb_info.apertures fbdev/offb: Allocate struct offb_par with framebuffer_alloc() fbdev/offb: Do not use struct fb_info.apertures fbdev/simplefb: Do not use struct fb_info.apertures fbdev/vesafb: Remove trailing whitespaces fbdev/vesafb: Do not use struct fb_info.apertures fbdev/vga16fb: Do not use struct fb_info.apertures drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE drivers/gpu/drm/drm_fb_helper.c| 20 ++- drivers/gpu/drm/gma500/framebuffer.c | 5 --- drivers/gpu/drm/i915/display/intel_fbdev.c | 7 drivers/gpu/drm/radeon/radeon_fb.c | 4 --- drivers/video/fbdev/clps711x-fb.c | 10 +- drivers/video/fbdev/core/fbcon.c | 41 ++ drivers/video/fbdev/core/fbmem.c | 33 - drivers/video/fbdev/core/fbsysfs.c | 1 - drivers/video/fbdev/efifb.c| 35 +++--- drivers/video/fbdev/hyperv_fb.c| 17 - drivers/video/fbdev/offb.c | 33 + drivers/video/fbdev/simplefb.c | 19 +- drivers/video/fbdev/vesafb.c | 37 ++- drivers/video/fbdev/vga16fb.c | 15 +++- include/linux/fb.h | 22 samples/vfio-mdev/mdpy-fb.c| 8 - 16 files changed, 99 insertions(+), 208 deletions(-) base-commit: d322881f7e33af24901ee8ccaec3beef82f21203 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6 -- 2.39.0
[PATCH 14/18] fbdev/simplefb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/simplefb.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index e770b4a356b5..10d71879d340 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -12,6 +12,7 @@
* Copyright (C) 1996 Paul Mackerras
*/
+#include
#include
#include
#include
@@ -68,6 +69,8 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int
green, u_int blue,
struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
+ resource_size_t base;
+ resource_size_t size;
struct resource *mem;
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
bool clks_enabled;
@@ -472,16 +475,11 @@ static int simplefb_probe(struct platform_device *pdev)
info->var.blue = params.format->blue;
info->var.transp = params.format->transp;
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- ret = -ENOMEM;
- goto error_fb_release;
- }
- info->apertures->ranges[0].base = info->fix.smem_start;
- info->apertures->ranges[0].size = info->fix.smem_len;
+ par->base = info->fix.smem_start;
+ par->size = info->fix.smem_len;
info->fbops = &simplefb_ops;
- info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
+ info->flags = FBINFO_DEFAULT;
info->screen_base = ioremap_wc(info->fix.smem_start,
info->fix.smem_len);
if (!info->screen_base) {
@@ -511,6 +509,11 @@ static int simplefb_probe(struct platform_device *pdev)
if (mem != res)
par->mem = mem; /* release in clean-up handler */
+ ret = devm_aperture_acquire_for_platform_device(pdev, par->base,
par->size);
+ if (ret) {
+ dev_err(&pdev->dev, "Unable to acquire aperture: %d\n", ret);
+ goto error_regulators;
+ }
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
--
2.39.0
[PATCH 15/18] fbdev/vesafb: Remove trailing whitespaces
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/vesafb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index 929d4775cb4b..47ce244e4bb8 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -140,7 +140,7 @@ static int vesafb_setcolreg(unsigned regno, unsigned red,
unsigned green,
* (according to the entries in the `var' structure). Return
* != 0 for invalid regno.
*/
-
+
if (regno >= info->cmap.len)
return 1;
@@ -209,13 +209,13 @@ static struct fb_ops vesafb_ops = {
static int vesafb_setup(char *options)
{
char *this_opt;
-
+
if (!options || !*options)
return 0;
-
+
while ((this_opt = strsep(&options, ",")) != NULL) {
if (!*this_opt) continue;
-
+
if (! strcmp(this_opt, "inverse"))
inverse=1;
else if (! strcmp(this_opt, "redraw"))
@@ -381,7 +381,7 @@ static int vesafb_probe(struct platform_device *dev)
vesafb_defined.pixclock = 1000 / vesafb_defined.xres * 1000 /
vesafb_defined.yres;
vesafb_defined.left_margin = (vesafb_defined.xres / 8) & 0xf8;
vesafb_defined.hsync_len= (vesafb_defined.xres / 8) & 0xf8;
-
+
vesafb_defined.red.offset= screen_info.red_pos;
vesafb_defined.red.length= screen_info.red_size;
vesafb_defined.green.offset = screen_info.green_pos;
--
2.39.0
[PATCH 03/18] drm/gma500: Do not set struct fb_info.apertures
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in gma500.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 8d5a37b8f110..9e892a82e109 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -297,11 +297,6 @@ static int psbfb_create(struct drm_fb_helper *fb_helper,
info->screen_base = dev_priv->vram_addr + backing->offset;
info->screen_size = size;
- if (dev_priv->gtt.stolen_size) {
- info->apertures->ranges[0].base = dev_priv->fb_base;
- info->apertures->ranges[0].size = dev_priv->gtt.stolen_size;
- }
-
drm_fb_helper_fill_info(info, fb_helper, sizes);
info->fix.mmio_start = pci_resource_start(pdev, 0);
--
2.39.0
[PATCH 01/18] fbcon: Remove trailing whitespaces
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbcon.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c0143d38df83..500b26d652f6 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -26,7 +26,7 @@
*
* Hardware cursor support added by Emmanuel Marty (c...@ggi-project.org)
* Smart redraw scrolling, arbitrary font width support, 512char font support
- * and software scrollback added by
+ * and software scrollback added by
* Jakub Jelinek (j...@ultra.linux.cz)
*
* Random hacking by Martin Mares
@@ -127,7 +127,7 @@ static int logo_shown = FBCON_LOGO_CANSHOW;
/* console mappings */
static unsigned int first_fb_vc;
static unsigned int last_fb_vc = MAX_NR_CONSOLES - 1;
-static int fbcon_is_default = 1;
+static int fbcon_is_default = 1;
static int primary_device = -1;
static int fbcon_has_console_bind;
@@ -415,12 +415,12 @@ static int __init fb_console_setup(char *this_opt)
strscpy(fontname, options + 5, sizeof(fontname));
continue;
}
-
+
if (!strncmp(options, "scrollback:", 11)) {
pr_warn("Ignoring scrollback size option\n");
continue;
}
-
+
if (!strncmp(options, "map:", 4)) {
options += 4;
if (*options) {
@@ -446,7 +446,7 @@ static int __init fb_console_setup(char *this_opt)
last_fb_vc = simple_strtoul(options, &options,
10) - 1;
if (last_fb_vc < first_fb_vc || last_fb_vc >=
MAX_NR_CONSOLES)
last_fb_vc = MAX_NR_CONSOLES - 1;
- fbcon_is_default = 0;
+ fbcon_is_default = 0;
continue;
}
@@ -940,7 +940,7 @@ static const char *fbcon_startup(void)
info = fbcon_registered_fb[info_idx];
if (!info)
return NULL;
-
+
if (fbcon_open(info))
return NULL;
@@ -1999,7 +1999,7 @@ static void updatescrollmode(struct fbcon_display *p,
#define PITCH(w) (((w) + 7) >> 3)
#define CALC_FONTSZ(h, p, c) ((h) * (p) * (c)) /* size = height * pitch *
charcount */
-static int fbcon_resize(struct vc_data *vc, unsigned int width,
+static int fbcon_resize(struct vc_data *vc, unsigned int width,
unsigned int height, unsigned int user)
{
struct fb_info *info = fbcon_info_from_console(vc->vc_num);
@@ -2174,7 +2174,7 @@ static int fbcon_switch(struct vc_data *vc)
ops->update_start(info);
}
- fbcon_set_palette(vc, color_table);
+ fbcon_set_palette(vc, color_table);
fbcon_clear_margins(vc, 0);
if (logo_shown == FBCON_LOGO_DRAW) {
@@ -2343,7 +2343,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
vc->vc_complement_mask >>= 1;
vc->vc_s_complement_mask >>= 1;
}
-
+
/* ++Edmund: reorder the attribute bits */
if (vc->vc_can_do_color) {
unsigned short *cp =
@@ -2366,7 +2366,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
vc->vc_complement_mask <<= 1;
vc->vc_s_complement_mask <<= 1;
}
-
+
/* ++Edmund: reorder the attribute bits */
{
unsigned short *cp =
@@ -2527,7 +2527,7 @@ static int fbcon_set_font(struct vc_data *vc, struct
console_font *font,
/* Check if the same font is on some other console already */
for (i = first_fb_vc; i <= last_fb_vc; i++) {
struct vc_data *tmp = vc_cons[i].d;
-
+
if (fb_display[i].userfont &&
fb_display[i].fontdata &&
FNTSUM(fb_display[i].fontdata) == csum &&
@@ -3435,5 +3435,5 @@ void __exit fb_console_exit(void)
do_unregister_con_driver(&fb_con);
console_unlock();
-}
+}
#endif
--
2.39.0
[PATCH 16/18] fbdev/vesafb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/vesafb.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index 47ce244e4bb8..3f8bdfcf51f0 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -9,6 +9,7 @@
*
*/
+#include
#include
#include
#include
@@ -31,6 +32,8 @@
struct vesafb_par {
u32 pseudo_palette[256];
+ resource_size_t base;
+ resource_size_t size;
int wc_cookie;
struct resource *region;
};
@@ -191,7 +194,7 @@ static void vesafb_destroy(struct fb_info *info)
arch_phys_wc_del(par->wc_cookie);
if (info->screen_base)
iounmap(info->screen_base);
- release_mem_region(info->apertures->ranges[0].base,
info->apertures->ranges[0].size);
+ release_mem_region(par->base, par->size);
framebuffer_release(info);
}
@@ -316,14 +319,8 @@ static int vesafb_probe(struct platform_device *dev)
par = info->par;
info->pseudo_palette = par->pseudo_palette;
- /* set vesafb aperture size for generic probing */
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- err = -ENOMEM;
- goto err;
- }
- info->apertures->ranges[0].base = screen_info.lfb_base;
- info->apertures->ranges[0].size = size_total;
+ par->base = screen_info.lfb_base;
+ par->size = size_total;
printk(KERN_INFO "vesafb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
vesafb_defined.xres, vesafb_defined.yres,
vesafb_defined.bits_per_pixel, vesafb_fix.line_length, screen_info.pages);
@@ -460,27 +457,29 @@ static int vesafb_probe(struct platform_device *dev)
info->fbops = &vesafb_ops;
info->var = vesafb_defined;
info->fix = vesafb_fix;
- info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
- (ypan ? FBINFO_HWACCEL_YPAN : 0);
+ info->flags = FBINFO_FLAG_DEFAULT | (ypan ? FBINFO_HWACCEL_YPAN : 0);
if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
err = -ENOMEM;
goto err_release_region;
}
+ err = devm_aperture_acquire_for_platform_device(dev, par->base,
par->size);
+ if (err)
+ goto err_fb_dealloc_cmap;
if (register_framebuffer(info)<0) {
err = -EINVAL;
- fb_dealloc_cmap(&info->cmap);
- goto err_release_region;
+ goto err_fb_dealloc_cmap;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
return 0;
+err_fb_dealloc_cmap:
+ fb_dealloc_cmap(&info->cmap);
err_release_region:
arch_phys_wc_del(par->wc_cookie);
if (info->screen_base)
iounmap(info->screen_base);
if (par->region)
release_region(0x3c0, 32);
-err:
framebuffer_release(info);
release_mem_region(vesafb_fix.smem_start, size_total);
return err;
--
2.39.0
[PATCH 07/18] fbdev/clps711x-fb: Do not set struct fb_info.apertures
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in clps711x-fb.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/clps711x-fb.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/clps711x-fb.c
b/drivers/video/fbdev/clps711x-fb.c
index a1061c2f1640..45c75ff01eca 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -251,16 +251,8 @@ static int clps711x_fb_probe(struct platform_device *pdev)
goto out_fb_release;
}
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- ret = -ENOMEM;
- goto out_fb_release;
- }
-
cfb->buffsize = resource_size(res);
info->fix.smem_start = res->start;
- info->apertures->ranges[0].base = info->fix.smem_start;
- info->apertures->ranges[0].size = cfb->buffsize;
cfb->clk = devm_clk_get(dev, NULL);
if (IS_ERR(cfb->clk)) {
@@ -345,7 +337,7 @@ static int clps711x_fb_probe(struct platform_device *pdev)
&clps711x_lcd_ops);
if (!IS_ERR(lcd))
return 0;
-
+
ret = PTR_ERR(lcd);
unregister_framebuffer(info);
--
2.39.0
[PATCH 06/18] drm/fb-helper: Do not allocate unused apertures structure
The apertures field in struct fb_info is not used by DRM drivers. Do
not allocate it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3a731b9170a..e8a7e8be91d9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -473,8 +473,8 @@ EXPORT_SYMBOL(drm_fb_helper_init);
* drm_fb_helper_alloc_info - allocate fb_info and some of its members
* @fb_helper: driver-allocated fbdev helper
*
- * A helper to alloc fb_info and the members cmap and apertures. Called
- * by the driver within the fb_probe fb_helper callback function. Drivers do
not
+ * A helper to alloc fb_info and the member cmap. Called by the driver
+ * within the fb_probe fb_helper callback function. Drivers do not
* need to release the allocated fb_info structure themselves, this is
* automatically done when calling drm_fb_helper_fini().
*
@@ -496,27 +496,11 @@ struct fb_info *drm_fb_helper_alloc_info(struct
drm_fb_helper *fb_helper)
if (ret)
goto err_release;
- /*
-* TODO: We really should be smarter here and alloc an aperture
-* for each IORESOURCE_MEM resource helper->dev->dev has and also
-* init the ranges of the appertures based on the resources.
-* Note some drivers currently count on there being only 1 empty
-* aperture and fill this themselves, these will need to be dealt
-* with somehow when fixing this.
-*/
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- ret = -ENOMEM;
- goto err_free_cmap;
- }
-
fb_helper->info = info;
info->skip_vt_switch = true;
return info;
-err_free_cmap:
- fb_dealloc_cmap(&info->cmap);
err_release:
framebuffer_release(info);
return ERR_PTR(ret);
--
2.39.0
[PATCH 09/18] vfio-mdev/mdpy-fb: Do not set struct fb_info.apertures
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
not set the values in mdpy-fb.
Signed-off-by: Thomas Zimmermann
---
samples/vfio-mdev/mdpy-fb.c | 8
1 file changed, 8 deletions(-)
diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
index 9ec93d90e8a5..1de5801cd2e8 100644
--- a/samples/vfio-mdev/mdpy-fb.c
+++ b/samples/vfio-mdev/mdpy-fb.c
@@ -161,14 +161,6 @@ static int mdpy_fb_probe(struct pci_dev *pdev,
goto err_release_fb;
}
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- ret = -ENOMEM;
- goto err_unmap;
- }
- info->apertures->ranges[0].base = info->fix.smem_start;
- info->apertures->ranges[0].size = info->fix.smem_len;
-
info->fbops = &mdpy_fb_ops;
info->flags = FBINFO_DEFAULT;
info->pseudo_palette = par->palette;
--
2.39.0
[PATCH 17/18] fbdev/vga16fb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/vga16fb.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
index af47f8217095..1a8ffdb2be26 100644
--- a/drivers/video/fbdev/vga16fb.c
+++ b/drivers/video/fbdev/vga16fb.c
@@ -10,6 +10,7 @@
* archive for more details.
*/
+#include
#include
#include
#include
@@ -1324,11 +1325,6 @@ static int vga16fb_probe(struct platform_device *dev)
ret = -ENOMEM;
goto err_fb_alloc;
}
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- ret = -ENOMEM;
- goto err_ioremap;
- }
/* XXX share VGA_FB_PHYS_BASE and I/O region with vgacon and others */
info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS_BASE, 0);
@@ -1363,8 +1359,7 @@ static int vga16fb_probe(struct platform_device *dev)
info->fix = vga16fb_fix;
/* supports rectangles with widths of multiples of 8 */
info->pixmap.blit_x = 1 << 7 | 1 << 15 | 1 << 23 | 1 << 31;
- info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
- FBINFO_HWACCEL_YPAN;
+ info->flags = FBINFO_FLAG_DEFAULT | FBINFO_HWACCEL_YPAN;
i = (info->var.bits_per_pixel == 8) ? 256 : 16;
ret = fb_alloc_cmap(&info->cmap, i, 0);
@@ -1382,9 +1377,9 @@ static int vga16fb_probe(struct platform_device *dev)
vga16fb_update_fix(info);
- info->apertures->ranges[0].base = VGA_FB_PHYS_BASE;
- info->apertures->ranges[0].size = VGA_FB_PHYS_SIZE;
-
+ ret = devm_aperture_acquire_for_platform_device(dev, VGA_FB_PHYS_BASE,
VGA_FB_PHYS_SIZE);
+ if (ret)
+ goto err_check_var;
if (register_framebuffer(info) < 0) {
printk(KERN_ERR "vga16fb: unable to register framebuffer\n");
ret = -EINVAL;
--
2.39.0
[PATCH 12/18] fbdev/offb: Allocate struct offb_par with framebuffer_alloc()
Move the palette array into struct offb_par and allocate both via
framebuffer_alloc(), as intended by fbdev. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/offb.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 91001990e351..a298adcee2d9 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -53,10 +53,9 @@ struct offb_par {
volatile void __iomem *cmap_data;
int cmap_type;
int blanked;
+ u32 pseudo_palette[16];
};
-struct offb_par default_par;
-
#ifdef CONFIG_PPC32
extern boot_infos_t *boot_infos;
#endif
@@ -393,11 +392,11 @@ static void offb_init_fb(struct platform_device *parent,
const char *name,
int foreign_endian, struct device_node *dp)
{
unsigned long res_size = pitch * height;
- struct offb_par *par = &default_par;
unsigned long res_start = address;
struct fb_fix_screeninfo *fix;
struct fb_var_screeninfo *var;
struct fb_info *info;
+ struct offb_par *par;
if (!request_mem_region(res_start, res_size, "offb"))
return;
@@ -411,17 +410,15 @@ static void offb_init_fb(struct platform_device *parent,
const char *name,
return;
}
- info = framebuffer_alloc(sizeof(u32) * 16, &parent->dev);
-
+ info = framebuffer_alloc(sizeof(*par), &parent->dev);
if (!info) {
release_mem_region(res_start, res_size);
return;
}
platform_set_drvdata(parent, info);
-
+ par = info->par;
fix = &info->fix;
var = &info->var;
- info->par = par;
if (name) {
strcpy(fix->id, "OFfb ");
@@ -515,7 +512,7 @@ static void offb_init_fb(struct platform_device *parent,
const char *name,
info->fbops = &offb_ops;
info->screen_base = ioremap(address, fix->smem_len);
- info->pseudo_palette = (void *) (info + 1);
+ info->pseudo_palette = par->pseudo_palette;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
fb_alloc_cmap(&info->cmap, 256, 0);
--
2.39.0
[PATCH 10/18] fbdev/efifb: Add struct efifb_par for driver data
The efifb_par structure holds the palette for efifb. It will also
be useful for storing the device's aperture range.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 16c1aaae9afa..694013f62781 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -49,6 +49,10 @@ static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
static struct pci_dev *efifb_pci_dev; /* dev with BAR covering the efifb */
+struct efifb_par {
+ u32 pseudo_palette[16];
+};
+
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -351,6 +355,7 @@ static u64 bar_offset;
static int efifb_probe(struct platform_device *dev)
{
struct fb_info *info;
+ struct efifb_par *par;
int err, orientation;
unsigned int size_vmode;
unsigned int size_remap;
@@ -447,14 +452,14 @@ static int efifb_probe(struct platform_device *dev)
efifb_fix.smem_start);
}
- info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
+ info = framebuffer_alloc(sizeof(*par), &dev->dev);
if (!info) {
err = -ENOMEM;
goto err_release_mem;
}
platform_set_drvdata(dev, info);
- info->pseudo_palette = info->par;
- info->par = NULL;
+ par = info->par;
+ info->pseudo_palette = par->pseudo_palette;
info->apertures = alloc_apertures(1);
if (!info->apertures) {
--
2.39.0
[PATCH 13/18] fbdev/offb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux'
aperture helpers. Remove the use of struct fb_info.apertures and do
not set FBINFO_MISC_FIRMWARE; both of which previously configured
buffer ownership.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/offb.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index a298adcee2d9..f7ad6bc9d02d 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -12,6 +12,7 @@
* more details.
*/
+#include
#include
#include
#include
@@ -54,6 +55,8 @@ struct offb_par {
int cmap_type;
int blanked;
u32 pseudo_palette[16];
+ resource_size_t base;
+ resource_size_t size;
};
#ifdef CONFIG_PPC32
@@ -279,9 +282,11 @@ static int offb_set_par(struct fb_info *info)
static void offb_destroy(struct fb_info *info)
{
+ struct offb_par *par = info->par;
+
if (info->screen_base)
iounmap(info->screen_base);
- release_mem_region(info->apertures->ranges[0].base,
info->apertures->ranges[0].size);
+ release_mem_region(par->base, par->size);
fb_dealloc_cmap(&info->cmap);
framebuffer_release(info);
}
@@ -503,20 +508,18 @@ static void offb_init_fb(struct platform_device *parent,
const char *name,
var->sync = 0;
var->vmode = FB_VMODE_NONINTERLACED;
- /* set offb aperture size for generic probing */
- info->apertures = alloc_apertures(1);
- if (!info->apertures)
- goto out_aper;
- info->apertures->ranges[0].base = address;
- info->apertures->ranges[0].size = fix->smem_len;
+ par->base = address;
+ par->size = fix->smem_len;
info->fbops = &offb_ops;
info->screen_base = ioremap(address, fix->smem_len);
info->pseudo_palette = par->pseudo_palette;
- info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
+ info->flags = FBINFO_DEFAULT | foreign_endian;
fb_alloc_cmap(&info->cmap, 256, 0);
+ if (devm_aperture_acquire_for_platform_device(parent, par->base,
par->size) < 0)
+ goto out_err;
if (register_framebuffer(info) < 0)
goto out_err;
@@ -526,7 +529,6 @@ static void offb_init_fb(struct platform_device *parent,
const char *name,
out_err:
fb_dealloc_cmap(&info->cmap);
iounmap(info->screen_base);
-out_aper:
iounmap(par->cmap_adr);
par->cmap_adr = NULL;
framebuffer_release(info);
--
2.39.0
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
corresponding
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.
v2:
* Fail engine probe if TLB invlidations registers are unknown.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
Cc: Matt Roper
Reviewed-by: Andrzej Hajda # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 93 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 15 +++
drivers/gpu/drm/i915/gt/intel_gt.c | 135 +++
3 files changed, 128 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN8_VTCR,
+ [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+ };
+ static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+ [RENDER_CLASS].reg = GEN12_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].reg = GEN12_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+ };
+ static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+ [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+ [VIDEO_DECODE_CLASS].mcr_reg = XEHP_VD_TLB_INV_CR,
+ [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+ [COPY_ENGINE_CLASS].mcr_reg = XEHP_BLT_TLB_INV_CR,
+ [COMPUTE_CLASS].mcr_reg = XEHP_COMPCTX_TLB_INV_CR,
+ };
+ struct drm_i915_private *i915 = engine->i915;
+ const union intel_engine_tlb_inv_reg *regs;
+ union intel_engine_tlb_inv_reg reg;
+ unsigned int class = engine->class;
+ unsigned int num = 0;
+ u32 val;
+
+ /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
+ regs = xehp_regs;
+ num = ARRAY_SIZE(xehp_regs);
+ } else if (GRAPHICS_VER(i915) == 12) {
+ regs = gen12_regs;
+ num = ARRAY_SIZE(gen12_regs);
+ } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
+ regs = gen8_regs;
+ num = ARRAY_SIZE(gen8_regs);
+ } else if (GRAPHICS_VER(i915) < 8) {
+ return 0;
+ } > +
+ if (drm_WARN_ONCE(&i915->drm, !num,
+ "Platform does not implement TLB invalidation!"))
+ return -ENODEV;
+
+ if (drm_WARN_ON_ONCE(&i915->drm,
+class >= num ||
+(!regs[class].reg.reg &&
+ !regs[class].mcr_reg.reg)))
+ return -ERANGE;
I hope the propagation of -ERANGE to device probe is OK.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
+
+ reg = regs[class];
+
+ if (GRAPHICS_VER(i915) == 8 && class == VIDEO_DECODE_CLASS) {
+ reg.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
+ val = 0;
+ } else {
+ val = engine->instance;
+ }
+
+ val = BIT(val);
+
+ engine->tlb_inv.mcr = regs == xehp_regs;
+ engine->tlb_inv.reg = reg;
+ engine->tlb_inv.done = val;
+
+ if (GRAPHICS_VER(i915) >= 12 &&
+ (engine->class == VIDEO_DECODE_CLASS ||
+engine->class == VIDEO_ENHANCEMENT_CLASS ||
+engine->class == COMPUTE_CLASS))
+ engine->tlb_inv.request = _MASKED_BIT_ENABLE(val);
+ else
+ engine->tlb_inv.request = val;
+
+
Re: [PATCH v3 10/11] arm64: dts: qcom: sm8350-hdk: Enable display & dsi nodes
On Mon, 5 Dec 2022 at 17:44, Dmitry Baryshkov
wrote:
>
> On 05/12/2022 18:37, Robert Foss wrote:
> > Enable the display subsystem and the dsi0 output for
> > the sm8350-hdk board.
> >
> > Signed-off-by: Robert Foss
> > ---
> > arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > index e6deb08c6da0..39462c659c58 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > +++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> > @@ -213,10 +213,32 @@ &cdsp {
> > firmware-name = "qcom/sm8350/cdsp.mbn";
> > };
> >
> > +&dispcc {
> > + status = "okay";
> > +};
> > +
> > +&dsi0 {
>
> Bjorn suggested using mdss_dsi0 / mdss_dsi0_phy labels for DSI host and
> PHY, as it allows us to group them nicely. WDYT?
Sounds quite reasonable, fixing it in dts/dtsi/binding.
>
> > + vdda-supply = <&vreg_l6b_1p2>;
> > + status = "okay";
> > +};
> > +
> > +&dsi0_phy {
> > + vdds-supply = <&vreg_l5b_0p88>;
> > + status = "okay";
> > +};
> > +
> > &gpi_dma1 {
> > status = "okay";
> > };
> >
> > +&mdss {
> > + status = "okay";
> > +};
> > +
> > +&mdss_mdp {
> > + status = "okay";
> > +};
> > +
> > &mpss {
> > status = "okay";
> > firmware-name = "qcom/sm8350/modem.mbn";
>
> --
> With best wishes
> Dmitry
>
Re: [PATCH] drm: Replace DRM_INFO() with pr_info()
Hi Am 19.12.22 um 16:34 schrieb Siddh Raman Pant: On Mon, 19 Dec 2022 20:27:45 +0530, Thomas Zimmermann wrote: Hi Am 19.12.22 um 15:23 schrieb Siddh Raman Pant: Line 536 of drm_print.h says DRM_INFO() is deprecated in favor of pr_info(). That's a misleading comment. DRM_INFO() is deprecated for drm_info(). pr_info() et al is only to be used of you don't have a dev pointer. Best regards Thomas Maybe you are confusing it with DRM_DEV_INFO? It takes the dev pointer, and is indeed told to be deprecated in favour of drm_info() in the comments (see line 394). DRM_INFO is a separate macro for printing stuff, and does not take the dev pointer. They seem to be early wrappers for printk, I guess when pr_info did not exist. And all they do different from pr_info is to add DRM_NAME (which seems to be just "drm") in front of the string. The DRM_ print macros in capital letters are deprecated AFAIK. In cases where a dev pointer is available, using drm_info() et al. is preferred over pr_info(). In the context of your patch, you should use drm_info() in drm_client_target_cloned(), as is gets a dev pointer as its first argument. In most the other cases from your patch, you can get the dev pointer from connector->dev. The final case, drm_legacy_pci_exit(), there's no dev pointer, so you can use pr_info() there. I'd remove '[drm]' from the string. We don't use this much elsewhere. Best regards Thomas Thanks, Siddh -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3 08/11] arm64: dts: qcom: sm8350: Use 2 interconnect cells
On Mon, 5 Dec 2022 at 20:19, Georgi Djakov wrote:
>
> Hi Robert,
>
> On 5.12.22 18:37, Robert Foss wrote:
> > Use two interconnect cells in order to optionally
> > support a path tag.
> >
> > Signed-off-by: Robert Foss
> > Reviewed-by: Konrad Dybcio
> > ---
> > arch/arm64/boot/dts/qcom/sm8350.dtsi | 28 ++--
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > index 805d53d91952..434f8e8b12c1 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> > @@ -1543,56 +1543,56 @@ apps_smmu: iommu@1500 {
> > config_noc: interconnect@150 {
> > compatible = "qcom,sm8350-config-noc";
> > reg = <0 0x0150 0 0xa580>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> > qcom,bcm-voters = <&apps_bcm_voter>;
> > };
> >
> > mc_virt: interconnect@158 {
> > compatible = "qcom,sm8350-mc-virt";
> > reg = <0 0x0158 0 0x1000>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> > qcom,bcm-voters = <&apps_bcm_voter>;
> > };
> [..]
> > @@ -1620,8 +1620,8 @@ ipa: ipa@1e4 {
> > clocks = <&rpmhcc RPMH_IPA_CLK>;
> > clock-names = "core";
> >
> > - interconnects = <&aggre2_noc MASTER_IPA &mc_virt
> > SLAVE_EBI1>,
> > - <&gem_noc MASTER_APPSS_PROC
> > &config_noc SLAVE_IPA_CFG>;
> > + interconnects = <&aggre2_noc MASTER_IPA 0 &mc_virt
> > SLAVE_EBI1 0>,
> > + <&gem_noc MASTER_APPSS_PROC 0
> > &config_noc SLAVE_IPA_CFG 0>;
> > interconnect-names = "memory",
> >"config";
> >
> > @@ -1661,7 +1661,7 @@ mpss: remoteproc@408 {
> > <&rpmhpd SM8350_MSS>;
> > power-domain-names = "cx", "mss";
> >
> > - interconnects = <&mc_virt MASTER_LLCC &mc_virt
> > SLAVE_EBI1>;
> > + interconnects = <&mc_virt MASTER_LLCC &mc_virt
> > SLAVE_EBI1 0>;
>
> The second cell for the first endpoint is missing, so this should be:
> interconnects = <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>;
Nice catch, thanks!
>
> Thanks,
> Georgi
>
> >
> > memory-region = <&pil_modem_mem>;
> >
> > @@ -2239,7 +2239,7 @@ cdsp: remoteproc@9890 {
> > <&rpmhpd SM8350_MXC>;
> > power-domain-names = "cx", "mxc";
> >
> > - interconnects = <&compute_noc MASTER_CDSP_PROC
> > &mc_virt SLAVE_EBI1>;
> > + interconnects = <&compute_noc MASTER_CDSP_PROC 0
> > &mc_virt SLAVE_EBI1 0>;
> >
> > memory-region = <&pil_cdsp_mem>;
> >
> > @@ -2421,14 +2421,14 @@ usb_2_ssphy: phy@88ebe00 {
> > dc_noc: interconnect@90c {
> > compatible = "qcom,sm8350-dc-noc";
> > reg = <0 0x090c 0 0x4200>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> > qcom,bcm-voters = <&apps_bcm_voter>;
> > };
> >
> > gem_noc: interconnect@910 {
> > compatible = "qcom,sm8350-gem-noc";
> > reg = <0 0x0910 0 0xb4000>;
> > - #interconnect-cells = <1>;
> > + #interconnect-cells = <2>;
> > qcom,bcm-voters = <&apps_bcm_voter>;
> > };
> >
>
Re: [PATCH v3 05/11] drm/msm: Add support for SM8350
On Thu, 8 Dec 2022 at 00:50, Dmitry Baryshkov
wrote:
>
> On 05/12/2022 18:37, Robert Foss wrote:
> > Add compatibles string, "qcom,sm8350-mdss", for the multimedia display
> > subsystem unit used on Qualcomm SM8350 platform.
> >
> > Signed-off-by: Robert Foss
> > ---
> > drivers/gpu/drm/msm/msm_mdss.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> > index a2264fb517a1..39746b972cdd 100644
> > --- a/drivers/gpu/drm/msm/msm_mdss.c
> > +++ b/drivers/gpu/drm/msm/msm_mdss.c
> > @@ -293,6 +293,9 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
> > /* UBWC_2_0 */
> > msm_mdss_setup_ubwc_dec_20(msm_mdss, 0x1e);
> > break;
> > + case DPU_HW_VER_700:
> > + msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_4_0, 6, 1, 1, 1);
> > + break;
>
> Judging from the vendor kernel, the highest_rank_bit is 3, with usual
> todo for 2 for LP_DDR4.
Thanks! Will fix.
>
> > case DPU_HW_VER_720:
> > msm_mdss_setup_ubwc_dec_40(msm_mdss, UBWC_3_0, 6, 1, 1, 1);
> > break;
> > @@ -530,6 +533,7 @@ static const struct of_device_id mdss_dt_match[] = {
> > { .compatible = "qcom,sc8180x-mdss" },
> > { .compatible = "qcom,sm8150-mdss" },
> > { .compatible = "qcom,sm8250-mdss" },
> > + { .compatible = "qcom,sm8350-mdss" },
> > { .compatible = "qcom,sm8450-mdss" },
> > {}
> > };
>
> --
> With best wishes
> Dmitry
>
[PATCH v4 1/5] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
Convert rockchip-lvds.txt to YAML.
Changed:
Add power-domains property.
Requirements between PX30 and RK3288
Signed-off-by: Johan Jonker
---
Changed V3:
Filename matching compatible style
Drop "Regulator phandle for "
Specify properties and requirements per SoC
Sort order and restyle
Changed V2:
Fix title
---
.../display/rockchip/rockchip,lvds.yaml | 170 ++
.../display/rockchip/rockchip-lvds.txt| 92 --
2 files changed, 170 insertions(+), 92 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
new file mode 100644
index 0..03b002a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
@@ -0,0 +1,170 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip low-voltage differential signal (LVDS) transmitter
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+enum:
+ - rockchip,px30-lvds
+ - rockchip,rk3288-lvds
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: pclk_lvds
+
+ avdd1v0-supply:
+description: 1.0V analog power.
+
+ avdd1v8-supply:
+description: 1.8V analog power.
+
+ avdd3v3-supply:
+description: 3.3V analog power.
+
+ rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: Phandle to the general register files syscon.
+
+ rockchip,output:
+$ref: /schemas/types.yaml#/definitions/string
+enum: [rgb, lvds, duallvds]
+description: This describes the output interface.
+
+ phys:
+maxItems: 1
+
+ phy-names:
+const: dphy
+
+ pinctrl-names:
+const: lcdc
+
+ pinctrl-0: true
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Video port 0 for the VOP input.
+ The remote endpoint maybe vopb or vopl.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Video port 1 for either a panel or subsequent encoder.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - rockchip,grf
+ - rockchip,output
+ - ports
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: rockchip,px30-lvds
+
+then:
+ properties:
+reg: false
+clocks: false
+clock-names: false
+avdd1v0-supply: false
+avdd1v8-supply: false
+avdd3v3-supply: false
+
+ required:
+- phys
+- phy-names
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: rockchip,rk3288-lvds
+
+then:
+ properties:
+phys: false
+phy-names: false
+
+ required:
+- reg
+- clocks
+- clock-names
+- avdd1v0-supply
+- avdd1v8-supply
+- avdd3v3-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+lvds: lvds@ff96c000 {
+ compatible = "rockchip,rk3288-lvds";
+ reg = <0xff96c000 0x4000>;
+ clocks = <&cru PCLK_LVDS_PHY>;
+ clock-names = "pclk_lvds";
+ avdd1v0-supply = <&vdd10_lcd>;
+ avdd1v8-supply = <&vcc18_lcd>;
+ avdd3v3-supply = <&vcca_33>;
+ pinctrl-names = "lcdc";
+ pinctrl-0 = <&lcdc_ctl>;
+ rockchip,grf = <&grf>;
+ rockchip,output = "rgb";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lvds_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in_vopb: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&vopb_out_lvds>;
+ };
+ lvds_in_vopl: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&vopl_out_lvds>;
+ };
+};
+
+lvds_out: port@1 {
+ reg = <1>;
+
+ lvds_out_panel: endpoint {
+remote-endpoint = <&panel_in_lvds>;
+ };
+};
+ };
+};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
deleted file mode 100644
index aaf8c44cf..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Rockchip RK3288 LVDS interface
-
-
-Required properties:
-- compatible: matching the soc type, one of
- - "rockchip,rk32
[PATCH v4 2/5] dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml
Add new converted rockchip,lvds.yaml to grf.yaml file. Prepare for more SoCs with lvds output. Signed-off-by: Johan Jonker --- .../devicetree/bindings/soc/rockchip/grf.yaml | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 2ed8cca79..d74295e98 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -75,13 +75,17 @@ allOf: properties: compatible: contains: -const: rockchip,px30-grf +enum: + - rockchip,px30-grf then: properties: lvds: - description: - Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt + type: object + + $ref: "/schemas/display/rockchip/rockchip,lvds.yaml#" + + unevaluatedProperties: false - if: properties: -- 2.20.1
[PATCH v4 3/5] dt-bindings: phy: add port node to phy-rockchip-inno-usb2.yaml
On Rockchip rk3399 a port node with one endpoint can be connected to a USB Type-C connector node. Add a port node to the phy-rockchip-inno-usb2.yaml file. Signed-off-by: Johan Jonker --- .../devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml index f71920082..ffc7e7560 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml @@ -115,6 +115,11 @@ properties: required: - "#phy-cells" + port: +$ref: /schemas/graph.yaml#/properties/port +description: + Port node with one endpoint connected to a USB Type-C connector node. + required: - compatible - reg -- 2.20.1
[PATCH v4 4/5] ARM: dts: rockchip: rk3288: add lvds_out node
With the conversion of rockchip,lvds.yaml a port@1 node
is required, so add a node with label lvds_out.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3288.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 487b0e03d..60207136f 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1170,6 +1170,10 @@
remote-endpoint = <&vopl_out_lvds>;
};
};
+
+ lvds_out: port@1 {
+ reg = <1>;
+ };
};
};
--
2.20.1
[PATCH v4 5/5] arm64: dts: rockchip: px30: add lvds_out node
With the conversion of rockchip,lvds.yaml a port@1 node
is required, so add a node with label lvds_out.
Signed-off-by: Johan Jonker
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index bfa358042..eb414d0f8 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -468,6 +468,10 @@
remote-endpoint =
<&vopl_out_lvds>;
};
};
+
+ lvds_out: port@1 {
+ reg = <1>;
+ };
};
};
};
--
2.20.1
Re: [PATCH] drm/panfrost: Fix GEM handle creation ref-counting
On Mon, Dec 19, 2022 at 6:02 AM Steven Price wrote:
>
> panfrost_gem_create_with_handle() previously returned a BO but with the
> only reference being from the handle, which user space could in theory
> guess and release, causing a use-after-free. Additionally if the call to
> panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then
> a(nother) reference on the BO was dropped.
>
> The _create_with_handle() is a problematic pattern, so ditch it and
> instead create the handle in panfrost_ioctl_create_bo(). If the call to
> panfrost_gem_mapping_get() fails then this means that user space has
> indeed gone behind our back and freed the handle. In which case just
> return an error code.
>
> Reported-by: Rob Clark
Yeah, I like getting rid of the _create_with_handle() pattern, the
only place where that pattern works is if you immediately return the
handle to userspace (and don't otherwise touch the obj)
Reviewed-by: Rob Clark
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 27 -
> drivers/gpu/drm/panfrost/panfrost_gem.c | 16 +--
> drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +
> 3 files changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index fa619fe72086..abb0dadd8f63 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -82,6 +82,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
> void *data,
> struct panfrost_gem_object *bo;
> struct drm_panfrost_create_bo *args = data;
> struct panfrost_gem_mapping *mapping;
> + int ret;
>
> if (!args->size || args->pad ||
> (args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
> @@ -92,21 +93,29 @@ static int panfrost_ioctl_create_bo(struct drm_device
> *dev, void *data,
> !(args->flags & PANFROST_BO_NOEXEC))
> return -EINVAL;
>
> - bo = panfrost_gem_create_with_handle(file, dev, args->size,
> args->flags,
> -&args->handle);
> + bo = panfrost_gem_create(dev, args->size, args->flags);
> if (IS_ERR(bo))
> return PTR_ERR(bo);
>
> + ret = drm_gem_handle_create(file, &bo->base.base, &args->handle);
> + if (ret)
> + goto out;
> +
> mapping = panfrost_gem_mapping_get(bo, priv);
> - if (!mapping) {
> - drm_gem_object_put(&bo->base.base);
> - return -EINVAL;
> + if (mapping) {
> + args->offset = mapping->mmnode.start << PAGE_SHIFT;
> + panfrost_gem_mapping_put(mapping);
> + } else {
> + /* This can only happen if the handle from
> +* drm_gem_handle_create() has already been guessed and freed
> +* by user space
> +*/
> + ret = -EINVAL;
> }
>
> - args->offset = mapping->mmnode.start << PAGE_SHIFT;
> - panfrost_gem_mapping_put(mapping);
> -
> - return 0;
> +out:
> + drm_gem_object_put(&bo->base.base);
> + return ret;
> }
>
> /**
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 293e799e2fe8..3c812fbd126f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -235,12 +235,8 @@ struct drm_gem_object *panfrost_gem_create_object(struct
> drm_device *dev, size_t
> }
>
> struct panfrost_gem_object *
> -panfrost_gem_create_with_handle(struct drm_file *file_priv,
> - struct drm_device *dev, size_t size,
> - u32 flags,
> - uint32_t *handle)
> +panfrost_gem_create(struct drm_device *dev, size_t size, u32 flags)
> {
> - int ret;
> struct drm_gem_shmem_object *shmem;
> struct panfrost_gem_object *bo;
>
> @@ -256,16 +252,6 @@ panfrost_gem_create_with_handle(struct drm_file
> *file_priv,
> bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
> bo->is_heap = !!(flags & PANFROST_BO_HEAP);
>
> - /*
> -* Allocate an id of idr table where the obj is registered
> -* and handle has the id what user can see.
> -*/
> - ret = drm_gem_handle_create(file_priv, &shmem->base, handle);
> - /* drop reference from allocate - handle holds it now. */
> - drm_gem_object_put(&shmem->base);
> - if (ret)
> - return ERR_PTR(ret);
> -
> return bo;
> }
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
> b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index 8088d5fd8480..ad2877eeeccd 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -69,10 +69,7 @@ panfros
[PATCH] drm/drv: Make use of local variable driver in drm_dev_register()
There is a local variable that contains dev->driver. Make use of it
instead of "open coding" it.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 203bf8d6c34c..3cc8e8111d16 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -889,8 +889,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
dev->registered = true;
- if (dev->driver->load) {
- ret = dev->driver->load(dev, flags);
+ if (driver->load) {
+ ret = driver->load(dev, flags);
if (ret)
goto err_minors;
}
base-commit: 678e5b2258e871b22fe8c26edac2723feb852a47
--
2.38.1
Re: [PATCH v2 1/7] media: Add 2-10-10-10 RGB formats
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:33PM +0200, Tomi Valkeinen wrote:
> Add XBGR2101010, ABGR2101010 and BGRA1010102 formats.
>
> Signed-off-by: Tomi Valkeinen
> ---
> .../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
> include/uapi/linux/videodev2.h| 3 +
> 3 files changed, 200 insertions(+)
>
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> index 30f51cd33f99..de78cd2dcd73 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> @@ -763,6 +763,200 @@ nomenclature that instead use the order of components
> as seen in a 24- or
> \normalsize
>
>
> +10 Bits Per Component
> +=
> +
> +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four
> +bytes. They are named based on the order of the RGB components as seen in a
> +32-bit word, which is then stored in memory in little endian byte order
> +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on
> the
> +number of bits for each component.
> +
> +.. raw:: latex
> +
> +\begingroup
> +\tiny
> +\setlength{\tabcolsep}{2pt}
> +
> +.. tabularcolumns::
> |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
> +
> +
> +.. flat-table:: RGB Formats 10 Bits Per Color Component
> +:header-rows: 2
> +:stub-columns: 0
> +
> +* - Identifier
> + - Code
> + - :cspan:`7` Byte 0 in memory
> + - :cspan:`7` Byte 1
> + - :cspan:`7` Byte 2
> + - :cspan:`7` Byte 3
> +* -
> + -
> + - 7
> + - 6
> + - 5
> + - 4
> + - 3
> + - 2
> + - 1
> + - 0
> +
> + - 7
> + - 6
> + - 5
> + - 4
> + - 3
> + - 2
> + - 1
> + - 0
> +
> + - 7
> + - 6
> + - 5
> + - 4
> + - 3
> + - 2
> + - 1
> + - 0
> +
> + - 7
> + - 6
> + - 5
> + - 4
> + - 3
> + - 2
> + - 1
> + - 0
> +* .. _V4L2-PIX-FMT-XBGR2101010:
> +
> + - ``V4L2_PIX_FMT_XBGR2101010``
> + - 'RX30'
> +
> + - b\ :sub:`5`
> + - b\ :sub:`4`
> + - b\ :sub:`3`
> + - b\ :sub:`2`
> + - b\ :sub:`1`
> + - b\ :sub:`0`
> + - x
> + - x
> +
> + - g\ :sub:`3`
> + - g\ :sub:`2`
> + - g\ :sub:`1`
> + - g\ :sub:`0`
> + - b\ :sub:`9`
> + - b\ :sub:`8`
> + - b\ :sub:`7`
> + - b\ :sub:`6`
> +
> + - r\ :sub:`1`
> + - r\ :sub:`0`
> + - g\ :sub:`9`
> + - g\ :sub:`8`
> + - g\ :sub:`7`
> + - g\ :sub:`6`
> + - g\ :sub:`5`
> + - g\ :sub:`4`
> +
> + - r\ :sub:`9`
> + - r\ :sub:`8`
> + - r\ :sub:`7`
> + - r\ :sub:`6`
> + - r\ :sub:`5`
> + - r\ :sub:`4`
> + - r\ :sub:`3`
> + - r\ :sub:`2`
> + -
This doesn't match the text above. This would be RGBX2101010. I'm not
sure which format you want, so I don't know if it's the documentation or
the format name that is incorrect. The next two formats also seem
incorrect to me.
> +* .. _V4L2-PIX-FMT-ABGR2101010:
> +
> + - ``V4L2_PIX_FMT_ABGR2101010``
> + - 'RA30'
> +
> + - b\ :sub:`5`
> + - b\ :sub:`4`
> + - b\ :sub:`3`
> + - b\ :sub:`2`
> + - b\ :sub:`1`
> + - b\ :sub:`0`
> + - a\ :sub:`1`
> + - a\ :sub:`0`
> +
> + - g\ :sub:`3`
> + - g\ :sub:`2`
> + - g\ :sub:`1`
> + - g\ :sub:`0`
> + - b\ :sub:`9`
> + - b\ :sub:`8`
> + - b\ :sub:`7`
> + - b\ :sub:`6`
> +
> + - r\ :sub:`1`
> + - r\ :sub:`0`
> + - g\ :sub:`9`
> + - g\ :sub:`8`
> + - g\ :sub:`7`
> + - g\ :sub:`6`
> + - g\ :sub:`5`
> + - g\ :sub:`4`
> +
> + - r\ :sub:`9`
> + - r\ :sub:`8`
> + - r\ :sub:`7`
> + - r\ :sub:`6`
> + - r\ :sub:`5`
> + - r\ :sub:`4`
> + - r\ :sub:`3`
> + - r\ :sub:`2`
> + -
> +* .. _V4L2-PIX-FMT-BGRA1010102:
> +
> + - ``V4L2_PIX_FMT_BGRA1010102``
> + - 'AR30'
> +
> + - b\ :sub:`7`
> + - b\ :sub:`6`
> + - b\ :sub:`5`
> + - b\ :sub:`4`
> + - b\ :sub:`3`
> + - b\ :sub:`2`
> + - b\ :sub:`1`
> + - b\ :sub:`0`
> +
> + - g\ :sub:`5`
> + - g\ :sub:`4`
> + - g\ :sub:`3`
> + - g\ :sub:`2`
> + - g\ :sub:`1`
> + - g\ :sub:`0`
> + - b\ :sub:`9`
> + - b\ :sub:`8`
> +
> + - r\ :sub:`3`
> + - r\ :sub:`2`
> + - r\ :sub:`1`
> + - r\ :sub:`0`
> + - g\ :sub:`9`
> + - g\
[PATCH v3 0/2] Add support for the orisetech ota5601
Changes since v2: - Documented the registers to the best of my knowledge - Used macros for on/off panel registers - Added SPI id_table (non-requested change, fixes a warning in dmesg) --- Changes since v1: - fixed the dt-bindings maintainer email adress - dropped backlight, port, power-supply and reset-gpios as they're provided by panel-common.yaml as pointed by Krzysztof Kozlowski - changed reg: true to reg : maxItems: 1 Christophe Branchereau (2): drm/panel: add the orisetech ota5601a dt-bindings: display/panel: Add the Focaltech gpt3 .../display/panel/focaltech,gpt3.yaml | 56 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-orisetech-ota5601a.c | 364 ++ 4 files changed, 430 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml create mode 100644 drivers/gpu/drm/panel/panel-orisetech-ota5601a.c -- 2.35.1
[PATCH v3 2/2] dt-bindings: display/panel: Add the Focaltech gpt3
Add bindings for the Forcaltech gpt3, which is a 640x480 3.0" 4:3
IPS LCD Panel found in the YLM/Anbernic RG300X handheld.
Signed-off-by: Christophe Branchereau
Reviewed-by: Krzysztof Kozlowski
---
.../display/panel/focaltech,gpt3.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
new file mode 100644
index ..d54e96b2a9e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/focaltech,gpt3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Focaltech GPT3 3.0" (640x480 pixels) IPS LCD panel
+
+maintainers:
+ - Christophe Branchereau
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+const: focaltech,gpt3
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-supply
+ - reset-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "focaltech,gpt3";
+reg = <0>;
+
+spi-max-frequency = <3125000>;
+
+reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+backlight = <&backlight>;
+power-supply = <&vcc>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <&panel_output>;
+};
+};
+};
+};
--
2.35.1
[PATCH v3 1/2] drm/panel: add the orisetech ota5601a
Add the orisetech ota5601a ic driver
For now it only supports the focaltech gpt3 3" 640x480 ips panel
found in the ylm rg300x handheld.
Signed-off-by: Christophe Branchereau
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-orisetech-ota5601a.c | 364 ++
3 files changed, 374 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 737edcdf9eef..114758f64d26 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -400,6 +400,15 @@ config DRM_PANEL_OLIMEX_LCD_OLINUXINO
Say Y here if you want to enable support for Olimex Ltd.
LCD-OLinuXino panel.
+config DRM_PANEL_ORISETECH_OTA5601A
+tristate "Orise Technology ota5601a RGB/SPI panel"
+depends on SPI
+depends on BACKLIGHT_CLASS_DEVICE
+select REGMAP_SPI
+help
+ Say Y here if you want to enable support for the panels built
+ around the Orise Technology OTA9601A display controller.
+
config DRM_PANEL_ORISETECH_OTM8009A
tristate "Orise Technology otm8009a 480x800 dsi 2dl panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f8f9d9f6a307..ddcf8df889c8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) +=
panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
+obj-$(CONFIG_DRM_PANEL_ORISETECH_OTA5601A) += panel-orisetech-ota5601a.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
new file mode 100644
index ..b40a641f1d67
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
@@ -0,0 +1,364 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Orisetech OTA5601A TFT LCD panel driver
+ *
+ * Copyright (C) 2021, Christophe Branchereau
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define OTA5601A_CTL 0x01
+#define OTA5601A_CTL_OFF 0x00
+#define OTA5601A_CTL_ON BIT(0)
+
+struct ota5601a_panel_info {
+ const struct drm_display_mode *display_modes;
+ unsigned int num_modes;
+ u16 width_mm, height_mm;
+ u32 bus_format, bus_flags;
+};
+
+struct ota5601a {
+ struct drm_panel drm_panel;
+ struct regmap *map;
+ struct regulator *supply;
+ const struct ota5601a_panel_info *panel_info;
+
+ struct gpio_desc *reset_gpio;
+};
+
+static inline struct ota5601a *to_ota5601a(struct drm_panel *panel)
+{
+ return container_of(panel, struct ota5601a, drm_panel);
+}
+
+static const struct reg_sequence ota5601a_panel_regs[] = {
+ { 0xfd, 0x00 }, /* Page Shift */
+ { 0x02, 0x00 }, /* Reset */
+
+ { 0x18, 0x00 }, /* Interface Sel: RGB 24 Bits */
+ { 0x34, 0x20 }, /* Undocumented */
+
+ { 0x0c, 0x01 }, /* Contrast set by CMD1 == within page 0x00 */
+ { 0x0d, 0x48 }, /* R Brightness */
+ { 0x0e, 0x48 }, /* G Brightness */
+ { 0x0f, 0x48 }, /* B Brightness */
+ { 0x07, 0x40 }, /* R Contrast */
+ { 0x08, 0x33 }, /* G Contrast */
+ { 0x09, 0x3a }, /* B Contrast */
+
+ { 0x16, 0x01 }, /* NTSC Sel */
+ { 0x19, 0x8d }, /* VBLK */
+ { 0x1a, 0x28 }, /* HBLK */
+ { 0x1c, 0x00 }, /* Scan Shift Dir. */
+
+ { 0xfd, 0xc5 }, /* Page Shift */
+ { 0x82, 0x0c }, /* PWR_CTRL Pump */
+ { 0xa2, 0xb4 }, /* PWR_CTRL VGH/VGL */
+
+ { 0xfd, 0xc4 }, /* Page Shift - What follows is listed as "RGB 24bit
Timing Set" */
+ { 0x82, 0x45 },
+
+ { 0xfd, 0xc1 },
+ { 0x91, 0x02 },
+
+ { 0xfd, 0xc0 },
+ { 0xa1, 0x01 },
+ { 0xa2, 0x1f },
+ { 0xa3, 0x0b },
+ { 0xa4, 0x38 },
+ { 0xa5, 0x00 },
+ { 0xa6, 0x0a },
+ { 0xa7, 0x38 },
+ { 0xa8, 0x00 },
+ { 0xa9, 0x0a },
+ { 0xaa, 0x37 },
+
+ { 0xfd, 0xce },
+ { 0x81, 0x18 },
+ { 0x82, 0x43 },
+ { 0x83, 0x43 },
+ { 0x91, 0x06 },
+ { 0x93, 0x38 },
+ { 0x94, 0x02 },
+ { 0x95, 0x06 },
+ { 0x97, 0x38 },
+ { 0x98, 0x02 },
+ { 0x99, 0x06 },
+ { 0x9b, 0x38 },
+ { 0x9c, 0x02 },
+
+ { 0xfd, 0x00 }, /* Page Shift */
+};
+
+static const struct regmap_config ota5601a_regmap_config = {
+
Re: [PATCH v2 2/7] media: Add Y210, Y212 and Y216 formats
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:34PM +0200, Tomi Valkeinen wrote:
> Add Y210, Y212 and Y216 formats.
>
> Signed-off-by: Tomi Valkeinen
> ---
> .../media/v4l/pixfmt-packed-yuv.rst | 44 +++
> drivers/media/v4l2-core/v4l2-ioctl.c | 3 ++
> include/uapi/linux/videodev2.h| 8
> 3 files changed, 55 insertions(+)
>
> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> index bf283a1b5581..3f193e5fd5cb 100644
> --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
> @@ -337,6 +337,50 @@ components horizontally by 2, storing 2 pixels in 4
> bytes.
I would patch the above sentence to mention that it applies to 8 bit
formats.
>- Y'\ :sub:`3`
>- Cb\ :sub:`2`
>
> +The packed YUYV formats with more than 8 bits per component are stored as
> four
> +16-bit little-endian words. Each word's most significat bits contain one
s/significat/significant/
> +component, and the least significant bits are zero padding.
> +
> +.. tabularcolumns::
> |p{3.4cm}|p{1.2cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
> +
> +.. flat-table:: Packed YUV 4:2:2 Formats in 64-bit container
> +:header-rows: 1
> +:stub-columns: 0
> +
> +* - Identifier
> + - Code
> + - Word 0
> + - Word 1
> + - Word 2
> + - Word 3
> +* .. _V4L2-PIX-FMT-Y210:
> +
> + - ``V4L2_PIX_FMT_Y210``
> + - 'Y210'
> +
> + - Y'\ :sub:`0` (bits 15-6)
> + - Cb\ :sub:`0` (bits 15-6)
> + - Y'\ :sub:`1` (bits 15-6)
> + - Cr\ :sub:`0` (bits 15-6)
> +* .. _V4L2-PIX-FMT-Y212:
> +
> + - ``V4L2_PIX_FMT_Y212``
> + - 'Y212'
> +
> + - Y'\ :sub:`0` (bits 15-4)
> + - Cb\ :sub:`0` (bits 15-4)
> + - Y'\ :sub:`1` (bits 15-4)
> + - Cr\ :sub:`0` (bits 15-4)
> +* .. _V4L2-PIX-FMT-Y216:
> +
> + - ``V4L2_PIX_FMT_Y216``
> + - 'Y216'
> +
> + - Y'\ :sub:`0` (bits 15-0)
> + - Cb\ :sub:`0` (bits 15-0)
> + - Y'\ :sub:`1` (bits 15-0)
> + - Cr\ :sub:`0` (bits 15-0)
> +
> .. raw:: latex
>
> \normalsize
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 964300deaf62..ba95389a59b5 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1449,6 +1449,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A
> Statistics"; break;
> case V4L2_PIX_FMT_NV12M_8L128: descr = "NV12M (8x128 Linear)"; break;
> case V4L2_PIX_FMT_NV12M_10BE_8L128: descr = "10-bit NV12M (8x128
> Linear, BE)"; break;
> + case V4L2_PIX_FMT_Y210: descr = "10-bit YUYV Packed"; break;
> + case V4L2_PIX_FMT_Y212: descr = "12-bit YUYV Packed"; break;
> + case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break;
While the names will not play nicely with future formats that would swap
the order of the Y, U and V components, they match the formats defined
by DRM, which I think is more important.
With the above small issues fixed,
Conditionally-Reviewed-by: Laurent Pinchart
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 877fd61693b8..15b640d2da8a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -621,6 +621,14 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_YUVX32 v4l2_fourcc('Y', 'U', 'V', 'X') /* 32
> YUVX-8-8-8-8 */
> #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12 YUV
> 4:2:0 2 lines y, 1 line uv interleaved */
>
> +/*
> + * YCbCr packed format. For each Y2xx format, xx bits of valid data occupy
> the MSBs
> + * of the 16 bit components, and 16-xx bits of zero padding occupy the LSBs.
> + */
> +#define V4L2_PIX_FMT_Y210v4l2_fourcc('Y', '2', '1', '0') /* 32 YUYV
> 4:2:2 */
> +#define V4L2_PIX_FMT_Y212v4l2_fourcc('Y', '2', '1', '2') /* 32 YUYV
> 4:2:2 */
> +#define V4L2_PIX_FMT_Y216v4l2_fourcc('Y', '2', '1', '6') /* 32 YUYV
> 4:2:2 */
> +
> /* two planes -- one Y, one Cr + Cb interleaved */
> #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
> 4:2:0 */
> #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
> 4:2:0 */
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/fsl-dcu: Remove redundant error logging
On Sun, Dec 11, 2022 at 03:57:47PM +0530, Deepak R Varma wrote:
Hello,
May I please request a review and feedback on this patch proposal?
Thank you,
./drv
> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
>
> Issue identified using platform_get_irq.cocci coccicheck script.
>
> Signed-off-by: Deepak R Varma
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 8579c7629f5e..1ba7d95e1956 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -272,10 +272,8 @@ static int fsl_dcu_drm_probe(struct platform_device
> *pdev)
> }
>
> fsl_dev->irq = platform_get_irq(pdev, 0);
> - if (fsl_dev->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> + if (fsl_dev->irq < 0)
> return fsl_dev->irq;
> - }
>
> fsl_dev->regmap = devm_regmap_init_mmio(dev, base,
> &fsl_dcu_regmap_config);
> --
> 2.34.1
>
Re: [PATCH] drm/sprd: remove redundant error logging
On Sun, Dec 11, 2022 at 07:25:08PM +0530, Deepak R Varma wrote:
Hello,
May I please request a review and feedback on this patch proposal?
Thank you,
./drv
> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
>
> Issue identified using platform_get_irq.cocci coccicheck script.
>
> Signed-off-by: Deepak R Varma
> ---
> drivers/gpu/drm/sprd/sprd_dpu.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c
> index 88f4259680f1..db0bcea1d9f4 100644
> --- a/drivers/gpu/drm/sprd/sprd_dpu.c
> +++ b/drivers/gpu/drm/sprd/sprd_dpu.c
> @@ -803,10 +803,8 @@ static int sprd_dpu_context_init(struct sprd_dpu *dpu,
> }
>
> ctx->irq = platform_get_irq(pdev, 0);
> - if (ctx->irq < 0) {
> - dev_err(dev, "failed to get dpu irq\n");
> + if (ctx->irq < 0)
> return ctx->irq;
> - }
>
> /* disable and clear interrupts before register dpu IRQ. */
> writel(0x00, ctx->base + REG_DPU_INT_EN);
> --
> 2.34.1
>
Re: [PATCH] drm/tegra: sor: Remove redundant error logging
On Mon, Dec 12, 2022 at 10:44:55AM +0530, Deepak R Varma wrote:
Hello,
May I please request a review and feedback on this patch proposal?
Also, I was able to build the changes for ARM arch verified using modinfo
tegr-drm.ko command.
Thank you,
./drv
> A call to platform_get_irq() already prints an error on failure within
> its own implementation. So printing another error based on its return
> value in the caller is redundant and should be removed. The clean up
> also makes if condition block braces unnecessary. Remove that as well.
>
> Issue identified using platform_get_irq.cocci coccicheck script.
>
> Signed-off-by: Deepak R Varma
> ---
> Please note: I was not able to build this driver since I did not find the
> DRM_TEGRA option in menu config. All dependencies listed in the KConfig are
> enabled, however, I was still not able to find the DRM_TEGRA module in the
> Graphics-Drivers list. Since the proposed change is known, minor and obvious,
> I
> am sending in this patch without build testing.
>
> Any advise on how to enable the DRM_TEGRA module in menuconfig selection list
> will be helpful. Thank you.
>
>
> drivers/gpu/drm/tegra/sor.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 8af632740673..ceaebd33408d 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -3799,10 +3799,8 @@ static int tegra_sor_probe(struct platform_device
> *pdev)
> }
>
> err = platform_get_irq(pdev, 0);
> - if (err < 0) {
> - dev_err(&pdev->dev, "failed to get IRQ: %d\n", err);
> + if (err < 0)
> goto remove;
> - }
>
> sor->irq = err;
>
> --
> 2.34.1
>
Re: [PATCH v2 3/7] media: renesas: vsp1: Change V3U to be gen4
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:35PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen4, not gen3. The same IP is also used in the
> (not-yet-supported) V4H.
>
> Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4,
> to represent the model correctly. V3U and V4H can still be
> differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx.
>
> Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info,
> and update the code to correcly match for gen 4.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/media/platform/renesas/vsp1/vsp1_drv.c | 4 ++--
> drivers/media/platform/renesas/vsp1/vsp1_hgo.c | 4 ++--
> drivers/media/platform/renesas/vsp1/vsp1_lif.c | 1 +
> drivers/media/platform/renesas/vsp1/vsp1_regs.h | 2 +-
> drivers/media/platform/renesas/vsp1/vsp1_rpf.c | 12 ++--
> drivers/media/platform/renesas/vsp1/vsp1_video.c | 4 ++--
> drivers/media/platform/renesas/vsp1/vsp1_wpf.c | 4 ++--
> 7 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> index c260d318d298..5710152d6511 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c
> @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[]
> = {
> .wpf_count = 2,
> .num_bru_inputs = 5,
> }, {
> - .version = VI6_IP_VERSION_MODEL_VSPD_V3U,
> + .version = VI6_IP_VERSION_MODEL_VSPD_GEN4,
> .model = "VSP2-D",
> - .gen = 3,
> + .gen = 4,
> .features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL,
> .lif_count = 1,
> .rpf_count = 5,
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> index bf3f981f93a1..e6492deb0a64 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c
> @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device
> *vsp1)
>
> /* Initialize the control handler. */
> v4l2_ctrl_handler_init(&hgo->ctrls.handler,
> -vsp1->info->gen == 3 ? 2 : 1);
> +vsp1->info->gen >= 3 ? 2 : 1);
> hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler,
> &hgo_max_rgb_control, NULL);
> - if (vsp1->info->gen == 3)
> + if (vsp1->info->gen >= 3)
> hgo->ctrls.num_bins =
> v4l2_ctrl_new_custom(&hgo->ctrls.handler,
>&hgo_num_bins_control, NULL);
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> index 186a5730e1e3..0ab2e0c70474 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c
> @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity
> *entity,
> break;
>
> case VI6_IP_VERSION_MODEL_VSPD_GEN3:
> + case VI6_IP_VERSION_MODEL_VSPD_GEN4:
While this doesn't cause any functional change, it doesn't fall into the
renaming explained in the commit message. I'd make a mention of it
there.
Conditional-Reviewed-by: Laurent Pinchart
> default:
> hbth = 0;
> obth = 3000;
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index 8928f4c6bb55..8c9333f76858 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -766,7 +766,7 @@
> #define VI6_IP_VERSION_MODEL_VSPD_V3 (0x18 << 8)
> #define VI6_IP_VERSION_MODEL_VSPDL_GEN3 (0x19 << 8)
> #define VI6_IP_VERSION_MODEL_VSPBS_GEN3 (0x1a << 8)
> -#define VI6_IP_VERSION_MODEL_VSPD_V3U(0x1c << 8)
> +#define VI6_IP_VERSION_MODEL_VSPD_GEN4 (0x1c << 8)
> /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */
> #define VI6_IP_VERSION_MODEL_VSPD_RZG2L (0x80 << 8)
>
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 75083cb234fe..045aa54f7998 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity
> *entity,
>* a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control
>* otherwise.
>*
> - * The Gen3 RPF has extended alpha capability and can both multiply the
> + * The Gen3+ RPF has extended alpha capability and can both multiply the
>* alpha channel by a fixed global alpha value, and multiply the pixel
>* components to convert the
Re: [PATCH v2 4/7] media: renesas: vsp1: Add V4H SoC version
Hi Tomi, Thank you for the patch. On Mon, Dec 19, 2022 at 04:01:36PM +0200, Tomi Valkeinen wrote: > Add VI6_IP_VERSION_SOC_V4H so that we can identify V4H SoC. > > Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart > --- > drivers/media/platform/renesas/vsp1/vsp1_regs.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h > b/drivers/media/platform/renesas/vsp1/vsp1_regs.h > index 8c9333f76858..c61e8dafeecf 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h > +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h > @@ -782,6 +782,7 @@ > #define VI6_IP_VERSION_SOC_M3N (0x04 << 0) > #define VI6_IP_VERSION_SOC_E3(0x04 << 0) > #define VI6_IP_VERSION_SOC_V3U (0x05 << 0) > +#define VI6_IP_VERSION_SOC_V4H (0x06 << 0) > /* RZ/G2L SoCs have no version register, So use 0x80 for SoC Identification > */ > #define VI6_IP_VERSION_SOC_RZG2L (0x80 << 0) > -- Regards, Laurent Pinchart
Re: [PATCH v2 5/7] media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210)
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:37PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: XBGR2101010, ABGR2101010, BGRA1010102 and Y210.
>
> Signed-off-by: Tomi Valkeinen
> ---
> .../media/platform/renesas/vsp1/vsp1_pipe.c | 15 ++
> .../media/platform/renesas/vsp1/vsp1_regs.h | 22 +
> .../media/platform/renesas/vsp1/vsp1_rpf.c| 49 +++
> 3 files changed, 86 insertions(+)
>
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> index f72ac01c21ea..2867b3de06fa 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> @@ -146,6 +146,18 @@ static const struct vsp1_format_info
> vsp1_video_formats[] = {
> VI6_FMT_ARGB_, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> 1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_XBGR2101010, MEDIA_BUS_FMT_ARGB_1X32,
> + VI6_FMT_RGB10_RGB10A2_A2RGB10,
> + VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> + 1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_ABGR2101010, MEDIA_BUS_FMT_ARGB_1X32,
> + VI6_FMT_RGB10_RGB10A2_A2RGB10,
> + VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> + 1, { 32, 0, 0 }, false, false, 1, 1, false },
> + { V4L2_PIX_FMT_BGRA1010102, MEDIA_BUS_FMT_ARGB_1X32,
> + VI6_FMT_RGB10_RGB10A2_A2RGB10,
> + VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> + 1, { 32, 0, 0 }, false, false, 1, 1, false },
> { V4L2_PIX_FMT_UYVY, MEDIA_BUS_FMT_AYUV8_1X32,
> VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> @@ -202,6 +214,9 @@ static const struct vsp1_format_info vsp1_video_formats[]
> = {
> VI6_FMT_Y_U_V_444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> 3, { 8, 8, 8 }, false, true, 1, 1, false },
> + { V4L2_PIX_FMT_Y210, MEDIA_BUS_FMT_AYUV8_1X32,
> + VI6_FMT_YUYV_422, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> + 1, { 32, 0, 0 }, false, false, 2, 1, false },
> };
>
> /**
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> index c61e8dafeecf..8947ea05f95e 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h
> @@ -228,6 +228,27 @@
> #define VI6_RPF_MULT_ALPHA_RATIO_MASK(0xff << 0)
> #define VI6_RPF_MULT_ALPHA_RATIO_SHIFT 0
>
> +#define VI6_RPF_EXT_INFMT0 0x0370
> +#define VI6_RPF_EXT_INFMT0_F2B_LSB (0 << 12)
> +#define VI6_RPF_EXT_INFMT0_F2B_MSB (1 << 12)
We don't normally define two macros for each bit. You can drop the
F2B_LSB macro, rename F2B_MSB to F2B, and use BIT(12).
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_8 (0 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_10 (1 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_Y_12 (2 << 8)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_8 (0 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_10 (1 << 4)
> +#define VI6_RPF_EXT_INFMT0_IPBD_C_12 (2 << 4)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_RGB10 (3 << 0)
> +#define VI6_RPF_EXT_INFMT0_BYPP_M1_N_RGB10 (0 << 0)
I would drop the last one as you don't use it.
> +
> +#define VI6_RPF_EXT_INFMT1 0x0374
> +#define VI6_RPF_EXT_INFMT2 0x0378
> +
> +#define VI6_RPF_BRDITH_CTRL 0x03e0
> +#define VI6_RPF_BRDITH_CTRL_ODE_EN (1 << 8)
> +#define VI6_RPF_BRDITH_CTRL_ODE_DIS (0 << 8)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_RO (1 << 0)
> +#define VI6_RPF_BRDITH_CTRL_CBRM_TR (0 << 0)
Same here, one macro per bit.
The BRDITH_CTRL registers doesn't seem to be used. I don't mind adding
it though.
> +
> /*
> -
> * WPF Control Registers
> */
> @@ -846,6 +867,7 @@
> #define VI6_FMT_XBXGXR_2626260x21
> #define VI6_FMT_ABGR_0x22
> #define VI6_FMT_XXRGB_88565 0x23
> +#define VI6_FMT_RGB10_RGB10A2_A2RGB100x30
>
> #define VI6_FMT_Y_UV_444 0x40
> #define VI6_FMT_Y_UV_422 0x41
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> index 045aa54f7998..60ba3c62e86c 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c
> @@ -55,6 +55,11 @@ static const struct v4l2_subdev_ops rpf_ops = {
> * VSP1 Entity Operations
> */
>
> +#define PACK_CPOS(a, b, c, d) \
> + (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +#define PACK_CLEN(a, b, c, d) \
> + (((a) << 24) | ((b) << 16) | ((c) << 8) | ((d) << 0))
> +
Please move this to vsp1_regs.h, just below
Re: [PATCH v2 6/7] drm: rcar-du: Bump V3U to gen 4
Hi Tomi,
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:38PM +0200, Tomi Valkeinen wrote:
> V3U is actually gen 4 IP, like in V4H. Bumb up V3U gen in the
> rcar_du_r8a779a0_info.
With the typo reporting by Kieran fixed,
Conditionally-Reviewed-by: Laurent Pinchart
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 46c60a2d710d..c7c5217cfc1a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -504,7 +504,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a7799x_info = {
> };
>
> static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
> - .gen = 3,
> + .gen = 4,
> .features = RCAR_DU_FEATURE_CRTC_IRQ
> | RCAR_DU_FEATURE_VSP1_SOURCE
> | RCAR_DU_FEATURE_NO_BLENDING,
--
Regards,
Laurent Pinchart
Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210)
Hi Tomi,
(CC'ing Sakari and Hans)
Thank you for the patch.
On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote:
> Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +--
> 2 files changed, 71 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 8c2719efda2a..8ccabf5a30c4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -259,6 +259,24 @@ static const struct rcar_du_format_info
> rcar_du_format_infos[] = {
> .bpp = 32,
> .planes = 1,
> .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_RGBX1010102,
Ah, here the format makes sense.
> + .v4l2 = V4L2_PIX_FMT_XBGR2101010,
But this is horrible :-( Could we use the same names as DRM for new
formats, when there is no conflict with existing V4L2 formats ?
Sakari, Hans, what do you think ? Please see patch 1/7 in the series for
the format definitions.
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_RGBA1010102,
> + .v4l2 = V4L2_PIX_FMT_ABGR2101010,
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_ARGB2101010,
> + .v4l2 = V4L2_PIX_FMT_BGRA1010102,
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 1,
> }, {
> .fourcc = DRM_FORMAT_YVYU,
> .v4l2 = V4L2_PIX_FMT_YVYU,
> @@ -307,6 +325,12 @@ static const struct rcar_du_format_info
> rcar_du_format_infos[] = {
> .bpp = 24,
> .planes = 3,
> .hsub = 1,
> + }, {
> + .fourcc = DRM_FORMAT_Y210,
> + .v4l2 = V4L2_PIX_FMT_Y210,
> + .bpp = 32,
> + .planes = 1,
> + .hsub = 2,
> },
Any reason why you'd not adding Y212 support already ?
> };
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index e465aef41585..6f3e109a4f80 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = {
> DRM_FORMAT_YVU444,
> };
>
> +/*
> + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB
> + * formats and Y210 format.
> + */
> +static const u32 rcar_du_vsp_formats_gen4[] = {
> + DRM_FORMAT_RGB332,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB1555,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_RGBX1010102,
> + DRM_FORMAT_RGBA1010102,
> + DRM_FORMAT_ARGB2101010,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_NV21,
> + DRM_FORMAT_NV16,
> + DRM_FORMAT_NV61,
> + DRM_FORMAT_YUV420,
> + DRM_FORMAT_YVU420,
> + DRM_FORMAT_YUV422,
> + DRM_FORMAT_YVU422,
> + DRM_FORMAT_YUV444,
> + DRM_FORMAT_YVU444,
> + DRM_FORMAT_Y210,
> +};
> +
> static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane)
> {
> struct rcar_du_vsp_plane_state *state =
> @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> device_node *np,
>? DRM_PLANE_TYPE_PRIMARY
>: DRM_PLANE_TYPE_OVERLAY;
> struct rcar_du_vsp_plane *plane = &vsp->planes[i];
> + unsigned int num_formats;
> + const u32 *formats;
> +
> + if (rcdu->info->gen < 4) {
> + num_formats = ARRAY_SIZE(rcar_du_vsp_formats);
> + formats = rcar_du_vsp_formats;
> + } else {
> + num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4);
> + formats = rcar_du_vsp_formats_gen4;
> + }
>
> plane->vsp = vsp;
> plane->index = i;
>
> ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane,
> crtcs, &rcar_du_vsp_plane_funcs,
> -rcar_du_vsp_formats,
> -ARRAY_SIZE(rcar_du_vsp_formats),
> +formats, num_formats,
> NULL, type, NULL);
> if (ret < 0)
> return ret;
--
Regards,
Laurent Pin
[PATCH AUTOSEL 6.1 10/16] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *,
struct drm_display_mode *)' with an expression of type 'int (struct
drm_connector *, struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
[PATCH AUTOSEL 6.1 11/16] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hda_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_dvo_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hdmi_connector_mode_valid,
^
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sti/sti_dvo.c | 5 +++--
drivers/gpu/drm/sti/sti_hda.c | 5 +++--
drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b6ee8a82e656..076d5f30a09c 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 03cc401ed593..a53b5a15c2a9 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -601,8 +601,9 @@ static int sti_hda_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index cb82622877d2..09e0cadb6368 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1004,8 +1004,9 @@ static int sti_hdmi_connector_get_modes(struct
drm_connector *connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
--
2.35.1
[PATCH AUTOSEL 5.15 7/9] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hda_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_dvo_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hdmi_connector_mode_valid,
^
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sti/sti_dvo.c | 5 +++--
drivers/gpu/drm/sti/sti_hda.c | 5 +++--
drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b6ee8a82e656..076d5f30a09c 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 03f3377f918c..1959387cda98 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -600,8 +600,9 @@ static int sti_hda_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index f3ace11209dd..dd256c7b9060 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1003,8 +1003,9 @@ static int sti_hdmi_connector_get_modes(struct
drm_connector *connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
--
2.35.1
[PATCH AUTOSEL 6.0 11/16] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hda_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_dvo_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hdmi_connector_mode_valid,
^
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sti/sti_dvo.c | 5 +++--
drivers/gpu/drm/sti/sti_hda.c | 5 +++--
drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index b6ee8a82e656..076d5f30a09c 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 03cc401ed593..a53b5a15c2a9 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -601,8 +601,9 @@ static int sti_hda_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index cb82622877d2..09e0cadb6368 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1004,8 +1004,9 @@ static int sti_hdmi_connector_get_modes(struct
drm_connector *connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
--
2.35.1
[PATCH AUTOSEL 5.10 2/5] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *,
struct drm_display_mode *)' with an expression of type 'int (struct
drm_connector *, struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
[PATCH AUTOSEL 6.0 10/16] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *,
struct drm_display_mode *)' with an expression of type 'int (struct
drm_connector *, struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
[PATCH AUTOSEL 5.10 3/5] drm/sti: Fix return type of sti_{dvo, hda, hdmi}_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hda_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_dvo_connector_mode_valid,
^~~~
drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer
types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct
drm_display_mode *)' with an expression of type 'int (struct drm_connector *,
struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = sti_hdmi_connector_mode_valid,
^
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sti/sti_dvo.c | 5 +++--
drivers/gpu/drm/sti/sti_hda.c | 5 +++--
drivers/gpu/drm/sti/sti_hdmi.c | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index ddb4184f0726..58b092eb8907 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -346,8 +346,9 @@ static int sti_dvo_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_dvo_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_dvo_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 5c2b650b561d..bc04b8f50b09 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -600,8 +600,9 @@ static int sti_hda_connector_get_modes(struct drm_connector
*connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hda_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hda_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 38a558768e53..b0890234ffbe 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -997,8 +997,9 @@ static int sti_hdmi_connector_get_modes(struct
drm_connector *connector)
#define CLK_TOLERANCE_HZ 50
-static int sti_hdmi_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+sti_hdmi_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
int target = mode->clock * 1000;
int target_min = target - CLK_TOLERANCE_HZ;
--
2.35.1
[PATCH AUTOSEL 5.15 6/9] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *,
struct drm_display_mode *)' with an expression of type 'int (struct
drm_connector *, struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 4d4a715b429d..2c2b92324a2e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -60,8 +60,9 @@ static int fsl_dcu_drm_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(fsl_connector->panel, connector);
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
[PATCH AUTOSEL 4.14 1/3] drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
From: Nathan Chancellor
[ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function
pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *,
struct drm_display_mode *)' with an expression of type 'int (struct
drm_connector *, struct drm_display_mode *)'
[-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = fsl_dcu_drm_connector_mode_valid,
^~~~
1 error generated.
->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
the warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen
Signed-off-by: Nathan Chancellor
Reviewed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20221102154215.78059-1-nat...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index c54806d08dd7..aec9fe01dfe9 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -83,8 +83,9 @@ static int fsl_dcu_drm_connector_get_modes(struct
drm_connector *connector)
return num_modes;
}
-static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
{
if (mode->hdisplay & 0xf)
return MODE_ERROR;
--
2.35.1
