[PATCH v7 2/6] drm/xe/xe_gt_pagefault: Migrate pagefault struct to header
Migrate the pagefault struct from xe_gt_pagefault.c to the
xe_gt_pagefault.h header file, along with the associated enum values.
v2: Normalize names for common header (Matt Brost)
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/xe_gt_pagefault.c | 41 +---
drivers/gpu/drm/xe/xe_gt_pagefault.h | 28 +++
2 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_gt_pagefault.c
b/drivers/gpu/drm/xe/xe_gt_pagefault.c
index a4e688e72efd..c8a9058aa09f 100644
--- a/drivers/gpu/drm/xe/xe_gt_pagefault.c
+++ b/drivers/gpu/drm/xe/xe_gt_pagefault.c
@@ -23,33 +23,6 @@
#include "xe_trace_bo.h"
#include "xe_vm.h"
-struct pagefault {
- u64 page_addr;
- u32 asid;
- u16 pdata;
- u8 vfid;
- u8 access_type;
- u8 fault_type;
- u8 fault_level;
- u8 engine_class;
- u8 engine_instance;
- u8 fault_unsuccessful;
- bool trva_fault;
-};
-
-enum access_type {
- ACCESS_TYPE_READ = 0,
- ACCESS_TYPE_WRITE = 1,
- ACCESS_TYPE_ATOMIC = 2,
- ACCESS_TYPE_RESERVED = 3,
-};
-
-enum fault_type {
- NOT_PRESENT = 0,
- WRITE_ACCESS_VIOLATION = 1,
- ATOMIC_ACCESS_VIOLATION = 2,
-};
-
struct acc {
u64 va_range_base;
u32 asid;
@@ -61,9 +34,9 @@ struct acc {
u8 engine_instance;
};
-static bool access_is_atomic(enum access_type access_type)
+static bool access_is_atomic(enum xe_pagefault_access_type access_type)
{
- return access_type == ACCESS_TYPE_ATOMIC;
+ return access_type == XE_PAGEFAULT_ACCESS_TYPE_ATOMIC;
}
static bool vma_is_valid(struct xe_tile *tile, struct xe_vma *vma)
@@ -205,7 +178,7 @@ static struct xe_vm *asid_to_vm(struct xe_device *xe, u32
asid)
return vm;
}
-static int handle_pagefault(struct xe_gt *gt, struct pagefault *pf)
+static int handle_pagefault(struct xe_gt *gt, struct xe_pagefault *pf)
{
struct xe_device *xe = gt_to_xe(gt);
struct xe_vm *vm;
@@ -237,7 +210,7 @@ static int handle_pagefault(struct xe_gt *gt, struct
pagefault *pf)
goto unlock_vm;
}
- if (xe_vma_read_only(vma) && pf->access_type != ACCESS_TYPE_READ) {
+ if (xe_vma_read_only(vma) && pf->access_type !=
XE_PAGEFAULT_ACCESS_TYPE_READ) {
err = -EPERM;
goto unlock_vm;
}
@@ -271,7 +244,7 @@ static int send_pagefault_reply(struct xe_guc *guc,
return xe_guc_ct_send(&guc->ct, action, ARRAY_SIZE(action), 0, 0);
}
-static void print_pagefault(struct xe_device *xe, struct pagefault *pf)
+static void print_pagefault(struct xe_device *xe, struct xe_pagefault *pf)
{
drm_dbg(&xe->drm, "\n\tASID: %d\n"
"\tVFID: %d\n"
@@ -291,7 +264,7 @@ static void print_pagefault(struct xe_device *xe, struct
pagefault *pf)
#define PF_MSG_LEN_DW 4
-static bool get_pagefault(struct pf_queue *pf_queue, struct pagefault *pf)
+static bool get_pagefault(struct pf_queue *pf_queue, struct xe_pagefault *pf)
{
const struct xe_guc_pagefault_desc *desc;
bool ret = false;
@@ -378,7 +351,7 @@ static void pf_queue_work_func(struct work_struct *w)
struct xe_gt *gt = pf_queue->gt;
struct xe_device *xe = gt_to_xe(gt);
struct xe_guc_pagefault_reply reply = {};
- struct pagefault pf = {};
+ struct xe_pagefault pf = {};
unsigned long threshold;
int ret;
diff --git a/drivers/gpu/drm/xe/xe_gt_pagefault.h
b/drivers/gpu/drm/xe/xe_gt_pagefault.h
index 839c065a5e4c..33616043d17a 100644
--- a/drivers/gpu/drm/xe/xe_gt_pagefault.h
+++ b/drivers/gpu/drm/xe/xe_gt_pagefault.h
@@ -11,6 +11,34 @@
struct xe_gt;
struct xe_guc;
+struct xe_pagefault {
+ u64 page_addr;
+ u32 asid;
+ u16 pdata;
+ u8 vfid;
+ u8 access_type;
+ u8 fault_type;
+ u8 fault_level;
+ u8 engine_class;
+ u8 engine_instance;
+ u8 fault_unsuccessful;
+ bool prefetch;
+ bool trva_fault;
+};
+
+enum xe_pagefault_access_type {
+ XE_PAGEFAULT_ACCESS_TYPE_READ = 0,
+ XE_PAGEFAULT_ACCESS_TYPE_WRITE = 1,
+ XE_PAGEFAULT_ACCESS_TYPE_ATOMIC = 2,
+ XE_PAGEFAULT_ACCESS_TYPE_RESERVED = 3,
+};
+
+enum xe_pagefault_type {
+ XE_PAGEFAULT_TYPE_NOT_PRESENT = 0,
+ XE_PAGEFAULT_TYPE_WRITE_ACCESS_VIOLATION = 1,
+ XE_PAGEFAULT_TYPE_ATOMIC_ACCESS_VIOLATION = 2,
+};
+
int xe_gt_pagefault_init(struct xe_gt *gt);
void xe_gt_pagefault_reset(struct xe_gt *gt);
int xe_guc_pagefault_handler(struct xe_guc *guc, u32 *msg, u32 len);
--
2.43.0
RE: [PATCH v6 0/6] drm/xe/xe_vm: Implement xe_vm_get_faults_ioctl
-Original Message- From: Lin, Shuicheng Sent: Friday, March 7, 2025 3:26 PM To: Cavitt, Jonathan ; intel...@lists.freedesktop.org Cc: Gupta, saurabhg ; Zuo, Alex ; joonas.lahti...@linux.intel.com; Brost, Matthew ; Zhang, Jianxun ; dri-devel@lists.freedesktop.org Subject: RE: [PATCH v6 0/6] drm/xe/xe_vm: Implement xe_vm_get_faults_ioctl > > One generic question, do we have test case to verify whether the function is > working correctly? Thanks. > I think we could have IGT test case to trigger the fault, then have another > IGT test case to query it with this new uapi. > And make sure we could get the expected data with the new uapi. That's the plan for the future, but this series has been so in-the-air for a while now that making an IGT series for testing it didn't make sense, since the uapi itself could change at a moment's notice and render any IGT tests immediately obsolete. I'll create IGT tests verifying this series in the next two to three days, now that the uapi has more-or-less been accepted with very few blocking notes. -Jonathan Cavitt > > Shuicheng > > On Fri, Mar 7, 2025 2:41 PM Cavitt, Jonathan wrote > > Add additional information to each VM so they can report up to the first > > 50 seen pagefaults. Only failed pagefaults are saved this way, as > > successful > > pagefaults should recover and not need to be reported to userspace. > > > > Additionally, add a new ioctl - xe_vm_get_faults_ioctl - that allows the > > user to > > query these pagefaults > > > > v2: (Matt Brost) > > - Break full ban list request into a separate property. > > - Reformat drm_xe_vm_get_property struct. > > - Remove need for drm_xe_faults helper struct. > > - Separate data pointer and scalar return value in ioctl. > > - Get address type on pagefault report and save it to the pagefault. > > - Correctly reject writes to read-only VMAs. > > - Miscellaneous formatting fixes. > > > > v3: (Matt Brost) > > - Only allow querying of failed pagefaults > > > > v4: > > - Remove unnecessary size parameter from helper function, as it > > is a property of the arguments. (jcavitt) > > - Remove unnecessary copy_from_user (Jainxun) > > - Set address_precision to 1 (Jainxun) > > - Report max size instead of dynamic size for memory allocation > > purposes. Total memory usage is reported separately. > > > > v5: > > - Return int from xe_vm_get_property_size (Shuicheng) > > - Fix memory leak (Shuicheng) > > - Remove unnecessary size variable (jcavitt) > > > > v6: > > - Free vm after use (Shuicheng) > > - Compress pf copy logic (Shuicheng) > > - Update fault_unsuccessful before storing (Shuicheng) > > - Fix old struct name in comments (Shuicheng) > > - Keep first 50 pagefaults instead of last 50 (Jianxun) > > - Rename ioctl to xe_vm_get_faults_ioctl (jcavitt) > > > > Signed-off-by: Jonathan Cavitt > > Suggested-by: Joonas Lahtinen > > Suggested-by: Matthew Brost > > CC: Zhang Jianxun > > CC: Shuicheng Lin > > > > Jonathan Cavitt (6): > > drm/xe/xe_gt_pagefault: Disallow writes to read-only VMAs > > drm/xe/xe_gt_pagefault: Migrate pagefault struct to header > > drm/xe/xe_vm: Add per VM pagefault info > > drm/xe/uapi: Define drm_xe_vm_get_faults > > drm/xe/xe_gt_pagefault: Add address_type field to pagefaults > > drm/xe/xe_vm: Implement xe_vm_get_faults_ioctl > > > > drivers/gpu/drm/xe/xe_device.c | 3 + > > drivers/gpu/drm/xe/xe_gt_pagefault.c | 64 +++--- > > drivers/gpu/drm/xe/xe_gt_pagefault.h | 29 +++ > > drivers/gpu/drm/xe/xe_vm.c | 120 +++ > > drivers/gpu/drm/xe/xe_vm.h | 8 ++ > > drivers/gpu/drm/xe/xe_vm_types.h | 20 + > > include/uapi/drm/xe_drm.h| 49 +++ > > 7 files changed, 260 insertions(+), 33 deletions(-) > > > > -- > > 2.43.0 > >
Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help)
在 2025/3/11 14:40, Bingbu Cao 写道:
[You don't often get email from bingbu@linux.intel.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Huan Yang and Vivek,
I am trying to use udmabuf for my test, and I cannot vmap the udmabuf
buffers now. vmap_pfn_apply() will report a warning to complain that
the pfns are invalid.
I dump the pfn numbers as below:
[ 3365.399641] pg[0] pfn 1148695
[ 3365.399642] pg[1] pfn 1145057
[ 3365.399642] pg[2] pfn 1134070
[ 3365.399643] pg[3] pfn 1148700
[ 3365.399643] pg[4] pfn 1144871
[ 3365.399643] pg[5] pfn 1408686
[ 3365.399643] pg[6] pfn 1408683
...
[ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489
vmap_pfn_apply+0xb7/0xd0
[ 3365.399667] Modules linked in:...
[ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted
6.13.0-rc2-rvp #845
[ 3365.399752] Hardware name: Intel Corporation Client Platform/, BIOS
xxxFWI1.R00.3221.D83.2408120121 08/12/2024
[ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0
[ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23
3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff
ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00
[ 3365.399756] RSP: 0018:b9b50c32fad0 EFLAGS: 00010202
[ 3365.399757] RAX: 0001 RBX: 00118717 RCX:
[ 3365.399758] RDX: 8000 RSI: b9b50c358000 RDI:
[ 3365.399758] RBP: b9b50c32fae8 R08: b9b50c32fbd0 R09: 0001
[ 3365.399759] R10: 941602479288 R11: R12: b9b50c32fbd0
[ 3365.399759] R13: 941618665ac0 R14: b9b50c358000 R15: 941618665ac8
[ 3365.399760] FS: 7ff9e9ddd740() GS:94196f78()
knlGS:
[ 3365.399760] CS: 0010 DS: ES: CR0: 80050033
[ 3365.399761] CR2: 55fda5dc69d9 CR3: 0001544de003 CR4: 00f72ef0
[ 3365.399762] DR0: DR1: DR2:
[ 3365.399762] DR3: DR6: 07f0 DR7: 0400
[ 3365.399763] PKRU: 5554
[ 3365.399763] Call Trace:
[ 3365.399765]
[ 3365.399769] ? show_regs+0x6d/0x80
[ 3365.399773] ? __warn+0x97/0x160
[ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0
[ 3365.399777] ? report_bug+0x1ec/0x240
[ 3365.399782] ? handle_bug+0x63/0xa0
[ 3365.399784] ? exc_invalid_op+0x1d/0x80
[ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30
[ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0
[ 3365.399791] __apply_to_page_range+0x522/0x8a0
[ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10
[ 3365.399795] apply_to_page_range+0x18/0x20
[ 3365.399796] vmap_pfn+0x77/0xd0
[ 3365.399797] vmap_udmabuf+0xc5/0x110
[ 3365.399802] dma_buf_vmap+0x96/0x130
I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04,
then I can vmap the pages. Could you help what's wrong with that?
Sorry for that, as I reviewed pfn_valid, that's someting wired:
/**
* pfn_valid - check if there is a valid memory map entry for a PFN
* @pfn: the page frame number to check
*
* Check if there is a valid memory map entry aka struct page for the @pfn.
* Note, that availability of the memory map entry does not imply that
* there is actual usable memory at that @pfn. The struct page may
* represent a hole or an unusable page frame.
*
* Return: 1 for PFNs that have memory map entries and 0 otherwise
*/
So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn.
But vmap_pfn_apply in there:
static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
{
struct vmap_pfn_data *data = private;
unsigned long pfn = data->pfns[data->idx];
pte_t ptent;
if (WARN_ON_ONCE(pfn_valid(pfn)))
return -EINVAL;
ptent = pte_mkspecial(pfn_pte(pfn, data->prot));
set_pte_at(&init_mm, addr, pte, ptent);
data->idx++;
return 0;
}
Do it give a wrong check? maybe should fix by:
static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
{
struct vmap_pfn_data *data = private;
unsigned long pfn = data->pfns[data->idx];
pte_t ptent;
- if (WARN_ON_ONCE(pfn_valid(pfn)))
+ if (WARN_ON_ONCE(!pfn_valid(pfn)))
return -EINVAL;
ptent = pte_mkspecial(pfn_pte(pfn, data->prot));
set_pte_at(&init_mm, addr, pte, ptent);
data->idx++;
return 0;
}
Please help me check it, also, you can apply this and then check it.:)
--
Best regards,
Bingbu Cao
Re: [PATCH v1 1/2] drm/msm/dp: Fix support of LTTPR handling
On 25-03-10 22:05:51, Aleksandrs Vinarskis wrote:
> Take into account LTTPR capabilities when selecting maximum allowed
> link rate, number of data lines. Initialize LTTPR before
> msm_dp_panel_read_sink_caps, as
> a) Link params computation need to take into account LTTPR's caps
> b) It appears DPTX shall (re)read DPRX caps after LTTPR detection
>
> Return lttpr_count to prepare for per-segment link training.
>
> Signed-off-by: Aleksandrs Vinarskis
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 31 +++--
> drivers/gpu/drm/msm/dp/dp_panel.c | 30 +++-
> drivers/gpu/drm/msm/dp/dp_panel.h | 2 ++
> 3 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index bbc47d86ae9e..2edbc6adfde5 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -108,6 +108,8 @@ struct msm_dp_display_private {
> struct msm_dp_event event_list[DP_EVENT_Q_MAX];
> spinlock_t event_lock;
>
> + u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
> +
> bool wide_bus_supported;
>
> struct msm_dp_audio *audio;
> @@ -367,17 +369,21 @@ static int msm_dp_display_send_hpd_notification(struct
> msm_dp_display_private *d
> return 0;
> }
>
> -static void msm_dp_display_lttpr_init(struct msm_dp_display_private *dp)
> +static int msm_dp_display_lttpr_init(struct msm_dp_display_private *dp, u8
> *dpcd)
> {
> - u8 lttpr_caps[DP_LTTPR_COMMON_CAP_SIZE];
> - int rc;
> + int rc, lttpr_count;
>
> - if (drm_dp_read_lttpr_common_caps(dp->aux, dp->panel->dpcd, lttpr_caps))
> - return;
> + if (drm_dp_read_lttpr_common_caps(dp->aux, dpcd, dp->lttpr_common_caps))
> + return 0;
>
> - rc = drm_dp_lttpr_init(dp->aux, drm_dp_lttpr_count(lttpr_caps));
> - if (rc)
> - DRM_ERROR("failed to set LTTPRs transparency mode, rc=%d\n",
> rc);
> + lttpr_count = drm_dp_lttpr_count(dp->lttpr_common_caps);
> + rc = drm_dp_lttpr_init(dp->aux, lttpr_count);
> + if (rc) {
> + DRM_ERROR("fialed to set LTTPRs transparency mode, rc=%d\n",
> rc);
Nitpick: failed
With that fixed, LGTM:
Reviewed-by: Abel Vesa
> + return 0;
> + }
> +
> + return lttpr_count;
> }
>
> static int msm_dp_display_process_hpd_high(struct msm_dp_display_private *dp)
> @@ -385,12 +391,17 @@ static int msm_dp_display_process_hpd_high(struct
> msm_dp_display_private *dp)
> struct drm_connector *connector = dp->msm_dp_display.connector;
> const struct drm_display_info *info = &connector->display_info;
> int rc = 0;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
>
> - rc = msm_dp_panel_read_sink_caps(dp->panel, connector);
> + rc = drm_dp_read_dpcd_caps(dp->aux, dpcd);
> if (rc)
> goto end;
>
> - msm_dp_display_lttpr_init(dp);
> + msm_dp_display_lttpr_init(dp, dpcd);
> +
> + rc = msm_dp_panel_read_sink_caps(dp->panel, dp->lttpr_common_caps,
> connector);
> + if (rc)
> + goto end;
>
> msm_dp_link_process_request(dp->link);
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
> b/drivers/gpu/drm/msm/dp/dp_panel.c
> index 92415bf8aa16..f41b4cf7002e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -45,9 +45,12 @@ static void msm_dp_panel_read_psr_cap(struct
> msm_dp_panel_private *panel)
> }
> }
>
> -static int msm_dp_panel_read_dpcd(struct msm_dp_panel *msm_dp_panel)
> +static int msm_dp_panel_read_dpcd(struct msm_dp_panel *msm_dp_panel,
> + const u8
> lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE])
> {
> int rc;
> + int max_sink_lanes, max_source_lanes, max_lttpr_lanes;
> + int max_sink_rate, max_source_rate, max_lttpr_rate;
> struct msm_dp_panel_private *panel;
> struct msm_dp_link_info *link_info;
> u8 *dpcd, major, minor;
> @@ -64,16 +67,24 @@ static int msm_dp_panel_read_dpcd(struct msm_dp_panel
> *msm_dp_panel)
> major = (link_info->revision >> 4) & 0x0f;
> minor = link_info->revision & 0x0f;
>
> - link_info->rate = drm_dp_max_link_rate(dpcd);
> - link_info->num_lanes = drm_dp_max_lane_count(dpcd);
> + max_source_lanes = msm_dp_panel->max_dp_lanes;
> + max_source_rate = msm_dp_panel->max_dp_link_rate;
>
> - /* Limit data lanes from data-lanes of endpoint property of dtsi */
> - if (link_info->num_lanes > msm_dp_panel->max_dp_lanes)
> - link_info->num_lanes = msm_dp_panel->max_dp_lanes;
> + max_sink_lanes = drm_dp_max_lane_count(dpcd);
> + max_sink_rate = drm_dp_max_link_rate(dpcd);
> +
> + max_lttpr_lanes = drm_dp_lttpr_max_lane_count(lttpr_common_caps);
> + max_lttpr_rate = drm_dp_lttpr_max_link_rate(lttpr_common_caps);
>
> + if (max_lttpr_lanes)
> + max_sink_lanes = min(max_sink_lan
Re: [PATCH v1] arm64: defconfig: mediatek: enable PHY drivers
On 11/03/2025 07:16, Vignesh Raman wrote: > The mediatek display driver fails to probe on mt8173 and mt8183 in > v6.14-rc4, with the following errors: Which boards? > > mt8173: > platform 1401b000.dsi: deferred probe pending: mtk-dsi: Failed to get hs clock > platform 14025000.hdmi: deferred probe pending: (reason unknown) > i2c 1-0008: deferred probe pending: (reason unknown) > > mt8183: > platform 14014000.dsi: deferred probe pending: mtk-dsi: Failed to get hs clock > i2c 4-0058: deferred probe pending: anx7625: fail to find dsi host. > > Enabling CONFIG_PHY_MTK_MIPI_DSI=y in drm-ci resolves this error, > but mt8173 still fails with, > > [drm:mtk_dsi_host_attach] *ERROR* failed to add dsi_host component: -517 > panel-simple-dp-aux aux-1-0008: DP AUX done_probing() can't defer > panel-simple-dp-aux aux-1-0008: probe with driver panel-simple-dp-aux failed > with error -22 > > Enabling CONFIG_PHY_MTK_XSPHY=y and CONFIG_PHY_MTK_HDMI=y in drm-ci > resolves this issue for mt8173. > > So enable these PHY configs for mediatek platforms. Just say which boards need it for which functionality/features. Three sentences are enough. Best regards, Krzysztof
Re: linux-next: manual merge of the drm-xe tree with the mm tree
Hi Alistair, On Tue, 11 Mar 2025 16:57:49 +1100 Alistair Popple wrote: > > I'm not sure what the process is here, but having either reviewed or authored > these patches I can add that the fix up carried below looks correct. Thanks. This means that people can have a bit more confidence in the resulting linux-next tree (and so can I :-)) and when the merge requests are sent to Linus, they can just reference my resolution. -- Cheers, Stephen Rothwell pgpq7h94XMjXm.pgp Description: OpenPGP digital signature
Re: [PATCH v2] drm/panel/synaptics-r63353: Use _multi variants
On Mon, Mar 10, 2025 at 04:58:22PM -0400, Anusha Srivatsa wrote:
> Move away from using deprecated API and use _multi
> variants if available. Use mipi_dsi_msleep()
> and mipi_dsi_usleep_range() instead of msleep()
> and usleep_range() respectively.
>
> Used Coccinelle to find the multiple occurences.
> SmPl patch:
> @rule@
> identifier dsi_var;
> identifier r;
> identifier func;
> type t;
> position p;
> expression dsi_device;
> expression list es;
> @@
> t func(...) {
> ...
> struct mipi_dsi_device *dsi_var = dsi_device;
> +struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi_var };
> <+...
> (
> -mipi_dsi_dcs_write_seq(dsi_var,es)@p;
> +mipi_dsi_dcs_write_seq_multi(&dsi_ctx,es);
> |
> -mipi_dsi_generic_write_seq(dsi_var,es)@p;
> +mipi_dsi_generic_write_seq_multi(&dsi_ctx,es);
> |
> -mipi_dsi_generic_write(dsi_var,es)@p;
> +mipi_dsi_generic_write_multi(&dsi_ctx,es);
> |
> -r = mipi_dsi_dcs_nop(dsi_var)@p;
> +mipi_dsi_dcs_nop_multi(&dsi_ctx);
> |
> rest of API
> ..
> )
> -if(r < 0) {
> -...
> -}
> ...+>
Again, you need to provide the full coccinelle script here otherwise
it's useless. And I have serious doubts that it's actually the script
you used, because ...
> @@ -106,53 +107,46 @@ static int r63353_panel_power_off(struct r63353_panel
> *rpanel)
> static int r63353_panel_activate(struct r63353_panel *rpanel)
> {
> struct mipi_dsi_device *dsi = rpanel->dsi;
> - struct device *dev = &dsi->dev;
> - int i, ret;
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
> + int i;
>
> - ret = mipi_dsi_dcs_soft_reset(dsi);
> - if (ret < 0) {
> - dev_err(dev, "Failed to do Software Reset (%d)\n", ret);
> + mipi_dsi_dcs_soft_reset_multi(&dsi_ctx);
> + if (dsi_ctx.accum_err)
> goto fail;
> - }
This changes was definitely not what the script is doing.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v1 4/6] drm/panfrost: Add support for AARCH64_4K page table format
Il 11/03/25 09:05, Boris Brezillon ha scritto:
On Mon, 10 Mar 2025 16:59:19 -0300
Ariel D'Alessandro wrote:
Currently, Panfrost only supports MMU configuration in "LEGACY" (as
Bifrost calls it) mode, a (modified) version of LPAE "Large Physical
Address Extension", which in Linux we've called "mali_lpae".
This commit adds support for conditionally enabling AARCH64_4K page
table format. To achieve that, a "GPU optional configurations" field was
added to `struct panfrost_features` with the related flag.
Note that, in order to enable AARCH64_4K mode, the GPU variant must have
the HW_FEATURE_AARCH64_MMU feature flag present.
Signed-off-by: Ariel D'Alessandro
---
drivers/gpu/drm/panfrost/panfrost_device.h | 16 +++
drivers/gpu/drm/panfrost/panfrost_mmu.c| 132 +++--
drivers/gpu/drm/panfrost/panfrost_regs.h | 34 ++
3 files changed, 169 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index cffcb0ac7c111..0385702aa43c7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -42,6 +42,14 @@ enum panfrost_gpu_pm {
GPU_PM_VREG_OFF,
};
+/**
+ * enum panfrost_gpu_config - GPU optional configurations
+ * @GPU_CONFIG_AARCH64_4K: Use AARCH64_4K page table format
+ */
+enum panfrost_gpu_config {
+ GPU_CONFIG_AARCH64_4K,
+};
+
struct panfrost_features {
u16 id;
u16 revision;
@@ -95,6 +103,9 @@ struct panfrost_compatible {
/* Allowed PM features */
u8 pm_features;
+
+ /* GPU features */
+ u8 gpu_configs;
I would probably name this gpu_quirks, with the GPU_CONFIG_AARCH64_4K
flag renamed GPU_QUIRK_FORCE_AARCH64_PAGE_TABLE.
Boris, at this point the quirk should be LPAE, not AARCH64_4K, because the
former is legacy...
I think that Ariel is right in this, as in, that's a capability of the GPU
MMU, so if anything I would rather rename it to gpu_capabilities, but then
that'd be confusing for other stuff - which means that gpu_configs is most
probably the least confusing and/or most appropriate name for this.
Of course, just IMO.
Cheers,
Angelo
};
Re: [PATCH v5 1/2] drm/bridge: split HDMI Audio from DRM_BRIDGE_OP_HDMI
On Mon, Mar 10, 2025 at 08:42:29PM +0200, Dmitry Baryshkov wrote:
> On Mon, 10 Mar 2025 at 16:55, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Fri, Mar 07, 2025 at 07:55:52AM +0200, Dmitry Baryshkov wrote:
> > > From: Dmitry Baryshkov
> > >
> > > As pointed out by Laurent, OP bits are supposed to describe operations.
> > > Split DRM_BRIDGE_OP_HDMI_AUDIO from DRM_BRIDGE_OP_HDMI instead of
> > > overloading DRM_BRIDGE_OP_HDMI.
> > >
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/bridge/lontium-lt9611.c| 2 +-
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 1 +
> > > drivers/gpu/drm/display/drm_bridge_connector.c | 59
> > > +-
> > > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> > > include/drm/drm_bridge.h | 23 --
> > > 5 files changed, 61 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > b/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > index
> > > 026803034231f78c17f619dc04119bdd9b2b6679..3b93c17e25c18ae0d13e9bb74553cf21dcc39f9d
> > > 100644
> > > --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > @@ -1130,7 +1130,7 @@ static int lt9611_probe(struct i2c_client *client)
> > > lt9611->bridge.of_node = client->dev.of_node;
> > > lt9611->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
> > >DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_MODES |
> > > - DRM_BRIDGE_OP_HDMI;
> > > + DRM_BRIDGE_OP_HDMI | DRM_BRIDGE_OP_HDMI_AUDIO;
> > > lt9611->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > > lt9611->bridge.vendor = "Lontium";
> > > lt9611->bridge.product = "LT9611";
> > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > index
> > > 6166f197e37b552cb8a52b7b0d23ffc632f54557..5e5f8c2f95be1f5c4633f1093b17a00f9425bb37
> > > 100644
> > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > @@ -1077,6 +1077,7 @@ struct dw_hdmi_qp *dw_hdmi_qp_bind(struct
> > > platform_device *pdev,
> > > hdmi->bridge.ops = DRM_BRIDGE_OP_DETECT |
> > > DRM_BRIDGE_OP_EDID |
> > > DRM_BRIDGE_OP_HDMI |
> > > +DRM_BRIDGE_OP_HDMI_AUDIO |
> > > DRM_BRIDGE_OP_HPD;
> > > hdmi->bridge.of_node = pdev->dev.of_node;
> > > hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > > diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c
> > > b/drivers/gpu/drm/display/drm_bridge_connector.c
> > > index
> > > 30c736fc0067e31a97db242e5b16ea8a5b4cf359..030f98d454608a63154827c65d4822d378df3b4c
> > > 100644
> > > --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> > > +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
> > > @@ -98,6 +98,13 @@ struct drm_bridge_connector {
> > >* HDMI connector infrastructure, if any (see &DRM_BRIDGE_OP_HDMI).
> > >*/
> > > struct drm_bridge *bridge_hdmi;
> > > + /**
> > > + * @bridge_hdmi_audio:
> > > + *
> > > + * The bridge in the chain that implements necessary support for the
> > > + * HDMI Audio infrastructure, if any (see
> > > &DRM_BRIDGE_OP_HDMI_AUDIO).
> > > + */
> > > + struct drm_bridge *bridge_hdmi_audio;
> > > };
> > >
> > > #define to_drm_bridge_connector(x) \
> > > @@ -433,7 +440,7 @@ static int drm_bridge_connector_audio_startup(struct
> > > drm_connector *connector)
> > > to_drm_bridge_connector(connector);
> > > struct drm_bridge *bridge;
> > >
> > > - bridge = bridge_connector->bridge_hdmi;
> > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > if (!bridge)
> > > return -EINVAL;
> > >
> > > @@ -451,7 +458,7 @@ static int drm_bridge_connector_audio_prepare(struct
> > > drm_connector *connector,
> > > to_drm_bridge_connector(connector);
> > > struct drm_bridge *bridge;
> > >
> > > - bridge = bridge_connector->bridge_hdmi;
> > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > if (!bridge)
> > > return -EINVAL;
> > >
> > > @@ -464,7 +471,7 @@ static void
> > > drm_bridge_connector_audio_shutdown(struct drm_connector *connector)
> > > to_drm_bridge_connector(connector);
> > > struct drm_bridge *bridge;
> > >
> > > - bridge = bridge_connector->bridge_hdmi;
> > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > if (!bridge)
> > > return;
> > >
> > > @@ -478,7 +485,7 @@ static int
> > > drm_bridge_connector_audio_mute_stream(struct drm_connector *connecto
> > > to_drm_bridge_connector(connector);
> > > struct drm_bridge *bridge;
> > >
> > > - bridge = bridge_connector->bridge_hdmi;
> > > + bridge = bridge_c
Re: [PATCH v7 2/6] drm/xe/xe_gt_pagefault: Migrate pagefault struct to header
On 10.03.2025 22:30, Cavitt, Jonathan wrote: > -Original Message- > From: Wajdeczko, Michal > Sent: Monday, March 10, 2025 11:20 AM > To: Cavitt, Jonathan ; > intel...@lists.freedesktop.org > Cc: Gupta, saurabhg ; Zuo, Alex > ; joonas.lahti...@linux.intel.com; Brost, Matthew > ; Zhang, Jianxun ; Lin, > Shuicheng ; dri-devel@lists.freedesktop.org > Subject: Re: [PATCH v7 2/6] drm/xe/xe_gt_pagefault: Migrate pagefault struct > to header >>> >>> On 10.03.2025 18:18, Jonathan Cavitt wrote: Migrate the pagefault struct from xe_gt_pagefault.c to the >>> >>> nit: we use "migrate" verb for different purposes. >>> maybe here (and in the title) the plain "move" will be better? >>> xe_gt_pagefault.h header file, along with the associated enum values. >>> >>> hmm, all other components have foo_types.h header file as place for own >>> types and use foo.h header only for function declarations. >>> >>> why are we doing it differently here? > > xe_gt_pagefault_types.h does not exist and would have to be created to > satisfy this > request. It would also basically only contain the below xe_pagefault struct > and its > related enums. Is this amenable? it's about the idea, it doesn't matter not how many items you will put there. You can take a look at few other "small" types.h files: $ ls -S -1 *types.h | tail -5 xe_ring_ops_types.h xe_huc_types.h xe_gt_stats_types.h xe_sa_types.h xe_bb_types.h
Re: [PATCH v1 2/2] drm/msm/dp: Introduce link training per-segment for LTTPRs
Hi Aleksandrs,
Just a drive-by comment.
On Mon, Mar 10, 2025 at 10:05:52PM +0100, Aleksandrs Vinarskis wrote:
> @@ -1084,10 +1091,13 @@ static int msm_dp_ctrl_update_vx_px(struct
> msm_dp_ctrl_private *ctrl)
> }
>
> static bool msm_dp_ctrl_train_pattern_set(struct msm_dp_ctrl_private *ctrl,
> - u8 pattern)
> + u8 pattern, enum drm_dp_phy dp_phy)
> {
> u8 buf;
> int ret = 0;
> + int reg = dp_phy == DP_PHY_DPRX ?
> + DP_TRAINING_PATTERN_SET :
> + DP_TRAINING_PATTERN_SET_PHY_REPEATER(dp_phy);
This is hardly readable; avoid using the ternary operator and split
declaration from non-trivial initialisation.
Johan
Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help)
Hi Christoph and Ryan,
Can you help us check vmap_pfn's pfn check is right? Did here mischecked
pfn_valid?
Thank you.
在 2025/3/11 17:02, Bingbu Cao 写道:
Christoph and Ryan,
Could you help check this? Thanks.
On 3/11/25 4:54 PM, Huan Yang wrote:
在 2025/3/11 16:42, Bingbu Cao 写道:
[You don't often get email from bingbu@linux.intel.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Huan,
Thanks for your response.
On 3/11/25 3:12 PM, Huan Yang wrote:
在 2025/3/11 14:40, Bingbu Cao 写道:
[You don't often get email from bingbu@linux.intel.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Huan Yang and Vivek,
I am trying to use udmabuf for my test, and I cannot vmap the udmabuf
buffers now. vmap_pfn_apply() will report a warning to complain that
the pfns are invalid.
I dump the pfn numbers as below:
[ 3365.399641] pg[0] pfn 1148695
[ 3365.399642] pg[1] pfn 1145057
[ 3365.399642] pg[2] pfn 1134070
[ 3365.399643] pg[3] pfn 1148700
[ 3365.399643] pg[4] pfn 1144871
[ 3365.399643] pg[5] pfn 1408686
[ 3365.399643] pg[6] pfn 1408683
...
[ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489
vmap_pfn_apply+0xb7/0xd0
[ 3365.399667] Modules linked in:...
[ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted
6.13.0-rc2-rvp #845
[ 3365.399752] Hardware name: Intel Corporation Client Platform/, BIOS
xxxFWI1.R00.3221.D83.2408120121 08/12/2024
[ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0
[ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23
3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff
ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00
[ 3365.399756] RSP: 0018:b9b50c32fad0 EFLAGS: 00010202
[ 3365.399757] RAX: 0001 RBX: 00118717 RCX:
[ 3365.399758] RDX: 8000 RSI: b9b50c358000 RDI:
[ 3365.399758] RBP: b9b50c32fae8 R08: b9b50c32fbd0 R09: 0001
[ 3365.399759] R10: 941602479288 R11: R12: b9b50c32fbd0
[ 3365.399759] R13: 941618665ac0 R14: b9b50c358000 R15: 941618665ac8
[ 3365.399760] FS: 7ff9e9ddd740() GS:94196f78()
knlGS:
[ 3365.399760] CS: 0010 DS: ES: CR0: 80050033
[ 3365.399761] CR2: 55fda5dc69d9 CR3: 0001544de003 CR4: 00f72ef0
[ 3365.399762] DR0: DR1: DR2:
[ 3365.399762] DR3: DR6: 07f0 DR7: 0400
[ 3365.399763] PKRU: 5554
[ 3365.399763] Call Trace:
[ 3365.399765]
[ 3365.399769] ? show_regs+0x6d/0x80
[ 3365.399773] ? __warn+0x97/0x160
[ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0
[ 3365.399777] ? report_bug+0x1ec/0x240
[ 3365.399782] ? handle_bug+0x63/0xa0
[ 3365.399784] ? exc_invalid_op+0x1d/0x80
[ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30
[ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0
[ 3365.399791] __apply_to_page_range+0x522/0x8a0
[ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10
[ 3365.399795] apply_to_page_range+0x18/0x20
[ 3365.399796] vmap_pfn+0x77/0xd0
[ 3365.399797] vmap_udmabuf+0xc5/0x110
[ 3365.399802] dma_buf_vmap+0x96/0x130
I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04,
then I can vmap the pages. Could you help what's wrong with that?
Sorry for that, as I reviewed pfn_valid, that's someting wired:
/**
* pfn_valid - check if there is a valid memory map entry for a PFN
* @pfn: the page frame number to check
*
* Check if there is a valid memory map entry aka struct page for the @pfn.
* Note, that availability of the memory map entry does not imply that
* there is actual usable memory at that @pfn. The struct page may
* represent a hole or an unusable page frame.
*
* Return: 1 for PFNs that have memory map entries and 0 otherwise
*/
So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But
vmap_pfn_apply in there:
static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
{
struct vmap_pfn_data *data = private;
unsigned long pfn = data->pfns[data->idx];
pte_t ptent;
if (WARN_ON_ONCE(pfn_valid(pfn)))
return -EINVAL;
ptent = pte_mkspecial(pfn_pte(pfn, data->prot));
set_pte_at(&init_mm, addr, pte, ptent);
data->idx++;
return 0;
}
Do it give a wrong check? maybe should fix by:
I guess not, it looks more like warning when you trying to vmap a
pfn which already took a valid entry in pte.
No, I think here check need pfn is valid, then can set it. If a pfn is invalid,
why we set it in PTE?
Also, I can't make sure.
BTW, can you fix it then retest?
Thank you.
However, the MM code is so complex for me, just my guess. :)
static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
{
struct vmap_pfn_data *data = private;
unsigned long pfn = data->pfns[data->idx];
Re: [PATCH 1/7] drm/ast: Replace AST_VIDMEM_SIZE_ with Linux SZ_ constants
On 05/03/2025 14:35, Thomas Zimmermann wrote:
Ast's AST_VIDMEM_SIZE_ constants enumerate supported video-memory
sizes from 8 MiB to 128 MiB. Replace them with Linux' SZ_ constants
of the same value. When expanded, the literal values remain the same.
The size constant for 128 MiB is unused and the default size is not
necessary. Remove both of them.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 8
drivers/gpu/drm/ast/ast_mm.c | 9 -
drivers/gpu/drm/ast/ast_post.c | 24
3 files changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index d2c2605d2728..2c7861835cfb 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -340,14 +340,6 @@ static inline void ast_set_index_reg_mask(struct
ast_device *ast, u32 base, u8 i
__ast_write8_i_masked(ast->ioregs, base, index, preserve_mask, val);
}
-#define AST_VIDMEM_SIZE_8M0x0080
-#define AST_VIDMEM_SIZE_16M 0x0100
-#define AST_VIDMEM_SIZE_32M 0x0200
-#define AST_VIDMEM_SIZE_64M 0x0400
-#define AST_VIDMEM_SIZE_128M 0x0800
-
-#define AST_VIDMEM_DEFAULT_SIZE AST_VIDMEM_SIZE_8M
-
struct ast_vbios_stdtable {
u8 misc;
u8 seq[4];
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 6dfe6d9777d4..20d833632a01 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -38,20 +38,19 @@ static u32 ast_get_vram_size(struct ast_device *ast)
u8 jreg;
u32 vram_size;
- vram_size = AST_VIDMEM_DEFAULT_SIZE;
jreg = ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xaa, 0xff);
switch (jreg & 3) {
case 0:
- vram_size = AST_VIDMEM_SIZE_8M;
+ vram_size = SZ_8M;
break;
case 1:
- vram_size = AST_VIDMEM_SIZE_16M;
+ vram_size = SZ_16M;
break;
case 2:
- vram_size = AST_VIDMEM_SIZE_32M;
+ vram_size = SZ_32M;
break;
case 3:
- vram_size = AST_VIDMEM_SIZE_64M;
+ vram_size = SZ_64M;
break;
}
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 91e85e457bdf..37568cf3822c 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -1075,16 +1075,16 @@ static void get_ddr3_info(struct ast_device *ast,
struct ast2300_dram_param *par
switch (param->vram_size) {
default:
- case AST_VIDMEM_SIZE_8M:
+ case SZ_8M:
param->dram_config |= 0x00;
break;
- case AST_VIDMEM_SIZE_16M:
+ case SZ_16M:
param->dram_config |= 0x04;
break;
- case AST_VIDMEM_SIZE_32M:
+ case SZ_32M:
param->dram_config |= 0x08;
break;
- case AST_VIDMEM_SIZE_64M:
+ case SZ_64M:
param->dram_config |= 0x0c;
break;
}
@@ -1446,16 +1446,16 @@ static void get_ddr2_info(struct ast_device *ast,
struct ast2300_dram_param *par
switch (param->vram_size) {
default:
- case AST_VIDMEM_SIZE_8M:
+ case SZ_8M:
param->dram_config |= 0x00;
break;
- case AST_VIDMEM_SIZE_16M:
+ case SZ_16M:
param->dram_config |= 0x04;
break;
- case AST_VIDMEM_SIZE_32M:
+ case SZ_32M:
param->dram_config |= 0x08;
break;
- case AST_VIDMEM_SIZE_64M:
+ case SZ_64M:
param->dram_config |= 0x0c;
break;
}
@@ -1635,19 +1635,19 @@ static void ast_post_chip_2300(struct ast_device *ast)
switch (temp & 0x0c) {
default:
case 0x00:
- param.vram_size = AST_VIDMEM_SIZE_8M;
+ param.vram_size = SZ_8M;
break;
case 0x04:
- param.vram_size = AST_VIDMEM_SIZE_16M;
+ param.vram_size = SZ_16M;
break;
case 0x08:
- param.vram_size = AST_VIDMEM_SIZE_32M;
+ param.vram_size = SZ_32M;
break;
case 0x0c:
- param.vram_size = AST_VIDMEM_SIZE_64M;
+ param.vram_size = SZ_64M;
break;
}
Re: [PATCH 3/7] drm/ast: Add VGACR99 register constants
On 05/03/2025 14:35, Thomas Zimmermann wrote:
Add register constants for VGACR99 and use them when detecting the
size of the VGA memory. Aligns the code with the programming manual.
Also replace literal size values with Linux' SZ_ size constants.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mm.c | 13 ++---
drivers/gpu/drm/ast/ast_reg.h | 1 +
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 8d8aac8c0814..3d03ef556d0a 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -35,9 +35,8 @@
static u32 ast_get_vram_size(struct ast_device *ast)
{
- u8 jreg;
u32 vram_size;
- u8 vgacraa;
+ u8 vgacr99, vgacraa;
vgacraa = ast_get_index_reg(ast, AST_IO_VGACRI, 0xaa);
switch (vgacraa & AST_IO_VGACRAA_VGAMEM_SIZE_MASK) {
@@ -55,16 +54,16 @@ static u32 ast_get_vram_size(struct ast_device *ast)
break;
}
- jreg = ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0x99, 0xff);
- switch (jreg & 0x03) {
+ vgacr99 = ast_get_index_reg(ast, AST_IO_VGACRI, 0x99);
+ switch (vgacr99 & AST_IO_VGACR99_VGAMEM_RSRV_MASK) {
case 1:
- vram_size -= 0x10;
+ vram_size -= SZ_1M;
break;
case 2:
- vram_size -= 0x20;
+ vram_size -= SZ_2M;
break;
case 3:
- vram_size -= 0x40;
+ vram_size -= SZ_4M;
break;
}
diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h
index 039b93bed19e..e15adaf3a80e 100644
--- a/drivers/gpu/drm/ast/ast_reg.h
+++ b/drivers/gpu/drm/ast/ast_reg.h
@@ -30,6 +30,7 @@
#define AST_IO_VGACRI (0x54)
#define AST_IO_VGACR80_PASSWORD (0xa8)
+#define AST_IO_VGACR99_VGAMEM_RSRV_MASKGENMASK(1, 0)
#define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1)
#define AST_IO_VGACRA1_MMIO_ENABLED BIT(2)
#define AST_IO_VGACRA3_DVO_ENABLEDBIT(7)
Re: [PATCH 4/7] drm/ast: cursor: Add helpers for computing location in video memory
On 05/03/2025 14:35, Thomas Zimmermann wrote:
The ast drivers stores the cursor image at the end of the video memory.
Add helpers to calculate the offset and size.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 21 +++--
drivers/gpu/drm/ast/ast_drv.h| 1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 139ab00dee8f..05e297f30b4e 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -45,6 +45,21 @@
#define AST_HWC_SIGNATURE_HOTSPOTX0x14
#define AST_HWC_SIGNATURE_HOTSPOTY0x18
+static unsigned long ast_cursor_vram_size(void)
+{
+ return AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE;
+}
+
+long ast_cursor_vram_offset(struct ast_device *ast)
+{
+ unsigned long size = ast_cursor_vram_size();
+
+ if (size > ast->vram_size)
+ return -EINVAL;
+
+ return PAGE_ALIGN_DOWN(ast->vram_size - size);
+}
+
static u32 ast_cursor_calculate_checksum(const void *src, unsigned int width,
unsigned int height)
{
u32 csum = 0;
@@ -276,7 +291,7 @@ int ast_cursor_plane_init(struct ast_device *ast)
struct drm_plane *cursor_plane = &ast_plane->base;
size_t size;
void __iomem *vaddr;
- u64 offset;
+ long offset;
int ret;
/*
@@ -290,7 +305,9 @@ int ast_cursor_plane_init(struct ast_device *ast)
return -ENOMEM;
vaddr = ast->vram + ast->vram_fb_available - size;
- offset = ast->vram_fb_available - size;
+ offset = ast_cursor_vram_offset(ast);
+ if (offset < 0)
+ return offset;
ret = ast_plane_init(dev, ast_plane, vaddr, offset, size,
0x01, &ast_cursor_plane_funcs,
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 2c7861835cfb..ec9ec77260e9 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -432,6 +432,7 @@ int ast_vga_output_init(struct ast_device *ast);
int ast_sil164_output_init(struct ast_device *ast);
/* ast_cursor.c */
+long ast_cursor_vram_offset(struct ast_device *ast);
int ast_cursor_plane_init(struct ast_device *ast);
/* ast dp501 */
Re: [PATCH v2 2/7] drm/ast: Add VGACRAA register constants
On 05/03/2025 17:30, Thomas Zimmermann wrote:
Add register constants for VGACRAA and use them when detecting the
size of the VGA memory. Aligns the code with the programming manual.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mm.c | 5 +++--
drivers/gpu/drm/ast/ast_reg.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 20d833632a01..8d8aac8c0814 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -37,9 +37,10 @@ static u32 ast_get_vram_size(struct ast_device *ast)
{
u8 jreg;
u32 vram_size;
+ u8 vgacraa;
- jreg = ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xaa, 0xff);
- switch (jreg & 3) {
+ vgacraa = ast_get_index_reg(ast, AST_IO_VGACRI, 0xaa);
+ switch (vgacraa & AST_IO_VGACRAA_VGAMEM_SIZE_MASK) {
case 0:
vram_size = SZ_8M;
break;
diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h
index bb2cc1d8b84e..039b93bed19e 100644
--- a/drivers/gpu/drm/ast/ast_reg.h
+++ b/drivers/gpu/drm/ast/ast_reg.h
@@ -33,6 +33,7 @@
#define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1)
#define AST_IO_VGACRA1_MMIO_ENABLED BIT(2)
#define AST_IO_VGACRA3_DVO_ENABLEDBIT(7)
+#define AST_IO_VGACRAA_VGAMEM_SIZE_MASKGENMASK(1, 0)
#define AST_IO_VGACRB6_HSYNC_OFF BIT(0)
#define AST_IO_VGACRB6_VSYNC_OFF BIT(1)
#define AST_IO_VGACRCB_HWC_16BPP BIT(0) /* set: ARGB, cleared: 2bpp
palette */
Re: [PATCH v2 3/7] drm/ast: Add VGACR99 register constants
On 05/03/2025 17:30, Thomas Zimmermann wrote:
Add register constants for VGACR99 and use them when detecting the
size of the VGA memory. Aligns the code with the programming manual.
Also replace literal size values with Linux' SZ_ size constants.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mm.c | 13 ++---
drivers/gpu/drm/ast/ast_reg.h | 1 +
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 8d8aac8c0814..3d03ef556d0a 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -35,9 +35,8 @@
static u32 ast_get_vram_size(struct ast_device *ast)
{
- u8 jreg;
u32 vram_size;
- u8 vgacraa;
+ u8 vgacr99, vgacraa;
vgacraa = ast_get_index_reg(ast, AST_IO_VGACRI, 0xaa);
switch (vgacraa & AST_IO_VGACRAA_VGAMEM_SIZE_MASK) {
@@ -55,16 +54,16 @@ static u32 ast_get_vram_size(struct ast_device *ast)
break;
}
- jreg = ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0x99, 0xff);
- switch (jreg & 0x03) {
+ vgacr99 = ast_get_index_reg(ast, AST_IO_VGACRI, 0x99);
+ switch (vgacr99 & AST_IO_VGACR99_VGAMEM_RSRV_MASK) {
case 1:
- vram_size -= 0x10;
+ vram_size -= SZ_1M;
break;
case 2:
- vram_size -= 0x20;
+ vram_size -= SZ_2M;
break;
case 3:
- vram_size -= 0x40;
+ vram_size -= SZ_4M;
break;
}
diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h
index 039b93bed19e..e15adaf3a80e 100644
--- a/drivers/gpu/drm/ast/ast_reg.h
+++ b/drivers/gpu/drm/ast/ast_reg.h
@@ -30,6 +30,7 @@
#define AST_IO_VGACRI (0x54)
#define AST_IO_VGACR80_PASSWORD (0xa8)
+#define AST_IO_VGACR99_VGAMEM_RSRV_MASKGENMASK(1, 0)
#define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1)
#define AST_IO_VGACRA1_MMIO_ENABLED BIT(2)
#define AST_IO_VGACRA3_DVO_ENABLEDBIT(7)
Re: [PATCH v2 5/7] drm/ast: Add helper for computing framebuffer location in video memory
On 05/03/2025 17:30, Thomas Zimmermann wrote:
The ast driver stores the primary plane's image in the framebuffer
memory up to where the cursor is located. Add helpers to calculate
the offset and size.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c3b950675485..4cac5c7f4547 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -51,6 +51,24 @@
#define AST_LUT_SIZE 256
+static unsigned long ast_fb_vram_offset(void)
+{
+ return 0; // with shmem, the primary plane is always at offset 0
+}
+
+static unsigned long ast_fb_vram_size(struct ast_device *ast)
+{
+ struct drm_device *dev = &ast->base;
+ unsigned long offset = ast_fb_vram_offset(); // starts at offset
+ long cursor_offset = ast_cursor_vram_offset(ast); // ends at cursor
offset
+
+ if (cursor_offset < 0)
+ cursor_offset = ast->vram_size; // no cursor; it's all ours
+ if (drm_WARN_ON_ONCE(dev, offset > cursor_offset))
+ return 0; // cannot legally happen; signal error
+ return cursor_offset - offset;
+}
+
static inline void ast_load_palette_index(struct ast_device *ast,
u8 index, u8 red, u8 green,
u8 blue)
@@ -609,9 +627,8 @@ static int ast_primary_plane_init(struct ast_device *ast)
struct ast_plane *ast_primary_plane = &ast->primary_plane;
struct drm_plane *primary_plane = &ast_primary_plane->base;
void __iomem *vaddr = ast->vram;
- u64 offset = 0; /* with shmem, the primary plane is always at offset 0
*/
- unsigned long cursor_size = roundup(AST_HWC_SIZE +
AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
- unsigned long size = ast->vram_fb_available - cursor_size;
+ u64 offset = ast_fb_vram_offset();
+ unsigned long size = ast_fb_vram_size(ast);
int ret;
ret = ast_plane_init(dev, ast_primary_plane, vaddr, offset, size,
@@ -942,7 +959,7 @@ static enum drm_mode_status
ast_mode_config_mode_valid(struct drm_device *dev,
struct ast_device *ast = to_ast_device(dev);
unsigned long fbsize, fbpages, max_fbpages;
- max_fbpages = (ast->vram_fb_available) >> PAGE_SHIFT;
+ max_fbpages = ast_fb_vram_size(ast) >> PAGE_SHIFT;
fbsize = mode->hdisplay * mode->vdisplay * max_bpp;
fbpages = DIV_ROUND_UP(fbsize, PAGE_SIZE);
Re: [PATCH v2 6/7] drm/ast: Remove vram_fb_available from struct ast_device
On 05/03/2025 17:30, Thomas Zimmermann wrote:
Helpers compute the offset and size of the available framebuffer
memory. Remove the obsolete field vram_fb_available from struct
ast_device. Also define the cursor-signature size next to its only
user.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
v2:
- initialize plane size
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 18 --
drivers/gpu/drm/ast/ast_drv.h| 4
drivers/gpu/drm/ast/ast_mm.c | 1 -
3 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 05e297f30b4e..cb0c48d47207 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -37,6 +37,7 @@
*/
/* define for signature structure */
+#define AST_HWC_SIGNATURE_SIZE SZ_32
#define AST_HWC_SIGNATURE_CHECKSUM0x00
#define AST_HWC_SIGNATURE_SizeX 0x04
#define AST_HWC_SIGNATURE_SizeY 0x08
@@ -289,25 +290,16 @@ int ast_cursor_plane_init(struct ast_device *ast)
struct ast_cursor_plane *ast_cursor_plane = &ast->cursor_plane;
struct ast_plane *ast_plane = &ast_cursor_plane->base;
struct drm_plane *cursor_plane = &ast_plane->base;
- size_t size;
+ unsigned long size;
void __iomem *vaddr;
long offset;
int ret;
- /*
-* Allocate backing storage for cursors. The BOs are permanently
-* pinned to the top end of the VRAM.
-*/
-
- size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
-
- if (ast->vram_fb_available < size)
- return -ENOMEM;
-
- vaddr = ast->vram + ast->vram_fb_available - size;
+ size = ast_cursor_vram_size();
offset = ast_cursor_vram_offset(ast);
if (offset < 0)
return offset;
+ vaddr = ast->vram + offset;
ret = ast_plane_init(dev, ast_plane, vaddr, offset, size,
0x01, &ast_cursor_plane_funcs,
@@ -320,7 +312,5 @@ int ast_cursor_plane_init(struct ast_device *ast)
drm_plane_helper_add(cursor_plane, &ast_cursor_plane_helper_funcs);
drm_plane_enable_fb_damage_clips(cursor_plane);
- ast->vram_fb_available -= size;
-
return 0;
}
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index ec9ec77260e9..d9da2328d46b 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -112,12 +112,9 @@ enum ast_config_mode {
#define AST_MAX_HWC_WIDTH 64
#define AST_MAX_HWC_HEIGHT64
-
#define AST_HWC_PITCH (AST_MAX_HWC_WIDTH * SZ_2)
#define AST_HWC_SIZE (AST_MAX_HWC_HEIGHT * AST_HWC_PITCH)
-#define AST_HWC_SIGNATURE_SIZE 32
-
/*
* Planes
*/
@@ -183,7 +180,6 @@ struct ast_device {
void __iomem*vram;
unsigned long vram_base;
unsigned long vram_size;
- unsigned long vram_fb_available;
struct mutex modeset_lock; /* Protects access to modeset I/O registers in ioregs */
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 3d03ef556d0a..0bc140319464 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -92,7 +92,6 @@ int ast_mm_init(struct ast_device *ast)
ast->vram_base = base;
ast->vram_size = vram_size;
- ast->vram_fb_available = vram_size;
return 0;
}
Re: [PATCH 02/10] drm/i915/display: Introduce HAS_CASF macro
On 3/4/2025 3:58 PM, Nemesa Garg wrote:
Add the macro for casf HAS_CASF.
A bit explanation about the macro and why is this introduced will be good.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_display_device.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
b/drivers/gpu/drm/i915/display/intel_display_device.h
index 717286981687..238488c4c3aa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -191,6 +191,7 @@ struct intel_display_platforms {
#define HAS_VRR(__display)(DISPLAY_VER(__display) >= 11)
#define HAS_AS_SDP(__display) (DISPLAY_VER(__display) >= 13)
#define HAS_CMRR(__display) (DISPLAY_VER(__display) >= 20)
+#define HAS_CASF(__display)(DISPLAY_VER(__display) >= 20)
I think all other macros are in alphabetical order so would be good to
follow suite.
CMRR and AS_SDP are the exception, for which I am partly to be blamed as
a reviwer.
But lets do the right thing for CASF.
Regards,
Ankit
#define INTEL_NUM_PIPES(__display)
(hweight8(DISPLAY_RUNTIME_INFO(__display)->pipe_mask))
#define I915_HAS_HOTPLUG(__display) (DISPLAY_INFO(__display)->has_hotplug)
#define OVERLAY_NEEDS_PHYSICAL(__display)
(DISPLAY_INFO(__display)->overlay_needs_physical)
Re: [PATCH v2 7/7] drm/ast: cursor: Drop page alignment
On 05/03/2025 17:30, Thomas Zimmermann wrote: The cursor scanout address requires alignment to a multiple of 8, but does not require page alignment. Change the offset calculation accordingly. Frees up a few more bytes for the primary framebuffer. The framebuffer is page aligned, so I'm not sure you can use the extra bytes. Otherwise, it looks good to me. Reviewed-by: Jocelyn Falempe Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_cursor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c index cb0c48d47207..5ee724bfd682 100644 --- a/drivers/gpu/drm/ast/ast_cursor.c +++ b/drivers/gpu/drm/ast/ast_cursor.c @@ -58,7 +58,7 @@ long ast_cursor_vram_offset(struct ast_device *ast) if (size > ast->vram_size) return -EINVAL; - return PAGE_ALIGN_DOWN(ast->vram_size - size); + return ALIGN_DOWN(ast->vram_size - size, SZ_8); } static u32 ast_cursor_calculate_checksum(const void *src, unsigned int width, unsigned int height)
Re: [PATCH v5 1/2] drm/bridge: split HDMI Audio from DRM_BRIDGE_OP_HDMI
On Tue, Mar 11, 2025 at 05:50:09PM +0200, Dmitry Baryshkov wrote:
> On Tue, Mar 11, 2025 at 09:36:37AM +0100, Maxime Ripard wrote:
> > On Mon, Mar 10, 2025 at 08:42:29PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, 10 Mar 2025 at 16:55, Maxime Ripard wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Fri, Mar 07, 2025 at 07:55:52AM +0200, Dmitry Baryshkov wrote:
> > > > > From: Dmitry Baryshkov
> > > > >
> > > > > As pointed out by Laurent, OP bits are supposed to describe
> > > > > operations.
> > > > > Split DRM_BRIDGE_OP_HDMI_AUDIO from DRM_BRIDGE_OP_HDMI instead of
> > > > > overloading DRM_BRIDGE_OP_HDMI.
> > > > >
> > > > > Signed-off-by: Dmitry Baryshkov
> > > > > ---
> > > > > drivers/gpu/drm/bridge/lontium-lt9611.c| 2 +-
> > > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 1 +
> > > > > drivers/gpu/drm/display/drm_bridge_connector.c | 59
> > > > > +-
> > > > > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> > > > > include/drm/drm_bridge.h | 23 --
> > > > > 5 files changed, 61 insertions(+), 25 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > > b/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > > index
> > > > > 026803034231f78c17f619dc04119bdd9b2b6679..3b93c17e25c18ae0d13e9bb74553cf21dcc39f9d
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > > +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > > @@ -1130,7 +1130,7 @@ static int lt9611_probe(struct i2c_client
> > > > > *client)
> > > > > lt9611->bridge.of_node = client->dev.of_node;
> > > > > lt9611->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
> > > > >DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_MODES |
> > > > > - DRM_BRIDGE_OP_HDMI;
> > > > > + DRM_BRIDGE_OP_HDMI |
> > > > > DRM_BRIDGE_OP_HDMI_AUDIO;
> > > > > lt9611->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > > > > lt9611->bridge.vendor = "Lontium";
> > > > > lt9611->bridge.product = "LT9611";
> > > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > > index
> > > > > 6166f197e37b552cb8a52b7b0d23ffc632f54557..5e5f8c2f95be1f5c4633f1093b17a00f9425bb37
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > > @@ -1077,6 +1077,7 @@ struct dw_hdmi_qp *dw_hdmi_qp_bind(struct
> > > > > platform_device *pdev,
> > > > > hdmi->bridge.ops = DRM_BRIDGE_OP_DETECT |
> > > > > DRM_BRIDGE_OP_EDID |
> > > > > DRM_BRIDGE_OP_HDMI |
> > > > > +DRM_BRIDGE_OP_HDMI_AUDIO |
> > > > > DRM_BRIDGE_OP_HPD;
> > > > > hdmi->bridge.of_node = pdev->dev.of_node;
> > > > > hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > > > > diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > > b/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > > index
> > > > > 30c736fc0067e31a97db242e5b16ea8a5b4cf359..030f98d454608a63154827c65d4822d378df3b4c
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > > +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > > @@ -98,6 +98,13 @@ struct drm_bridge_connector {
> > > > >* HDMI connector infrastructure, if any (see
> > > > > &DRM_BRIDGE_OP_HDMI).
> > > > >*/
> > > > > struct drm_bridge *bridge_hdmi;
> > > > > + /**
> > > > > + * @bridge_hdmi_audio:
> > > > > + *
> > > > > + * The bridge in the chain that implements necessary support
> > > > > for the
> > > > > + * HDMI Audio infrastructure, if any (see
> > > > > &DRM_BRIDGE_OP_HDMI_AUDIO).
> > > > > + */
> > > > > + struct drm_bridge *bridge_hdmi_audio;
> > > > > };
> > > > >
> > > > > #define to_drm_bridge_connector(x) \
> > > > > @@ -433,7 +440,7 @@ static int
> > > > > drm_bridge_connector_audio_startup(struct drm_connector *connector)
> > > > > to_drm_bridge_connector(connector);
> > > > > struct drm_bridge *bridge;
> > > > >
> > > > > - bridge = bridge_connector->bridge_hdmi;
> > > > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > > > if (!bridge)
> > > > > return -EINVAL;
> > > > >
> > > > > @@ -451,7 +458,7 @@ static int
> > > > > drm_bridge_connector_audio_prepare(struct drm_connector *connector,
> > > > > to_drm_bridge_connector(connector);
> > > > > struct drm_bridge *bridge;
> > > > >
> > > > > - bridge = bridge_connector->bridge_hdmi;
> > > > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > > > if (!bridge)
> > > > > return -EINVAL;
> > > > >
> > > > > @@ -464,7 +471,7 @@ static void
> > > > > drm_bridge_connector_audio_shutdown(struct drm_connector
[PATCH v4 14/25] drm/nouveau: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch to a multiple of 256. Signed-off-by: Thomas Zimmermann Reviewed-by: Lyude Paul Cc: Karol Herbst Cc: Lyude Paul Cc: Danilo Krummrich --- drivers/gpu/drm/nouveau/nouveau_display.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index add006fc8d81..daa2528f9c9a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include #include @@ -808,9 +809,9 @@ nouveau_display_dumb_create(struct drm_file *file_priv, struct drm_device *dev, uint32_t domain; int ret; - args->pitch = roundup(args->width * (args->bpp / 8), 256); - args->size = args->pitch * args->height; - args->size = roundup(args->size, PAGE_SIZE); + ret = drm_mode_size_dumb(dev, args, SZ_256, 0); + if (ret) + return ret; /* Use VRAM if there is any ; otherwise fallback to system memory */ if (nouveau_drm(dev)->client.device.info.ram_size != 0) -- 2.48.1
[PATCH v4 12/25] drm/mediatek: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch to a multiple of 8. Signed-off-by: Thomas Zimmermann Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Matthias Brugger Cc: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_gem.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_gem.c b/drivers/gpu/drm/mediatek/mtk_gem.c index a172456d1d7b..21e08fabfd7f 100644 --- a/drivers/gpu/drm/mediatek/mtk_gem.c +++ b/drivers/gpu/drm/mediatek/mtk_gem.c @@ -8,6 +8,7 @@ #include #include +#include #include #include #include @@ -124,15 +125,9 @@ int mtk_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev, struct mtk_gem_obj *mtk_gem; int ret; - args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8); - - /* -* Multiply 2 variables of different types, -* for example: args->size = args->spacing * args->height; -* may cause coverity issue with unintentional overflow. -*/ - args->size = args->pitch; - args->size *= args->height; + ret = drm_mode_size_dumb(dev, args, SZ_8, 0); + if (ret) + return ret; mtk_gem = mtk_gem_create(dev, args->size, false); if (IS_ERR(mtk_gem)) -- 2.48.1
[PATCH v4 24/25] drm/xen: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Cc: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1bda7ef606cc..fd2f250fbc33 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -414,8 +415,10 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
* object without pages etc.
* For details also see drm_gem_handle_create
*/
- args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- args->size = args->pitch * args->height;
+
+ ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+ if (ret)
+ return ret;
obj = xen_drm_front_gem_create(dev, args->size);
if (IS_ERR(obj)) {
--
2.48.1
[PATCH v4 02/25] drm/dumb-buffers: Provide helper to set pitch and size
Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
scanline pitch and allocation size. Implementations of struct
drm_driver.dumb_create can call the new helper for their size
computations.
There is currently quite a bit of code duplication among DRM's
memory managers. Each calculates scanline pitch and buffer size
from the given arguments, but the implementations are inconsistent
in how they treat alignment and format support. Later patches will
unify this code on top of drm_mode_size_dumb() as much as possible.
drm_mode_size_dumb() uses existing 4CC format helpers to interpret
the given color mode. This makes the dumb-buffer interface behave
similar the kernel's video= parameter. Current per-driver implementations
again likely have subtle differences or bugs in how they support color
modes.
The dumb-buffer UAPI is only specified for known color modes. These
values describe linear, single-plane RGB color formats or legacy index
formats. Other values should not be specified. But some user space
still does. So for unknown color modes, there are a number of known
exceptions for which drm_mode_size_dumb() calculates the pitch from
the bpp value, as before. All other values work the same but print
an error.
v4:
- use %u conversion specifier (Geert)
- list DRM_FORMAT_Dn in UAPI docs (Geert)
- avoid dmesg spamming with drm_warn_once() (Sima)
- add more information about bpp special case (Sima)
- clarify parameters for hardware alignment
- add a TODO item for DUMB_CREATE2
v3:
- document the UAPI semantics
- compute scanline pitch from for unknown color modes (Andy, Tomi)
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 28 ++
drivers/gpu/drm/drm_dumb_buffers.c | 132 +
include/drm/drm_dumb_buffers.h | 14 +++
include/uapi/drm/drm_mode.h| 50 ++-
4 files changed, 223 insertions(+), 1 deletion(-)
create mode 100644 include/drm/drm_dumb_buffers.h
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index c5a24e03..f1bd741b06dc 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -515,6 +515,34 @@ Contact: Douglas Anderson
Level: Starter
+Implement a new DUMB_CREATE2 ioctl
+--
+
+The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and
+framebuffer format, it only accepts a color mode of vague semantics. Assuming
+a linear framebuffer, the color mode gives and idea of the supported pixel
+format. But userspace effectively has to guess the correct values. It really
+only works reliable with framebuffers in XRGB. Userspace has begun to
+workaround these limitations by computing arbitrary format's buffer sizes and
+calculating their sizes in terms of XRGB pixels.
+
+One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM
+format and a format modifier to resolve the color mode's ambiguity. As
+framebuffers can be multi-planar, the new ioctl has to return the buffer size,
+pitch and GEM handle for each individual color plane.
+
+In the first step, the new ioctl can be limited to the current features of
+the existing DUMB_CREATE. Individual drivers can then be extended to support
+multi-planar formats. Rockchip might require this and would be a good
candidate.
+
+In addition to the kernel implementation, there must be user-space support
+for the new ioctl. There's code in Mesa that might be able to use the new
+call.
+
+Contact: Thomas Zimmermann
+
+Level: Advanced
+
Core refactorings
=
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
b/drivers/gpu/drm/drm_dumb_buffers.c
index 9916aaf5b3f2..97cd3dcb79f1 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -25,6 +25,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -57,6 +59,136 @@
* a hardware-specific ioctl to allocate suitable buffer objects.
*/
+static int drm_mode_align_dumb(struct drm_mode_create_dumb *args,
+ unsigned long hw_pitch_align,
+ unsigned long hw_size_align)
+{
+ u32 pitch = args->pitch;
+ u32 size;
+
+ if (!pitch)
+ return -EINVAL;
+
+ if (hw_pitch_align)
+ pitch = roundup(pitch, hw_pitch_align);
+
+ /* overflow checks for 32bit size calculations */
+ if (args->height > U32_MAX / pitch)
+ return -EINVAL;
+
+ if (!hw_size_align)
+ hw_size_align = PAGE_SIZE;
+ else if (!IS_ALIGNED(hw_size_align, PAGE_SIZE))
+ return -EINVAL; /* TODO: handle this if necessary */
+
+ size = ALIGN(args->height * pitch, hw_size_align);
+ if (!size)
+ return -EINVAL;
+
+ args->pitch = pitch;
+ args->size = size;
+
+ return 0;
+}
+
+/**
+ * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb
buffers
+ * @dev: DRM device
+ * @args
[PATCH v4 07/25] drm/exynos: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. No alignment required. Signed-off-by: Thomas Zimmermann Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Krzysztof Kozlowski Cc: Alim Akhtar --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 4787fee4696f..ffa1c02b4b1e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -11,6 +11,7 @@ #include #include +#include #include #include #include @@ -330,15 +331,16 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv, unsigned int flags; int ret; + ret = drm_mode_size_dumb(dev, args, 0, 0); + if (ret) + return ret; + /* * allocate memory to be used for framebuffer. * - this callback would be called by user application * with DRM_IOCTL_MODE_CREATE_DUMB command. */ - args->pitch = args->width * ((args->bpp + 7) / 8); - args->size = args->pitch * args->height; - if (is_drm_iommu_supported(dev)) flags = EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC; else -- 2.48.1
[PATCH v4 23/25] drm/xe: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch to a multiple of 8. Align the buffer size according to hardware requirements. Xe's internal calculation allowed for 64-bit wide buffer sizes, but the ioctl's internal checks always verified against 32-bit wide limits. Hance, it is safe to limit the driver code to 32-bit calculations as well. v3: - mention 32-bit calculation in commit description (Matthew) Signed-off-by: Thomas Zimmermann Reviewed-by: Matthew Auld Cc: Lucas De Marchi Cc: "Thomas Hellström" Cc: Rodrigo Vivi --- drivers/gpu/drm/xe/xe_bo.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c index 64f9c936eea0..471aab61176e 100644 --- a/drivers/gpu/drm/xe/xe_bo.c +++ b/drivers/gpu/drm/xe/xe_bo.c @@ -9,6 +9,7 @@ #include #include +#include #include #include #include @@ -2910,14 +2911,13 @@ int xe_bo_dumb_create(struct drm_file *file_priv, struct xe_device *xe = to_xe_device(dev); struct xe_bo *bo; uint32_t handle; - int cpp = DIV_ROUND_UP(args->bpp, 8); int err; u32 page_size = max_t(u32, PAGE_SIZE, xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K); - args->pitch = ALIGN(args->width * cpp, 64); - args->size = ALIGN(mul_u32_u32(args->pitch, args->height), - page_size); + err = drm_mode_size_dumb(dev, args, SZ_64, page_size); + if (err) + return err; bo = xe_bo_create_user(xe, NULL, NULL, args->size, DRM_XE_GEM_CPU_CACHING_WC, -- 2.48.1
[PATCH v4 20/25] drm/tegra: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Acked-by: Thierry Reding
Cc: Thierry Reding
Cc: Mikko Perttunen
---
drivers/gpu/drm/tegra/gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index ace3e5a805cf..4d88e71192fb 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
@@ -543,12 +544,13 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
int tegra_bo_dumb_create(struct drm_file *file, struct drm_device *drm,
struct drm_mode_create_dumb *args)
{
- unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
struct tegra_drm *tegra = drm->dev_private;
struct tegra_bo *bo;
+ int ret;
- args->pitch = round_up(min_pitch, tegra->pitch_align);
- args->size = args->pitch * args->height;
+ ret = drm_mode_size_dumb(drm, args, tegra->pitch_align, 0);
+ if (ret)
+ return ret;
bo = tegra_bo_create_with_handle(file, drm, args->size, 0,
&args->handle);
--
2.48.1
[PATCH v4 21/25] drm/virtio: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 4.
Signed-off-by: Thomas Zimmermann
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index dde8fc1a3689..5e5e38d53990 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -23,6 +23,7 @@
* WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
@@ -66,15 +67,14 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
struct virtio_gpu_object_params params = { 0 };
struct virtio_gpu_device *vgdev = dev->dev_private;
int ret;
- uint32_t pitch;
+
+ ret = drm_mode_size_dumb(dev, args, SZ_4, 0);
+ if (ret)
+ return ret;
if (args->bpp != 32)
return -EINVAL;
- pitch = args->width * 4;
- args->size = pitch * args->height;
- args->size = ALIGN(args->size, PAGE_SIZE);
-
params.format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB);
params.width = args->width;
params.height = args->height;
@@ -92,7 +92,6 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
if (ret)
goto fail;
- args->pitch = pitch;
return ret;
fail:
--
2.48.1
[PATCH v4 05/25] drm/gem-vram: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Inline code from drm_gem_vram_fill_create_dumb() without
the existing size computation. Align the pitch to a multiple of 8.
Only hibmc and vboxvideo use gem-vram. Hibmc invokes the call to
drm_gem_vram_fill_create_dumb() directly and is therefore not affected.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 22b1fe9c03b8..15cd564cbeac 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -582,10 +583,31 @@ int drm_gem_vram_driver_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
+ struct drm_gem_vram_object *gbo;
+ int ret;
+
if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
return -EINVAL;
- return drm_gem_vram_fill_create_dumb(file, dev, 0, 0, args);
+ ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+ if (ret)
+ return ret;
+
+ gbo = drm_gem_vram_create(dev, args->size, 0);
+ if (IS_ERR(gbo))
+ return PTR_ERR(gbo);
+
+ ret = drm_gem_handle_create(file, &gbo->bo.base, &args->handle);
+ if (ret)
+ goto err_drm_gem_object_put;
+
+ drm_gem_object_put(&gbo->bo.base);
+
+ return 0;
+
+err_drm_gem_object_put:
+ drm_gem_object_put(&gbo->bo.base);
+ return ret;
}
EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create);
--
2.48.1
[PATCH v4 19/25] drm/rockchip: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 64.
Signed-off-by: Thomas Zimmermann
Acked-by: Heiko Stuebner
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 6330b883efc3..3bd06202e232 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -403,13 +404,12 @@ int rockchip_gem_dumb_create(struct drm_file *file_priv,
struct drm_mode_create_dumb *args)
{
struct rockchip_gem_object *rk_obj;
- int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ int ret;
- /*
-* align to 64 bytes since Mali requires it.
-*/
- args->pitch = ALIGN(min_pitch, 64);
- args->size = args->pitch * args->height;
+ /* 64-byte alignment required by Mali */
+ ret = drm_mode_size_dumb(dev, args, SZ_64, 0);
+ if (ret)
+ return ret;
rk_obj = rockchip_gem_create_with_handle(file_priv, dev, args->size,
&args->handle);
--
2.48.1
[PATCH v4 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
---
drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index b47463473472..7ea0cd4f71d3 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -363,10 +364,12 @@ static int zynqmp_dpsub_dumb_create(struct drm_file
*file_priv,
struct drm_mode_create_dumb *args)
{
struct zynqmp_dpsub *dpsub = to_zynqmp_dpsub(drm);
- unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ int ret;
/* Enforce the alignment constraints of the DMA engine. */
- args->pitch = ALIGN(pitch, dpsub->dma_align);
+ ret = drm_mode_size_dumb(drm, args, dpsub->dma_align, 0);
+ if (ret)
+ return ret;
return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
}
--
2.48.1
Re: [PATCH v5 2/2] drm/msm/dp: reuse generic HDMI codec implementation
On Tue, Mar 11, 2025 at 09:41:13AM +0100, Maxime Ripard wrote:
> Hi,
>
> On Mon, Mar 10, 2025 at 08:53:24PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 10 Mar 2025 at 17:08, Maxime Ripard wrote:
> > >
> > > On Fri, Mar 07, 2025 at 07:55:53AM +0200, Dmitry Baryshkov wrote:
> > > > From: Dmitry Baryshkov
> > > >
> > > > The MSM DisplayPort driver implements several HDMI codec functions
> > > > in the driver, e.g. it manually manages HDMI codec device registration,
> > > > returning ELD and plugged_cb support. In order to reduce code
> > > > duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
> > > > integration.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov
> > > > ---
> > > > drivers/gpu/drm/msm/Kconfig | 1 +
> > > > drivers/gpu/drm/msm/dp/dp_audio.c | 131
> > > >
> > > > drivers/gpu/drm/msm/dp/dp_audio.h | 27 ++--
> > > > drivers/gpu/drm/msm/dp/dp_display.c | 28 ++--
> > > > drivers/gpu/drm/msm/dp/dp_display.h | 6 --
> > > > drivers/gpu/drm/msm/dp/dp_drm.c | 8 +++
> > > > 6 files changed, 31 insertions(+), 170 deletions(-)
> > > >
[...]
> > > >
> > > > static int msm_edp_bridge_atomic_check(struct drm_bridge *drm_bridge,
> > > > @@ -320,9 +324,13 @@ int msm_dp_bridge_init(struct msm_dp
> > > > *msm_dp_display, struct drm_device *dev,
> > > >*/
> > > > if (!msm_dp_display->is_edp) {
> > > > bridge->ops =
> > > > + DRM_BRIDGE_OP_HDMI_AUDIO |
> > > > DRM_BRIDGE_OP_DETECT |
> > > > DRM_BRIDGE_OP_HPD |
> > > > DRM_BRIDGE_OP_MODES;
> > > > + bridge->hdmi_audio_dev = &msm_dp_display->pdev->dev;
> > > > + bridge->hdmi_audio_max_i2s_playback_channels = 8;
> > > > + bridge->hdmi_audio_dai_port = -1;
> > > > }
> > >
> > > I think I'd prefer the toggle to be OP_DP_AUDIO, even if the
> > > implementation is exactly the same. That way, we'll be able to condition
> > > it to the DP support when that arrives, and we have the latitude to
> > > rework it to accomodate some DP subtleties without affecting the drivers
> > > later on.
> >
> > I don't think that there is a point in having OP_DP_AUDIO. There is
> > not so much difference in the driver. Also currently OP_HDMI_AUDIO
> > follows existing approach (which was pointed out by Laurent) - that
> > OP_foo should guard a particular set of callbacks. From this
> > perspective, OP_HDMI_AUDIO is fine - it guards usage of
> > hdmi_audio_foo(). OP_DP_AUDIO would duplicate that.
>
> HDMI and DP are two competing standards, with different governing
> bodies. I don't think either have claimed that they will strictly adhere
> to what the other is doing, and I don't have the will to cross-check
> every given audio feature in both HDMI and DP right now.
Hmm. Currently (or before the first hdmi_audio patchset) everybody has
been plumbing hdmi-codec directly from the driver (even for DP audio).
> However, I think we should really have the flexibility to deal with that
> situation if it happens, and without having to do any major refactoring.
> That means providing an API that is consistent to the drivers, and
> provides what the driver needs. Here, it needs DP audio support, not
> HDMI's.
Would OP_HDMI_CODEC be a better name for the OP? (we can rename the
existing callbacks to be hdmi_codec instead of hdmi_audio too).
> How we plumb it is an implementation detail, and I do agree we can use
> the same functions under the hood right now. But the driver is a DP
> driver, it wants DP infrastructure and DP audio support.
Would OP_DP_AUDIO require a different set of callbacks on the bridge
level? I don't want to end up with too much of duplication. Maybe we
should the cdns bridges which implement both HDMI and DP functionality
IIRC.
--
With best wishes
Dmitry
Re: [PATCH v2 7/7] drm/ast: cursor: Drop page alignment
Hi Am 11.03.25 um 14:10 schrieb Jocelyn Falempe: On 05/03/2025 17:30, Thomas Zimmermann wrote: The cursor scanout address requires alignment to a multiple of 8, but does not require page alignment. Change the offset calculation accordingly. Frees up a few more bytes for the primary framebuffer. The framebuffer is page aligned, so I'm not sure you can use the extra bytes. The GEM buffer located in system ram is page aligned, so that mmap works as expected. But the scanout buffer in VRAM doesn't have to be as we don't ever mmap that to user space. The cursor scanout address only requires an alignment of 8. The damage handling only copies visible bytes, hence we don't accidentally overwrite cursor bytes when we copy the primary plane. So this should all be fine. The driver likely requires an improved version of ast_mode_config_mode_valid() to really use these extra bytes. I've been working on this a bit. I think this might not make much of a difference on most machines, but there are lowest-of-the-low-end systems with only 4 MiB of VRAM available. Maybe there's a case where those additional bytes will be useful. Otherwise, it looks good to me. Reviewed-by: Jocelyn Falempe Thanks for reviewing, BTW Best regards Thomas Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_cursor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c index cb0c48d47207..5ee724bfd682 100644 --- a/drivers/gpu/drm/ast/ast_cursor.c +++ b/drivers/gpu/drm/ast/ast_cursor.c @@ -58,7 +58,7 @@ long ast_cursor_vram_offset(struct ast_device *ast) if (size > ast->vram_size) return -EINVAL; - return PAGE_ALIGN_DOWN(ast->vram_size - size); + return ALIGN_DOWN(ast->vram_size - size, SZ_8); } static u32 ast_cursor_calculate_checksum(const void *src, unsigned int width, unsigned int height) -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Re: [PATCH v5 1/2] drm/bridge: split HDMI Audio from DRM_BRIDGE_OP_HDMI
On Tue, Mar 11, 2025 at 09:36:37AM +0100, Maxime Ripard wrote:
> On Mon, Mar 10, 2025 at 08:42:29PM +0200, Dmitry Baryshkov wrote:
> > On Mon, 10 Mar 2025 at 16:55, Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Fri, Mar 07, 2025 at 07:55:52AM +0200, Dmitry Baryshkov wrote:
> > > > From: Dmitry Baryshkov
> > > >
> > > > As pointed out by Laurent, OP bits are supposed to describe operations.
> > > > Split DRM_BRIDGE_OP_HDMI_AUDIO from DRM_BRIDGE_OP_HDMI instead of
> > > > overloading DRM_BRIDGE_OP_HDMI.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov
> > > > ---
> > > > drivers/gpu/drm/bridge/lontium-lt9611.c| 2 +-
> > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 1 +
> > > > drivers/gpu/drm/display/drm_bridge_connector.c | 59
> > > > +-
> > > > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
> > > > include/drm/drm_bridge.h | 23 --
> > > > 5 files changed, 61 insertions(+), 25 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > b/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > index
> > > > 026803034231f78c17f619dc04119bdd9b2b6679..3b93c17e25c18ae0d13e9bb74553cf21dcc39f9d
> > > > 100644
> > > > --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> > > > @@ -1130,7 +1130,7 @@ static int lt9611_probe(struct i2c_client *client)
> > > > lt9611->bridge.of_node = client->dev.of_node;
> > > > lt9611->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
> > > >DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_MODES |
> > > > - DRM_BRIDGE_OP_HDMI;
> > > > + DRM_BRIDGE_OP_HDMI |
> > > > DRM_BRIDGE_OP_HDMI_AUDIO;
> > > > lt9611->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > > > lt9611->bridge.vendor = "Lontium";
> > > > lt9611->bridge.product = "LT9611";
> > > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > index
> > > > 6166f197e37b552cb8a52b7b0d23ffc632f54557..5e5f8c2f95be1f5c4633f1093b17a00f9425bb37
> > > > 100644
> > > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > > @@ -1077,6 +1077,7 @@ struct dw_hdmi_qp *dw_hdmi_qp_bind(struct
> > > > platform_device *pdev,
> > > > hdmi->bridge.ops = DRM_BRIDGE_OP_DETECT |
> > > > DRM_BRIDGE_OP_EDID |
> > > > DRM_BRIDGE_OP_HDMI |
> > > > +DRM_BRIDGE_OP_HDMI_AUDIO |
> > > > DRM_BRIDGE_OP_HPD;
> > > > hdmi->bridge.of_node = pdev->dev.of_node;
> > > > hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> > > > diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > b/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > index
> > > > 30c736fc0067e31a97db242e5b16ea8a5b4cf359..030f98d454608a63154827c65d4822d378df3b4c
> > > > 100644
> > > > --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
> > > > @@ -98,6 +98,13 @@ struct drm_bridge_connector {
> > > >* HDMI connector infrastructure, if any (see
> > > > &DRM_BRIDGE_OP_HDMI).
> > > >*/
> > > > struct drm_bridge *bridge_hdmi;
> > > > + /**
> > > > + * @bridge_hdmi_audio:
> > > > + *
> > > > + * The bridge in the chain that implements necessary support for
> > > > the
> > > > + * HDMI Audio infrastructure, if any (see
> > > > &DRM_BRIDGE_OP_HDMI_AUDIO).
> > > > + */
> > > > + struct drm_bridge *bridge_hdmi_audio;
> > > > };
> > > >
> > > > #define to_drm_bridge_connector(x) \
> > > > @@ -433,7 +440,7 @@ static int
> > > > drm_bridge_connector_audio_startup(struct drm_connector *connector)
> > > > to_drm_bridge_connector(connector);
> > > > struct drm_bridge *bridge;
> > > >
> > > > - bridge = bridge_connector->bridge_hdmi;
> > > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > > if (!bridge)
> > > > return -EINVAL;
> > > >
> > > > @@ -451,7 +458,7 @@ static int
> > > > drm_bridge_connector_audio_prepare(struct drm_connector *connector,
> > > > to_drm_bridge_connector(connector);
> > > > struct drm_bridge *bridge;
> > > >
> > > > - bridge = bridge_connector->bridge_hdmi;
> > > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > > if (!bridge)
> > > > return -EINVAL;
> > > >
> > > > @@ -464,7 +471,7 @@ static void
> > > > drm_bridge_connector_audio_shutdown(struct drm_connector *connector)
> > > > to_drm_bridge_connector(connector);
> > > > struct drm_bridge *bridge;
> > > >
> > > > - bridge = bridge_connector->bridge_hdmi;
> > > > + bridge = bridge_connector->bridge_hdmi_audio;
> > > > if (!bridge)
> > > > return;
>
Re: [PATCH v2] drm/panthor: Make the timeout per-queue instead of per-job
On 10/03/2025 13:30, Ashley Smith wrote:
> The timeout logic provided by drm_sched leads to races when we try
> to suspend it while the drm_sched workqueue queues more jobs. Let's
> overhaul the timeout handling in panthor to have our own delayed work
> that's resumed/suspended when a group is resumed/suspended. When an
> actual timeout occurs, we call drm_sched_fault() to report it
> through drm_sched, still. But otherwise, the drm_sched timeout is
> disabled (set to MAX_SCHEDULE_TIMEOUT), which leaves us in control of
> how we protect modifications on the timer.
>
> One issue seems to be when we call drm_sched_suspend_timeout() from
> both queue_run_job() and tick_work() which could lead to races due to
> drm_sched_suspend_timeout() not having a lock. Another issue seems to
> be in queue_run_job() if the group is not scheduled, we suspend the
> timeout again which undoes what drm_sched_job_begin() did when calling
> drm_sched_start_timeout(). So the timeout does not reset when a job
> is finished.
>
> Co-developed-by: Boris Brezillon
> Signed-off-by: Boris Brezillon
> Tested-by: Daniel Stone
> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> Signed-off-by: Ashley Smith
Reviewed-by: Steven Price
Steve
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 233 +---
> 1 file changed, 167 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index 4d31d1967716..5f02d2ec28f9 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -360,17 +360,20 @@ struct panthor_queue {
> /** @entity: DRM scheduling entity used for this queue. */
> struct drm_sched_entity entity;
>
> - /**
> - * @remaining_time: Time remaining before the job timeout expires.
> - *
> - * The job timeout is suspended when the queue is not scheduled by the
> - * FW. Every time we suspend the timer, we need to save the remaining
> - * time so we can restore it later on.
> - */
> - unsigned long remaining_time;
> + /** @timeout: Queue timeout related fields. */
> + struct {
> + /** @timeout.work: Work executed when a queue timeout occurs. */
> + struct delayed_work work;
>
> - /** @timeout_suspended: True if the job timeout was suspended. */
> - bool timeout_suspended;
> + /**
> + * @timeout.remaining: Time remaining before a queue timeout.
> + *
> + * When the timer is running, this value is set to
> MAX_SCHEDULE_TIMEOUT.
> + * When the timer is suspended, it's set to the time remaining
> when the
> + * timer was suspended.
> + */
> + unsigned long remaining;
> + } timeout;
>
> /**
>* @doorbell_id: Doorbell assigned to this queue.
> @@ -1031,6 +1034,82 @@ group_unbind_locked(struct panthor_group *group)
> return 0;
> }
>
> +static bool
> +group_is_idle(struct panthor_group *group)
> +{
> + struct panthor_device *ptdev = group->ptdev;
> + u32 inactive_queues;
> +
> + if (group->csg_id >= 0)
> + return ptdev->scheduler->csg_slots[group->csg_id].idle;
> +
> + inactive_queues = group->idle_queues | group->blocked_queues;
> + return hweight32(inactive_queues) == group->queue_count;
> +}
> +
> +static void
> +queue_suspend_timeout(struct panthor_queue *queue)
> +{
> + unsigned long qtimeout, now;
> + struct panthor_group *group;
> + struct panthor_job *job;
> + bool timer_was_active;
> +
> + spin_lock(&queue->fence_ctx.lock);
> +
> + /* Already suspended, nothing to do. */
> + if (queue->timeout.remaining != MAX_SCHEDULE_TIMEOUT)
> + goto out_unlock;
> +
> + job = list_first_entry_or_null(&queue->fence_ctx.in_flight_jobs,
> +struct panthor_job, node);
> + group = job ? job->group : NULL;
> +
> + /* If the queue is blocked and the group is idle, we want the timer to
> + * keep running because the group can't be unblocked by other queues,
> + * so it has to come from an external source, and we want to timebox
> + * this external signalling.
> + */
> + if (group && (group->blocked_queues & BIT(job->queue_idx)) &&
> + group_is_idle(group))
> + goto out_unlock;
> +
> + now = jiffies;
> + qtimeout = queue->timeout.work.timer.expires;
> +
> + /* Cancel the timer. */
> + timer_was_active = cancel_delayed_work(&queue->timeout.work);
> + if (!timer_was_active || !job)
> + queue->timeout.remaining = msecs_to_jiffies(JOB_TIMEOUT_MS);
> + else if (time_after(qtimeout, now))
> + queue->timeout.remaining = qtimeout - now;
> + else
> + queue->timeout.remaining = 0;
> +
> + if (WARN_ON_ONCE(queue->timeout.remaining >
> msecs_to_jiffies(J
Re: [PATCH v7 2/6] drm/xe/xe_gt_pagefault: Migrate pagefault struct to header
On 10.03.2025 18:18, Jonathan Cavitt wrote:
> Migrate the pagefault struct from xe_gt_pagefault.c to the
nit: we use "migrate" verb for different purposes.
maybe here (and in the title) the plain "move" will be better?
> xe_gt_pagefault.h header file, along with the associated enum values.
hmm, all other components have foo_types.h header file as place for own
types and use foo.h header only for function declarations.
why are we doing it differently here?
>
> v2: Normalize names for common header (Matt Brost)
>
> Signed-off-by: Jonathan Cavitt
> ---
> drivers/gpu/drm/xe/xe_gt_pagefault.c | 41 +---
> drivers/gpu/drm/xe/xe_gt_pagefault.h | 28 +++
> 2 files changed, 35 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_gt_pagefault.c
> b/drivers/gpu/drm/xe/xe_gt_pagefault.c
> index a4e688e72efd..c8a9058aa09f 100644
> --- a/drivers/gpu/drm/xe/xe_gt_pagefault.c
> +++ b/drivers/gpu/drm/xe/xe_gt_pagefault.c
> @@ -23,33 +23,6 @@
> #include "xe_trace_bo.h"
> #include "xe_vm.h"
>
> -struct pagefault {
> - u64 page_addr;
> - u32 asid;
> - u16 pdata;
> - u8 vfid;
> - u8 access_type;
> - u8 fault_type;
> - u8 fault_level;
> - u8 engine_class;
> - u8 engine_instance;
> - u8 fault_unsuccessful;
> - bool trva_fault;
> -};
> -
> -enum access_type {
> - ACCESS_TYPE_READ = 0,
> - ACCESS_TYPE_WRITE = 1,
> - ACCESS_TYPE_ATOMIC = 2,
> - ACCESS_TYPE_RESERVED = 3,
> -};
> -
> -enum fault_type {
> - NOT_PRESENT = 0,
> - WRITE_ACCESS_VIOLATION = 1,
> - ATOMIC_ACCESS_VIOLATION = 2,
> -};
> -
> struct acc {
> u64 va_range_base;
> u32 asid;
> @@ -61,9 +34,9 @@ struct acc {
> u8 engine_instance;
> };
>
> -static bool access_is_atomic(enum access_type access_type)
> +static bool access_is_atomic(enum xe_pagefault_access_type access_type)
> {
> - return access_type == ACCESS_TYPE_ATOMIC;
> + return access_type == XE_PAGEFAULT_ACCESS_TYPE_ATOMIC;
> }
>
> static bool vma_is_valid(struct xe_tile *tile, struct xe_vma *vma)
> @@ -205,7 +178,7 @@ static struct xe_vm *asid_to_vm(struct xe_device *xe, u32
> asid)
> return vm;
> }
>
> -static int handle_pagefault(struct xe_gt *gt, struct pagefault *pf)
> +static int handle_pagefault(struct xe_gt *gt, struct xe_pagefault *pf)
> {
> struct xe_device *xe = gt_to_xe(gt);
> struct xe_vm *vm;
> @@ -237,7 +210,7 @@ static int handle_pagefault(struct xe_gt *gt, struct
> pagefault *pf)
> goto unlock_vm;
> }
>
> - if (xe_vma_read_only(vma) && pf->access_type != ACCESS_TYPE_READ) {
> + if (xe_vma_read_only(vma) && pf->access_type !=
> XE_PAGEFAULT_ACCESS_TYPE_READ) {
> err = -EPERM;
> goto unlock_vm;
> }
> @@ -271,7 +244,7 @@ static int send_pagefault_reply(struct xe_guc *guc,
> return xe_guc_ct_send(&guc->ct, action, ARRAY_SIZE(action), 0, 0);
> }
>
> -static void print_pagefault(struct xe_device *xe, struct pagefault *pf)
> +static void print_pagefault(struct xe_device *xe, struct xe_pagefault *pf)
> {
> drm_dbg(&xe->drm, "\n\tASID: %d\n"
>"\tVFID: %d\n"
> @@ -291,7 +264,7 @@ static void print_pagefault(struct xe_device *xe, struct
> pagefault *pf)
>
> #define PF_MSG_LEN_DW4
>
> -static bool get_pagefault(struct pf_queue *pf_queue, struct pagefault *pf)
> +static bool get_pagefault(struct pf_queue *pf_queue, struct xe_pagefault *pf)
> {
> const struct xe_guc_pagefault_desc *desc;
> bool ret = false;
> @@ -378,7 +351,7 @@ static void pf_queue_work_func(struct work_struct *w)
> struct xe_gt *gt = pf_queue->gt;
> struct xe_device *xe = gt_to_xe(gt);
> struct xe_guc_pagefault_reply reply = {};
> - struct pagefault pf = {};
> + struct xe_pagefault pf = {};
> unsigned long threshold;
> int ret;
>
> diff --git a/drivers/gpu/drm/xe/xe_gt_pagefault.h
> b/drivers/gpu/drm/xe/xe_gt_pagefault.h
> index 839c065a5e4c..33616043d17a 100644
> --- a/drivers/gpu/drm/xe/xe_gt_pagefault.h
> +++ b/drivers/gpu/drm/xe/xe_gt_pagefault.h
> @@ -11,6 +11,34 @@
> struct xe_gt;
> struct xe_guc;
>
> +struct xe_pagefault {
shouldn't this be "xe_gt_pagefault" ?
all functions seem to be related to the gt
> + u64 page_addr;
> + u32 asid;
> + u16 pdata;
> + u8 vfid;
> + u8 access_type;
> + u8 fault_type;
> + u8 fault_level;
> + u8 engine_class;
> + u8 engine_instance;
> + u8 fault_unsuccessful;
> + bool prefetch;
> + bool trva_fault;
> +};
missing kernel-doc (for struct and members)
and for below enums
> +
> +enum xe_pagefault_access_type {
> + XE_PAGEFAULT_ACCESS_TYPE_READ = 0,
> + XE_PAGEFAULT_ACCESS_TYPE_WRITE = 1,
> + XE_PAGEFAULT_ACCESS_TYPE_ATOMIC = 2,
> + XE_PAGEFAULT_ACCESS_TYPE_RESERVED = 3,
> +};
> +
> +enum xe_pagefault_type {
> + XE_PAGEFAULT_TYPE_NOT_PRESENT = 0,
> + XE_PAGEFAULT_TY
Re: [PATCH v2] drm/panel/synaptics-r63353: Use _multi variants
Hi,
On Mon, Mar 10, 2025 at 1:58 PM Anusha Srivatsa wrote:
>
> @@ -70,6 +70,7 @@ static int r63353_panel_power_on(struct r63353_panel
> *rpanel)
> {
> struct mipi_dsi_device *dsi = rpanel->dsi;
> struct device *dev = &dsi->dev;
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
> int ret;
>
> ret = regulator_enable(rpanel->avdd);
> @@ -78,7 +79,7 @@ static int r63353_panel_power_on(struct r63353_panel
> *rpanel)
> return ret;
> }
>
> - usleep_range(15000, 25000);
> + mipi_dsi_usleep_range(&dsi_ctx, 15000, 25000);
No. None of the conversions in this function are correct.
mipi_dsi_usleep_range() is only for use when you're in the middle of a
bunch of other "multi" calls and want the sleep to be conditional upon
there being no error. Here there is no chance of an error because no
_multi() are used. Go back to the normal usleep_range().
> @@ -106,53 +107,46 @@ static int r63353_panel_power_off(struct r63353_panel
> *rpanel)
> static int r63353_panel_activate(struct r63353_panel *rpanel)
> {
> struct mipi_dsi_device *dsi = rpanel->dsi;
> - struct device *dev = &dsi->dev;
> - int i, ret;
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
> + int i;
>
> - ret = mipi_dsi_dcs_soft_reset(dsi);
> - if (ret < 0) {
> - dev_err(dev, "Failed to do Software Reset (%d)\n", ret);
> + mipi_dsi_dcs_soft_reset_multi(&dsi_ctx);
> + if (dsi_ctx.accum_err)
> goto fail;
> - }
This isn't how the _multi() functions are intended to be used. The
whole idea is _not_ to have scattered "if" statements everywhere and
to just deal with errors at the appropriate places. You just trust
that the _multi() functions are no-ops if an error is set and so it
doesn't hurt to keep calling them. In this case you'd just have a pile
of _multi() functions with no "if" checks and then at the very end of
the function you check for the error. If the error is set then you set
the reset GPIO and return the error.
-Doug
[PATCH 5.15 441/620] drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
[ Upstream commit 666e1960464140cc4bc9203c203097e70b54c95a ]
The code for detecting and updating the connector status in
cdn_dp_pd_event_work() has a number of problems.
- It does not aquire the locks to call the detect helper and update
the connector status. These are struct drm_mode_config.connection_mutex
and struct drm_mode_config.mutex.
- It does not use drm_helper_probe_detect(), which helps with the
details of locking and detection.
- It uses the connector's status field to determine a change to
the connector status. The epoch_counter field is the correct one. The
field signals a change even if the connector status' value did not
change.
Replace the code with a call to drm_connector_helper_hpd_irq_event(),
which fixes all these problems.
Signed-off-by: Thomas Zimmermann
Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use
drm_helper_hpd_irq_event")
Cc: Chris Zhong
Cc: Guenter Roeck
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Andy Yan
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: # v4.11+
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105133848.480407-1-tzimmerm...@suse.de
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index b9ef35a35c857..af1e361da8df9 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -916,9 +916,6 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
{
struct cdn_dp_device *dp = container_of(work, struct cdn_dp_device,
event_work);
- struct drm_connector *connector = &dp->connector;
- enum drm_connector_status old_status;
-
int ret;
mutex_lock(&dp->lock);
@@ -980,11 +977,7 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
out:
mutex_unlock(&dp->lock);
-
- old_status = connector->status;
- connector->status = connector->funcs->detect(connector, false);
- if (old_status != connector->status)
- drm_kms_helper_hotplug_event(dp->drm_dev);
+ drm_connector_helper_hpd_irq_event(&dp->connector);
}
static int cdn_dp_pd_event(struct notifier_block *nb,
--
2.39.5
Re: [PATCH] drm/amdgpu/gfx: delete stray tabs
Applied. Thanks!
On Mon, Mar 10, 2025 at 8:18 AM SRINIVASAN SHANMUGAM
wrote:
>
>
> On 3/10/2025 4:17 PM, Dan Carpenter wrote:
>
> These lines are indented one tab too far. Delete the extra tabs.
>
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index a194bf3347cb..984e6ff6e463 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -2002,8 +2002,8 @@ void amdgpu_gfx_enforce_isolation_handler(struct
> work_struct *work)
> if (adev->kfd.init_complete) {
> WARN_ON_ONCE(!adev->gfx.kfd_sch_inactive[idx]);
> WARN_ON_ONCE(adev->gfx.kfd_sch_req_count[idx]);
> - amdgpu_amdkfd_start_sched(adev, idx);
> - adev->gfx.kfd_sch_inactive[idx] = false;
> + amdgpu_amdkfd_start_sched(adev, idx);
> + adev->gfx.kfd_sch_inactive[idx] = false;
> }
> }
> mutex_unlock(&adev->enforce_isolation_mutex);
>
> Thanks!
>
> Reviewed-by: Srinivasan Shanmugam
Re: [PATCH v2 05/10] drm/msm/dsi: add DSI support for SA8775P
On Tue, Mar 11, 2025 at 05:54:40PM +0530, Ayushi Makhija wrote: > Add DSI Controller v2.5.1 support for SA8775P SoC. > > Signed-off-by: Ayushi Makhija > --- > drivers/gpu/drm/msm/dsi/dsi_cfg.c | 18 ++ > drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + > 2 files changed, 19 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 04/10] drm/msm/dsi: add DSI PHY configuration on SA8775P
On Tue, Mar 11, 2025 at 05:54:39PM +0530, Ayushi Makhija wrote: > The SA8775P SoC uses the 5nm (v4.2) DSI PHY driver with > different enable regulator load. > > Signed-off-by: Ayushi Makhija > --- > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++ > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 27 +++ > 3 files changed, 30 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 09/10] drm/bridge: anx7625: update bridge_ops and sink detect logic
On Tue, Mar 11, 2025 at 05:54:44PM +0530, Ayushi Makhija wrote:
> The anx7625_link_bridge() checks if a device is not a panel
> bridge and add DRM_BRIDGE_OP_HPD and DRM_BRIDGE_OP_DETECT to
> the bridge operations. However, on port 1 of the anx7625
> bridge, any device added is always treated as a panel
> bridge, preventing connector_detect function from being
> called. To resolve this, instead of just checking if it is a
> panel bridge, verify the type of panel bridge
> whether it is a DisplayPort or eDP panel. If the panel
> bridge is not of the eDP type, add DRM_BRIDGE_OP_HPD and
> DRM_BRIDGE_OP_DETECT to the bridge operations.
Are/were there any devices using anx7625, eDP panel _and_ not using the
AUX bus? It would be better to use the precence of the 'aux' node to
determine whether it is an eDP or a DP configuration.
>
> In the anx7625_sink_detect(), the device is checked to see
> if it is a panel bridge, and it always sends a "connected"
> status to the connector. When adding the DP port on port 1 of the
> anx7625, it incorrectly treats it as a panel bridge and sends an
> always "connected" status. Instead of checking the status on the
> panel bridge, it's better to check the hpd_status for connectors
> like DisplayPort. This way, it verifies the hpd_status variable
> before sending the status to the connector.
>
> Signed-off-by: Ayushi Makhija
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 764da1c1dc11..ad99ad19653f 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -1814,9 +1814,6 @@ static enum drm_connector_status
> anx7625_sink_detect(struct anx7625_data *ctx)
>
> DRM_DEV_DEBUG_DRIVER(dev, "sink detect\n");
>
> - if (ctx->pdata.panel_bridge)
> - return connector_status_connected;
> -
> return ctx->hpd_status ? connector_status_connected :
>connector_status_disconnected;
> }
> @@ -2608,9 +2605,10 @@ static int anx7625_link_bridge(struct drm_dp_aux *aux)
> platform->bridge.of_node = dev->of_node;
> if (!anx7625_of_panel_on_aux_bus(dev))
> platform->bridge.ops |= DRM_BRIDGE_OP_EDID;
> - if (!platform->pdata.panel_bridge)
> - platform->bridge.ops |= DRM_BRIDGE_OP_HPD |
> - DRM_BRIDGE_OP_DETECT;
> + if (!platform->pdata.panel_bridge ||
> + platform->pdata.panel_bridge->type != DRM_MODE_CONNECTOR_eDP) {
> + platform->bridge.ops |= DRM_BRIDGE_OP_HPD |
> DRM_BRIDGE_OP_DETECT;
> + }
> platform->bridge.type = platform->pdata.panel_bridge ?
> DRM_MODE_CONNECTOR_eDP :
> DRM_MODE_CONNECTOR_DisplayPort;
> --
> 2.34.1
>
--
With best wishes
Dmitry
[PATCH] drm: Add UAPI for the Asahi driver
This adds the UAPI for the Asahi driver targeting the GPU in the Apple
M1 and M2 series systems on chip. The UAPI design is based on other
modern Vulkan-capable drivers, including Xe and Panthor. Memory
management is based on explicit VM management. Synchronization is
exclusively explicit sync.
This UAPI is validated against our open source Mesa stack, which is
fully conformant to the OpenGL 4.6, OpenGL ES 3.2, OpenCL 3.0, and
Vulkan 1.4 standards. The Vulkan driver supports sparse, exercising the
VM_BIND mechanism.
This patch adds the standalone UAPI header. It is implemented by an open
source DRM driver written in Rust. We fully intend to upstream this
driver when possible. However, as a production graphics driver, it
depends on a significant number of Rust abstractions that will take a
long time to upstream. In the mean time, our userspace is upstream in
Mesa but is not allowed to probe with upstream Mesa as the UAPI is not
yet reviewed and merged in the upstream kernel. Although we ship a
patched Mesa in Fedora Asahi Remix, any containers shipping upstream
Mesa builds are broken for our users, including upstream Flatpak and
Waydroid runtimes. Additionally, it forces us to maintain forks of Mesa
and virglrenderer, which complicates bisects.
The intention in sending out this patch is for this UAPI to be
thoroughly reviewed. Once we as the DRM community are satisfied with the
UAPI, this header lands signifying that the UAPI is stable and must only
be evolved in backwards-compatible ways; it will be the UAPI implemented
in the DRM driver that eventually lands upstream. That promise lets us
enable upstream Mesa, solving all these issues while the upstream Rust
abstractions are developed.
https://github.com/alyssarosenzweig/linux/commits/agx/uapi/ contains the
DRM driver implementing this proposed UAPI.
https://github.com/alyssarosenzweig/mesa/tree/agx-uapi contains the Mesa
patches to implement this proposed UAPI.
That Linux and Mesa branch together give a complete graphics/compute
stack on top of this UAPI.
Co-developed-by: Asahi Lina
Signed-off-by: Asahi Lina
Signed-off-by: Alyssa Rosenzweig
---
Documentation/gpu/driver-uapi.rst |5 +
MAINTAINERS |1 +
include/uapi/drm/asahi_drm.h | 1153 +
3 files changed, 1159 insertions(+)
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index
971cdb4816fc98d80a64d93637481d10c2e79718..1f15a8ca126516c23bd7374cc4aead0dfbbccf67
100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -27,3 +27,8 @@ drm/xe uAPI
===
.. kernel-doc:: include/uapi/drm/xe_drm.h
+
+drm/asahi uAPI
+
+
+.. kernel-doc:: include/uapi/drm/asahi_drm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index
d1050702f681fbd0e4e2d0457b2ba569a64070d9..7f692a935808d4ec82ee741324f8043302dae491
100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2256,6 +2256,7 @@ F:drivers/watchdog/apple_wdt.c
F: include/dt-bindings/interrupt-controller/apple-aic.h
F: include/dt-bindings/pinctrl/apple.h
F: include/linux/soc/apple/*
+F: include/uapi/drm/asahi_drm.h
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson
diff --git a/include/uapi/drm/asahi_drm.h b/include/uapi/drm/asahi_drm.h
new file mode 100644
index
..1491ddbf807d1a26d7d5c5df78a7a988787d15c4
--- /dev/null
+++ b/include/uapi/drm/asahi_drm.h
@@ -0,0 +1,1153 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) The Asahi Linux Contributors
+ * Copyright (C) 2018-2023 Collabora Ltd.
+ * Copyright (C) 2014-2018 Broadcom
+ */
+#ifndef _ASAHI_DRM_H_
+#define _ASAHI_DRM_H_
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+/**
+ * DOC: Introduction to the Asahi UAPI
+ *
+ * This documentation describes the Asahi IOCTLs.
+ *
+ * Just a few generic rules about the data passed to the Asahi IOCTLs (cribbed
+ * from Panthor):
+ *
+ * - Structures must be aligned on 64-bit/8-byte. If the object is not
+ * naturally aligned, a padding field must be added.
+ * - Fields must be explicitly aligned to their natural type alignment with
+ * pad[0..N] fields.
+ * - All padding fields will be checked by the driver to make sure they are
+ * zeroed.
+ * - Flags can be added, but not removed/replaced.
+ * - New fields can be added to the main structures (the structures
+ * directly passed to the ioctl). Those fields can be added at the end of
+ * the structure, or replace existing padding fields. Any new field being
+ * added must preserve the behavior that existed before those fields were
+ * added when a value of zero is passed.
+ * - New fields can be added to indirect objects (objects pointed by the
+ * main structure), iff those objects are passed a size to reflect the
+ * size known by the userspace driver (see
+ * drm_asahi_command::cmd_buffer_size).
+ * - If the kernel driver is too old to know som
dri-devel@lists.freedesktop.org
On Mon, Mar 10, 2025 at 06:41:08PM +0800, Damon Ding wrote: > Add analogix_dpaux_wait_hpd_asserted() to help confirm the HPD state > before doing AUX transfers. > > Signed-off-by: Damon Ding > --- > .../drm/bridge/analogix/analogix_dp_core.c| 21 +++ > 1 file changed, 21 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 19/21] drm/msm/dpu: Implement CTL_PIPE_ACTIVE for v12.0 DPU
On 21/02/2025 17:26, Dmitry Baryshkov wrote: > Minot nit below > >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c >> index >> 43a254cf57da571e2ec8aad38028477652f9283c..3e0bdd1100ebb0d302a852ceeaf8af86835e69a1 >> 100644 >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c >> @@ -40,6 +40,7 @@ >> #define CTL_INTF_FLUSH0x110 >> #define CTL_CDM_FLUSH0x114 >> #define CTL_PERIPH_FLUSH 0x128 >> +#define CTL_PIPE_ACTIVE 0x12C > > lowercase hex, please. Ack Best regards, Krzysztof
Re: [PATCH] drm: Add UAPI for the Asahi driver
> > +/**
> > + * struct drm_asahi_gem_bind - Arguments passed to
> > + * DRM_IOCTL_ASAHI_GEM_BIND
> > + */
> > +struct drm_asahi_gem_bind {
> > + /** @op: Bind operation (enum drm_asahi_bind_op) */
> > + __u32 op;
> > +
> > + /** @flags: One or more of ASAHI_BIND_* (BIND only) */
> > + __u32 flags;
> > +
> > + /** @handle: GEM object to bind/unbind (BIND or UNBIND_ALL) */
> > + __u32 handle;
> > +
> > + /** @vm_id: The ID of the VM to operate on */
> > + __u32 vm_id;
> > +
> > + /** @offset: Offset into the object (BIND only) */
> > + __u64 offset;
> > +
> > + /**
> > +* @range: Number of bytes to bind/unbind to addr (BIND or UNBIND
> > only)
> > +*/
> > + __u64 range;
> > +
> > + /** @addr: Address to bind to (BIND or UNBIND only) */
> > + __u64 addr;
> > +};
>
> No in/out syncobj/fences? This seems to diverge from xe/nouveau/panthor..
Async vm_bind is useful mainly as an optimization, it's not (as far as I
know) required for correctness - you can always wait/signal from a
userspace submit thread with sync vm_bind. It's my understanding (from
when I chatted with Faith about this when bringing up sparse) that this
is how sparse was implemented historically and maybe still is on
Windows?
> > +/**
> > + * enum drm_asahi_sync_type - Sync item type
> > + */
> > +enum drm_asahi_sync_type {
> > + /** @DRM_ASAHI_SYNC_SYNCOBJ: Binary sync object */
> > + DRM_ASAHI_SYNC_SYNCOBJ = 0,
> > +
> > + /** @DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ: Timeline sync object */
> > + DRM_ASAHI_SYNC_TIMELINE_SYNCOBJ = 1,
> > +};
>
> IMHO it would still be worthwhile to also support fence fd's, since it
> would avoid a couple extra ioctls to convert btwn fence fds and
> syncobj for virtgpu native context..
Ditto for this as an optimization. Both of these can be added in a
straightforward backwards-compat way later, so I'm inclined to not add
any extra functionality beyond what we already have (and know works),
rather than commit prematurely to new features and risk getting
something wrong.
(and then it means more rust bindings...)
RE: [PATCH v7 4/6] drm/xe/uapi: Define drm_xe_vm_get_faults
-Original Message-
From: Brost, Matthew
Sent: Monday, March 10, 2025 9:51 PM
To: Cavitt, Jonathan
Cc: intel...@lists.freedesktop.org; Gupta, saurabhg ;
Zuo, Alex ; joonas.lahti...@linux.intel.com; Zhang, Jianxun
; Lin, Shuicheng ;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v7 4/6] drm/xe/uapi: Define drm_xe_vm_get_faults
>
> On Mon, Mar 10, 2025 at 05:18:32PM +, Jonathan Cavitt wrote:
> > Add initial declarations for the drm_xe_vm_get_faults ioctl.
> >
> > Signed-off-by: Jonathan Cavitt
> > ---
> > include/uapi/drm/xe_drm.h | 49 +++
> > 1 file changed, 49 insertions(+)
> >
> > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > index 616916985e3f..90c2fcdbd5c1 100644
> > --- a/include/uapi/drm/xe_drm.h
> > +++ b/include/uapi/drm/xe_drm.h
> > @@ -81,6 +81,7 @@ extern "C" {
> > * - &DRM_IOCTL_XE_EXEC
> > * - &DRM_IOCTL_XE_WAIT_USER_FENCE
> > * - &DRM_IOCTL_XE_OBSERVATION
> > + * - %DRM_IOCTL_XE_VM_GET_FAULTS
>
> This should be a generic "get VM property" IOCTL, not a specific IOCTL
> that only retrieves faults. This allows for future expansion of the
> uAPI.
Question from @Zhang, Jianxun :
"""
But first of all, should we regard faults as a property?
"""
-Jonathan Cavitt
>
> > */
> >
> > /*
> > @@ -102,6 +103,7 @@ extern "C" {
> > #define DRM_XE_EXEC0x09
> > #define DRM_XE_WAIT_USER_FENCE 0x0a
> > #define DRM_XE_OBSERVATION 0x0b
> > +#define DRM_XE_VM_GET_FAULTS 0x0c
> >
> > /* Must be kept compact -- no holes */
> >
> > @@ -117,6 +119,7 @@ extern "C" {
> > #define DRM_IOCTL_XE_EXEC DRM_IOW(DRM_COMMAND_BASE +
> > DRM_XE_EXEC, struct drm_xe_exec)
> > #define DRM_IOCTL_XE_WAIT_USER_FENCE
> > DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_WAIT_USER_FENCE, struct
> > drm_xe_wait_user_fence)
> > #define DRM_IOCTL_XE_OBSERVATION DRM_IOW(DRM_COMMAND_BASE +
> > DRM_XE_OBSERVATION, struct drm_xe_observation_param)
> > +#define DRM_IOCTL_XE_VM_GET_FAULTS DRM_IOWR(DRM_COMMAND_BASE +
> > DRM_XE_VM_GET_FAULTS, struct drm_xe_vm_get_faults)
> >
> > /**
> > * DOC: Xe IOCTL Extensions
> > @@ -1189,6 +1192,52 @@ struct drm_xe_vm_bind {
> > __u64 reserved[2];
> > };
> >
> > +struct xe_vm_fault {
> > + /** @address: Address of the fault, if relevant */
> > + __u64 address;
> > +#define DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT 0
> > +#define DRM_XE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT 1
> > +#define DRM_XE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT2
> > + /** @address_type: , if relevant */
> > + __u32 address_type;
> > + /**
> > +* @address_precision: Precision of faulted address, if relevant.
> > +* Currently only SZ_4K.
> > +*/
> > + __u32 address_precision;
> > + /** @reserved: MBZ */
> > + __u64 reserved[3];
> > +};
> > +
> > +/**
> > + * struct drm_xe_vm_get_faults - Input of &DRM_IOCTL_XE_VM_GET_FAULTS
> > + *
> > + * The user provides a VM ID, and the ioctl will
> > + *
> > + */
> > +struct drm_xe_vm_get_faults {
> > + /** @extensions: Pointer to the first extension struct, if any */
> > + __u64 extensions;
> > +
> > + /** @vm_id: The ID of the VM to query the properties of */
> > + __u32 vm_id;
> > +
> > + /** @size: Size to allocate for @ptr */
> > + __u32 size;
> > +
> > + /** @fault_count: Number of faults to be returned */
> > + __u32 fault_count;
> > +
>
> fault_count is implied by size.
>
> Matt
>
> > + /** @pad: MBZ */
> > + __u32 pad;
> > +
> > + /** @reserved: MBZ */
> > + __u64 reserved[2];
> > +
> > + /** @faults: Pointer to user-defined array of xe_vm_fault of flexible
> > size */
> > + __u64 faults;
> > +};
> > +
> > /**
> > * struct drm_xe_exec_queue_create - Input of
> > &DRM_IOCTL_XE_EXEC_QUEUE_CREATE
> > *
> > --
> > 2.43.0
> >
>
Re: [PATCH v2 4/7] drm/ast: cursor: Add helpers for computing location in video memory
On 05/03/2025 17:30, Thomas Zimmermann wrote:
The ast drivers stores the cursor image at the end of the video memory.
Add helpers to calculate the offset and size.
Thanks, it looks good to me.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 21 +++--
drivers/gpu/drm/ast/ast_drv.h| 1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 139ab00dee8f..05e297f30b4e 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -45,6 +45,21 @@
#define AST_HWC_SIGNATURE_HOTSPOTX0x14
#define AST_HWC_SIGNATURE_HOTSPOTY0x18
+static unsigned long ast_cursor_vram_size(void)
+{
+ return AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE;
+}
+
+long ast_cursor_vram_offset(struct ast_device *ast)
+{
+ unsigned long size = ast_cursor_vram_size();
+
+ if (size > ast->vram_size)
+ return -EINVAL;
+
+ return PAGE_ALIGN_DOWN(ast->vram_size - size);
+}
+
static u32 ast_cursor_calculate_checksum(const void *src, unsigned int width,
unsigned int height)
{
u32 csum = 0;
@@ -276,7 +291,7 @@ int ast_cursor_plane_init(struct ast_device *ast)
struct drm_plane *cursor_plane = &ast_plane->base;
size_t size;
void __iomem *vaddr;
- u64 offset;
+ long offset;
int ret;
/*
@@ -290,7 +305,9 @@ int ast_cursor_plane_init(struct ast_device *ast)
return -ENOMEM;
vaddr = ast->vram + ast->vram_fb_available - size;
- offset = ast->vram_fb_available - size;
+ offset = ast_cursor_vram_offset(ast);
+ if (offset < 0)
+ return offset;
ret = ast_plane_init(dev, ast_plane, vaddr, offset, size,
0x01, &ast_cursor_plane_funcs,
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 2c7861835cfb..ec9ec77260e9 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -432,6 +432,7 @@ int ast_vga_output_init(struct ast_device *ast);
int ast_sil164_output_init(struct ast_device *ast);
/* ast_cursor.c */
+long ast_cursor_vram_offset(struct ast_device *ast);
int ast_cursor_plane_init(struct ast_device *ast);
/* ast dp501 */
[PATCH v4 03/25] drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Push the current calculation into the only direct caller imx. Imx's
hardware requires the framebuffer width to be aligned to 8. The
driver's current approach is actually incorrect, as it only guarantees
this implicitly and requires bpp to be a multiple of 8 already. A
later commit will fix this problem by aligning the scanline pitch
such that an aligned width still fits into each scanline's memory.
A number of other drivers are build on top of gem-dma helpers and
implement their own dumb-buffer allocation. These drivers invoke
drm_gem_dma_dumb_create_internal(), which is not affected by this
commit.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_dma_helper.c | 7 +--
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index b7f033d4352a..49be9b033610 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -304,9 +305,11 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
struct drm_mode_create_dumb *args)
{
struct drm_gem_dma_object *dma_obj;
+ int ret;
- args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- args->size = args->pitch * args->height;
+ ret = drm_mode_size_dumb(drm, args, SZ_8, 0);
+ if (ret)
+ return ret;
dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
&args->handle);
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index ec5fd9a01f1e..e7025df7b978 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -145,6 +145,8 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
int ret;
args->width = ALIGN(width, 8);
+ args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ args->size = args->pitch * args->height;
ret = drm_gem_dma_dumb_create(file_priv, drm, args);
if (ret)
--
2.48.1
[PATCH v4 01/25] drm/dumb-buffers: Sanitize output on errors
The ioctls MODE_CREATE_DUMB and MODE_MAP_DUMB return results into a
memory buffer supplied by user space. On errors, it is possible that
intermediate values are being returned. The exact semantics depends
on the DRM driver's implementation of these ioctls. Although this is
most-likely not a security problem in practice, avoid any uncertainty
by clearing the memory to 0 on errors.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_dumb_buffers.c | 40 ++
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
b/drivers/gpu/drm/drm_dumb_buffers.c
index 70032bba1c97..9916aaf5b3f2 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -99,7 +99,30 @@ int drm_mode_create_dumb(struct drm_device *dev,
int drm_mode_create_dumb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- return drm_mode_create_dumb(dev, data, file_priv);
+ struct drm_mode_create_dumb *args = data;
+ int err;
+
+ err = drm_mode_create_dumb(dev, args, file_priv);
+ if (err) {
+ args->handle = 0;
+ args->pitch = 0;
+ args->size = 0;
+ }
+ return err;
+}
+
+static int drm_mode_mmap_dumb(struct drm_device *dev, struct drm_mode_map_dumb
*args,
+ struct drm_file *file_priv)
+{
+ if (!dev->driver->dumb_create)
+ return -ENOSYS;
+
+ if (dev->driver->dumb_map_offset)
+ return dev->driver->dumb_map_offset(file_priv, dev,
args->handle,
+ &args->offset);
+ else
+ return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
+ &args->offset);
}
/**
@@ -120,17 +143,12 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
struct drm_mode_map_dumb *args = data;
+ int err;
- if (!dev->driver->dumb_create)
- return -ENOSYS;
-
- if (dev->driver->dumb_map_offset)
- return dev->driver->dumb_map_offset(file_priv, dev,
- args->handle,
- &args->offset);
- else
- return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
- &args->offset);
+ err = drm_mode_mmap_dumb(dev, args, file_priv);
+ if (err)
+ args->offset = 0;
+ return err;
}
int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
--
2.48.1
[PATCH v4 09/25] drm/hibmc: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.
The hibmc driver's new hibmc_dumb_create() is similar to the one
in GEM VRAM helpers. The driver was the only caller of
drm_gem_vram_fill_create_dumb(). Remove the now unused helper.
Signed-off-by: Thomas Zimmermann
Cc: Xinliang Liu
Cc: Tian Tao
Cc: Xinwei Kong
Cc: Sumit Semwal
Cc: Yongqin Liu
Cc: John Stultz
---
drivers/gpu/drm/drm_gem_vram_helper.c | 65 ---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 25 ++-
include/drm/drm_gem_vram_helper.h | 6 --
3 files changed, 24 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 15cd564cbeac..b4cf8134df6d 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -444,71 +444,6 @@ void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
}
EXPORT_SYMBOL(drm_gem_vram_vunmap);
-/**
- * drm_gem_vram_fill_create_dumb() - Helper for implementing
- * &struct drm_driver.dumb_create
- *
- * @file: the DRM file
- * @dev: the DRM device
- * @pg_align: the buffer's alignment in multiples of the page size
- * @pitch_align: the scanline's alignment in powers of 2
- * @args: the arguments as provided to
- * &struct drm_driver.dumb_create
- *
- * This helper function fills &struct drm_mode_create_dumb, which is used
- * by &struct drm_driver.dumb_create. Implementations of this interface
- * should forwards their arguments to this helper, plus the driver-specific
- * parameters.
- *
- * Returns:
- * 0 on success, or
- * a negative error code otherwise.
- */
-int drm_gem_vram_fill_create_dumb(struct drm_file *file,
- struct drm_device *dev,
- unsigned long pg_align,
- unsigned long pitch_align,
- struct drm_mode_create_dumb *args)
-{
- size_t pitch, size;
- struct drm_gem_vram_object *gbo;
- int ret;
- u32 handle;
-
- pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
- if (pitch_align) {
- if (WARN_ON_ONCE(!is_power_of_2(pitch_align)))
- return -EINVAL;
- pitch = ALIGN(pitch, pitch_align);
- }
- size = pitch * args->height;
-
- size = roundup(size, PAGE_SIZE);
- if (!size)
- return -EINVAL;
-
- gbo = drm_gem_vram_create(dev, size, pg_align);
- if (IS_ERR(gbo))
- return PTR_ERR(gbo);
-
- ret = drm_gem_handle_create(file, &gbo->bo.base, &handle);
- if (ret)
- goto err_drm_gem_object_put;
-
- drm_gem_object_put(&gbo->bo.base);
-
- args->pitch = pitch;
- args->size = size;
- args->handle = handle;
-
- return 0;
-
-err_drm_gem_object_put:
- drm_gem_object_put(&gbo->bo.base);
- return ret;
-}
-EXPORT_SYMBOL(drm_gem_vram_fill_create_dumb);
-
/*
* Helpers for struct ttm_device_funcs
*/
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index e6de6d5edf6b..81768577871f 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -18,10 +18,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -54,7 +56,28 @@ static irqreturn_t hibmc_interrupt(int irq, void *arg)
static int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- return drm_gem_vram_fill_create_dumb(file, dev, 0, 128, args);
+ struct drm_gem_vram_object *gbo;
+ int ret;
+
+ ret = drm_mode_size_dumb(dev, args, SZ_128, 0);
+ if (ret)
+ return ret;
+
+ gbo = drm_gem_vram_create(dev, args->size, 0);
+ if (IS_ERR(gbo))
+ return PTR_ERR(gbo);
+
+ ret = drm_gem_handle_create(file, &gbo->bo.base, &args->handle);
+ if (ret)
+ goto err_drm_gem_object_put;
+
+ drm_gem_object_put(&gbo->bo.base);
+
+ return 0;
+
+err_drm_gem_object_put:
+ drm_gem_object_put(&gbo->bo.base);
+ return ret;
}
static const struct drm_driver hibmc_driver = {
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 00830b49a3ff..b6e821f5dd03 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -100,12 +100,6 @@ int drm_gem_vram_vmap(struct drm_gem_vram_object *gbo,
struct iosys_map *map);
void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo,
struct iosys_map *map);
-int drm_gem_vram_fill_create_dumb(struct drm_file *file,
-
[PATCH v4 11/25] drm/loongson: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sui Jingfeng
Cc: Sui Jingfeng
---
drivers/gpu/drm/loongson/lsdc_gem.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c
b/drivers/gpu/drm/loongson/lsdc_gem.c
index a720d8f53209..9f982b85301f 100644
--- a/drivers/gpu/drm/loongson/lsdc_gem.c
+++ b/drivers/gpu/drm/loongson/lsdc_gem.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -204,45 +205,31 @@ int lsdc_dumb_create(struct drm_file *file, struct
drm_device *ddev,
const struct lsdc_desc *descp = ldev->descp;
u32 domain = LSDC_GEM_DOMAIN_VRAM;
struct drm_gem_object *gobj;
- size_t size;
- u32 pitch;
- u32 handle;
int ret;
- if (!args->width || !args->height)
- return -EINVAL;
-
- if (args->bpp != 32 && args->bpp != 16)
- return -EINVAL;
-
- pitch = args->width * args->bpp / 8;
- pitch = ALIGN(pitch, descp->pitch_align);
- size = pitch * args->height;
- size = ALIGN(size, PAGE_SIZE);
+ ret = drm_mode_size_dumb(ddev, args, descp->pitch_align, 0);
+ if (ret)
+ return ret;
/* Maximum single bo size allowed is the half vram size available */
- if (size > ldev->vram_size / 2) {
- drm_err(ddev, "Requesting(%zuMiB) failed\n", size >> 20);
+ if (args->size > ldev->vram_size / 2) {
+ drm_err(ddev, "Requesting(%zuMiB) failed\n",
(size_t)(args->size >> PAGE_SHIFT));
return -ENOMEM;
}
- gobj = lsdc_gem_object_create(ddev, domain, size, false, NULL, NULL);
+ gobj = lsdc_gem_object_create(ddev, domain, args->size, false, NULL,
NULL);
if (IS_ERR(gobj)) {
drm_err(ddev, "Failed to create gem object\n");
return PTR_ERR(gobj);
}
- ret = drm_gem_handle_create(file, gobj, &handle);
+ ret = drm_gem_handle_create(file, gobj, &args->handle);
/* drop reference from allocate, handle holds it now */
drm_gem_object_put(gobj);
if (ret)
return ret;
- args->pitch = pitch;
- args->size = size;
- args->handle = handle;
-
return 0;
}
--
2.48.1
[PATCH v4 13/25] drm/msm: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. Alignment is specified in bytes, but the hardware
requires the scanline pitch to be a multiple of 32 pixels. Therefore
compute the byte size of 32 pixels in the given color mode and align
the pitch accordingly. This replaces the existing code in the driver's
align_pitch() helper.
v3:
- clarify pitch alignment in commit message (Dmitry)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Dmitry Baryshkov
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: Marijn Suijten
---
drivers/gpu/drm/msm/msm_gem.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index ebc9ba66efb8..a956905f1ef2 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -11,8 +11,10 @@
#include
#include
+#include
#include
#include
+#include
#include
@@ -700,8 +702,29 @@ void msm_gem_unpin_iova(struct drm_gem_object *obj,
int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- args->pitch = align_pitch(args->width, args->bpp);
- args->size = PAGE_ALIGN(args->pitch * args->height);
+ u32 fourcc;
+ const struct drm_format_info *info;
+ u64 pitch_align;
+ int ret;
+
+ /*
+* Adreno needs pitch aligned to 32 pixels. Compute the number
+* of bytes for a block of 32 pixels at the given color format.
+* Use the result as pitch alignment.
+*/
+ fourcc = drm_driver_color_mode_format(dev, args->bpp);
+ if (fourcc == DRM_FORMAT_INVALID)
+ return -EINVAL;
+ info = drm_format_info(fourcc);
+ if (!info)
+ return -EINVAL;
+ pitch_align = drm_format_info_min_pitch(info, 0, SZ_32);
+ if (!pitch_align || pitch_align > U32_MAX)
+ return -EINVAL;
+ ret = drm_mode_size_dumb(dev, args, pitch_align, 0);
+ if (ret)
+ return ret;
+
return msm_gem_new_handle(dev, file, args->size,
MSM_BO_SCANOUT | MSM_BO_WC, &args->handle, "dumb");
}
--
2.48.1
[PATCH v4 04/25] drm/gem-shmem: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index d99dee67353a..849ee2cde990 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -514,18 +515,11 @@ EXPORT_SYMBOL(drm_gem_shmem_purge);
int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- u32 min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ int ret;
- if (!args->pitch || !args->size) {
- args->pitch = min_pitch;
- args->size = PAGE_ALIGN(args->pitch * args->height);
- } else {
- /* ensure sane minimum values */
- if (args->pitch < min_pitch)
- args->pitch = min_pitch;
- if (args->size < args->pitch * args->height)
- args->size = PAGE_ALIGN(args->pitch * args->height);
- }
+ ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+ if (ret)
+ return ret;
return drm_gem_shmem_create_with_handle(file, dev, args->size,
&args->handle);
}
--
2.48.1
[PATCH v4 10/25] drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. The hardware requires the framebuffer width to be a
multiple of 8. The scanline pitch has be large enough to support
this. Therefore compute the byte size of 8 pixels in the given color
mode and align the pitch accordingly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Philipp Zabel
Cc: Philipp Zabel
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
---
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 31 ++--
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index e7025df7b978..465b5a6ad5bb 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -17,7 +17,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -141,19 +143,32 @@ static int imx_drm_dumb_create(struct drm_file *file_priv,
struct drm_device *drm,
struct drm_mode_create_dumb *args)
{
- u32 width = args->width;
+ u32 fourcc;
+ const struct drm_format_info *info;
+ u64 pitch_align;
int ret;
- args->width = ALIGN(width, 8);
- args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- args->size = args->pitch * args->height;
-
- ret = drm_gem_dma_dumb_create(file_priv, drm, args);
+ /*
+* Hardware requires the framebuffer width to be aligned to
+* multiples of 8. The mode-setting code handles this, but
+* the buffer pitch has to be aligned as well. Set the pitch
+* alignment accordingly, so that the each scanline fits into
+* the allocated buffer.
+*/
+ fourcc = drm_driver_color_mode_format(drm, args->bpp);
+ if (fourcc == DRM_FORMAT_INVALID)
+ return -EINVAL;
+ info = drm_format_info(fourcc);
+ if (!info)
+ return -EINVAL;
+ pitch_align = drm_format_info_min_pitch(info, 0, SZ_8);
+ if (!pitch_align || pitch_align > U32_MAX)
+ return -EINVAL;
+ ret = drm_mode_size_dumb(drm, args, pitch_align, 0);
if (ret)
return ret;
- args->width = width;
- return ret;
+ return drm_gem_dma_dumb_create(file_priv, drm, args);
}
static const struct drm_driver imx_drm_driver = {
--
2.48.1
[PATCH v4 06/25] drm/armada: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 128.
v4:
- align pitch to 128 bytes (Russell)
Signed-off-by: Thomas Zimmermann
Cc: Russell King
---
drivers/gpu/drm/armada/armada_gem.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 1a1680d71486..a767c4edd5c8 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include "armada_drm.h"
@@ -244,14 +245,13 @@ int armada_gem_dumb_create(struct drm_file *file, struct
drm_device *dev,
struct drm_mode_create_dumb *args)
{
struct armada_gem_object *dobj;
- u32 handle;
- size_t size;
int ret;
- args->pitch = armada_pitch(args->width, args->bpp);
- args->size = size = args->pitch * args->height;
+ ret = drm_mode_size_dumb(dev, args, SZ_128, 0);
+ if (ret)
+ return ret;
- dobj = armada_gem_alloc_private_object(dev, size);
+ dobj = armada_gem_alloc_private_object(dev, args->size);
if (dobj == NULL)
return -ENOMEM;
@@ -259,14 +259,12 @@ int armada_gem_dumb_create(struct drm_file *file, struct
drm_device *dev,
if (ret)
goto err;
- ret = drm_gem_handle_create(file, &dobj->obj, &handle);
+ ret = drm_gem_handle_create(file, &dobj->obj, &args->handle);
if (ret)
goto err;
- args->handle = handle;
-
/* drop reference from allocate - handle holds it now */
- DRM_DEBUG_DRIVER("obj %p size %zu handle %#x\n", dobj, size, handle);
+ DRM_DEBUG_DRIVER("obj %p size %llu handle %#x\n", dobj, args->size,
args->handle);
err:
drm_gem_object_put(&dobj->obj);
return ret;
--
2.48.1
Re: [PATCH v2 4/7] drm/connector: hdmi: Use YUV420 output format as an RGB fallback
Hi,
I think the first thing we need to address is that we will need to
differentiate between HDMI 1.4 devices and HDMI 2.0.
It applies to YUV420, which is HDMI 2.0-only, and I guess your patches
are good enough if you consider YUV420 support only, but scrambler setup
for example is a thing we want to support in that infrastructure
eventually, and is conditioned on HDMI 2.0 as well.
On Tue, Mar 11, 2025 at 12:57:36PM +0200, Cristian Ciocaltea wrote:
> Try to make use of YUV420 when computing the best output format and
> RGB cannot be supported for any of the available color depths.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 69
> +
> 1 file changed, 35 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index
> a70e204a8df3ac1c2d7318e81cde87a83267dd21..f2052781b797dd09b41127e33d98fe25408a9b23
> 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> @@ -287,8 +287,9 @@ hdmi_try_format_bpc(const struct drm_connector *connector,
> struct drm_device *dev = connector->dev;
> int ret;
>
> - drm_dbg_kms(dev, "Trying %s output format\n",
> - drm_hdmi_connector_get_output_format_name(fmt));
> + drm_dbg_kms(dev, "Trying %s output format with %u bpc\n",
> + drm_hdmi_connector_get_output_format_name(fmt),
> + bpc);
That part should be in a separate patch, it's independant of the rest.
> if (!sink_supports_format_bpc(connector, info, mode, fmt, bpc)) {
> drm_dbg_kms(dev, "%s output format not supported with %u bpc\n",
> @@ -313,47 +314,22 @@ hdmi_try_format_bpc(const struct drm_connector
> *connector,
> }
>
> static int
> -hdmi_compute_format(const struct drm_connector *connector,
> - struct drm_connector_state *conn_state,
> - const struct drm_display_mode *mode,
> - unsigned int bpc)
> -{
> - struct drm_device *dev = connector->dev;
> -
> - /*
> - * TODO: Add support for YCbCr420 output for HDMI 2.0 capable
> - * devices, for modes that only support YCbCr420.
> - */
> - if (hdmi_try_format_bpc(connector, conn_state, mode, bpc,
> HDMI_COLORSPACE_RGB)) {
> - conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> - return 0;
> - }
> -
> - drm_dbg_kms(dev, "Failed. No Format Supported for that bpc count.\n");
> -
> - return -EINVAL;
> -}
> -
> -static int
> -hdmi_compute_config(const struct drm_connector *connector,
> - struct drm_connector_state *conn_state,
> - const struct drm_display_mode *mode)
> +hdmi_try_format(const struct drm_connector *connector,
> + struct drm_connector_state *conn_state,
> + const struct drm_display_mode *mode,
> + unsigned int max_bpc, enum hdmi_colorspace fmt)
> {
> struct drm_device *dev = connector->dev;
> - unsigned int max_bpc = clamp_t(unsigned int,
> -conn_state->max_bpc,
> -8, connector->max_bpc);
> unsigned int bpc;
> int ret;
>
> for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
> - drm_dbg_kms(dev, "Trying with a %d bpc output\n", bpc);
> -
> - ret = hdmi_compute_format(connector, conn_state, mode, bpc);
> - if (ret)
> + ret = hdmi_try_format_bpc(connector, conn_state, mode, bpc,
> fmt);
> + if (!ret)
> continue;
>
> conn_state->hdmi.output_bpc = bpc;
> + conn_state->hdmi.output_format = fmt;
I guess it's a matter of semantics, but if it sets the value in the
state, it doesn't try. Maybe the function should be named
hdmi_compute_format_bpc then?
That renaming should be in a separate patch too (possibly several).
> drm_dbg_kms(dev,
> "Mode %ux%u @ %uHz: Found configuration: bpc: %u,
> fmt: %s, clock: %llu\n",
> @@ -368,6 +344,31 @@ hdmi_compute_config(const struct drm_connector
> *connector,
> return -EINVAL;
> }
>
> +static int
> +hdmi_compute_config(const struct drm_connector *connector,
> + struct drm_connector_state *conn_state,
> + const struct drm_display_mode *mode)
> +{
> + unsigned int max_bpc = clamp_t(unsigned int,
> +conn_state->max_bpc,
> +8, connector->max_bpc);
> + int ret;
> +
> + ret = hdmi_try_format(connector, conn_state, mode, max_bpc,
> + HDMI_COLORSPACE_RGB);
> + if (!ret)
> + return 0;
> +
> + if (connector->ycbcr_420_allowed)
> + ret = hdmi_try_format(connector, conn_state, mode, max_bpc,
> +
[PATCH v4 22/25] drm/vmwgfx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 02ab65cc63ec..c3a4ea713559 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -15,6 +15,7 @@
#include "vmw_surface_cache.h"
#include "device_include/svga3d_surfacedefs.h"
+#include
#include
#define SVGA3D_FLAGS_64(upper32, lower32) (((uint64_t)upper32 << 32) | lower32)
@@ -2270,23 +2271,9 @@ int vmw_dumb_create(struct drm_file *file_priv,
* contents is going to be rendered guest side.
*/
if (!dev_priv->has_mob || !vmw_supports_3d(dev_priv)) {
- int cpp = DIV_ROUND_UP(args->bpp, 8);
-
- switch (cpp) {
- case 1: /* DRM_FORMAT_C8 */
- case 2: /* DRM_FORMAT_RGB565 */
- case 4: /* DRM_FORMAT_XRGB */
- break;
- default:
- /*
-* Dumb buffers don't allow anything else.
-* This is tested via IGT's dumb_buffers
-*/
- return -EINVAL;
- }
-
- args->pitch = args->width * cpp;
- args->size = ALIGN(args->pitch * args->height, PAGE_SIZE);
+ ret = drm_mode_size_dumb(dev, args, 0, 0);
+ if (ret)
+ return ret;
ret = vmw_gem_object_create_with_handle(dev_priv, file_priv,
args->size,
&args->handle,
--
2.48.1
[PATCH v4 15/25] drm/omapdrm: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Tomi Valkeinen
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index b9c67e4ca360..b8413a2dcdeb 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
@@ -583,15 +584,13 @@ static int omap_gem_object_mmap(struct drm_gem_object
*obj, struct vm_area_struc
int omap_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- union omap_gem_size gsize;
-
- args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
-
- args->size = PAGE_ALIGN(args->pitch * args->height);
+ union omap_gem_size gsize = { };
+ int ret;
- gsize = (union omap_gem_size){
- .bytes = args->size,
- };
+ ret = drm_mode_size_dumb(dev, args, SZ_8, 0);
+ if (ret)
+ return ret;
+ gsize.bytes = args->size;
return omap_gem_new_handle(dev, file, gsize,
OMAP_BO_SCANOUT | OMAP_BO_WC, &args->handle);
--
2.48.1
[PATCH v4 16/25] drm/qxl: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch
and buffer size. No alignment required.
Signed-off-by: Thomas Zimmermann
Cc: Dave Airlie
Cc: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_dumb.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 17df5c7ccf69..1200946767ce 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -23,6 +23,8 @@
* Alon Levy
*/
+#include
+
#include "qxl_drv.h"
#include "qxl_object.h"
@@ -35,14 +37,13 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
struct qxl_device *qdev = to_qxl(dev);
struct qxl_bo *qobj;
struct drm_gem_object *gobj;
- uint32_t handle;
int r;
struct qxl_surface surf;
- uint32_t pitch, format;
+ u32 format;
- pitch = args->width * ((args->bpp + 1) / 8);
- args->size = pitch * args->height;
- args->size = ALIGN(args->size, PAGE_SIZE);
+ r = drm_mode_size_dumb(dev, args, 0, 0);
+ if (r)
+ return r;
switch (args->bpp) {
case 16:
@@ -57,20 +58,18 @@ int qxl_mode_dumb_create(struct drm_file *file_priv,
surf.width = args->width;
surf.height = args->height;
- surf.stride = pitch;
+ surf.stride = args->pitch;
surf.format = format;
surf.data = 0;
r = qxl_gem_object_create_with_handle(qdev, file_priv,
QXL_GEM_DOMAIN_CPU,
args->size, &surf, &gobj,
- &handle);
+ &args->handle);
if (r)
return r;
qobj = gem_to_qxl_bo(gobj);
qobj->is_dumb = true;
drm_gem_object_put(gobj);
- args->pitch = pitch;
- args->handle = handle;
return 0;
}
--
2.48.1
[PATCH v4 17/25] drm/renesas/rcar-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: Kieran Bingham
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
index 70d8ad065bfa..32c8307da522 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -407,8 +408,8 @@ int rcar_du_dumb_create(struct drm_file *file, struct
drm_device *dev,
struct drm_mode_create_dumb *args)
{
struct rcar_du_device *rcdu = to_rcar_du_device(dev);
- unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
unsigned int align;
+ int ret;
/*
* The R8A7779 DU requires a 16 pixels pitch alignment as documented,
@@ -419,7 +420,9 @@ int rcar_du_dumb_create(struct drm_file *file, struct
drm_device *dev,
else
align = 16 * args->bpp / 8;
- args->pitch = roundup(min_pitch, align);
+ ret = drm_mode_size_dumb(dev, args, align, 0);
+ if (ret)
+ return ret;
return drm_gem_dma_dumb_create_internal(file, dev, args);
}
--
2.48.1
[PATCH v4 18/25] drm/renesas/rz-du: Compute dumb-buffer sizes with drm_mode_size_dumb()
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Biju Das
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
index 90c6269ccd29..f752369cd52f 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
@@ -75,10 +75,11 @@ const struct rzg2l_du_format_info *rzg2l_du_format_info(u32
fourcc)
int rzg2l_du_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- unsigned int align = 16 * args->bpp / 8;
+ int ret;
- args->pitch = roundup(min_pitch, align);
+ ret = drm_mode_size_dumb(dev, args, 16 * args->bpp / 8, 0);
+ if (ret)
+ return ret;
return drm_gem_dma_dumb_create_internal(file, dev, args);
}
--
2.48.1
Re: [PATCH v2] fbdev: fsl-diu-fb: add missing device_remove_file()
Yeah, you are right, but I believe it would be better to retain the checks.
Anyway, I have submitted the V3 patch which has dropped the checks.
Thanks and Regards,
Shixiong Ou.
在 2025/3/10 03:42, Helge Deller 写道:
On 3/9/25 09:16, Shixiong Ou wrote:
From: Shixiong Ou
Call device_remove_file() when driver remove.
Signed-off-by: Shixiong Ou
---
v1->v2:
add has_sysfs_attrs flag.
drivers/video/fbdev/fsl-diu-fb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/fbdev/fsl-diu-fb.c
b/drivers/video/fbdev/fsl-diu-fb.c
index 5ac8201c3533..57f7fe6a4c76 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -384,6 +384,7 @@ struct fsl_diu_data {
__le16 next_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
+ bool has_dev_attr;
} __aligned(32);
/* Determine the DMA address of a member of the fsl_diu_data
structure */
@@ -1809,6 +1810,7 @@ static int fsl_diu_probe(struct platform_device
*pdev)
data->dev_attr.attr.name);
}
+ data->has_dev_attr = true;
dev_set_drvdata(&pdev->dev, data);
return 0;
@@ -1827,6 +1829,10 @@ static void fsl_diu_remove(struct
platform_device *pdev)
int i;
data = dev_get_drvdata(&pdev->dev);
+
+ if (data->has_dev_attr)
Looking at other drivers (e.g. drivers/net/can/usb/esd_usb.c) it seems
that device_remove_file() is ok even if it's not fully initialized...
I think you can drop those extra checks.
Helge
+ device_remove_file(&pdev->dev, &data->dev_attr);
+
disable_lcdc(&data->fsl_diu_info[0]);
free_irq(data->irq, data->diu_reg);
Re: [PATCH v5 0/9] drm/verisilicon : support DC8200 and inno hdmi
On 11/20/24 07:18, keith zhao wrote:
Verisilicon/DC8200 display controller IP has 2 display pipes and each
pipe support a primary plane and a cursor plane .
In addition, there are 4 overlay planes as 2 display pipes common resources.
The first display pipe is bound to the inno HDMI encoder.
The second display pipe is bound to Internal custom encoder,
which is used to find dsi bridge by dts node.
This patchset should be applied on next branch.
V1:
Changes since v1:
- Further standardize the yaml file.
- Dts naming convention improved.
- Fix the problem of compiling and loading ko files.
- Use drm new api to automatically manage resources.
- Drop vs_crtc_funcs&vs_plane_funcs, subdivide the plane's help interface.
- Reduce the modifiers unused.
- Optimize the hdmi driver code
V2:
Changes since v2:
- fix the error about checking the yaml file.
- match drm driver GEM DMA API.
- Delete the custom crtc property .
- hdmi use drmm_ new api to automatically manage resources.
- update the modifiers comments.
- enabling KASAN, fix the error during removing module
V3:
Changes since v3:
- Delete the custom plane property.
- Delete the custom fourcc modifiers.
- Adjust the calculation mode of hdmi pixclock.
- Add match data for dc8200 driver.
- Adjust some magic values.
- Add a simple encoder for dsi output.
V4:
Changes since v4:
- Delete the display subsystem module as all crtcs and planes are a driver.
- Delete the custom struct, directly use the drm struct data.
- Tidy up the inno hdmi public interface.
- Add a simple encoder for dsi output.
V5:
Changes since v5:
- Refine the Innosilicon HDMI by quoting bridge abstracting.
- Delete the encoder driver, which is created directly by internal functions.
- Adapt to the changes in kernel upgrade APIs, such as drm_client_setup.
keith zhao (9):
dt-bindings: display: bindings for starfive,JH7110 display pipeline
riscv: dts: Add display property
drm: bridge: inno-hdmi: add inno bridge driver.
drm/vs: Add Hardware Functions for VS DC8200
drm/vs: Add Base API for VS Mode Configuration
drm/vs: Add CRTC Functions
drm/vs: Add VS Plane API
drm/vs: Add Innosilicon HDMI Support
drm/vs: Add VS DRM Master Driver for JH7110 SoC
.../display/bridge/innosilicon,inno-hdmi.yaml | 45 +
.../display/rockchip/rockchip,inno-hdmi.yaml | 27 +-
.../starfive/starfive,jh7110-dc8200.yaml | 176 +++
.../starfive/starfive,jh7110-inno-hdmi.yaml | 91 ++
.../soc/starfive/starfive,jh7110-syscon.yaml |1 +
MAINTAINERS | 11 +
.../boot/dts/starfive/jh7110-common.dtsi | 125 ++
arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 +
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/bridge/Kconfig|2 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/innosilicon/Kconfig|6 +
drivers/gpu/drm/bridge/innosilicon/Makefile |2 +
.../gpu/drm/bridge/innosilicon/inno-hdmi.c| 376 ++
.../gpu/drm/bridge/innosilicon/inno-hdmi.h| 34 +
drivers/gpu/drm/rockchip/Kconfig |1 +
drivers/gpu/drm/rockchip/Makefile |2 +-
drivers/gpu/drm/rockchip/inno_hdmi-rockchip.c | 690 +++
.../{inno_hdmi.h => inno_hdmi-rockchip.h} |0
drivers/gpu/drm/rockchip/inno_hdmi.c | 1025 ---
drivers/gpu/drm/verisilicon/Kconfig | 32 +
drivers/gpu/drm/verisilicon/Makefile | 10 +
.../gpu/drm/verisilicon/inno_hdmi-starfive.c | 553 +
.../gpu/drm/verisilicon/inno_hdmi-starfive.h | 194 +++
drivers/gpu/drm/verisilicon/vs_crtc.c | 241
drivers/gpu/drm/verisilicon/vs_crtc.h | 42 +
drivers/gpu/drm/verisilicon/vs_dc_hw.c| 1104 +
drivers/gpu/drm/verisilicon/vs_dc_hw.h| 492
drivers/gpu/drm/verisilicon/vs_drv.c | 777
drivers/gpu/drm/verisilicon/vs_drv.h | 41 +
drivers/gpu/drm/verisilicon/vs_modeset.c | 31 +
drivers/gpu/drm/verisilicon/vs_modeset.h | 10 +
drivers/gpu/drm/verisilicon/vs_plane.c| 358 ++
drivers/gpu/drm/verisilicon/vs_plane.h| 27 +
drivers/gpu/drm/verisilicon/vs_type.h | 54 +
include/drm/bridge/inno_hdmi.h| 56 +
37 files changed, 5630 insertions(+), 1051 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/innosilicon,inno-hdmi.yaml
create mode 100644
Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
create mode 100644
Documentation/devicetree/bindings/display/starfive/starfive,jh7110-inno-hdmi.yaml
create mode 100644 drivers/gpu/drm/bridge/innosilicon/Kconfig
create mode 100644 drivers/gpu/drm/bridge/innosilicon/Makefile
create mode 100644 drivers/gpu/drm/bridge/innosilicon/inno-hdmi.c
create mode 100644 driv
Re: [PATCH 3/5] dt-bindings: display: simple-bridge: Document DPI color encoder
Hi, On Tue, Mar 11, 2025 at 10:29:28AM +0800, Liu Ying wrote: > On 03/10/2025, Maxime Ripard wrote: > > On Fri, Mar 07, 2025 at 11:25:40AM +0800, Liu Ying wrote: > >> On 03/07/2025, Rob Herring wrote: > >>> On Thu, Mar 06, 2025 at 12:35:49PM +0100, Maxime Ripard wrote: > On Thu, Mar 06, 2025 at 03:02:41PM +0800, Liu Ying wrote: > > On 03/06/2025, Rob Herring wrote: > >> On Wed, Mar 05, 2025 at 10:35:26AM +0100, Alexander Stein wrote: > >>> Hi, > >>> > >>> Am Dienstag, 4. März 2025, 16:23:20 CET schrieb Rob Herring: > On Tue, Mar 04, 2025 at 06:15:28PM +0800, Liu Ying wrote: > > A DPI color encoder, as a simple display bridge, converts input DPI > > color > > coding to output DPI color coding, like Adafruit Kippah DPI hat[1] > > which > > converts input 18-bit pixel data to 24-bit pixel data(with 2 low > > padding > > bits in every color component though). Document the DPI color > > encoder. > > Why do we need a node for this? Isn't this just wired how it is > wired > and there's nothing for s/w to see or do? I suppose if you are > trying to > resolve the mode with 24-bit on one end and 18-bit on the other end, > you > need to allow that and not require an exact match. You still might > need > to figure out which pins the 18-bit data comes out on, but you have > that > problem with an 18-bit panel too. IOW, how is this any different if > you > have an 18-bit panel versus 24-bit panel? > >>> > >>> Especially panel-simple.c has a fixed configuration for each display, > >>> such as: > .bus_format = MEDIA_BUS_FMT_RGB666_1X18 > >>> > >>> How would you allow or even know it should be addressed as > >>> MEDIA_BUS_FMT_RGB888_1X24 instead? I see different ways: > >>> 1. Create a new display setting/compatible > >>> 2. Add an overwrite property to the displays > >>> 3. Use a (transparent) bridge (this series) > >>> > >>> Number 1 is IMHO out of question. > >> > >> Agreed. > >> > >>> I personally don't like number 2 as this > >>> feels like adding quirks to displays, which they don't have. > >> > >> This is what I would do except apply it to the controller side. We > >> know > >> the panel side already. This is a board variation, so a property makes > >> sense. I don't think you need any more than knowing what's on each > >> end. > > > > With option 2, no matter putting a property in source side or sink side, > > impacted display drivers and DT bindings need to be changed, once a > > board > > manipulates the DPI color coding. This adds burdens and introduces new > > versions of those DT bindings. Is this what we want? > > There's an option 4: make it a property of the OF graph endpoints. In > essence, it's similar to properties that are already there like > lane-mapping, and it wouldn't affect the panel drivers, or create an > intermediate bridge. > >>> > >>> Yes, that's actually where I meant to put the property(ies). > >> > >> Put optional dpi-color-coding or something else in endpoint-base? > > > > I'm not sure what you mean by endpoint base, but it would be just like > > I meant the endpoint-base definition in graph.yaml. > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/graph.yaml#L37 I don't think it should be put in the graph binding document, but either in video-interfaces, or, since it's mostly used by v4l2, in a similar but separate document for DRM. > If optional dpi-color-coding property or something else is put there, then > any existing DT binding doc which references it starts to contain the > additional property automatically, which means those existing DT binding docs > don't need any change. I'm not saying that this is ok to do(due to burdens > added by driver modification and maintainence) - I still think option 3 is the > right thing to do. If the property is generic, and the support for it done well enough, it's probably going to be a single function call in drivers. I wouldn't call that a burden. > > data-lanes, on the endpoint itself, right next to remote-endpoint. Given > > the nomenclature we have, something like "color-format" or > > "color-encoding", and taking the media format bus as value. > > This requires to change drivers and maintain the change, which adds burdens. > > > > >> Assuming it's optional, then it implies that it will overwrite OS's > >> setting, which sounds kinda awkward, because it is supposed to be > >> required to describe the actual color coding. > > > > I'm sorry, I don't understand what you mean here. Your bridge would have > > I meant an optional new property is not that welcomed Not that welcomed by whom? > and it is supposed to be requ
Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help)
Huan,
Thanks for your response.
On 3/11/25 3:12 PM, Huan Yang wrote:
>
> 在 2025/3/11 14:40, Bingbu Cao 写道:
>> [You don't often get email from bingbu@linux.intel.com. Learn why this
>> is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Huan Yang and Vivek,
>>
>> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf
>> buffers now. vmap_pfn_apply() will report a warning to complain that
>> the pfns are invalid.
>> I dump the pfn numbers as below:
>> [ 3365.399641] pg[0] pfn 1148695
>> [ 3365.399642] pg[1] pfn 1145057
>> [ 3365.399642] pg[2] pfn 1134070
>> [ 3365.399643] pg[3] pfn 1148700
>> [ 3365.399643] pg[4] pfn 1144871
>> [ 3365.399643] pg[5] pfn 1408686
>> [ 3365.399643] pg[6] pfn 1408683
>> ...
>> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489
>> vmap_pfn_apply+0xb7/0xd0
>> [ 3365.399667] Modules linked in:...
>> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted
>> 6.13.0-rc2-rvp #845
>> [ 3365.399752] Hardware name: Intel Corporation Client Platform/, BIOS
>> xxxFWI1.R00.3221.D83.2408120121 08/12/2024
>> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0
>> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21
>> c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f>
>> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00
>> [ 3365.399756] RSP: 0018:b9b50c32fad0 EFLAGS: 00010202
>> [ 3365.399757] RAX: 0001 RBX: 00118717 RCX:
>>
>> [ 3365.399758] RDX: 8000 RSI: b9b50c358000 RDI:
>>
>> [ 3365.399758] RBP: b9b50c32fae8 R08: b9b50c32fbd0 R09:
>> 0001
>> [ 3365.399759] R10: 941602479288 R11: R12:
>> b9b50c32fbd0
>> [ 3365.399759] R13: 941618665ac0 R14: b9b50c358000 R15:
>> 941618665ac8
>> [ 3365.399760] FS: 7ff9e9ddd740() GS:94196f78()
>> knlGS:
>> [ 3365.399760] CS: 0010 DS: ES: CR0: 80050033
>> [ 3365.399761] CR2: 55fda5dc69d9 CR3: 0001544de003 CR4:
>> 00f72ef0
>> [ 3365.399762] DR0: DR1: DR2:
>>
>> [ 3365.399762] DR3: DR6: 07f0 DR7:
>> 0400
>> [ 3365.399763] PKRU: 5554
>> [ 3365.399763] Call Trace:
>> [ 3365.399765]
>> [ 3365.399769] ? show_regs+0x6d/0x80
>> [ 3365.399773] ? __warn+0x97/0x160
>> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0
>> [ 3365.399777] ? report_bug+0x1ec/0x240
>> [ 3365.399782] ? handle_bug+0x63/0xa0
>> [ 3365.399784] ? exc_invalid_op+0x1d/0x80
>> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30
>> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0
>> [ 3365.399791] __apply_to_page_range+0x522/0x8a0
>> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10
>> [ 3365.399795] apply_to_page_range+0x18/0x20
>> [ 3365.399796] vmap_pfn+0x77/0xd0
>> [ 3365.399797] vmap_udmabuf+0xc5/0x110
>> [ 3365.399802] dma_buf_vmap+0x96/0x130
>>
>> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04,
>> then I can vmap the pages. Could you help what's wrong with that?
>
> Sorry for that, as I reviewed pfn_valid, that's someting wired:
>
> /**
> * pfn_valid - check if there is a valid memory map entry for a PFN
> * @pfn: the page frame number to check
> *
> * Check if there is a valid memory map entry aka struct page for the @pfn.
> * Note, that availability of the memory map entry does not imply that
> * there is actual usable memory at that @pfn. The struct page may
> * represent a hole or an unusable page frame.
> *
> * Return: 1 for PFNs that have memory map entries and 0 otherwise
> */
>
> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But
> vmap_pfn_apply in there:
>
> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
> {
> struct vmap_pfn_data *data = private;
> unsigned long pfn = data->pfns[data->idx];
> pte_t ptent;
>
> if (WARN_ON_ONCE(pfn_valid(pfn)))
> return -EINVAL;
>
> ptent = pte_mkspecial(pfn_pte(pfn, data->prot));
> set_pte_at(&init_mm, addr, pte, ptent);
>
> data->idx++;
> return 0;
> }
>
> Do it give a wrong check? maybe should fix by:
I guess not, it looks more like warning when you trying to vmap a
pfn which already took a valid entry in pte.
However, the MM code is so complex for me, just my guess. :)
>
> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
> {
> struct vmap_pfn_data *data = private;
> unsigned long pfn = data->pfns[data->idx];
> pte_t ptent;
>
> -if (WARN_ON_ONCE(pfn_valid(pfn)))
> +if (WARN_ON_ONCE(!pfn_valid(pfn)))
> return -EINVAL;
>
> ptent = pte_mkspecial(pfn_pte(pfn, data->prot));
> set_pte_at(&init_mm, addr, pte, ptent);
>
> data->idx++;
> return 0;
> }
>
> Please help me check it, also, you can apply this and then check it.:)
>
>
[PATCH v7 1/7] drm: Move some options to separate new Kconfig
Move some options out into a new debug specific kconfig file in order to make things a bit cleaner. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner --- drivers/gpu/drm/Kconfig | 109 ++ drivers/gpu/drm/Kconfig.debug | 103 2 files changed, 108 insertions(+), 104 deletions(-) create mode 100644 drivers/gpu/drm/Kconfig.debug diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index d9986fd52194..46ba24592553 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -26,6 +26,11 @@ menuconfig DRM details. You should also select and configure AGP (/dev/agpgart) support if it is available for your platform. +menu "DRM debugging options" +depends on DRM +source "drivers/gpu/drm/Kconfig.debug" +endmenu + if DRM config DRM_MIPI_DBI @@ -37,65 +42,6 @@ config DRM_MIPI_DSI bool depends on DRM -config DRM_DEBUG_MM - bool "Insert extra checks and debug info into the DRM range managers" - default n - depends on DRM - depends on STACKTRACE_SUPPORT - select STACKDEPOT - help - Enable allocation tracking of memory manager and leak detection on - shutdown. - - Recommended for driver developers only. - - If in doubt, say "N". - -config DRM_USE_DYNAMIC_DEBUG - bool "use dynamic debug to implement drm.debug" - default n - depends on BROKEN - depends on DRM - depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE - depends on JUMP_LABEL - help - Use dynamic-debug to avoid drm_debug_enabled() runtime overheads. - Due to callsite counts in DRM drivers (~4k in amdgpu) and 56 - bytes per callsite, the .data costs can be substantial, and - are therefore configurable. - -config DRM_KUNIT_TEST_HELPERS - tristate - depends on DRM && KUNIT - select DRM_KMS_HELPER - help - KUnit Helpers for KMS drivers. - -config DRM_KUNIT_TEST - tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS - depends on DRM && KUNIT && MMU - select DRM_BUDDY - select DRM_DISPLAY_DP_HELPER - select DRM_DISPLAY_HDMI_STATE_HELPER - select DRM_DISPLAY_HELPER - select DRM_EXEC - select DRM_EXPORT_FOR_TESTS if m - select DRM_GEM_SHMEM_HELPER - select DRM_KUNIT_TEST_HELPERS - select DRM_LIB_RANDOM - select PRIME_NUMBERS - default KUNIT_ALL_TESTS - help - This builds unit tests for DRM. This option is not useful for - distributions or general kernels, but only for kernel - developers working on DRM and associated drivers. - - For more information on KUnit and unit tests in general, - please refer to the KUnit documentation in - Documentation/dev-tools/kunit/. - - If in doubt, say "N". - config DRM_KMS_HELPER tristate depends on DRM @@ -247,23 +193,6 @@ config DRM_TTM GPU memory types. Will be enabled automatically if a device driver uses it. -config DRM_TTM_KUNIT_TEST -tristate "KUnit tests for TTM" if !KUNIT_ALL_TESTS -default n -depends on DRM && KUNIT && MMU && (UML || COMPILE_TEST) -select DRM_TTM -select DRM_BUDDY -select DRM_EXPORT_FOR_TESTS if m -select DRM_KUNIT_TEST_HELPERS -default KUNIT_ALL_TESTS -help - Enables unit tests for TTM, a GPU memory manager subsystem used - to manage memory buffers. This option is mostly useful for kernel - developers. It depends on (UML || COMPILE_TEST) since no other driver - which uses TTM can be loaded while running the tests. - - If in doubt, say "N". - config DRM_EXEC tristate depends on DRM @@ -463,9 +392,6 @@ config DRM_HYPERV If M is selected the module will be called hyperv_drm. -config DRM_EXPORT_FOR_TESTS - bool - # Separate option as not all DRM drivers use it config DRM_PANEL_BACKLIGHT_QUIRKS tristate @@ -478,31 +404,6 @@ config DRM_PRIVACY_SCREEN bool default n -config DRM_WERROR - bool "Compile the drm subsystem with warnings as errors" - depends on DRM && EXPERT - depends on !WERROR - default n - help - A kernel build should not cause any compiler warnings, and this - enables the '-Werror' flag to enforce that rule in the drm subsystem. - - The drm subsystem enables more warnings than the kernel default, so - this config option is disabled by default. - - If in doubt, say N. - -config DRM_HEADER_TEST - bool "Ensure DRM headers are self-contained and pass kernel-doc" - depends on DRM && EXPERT - default n - help - Ensure the DRM subsystem headers both under drivers/gpu/drm and - include/dr
Re: [PATCH 1/1] MAINTAINERS: Change habanalabs maintainer
On 07/03/2025 11:21, Oded Gabbay wrote: > On Thu, Mar 06, 2025 at 03:51:24PM +0200, Avizrat, Yaron wrote: >> On 05/03/2025 13:57, Jani Nikula wrote: >>> On Wed, 05 Mar 2025, "Avizrat, Yaron" wrote: On 29/07/2024 15:17, Ofir Bitton wrote: > I will be leaving Intel soon, Yaron Avizrat will take the role > of habanalabs driver maintainer. > > Signed-off-by: Ofir Bitton > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ed2d2dbcec81..a4b36590061e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9599,7 +9599,7 @@ S: Maintained > F: block/partitions/efi.* > > HABANALABS PCI DRIVER > -M: Ofir Bitton > +M: Yaron Avizrat > L: dri-devel@lists.freedesktop.org > S: Supported > C: irc://irc.oftc.net/dri-devel Acked-by: Yaron Avizrat Apologies for the long silence — it’s been a challenging period with the Habanalabs-Intel merger, but we're back and ready to continue contributing. We'll be moving forward with our roadmap — upstreaming the latest HabanaLabs driver, including recent changes and full support for the entire GaudiX series. To support this effort, Koby Elbaz and Konstantin Sinyuk will join me as co-maintainers on a regular basis. >>> Should they be added as maintainers in the MAINTAINERS entry too? >>> >>> Are you going to pick this up and apply to the Habanalabs repo, and send >>> a pull request with it? Or how do you propose to proceed? >>> >>> >>> BR, >>> Jani. >>> >> Yes, in a later patch, they would be added as maintainers in the MAINTAINERS >> entry too. >> Regarding your second question, we should start with merging Ofir's initial >> patch. >> Any additional/upcoming changes will be initially merged into the official >> HabanaLabs repo as you mentioned above. >> >> Regards, >> Yaron >> > Acked-by: Oded Gabbay Reminder: can someone pick it up, please?
[PATCH v2 5/7] drm/tests: hdmi: Add macros to simplify EDID setup
Introduce a few macros to facilitate setting custom (i.e. non-default)
EDID data during connector initialization.
This helps reducing boilerplate code while also drops some redundant
calls to set_connector_edid().
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 245 -
1 file changed, 93 insertions(+), 152 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
index
e97efd3af9ed18e6cf8ee66b4923dfc805b34e19..a3f7f3ce31c73335c2c2643bdc5395b6ceb6f071
100644
--- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
@@ -183,10 +183,12 @@ static const struct drm_connector_funcs
dummy_connector_funcs = {
static
struct drm_atomic_helper_connector_hdmi_priv *
-drm_kunit_helper_connector_hdmi_init_funcs(struct kunit *test,
- unsigned int formats,
- unsigned int max_bpc,
- const struct
drm_connector_hdmi_funcs *hdmi_funcs)
+connector_hdmi_init_funcs_set_edid(struct kunit *test,
+ unsigned int formats,
+ unsigned int max_bpc,
+ const struct drm_connector_hdmi_funcs
*hdmi_funcs,
+ const char *edid_data,
+ size_t edid_len)
{
struct drm_atomic_helper_connector_hdmi_priv *priv;
struct drm_connector *conn;
@@ -240,30 +242,27 @@ drm_kunit_helper_connector_hdmi_init_funcs(struct kunit
*test,
drm_mode_config_reset(drm);
+ if (edid_data && edid_len) {
+ ret = set_connector_edid(test, &priv->connector, edid_data,
edid_len);
+ KUNIT_ASSERT_GT(test, ret, 0);
+ }
+
return priv;
}
-static
-struct drm_atomic_helper_connector_hdmi_priv *
-drm_kunit_helper_connector_hdmi_init(struct kunit *test,
-unsigned int formats,
-unsigned int max_bpc)
-{
- struct drm_atomic_helper_connector_hdmi_priv *priv;
- int ret;
+#define drm_kunit_helper_connector_hdmi_init_funcs_set_edid(test, formats,
max_bpc, funcs, edid) \
+ connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, edid,
ARRAY_SIZE(edid))
- priv = drm_kunit_helper_connector_hdmi_init_funcs(test,
- formats, max_bpc,
-
&dummy_connector_hdmi_funcs);
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
+#define drm_kunit_helper_connector_hdmi_init_funcs(test, formats, max_bpc,
funcs) \
+ connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, NULL,
0)
- ret = set_connector_edid(test, &priv->connector,
-test_edid_hdmi_1080p_rgb_max_200mhz,
-
ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
- KUNIT_ASSERT_GT(test, ret, 0);
+#define drm_kunit_helper_connector_hdmi_init_set_edid(test, formats, max_bpc,
edid)\
+ drm_kunit_helper_connector_hdmi_init_funcs_set_edid(test, formats,
max_bpc, \
+
&dummy_connector_hdmi_funcs, edid)
- return priv;
-}
+#define drm_kunit_helper_connector_hdmi_init(test, formats, max_bpc)
\
+ drm_kunit_helper_connector_hdmi_init_set_edid(test, formats, max_bpc,
\
+
test_edid_hdmi_1080p_rgb_max_200mhz)
/*
* Test that if we change the RGB quantization property to a different
@@ -771,19 +770,15 @@ static void
drm_test_check_output_bpc_crtc_mode_changed(struct kunit *test)
struct drm_crtc *crtc;
int ret;
- priv = drm_kunit_helper_connector_hdmi_init(test,
- BIT(HDMI_COLORSPACE_RGB),
- 10);
+ priv = drm_kunit_helper_connector_hdmi_init_set_edid(test,
+ BIT(HDMI_COLORSPACE_RGB),
+ 10,
+ test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz);
KUNIT_ASSERT_NOT_NULL(test, priv);
drm = &priv->drm;
crtc = priv->crtc;
conn = &priv->connector;
- ret = set_connector_edid(test, conn,
-test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz,
-
ARRAY_SIZE(test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz));
- KUNIT_ASSERT_GT(test, ret, 0);
-
preferred = find_preferred_mode(conn);
KUNIT_ASSERT_NOT_NULL(test, preferred);
@@ -847,19 +842,15 @@ static void
drm_test_check_output_bpc_crtc
[PATCH v2 1/7] drm/connector: hdmi: Evaluate limited range after computing format
Evaluating the requirement to use a limited RGB quantization range
involves a verification of the output format, among others, but this is
currently performed before actually computing the format, hence relying
on the old connector state.
Move the call to hdmi_is_limited_range() after hdmi_compute_config() to
ensure the verification is done on the updated output format.
Fixes: 027d43590649 ("drm/connector: hdmi: Add RGB Quantization Range to the
connector state")
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index
c205f37da1e12b11c384670db83e43613e031340..6bc96d5d1ab9115989e208d9899e16cd22254fb6
100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -506,12 +506,12 @@ int drm_atomic_helper_connector_hdmi_check(struct
drm_connector *connector,
if (!new_conn_state->crtc || !new_conn_state->best_encoder)
return 0;
- new_conn_state->hdmi.is_limited_range =
hdmi_is_limited_range(connector, new_conn_state);
-
ret = hdmi_compute_config(connector, new_conn_state, mode);
if (ret)
return ret;
+ new_conn_state->hdmi.is_limited_range =
hdmi_is_limited_range(connector, new_conn_state);
+
ret = hdmi_generate_infoframes(connector, new_conn_state);
if (ret)
return ret;
--
2.48.1
[PATCH v2 4/7] drm/connector: hdmi: Use YUV420 output format as an RGB fallback
Try to make use of YUV420 when computing the best output format and
RGB cannot be supported for any of the available color depths.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 69 +
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index
a70e204a8df3ac1c2d7318e81cde87a83267dd21..f2052781b797dd09b41127e33d98fe25408a9b23
100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -287,8 +287,9 @@ hdmi_try_format_bpc(const struct drm_connector *connector,
struct drm_device *dev = connector->dev;
int ret;
- drm_dbg_kms(dev, "Trying %s output format\n",
- drm_hdmi_connector_get_output_format_name(fmt));
+ drm_dbg_kms(dev, "Trying %s output format with %u bpc\n",
+ drm_hdmi_connector_get_output_format_name(fmt),
+ bpc);
if (!sink_supports_format_bpc(connector, info, mode, fmt, bpc)) {
drm_dbg_kms(dev, "%s output format not supported with %u bpc\n",
@@ -313,47 +314,22 @@ hdmi_try_format_bpc(const struct drm_connector *connector,
}
static int
-hdmi_compute_format(const struct drm_connector *connector,
- struct drm_connector_state *conn_state,
- const struct drm_display_mode *mode,
- unsigned int bpc)
-{
- struct drm_device *dev = connector->dev;
-
- /*
-* TODO: Add support for YCbCr420 output for HDMI 2.0 capable
-* devices, for modes that only support YCbCr420.
-*/
- if (hdmi_try_format_bpc(connector, conn_state, mode, bpc,
HDMI_COLORSPACE_RGB)) {
- conn_state->hdmi.output_format = HDMI_COLORSPACE_RGB;
- return 0;
- }
-
- drm_dbg_kms(dev, "Failed. No Format Supported for that bpc count.\n");
-
- return -EINVAL;
-}
-
-static int
-hdmi_compute_config(const struct drm_connector *connector,
- struct drm_connector_state *conn_state,
- const struct drm_display_mode *mode)
+hdmi_try_format(const struct drm_connector *connector,
+ struct drm_connector_state *conn_state,
+ const struct drm_display_mode *mode,
+ unsigned int max_bpc, enum hdmi_colorspace fmt)
{
struct drm_device *dev = connector->dev;
- unsigned int max_bpc = clamp_t(unsigned int,
- conn_state->max_bpc,
- 8, connector->max_bpc);
unsigned int bpc;
int ret;
for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
- drm_dbg_kms(dev, "Trying with a %d bpc output\n", bpc);
-
- ret = hdmi_compute_format(connector, conn_state, mode, bpc);
- if (ret)
+ ret = hdmi_try_format_bpc(connector, conn_state, mode, bpc,
fmt);
+ if (!ret)
continue;
conn_state->hdmi.output_bpc = bpc;
+ conn_state->hdmi.output_format = fmt;
drm_dbg_kms(dev,
"Mode %ux%u @ %uHz: Found configuration: bpc: %u,
fmt: %s, clock: %llu\n",
@@ -368,6 +344,31 @@ hdmi_compute_config(const struct drm_connector *connector,
return -EINVAL;
}
+static int
+hdmi_compute_config(const struct drm_connector *connector,
+ struct drm_connector_state *conn_state,
+ const struct drm_display_mode *mode)
+{
+ unsigned int max_bpc = clamp_t(unsigned int,
+ conn_state->max_bpc,
+ 8, connector->max_bpc);
+ int ret;
+
+ ret = hdmi_try_format(connector, conn_state, mode, max_bpc,
+ HDMI_COLORSPACE_RGB);
+ if (!ret)
+ return 0;
+
+ if (connector->ycbcr_420_allowed)
+ ret = hdmi_try_format(connector, conn_state, mode, max_bpc,
+ HDMI_COLORSPACE_YUV420);
+ else
+ drm_dbg_kms(connector->dev,
+ "%s output format not allowed for connector\n",
+
drm_hdmi_connector_get_output_format_name(HDMI_COLORSPACE_YUV420));
+ return ret;
+}
+
static int hdmi_generate_avi_infoframe(const struct drm_connector *connector,
struct drm_connector_state *conn_state)
{
--
2.48.1
[PATCH v2 0/7] drm/connector: hdmi: Allow using the YUV420 output format
Provide the basic support to enable using YUV420 as an RGB fallback when computing the best output format and color depth. Signed-off-by: Cristian Ciocaltea --- Changes in v2: - Provided the missing Fixes tag on first patch (Dmitry) - Added patch "drm/connector: hdmi: Improve debug message for supported format" - Reworked "drm/connector: hdmi: Use YUV420 output format as an RGB fallback" so that the fallback to YUV420 will be attempted only when RGB cannot be supported for any of the available color depths (Maxime) - Added a patch to simplify EDID setup in KUnit cases - Added two patches extending KUnit coverage for YUV420 by providing tests for limited range and max TMDS rate fallback - Rebased series onto drm-misc-next-2025-03-06 - Link to v1: https://lore.kernel.org/r/20241130-hdmi-conn-yuv-v1-0-254279a08...@collabora.com --- Cristian Ciocaltea (7): drm/connector: hdmi: Evaluate limited range after computing format drm/connector: hdmi: Add support for YUV420 format verification drm/connector: hdmi: Improve debug message for supported format drm/connector: hdmi: Use YUV420 output format as an RGB fallback drm/tests: hdmi: Add macros to simplify EDID setup drm/tests: hdmi: Add limited range tests for YUV420 mode drm/tests: hdmi: Add max TMDS rate fallback tests for YUV420 mode drivers/gpu/drm/display/drm_hdmi_state_helper.c| 115 +++-- drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 479 ++--- drivers/gpu/drm/tests/drm_kunit_edid.h | 222 ++ 3 files changed, 615 insertions(+), 201 deletions(-) --- base-commit: 4423e607ff50157aaf088854b145936cbab4d560 change-id: 20241130-hdmi-conn-yuv-e1fa596df768
[PATCH v2 7/7] drm/tests: hdmi: Add max TMDS rate fallback tests for YUV420 mode
Provide tests to verify drm_atomic_helper_connector_hdmi_check() helper
fallback behavior when using YUV420 output.
Also rename drm_test_check_max_tmds_rate_{bpc|format}_fallback() to
better differentiate from the newly introduced *_yuv420() variants.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 145 -
drivers/gpu/drm/tests/drm_kunit_edid.h | 110
2 files changed, 251 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
index
1df12c0b7768e4f85f4c943840d9b4dcb6e079e0..77da5b88c4cbd5bba22f4f0ce1ef2928042d7d50
100644
--- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
@@ -1223,7 +1223,7 @@ static void drm_test_check_hdmi_funcs_reject_rate(struct
kunit *test)
* Then we will pick the latter, and the computed TMDS character rate
* will be equal to 1.25 times the mode pixel clock.
*/
-static void drm_test_check_max_tmds_rate_bpc_fallback(struct kunit *test)
+static void drm_test_check_max_tmds_rate_bpc_fallback_rgb(struct kunit *test)
{
struct drm_atomic_helper_connector_hdmi_priv *priv;
struct drm_modeset_acquire_ctx ctx;
@@ -1275,6 +1275,72 @@ static void
drm_test_check_max_tmds_rate_bpc_fallback(struct kunit *test)
drm_modeset_acquire_fini(&ctx);
}
+/*
+ * Test that if:
+ * - We have an HDMI connector supporting both RGB and YUV420
+ * - The chosen mode can be supported in YUV420 output format only
+ * - The chosen mode has a TMDS character rate higher than the display
+ * supports in YUV420/12bpc
+ * - The chosen mode has a TMDS character rate lower than the display
+ * supports in YUV420/10bpc.
+ *
+ * Then we will pick the latter, and the computed TMDS character rate
+ * will be equal to 1.25 * 0.5 times the mode pixel clock.
+ */
+static void drm_test_check_max_tmds_rate_bpc_fallback_yuv420(struct kunit
*test)
+{
+ struct drm_atomic_helper_connector_hdmi_priv *priv;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_connector_state *conn_state;
+ struct drm_display_info *info;
+ struct drm_display_mode *yuv420_only_mode;
+ unsigned long long rate;
+ struct drm_connector *conn;
+ struct drm_device *drm;
+ struct drm_crtc *crtc;
+ int ret;
+
+ priv = drm_kunit_helper_connector_hdmi_init_set_edid(test,
+ BIT(HDMI_COLORSPACE_RGB) |
+ BIT(HDMI_COLORSPACE_YUV420),
+ 12,
+
test_edid_hdmi_1080p_rgb_yuv_4k_yuv420_dc_max_200mhz);
+ KUNIT_ASSERT_NOT_NULL(test, priv);
+
+ drm = &priv->drm;
+ crtc = priv->crtc;
+ conn = &priv->connector;
+ info = &conn->display_info;
+ KUNIT_ASSERT_TRUE(test, info->is_hdmi);
+ KUNIT_ASSERT_GT(test, info->max_tmds_clock, 0);
+
+ yuv420_only_mode = drm_kunit_display_mode_from_cea_vic(test, drm, 95);
+ KUNIT_ASSERT_NOT_NULL(test, yuv420_only_mode);
+ KUNIT_ASSERT_TRUE(test, drm_mode_is_420_only(info, yuv420_only_mode));
+
+ rate = drm_hdmi_compute_mode_clock(yuv420_only_mode, 12,
HDMI_COLORSPACE_YUV420);
+ KUNIT_ASSERT_GT(test, rate, info->max_tmds_clock * 1000);
+
+ rate = drm_hdmi_compute_mode_clock(yuv420_only_mode, 10,
HDMI_COLORSPACE_YUV420);
+ KUNIT_ASSERT_LT(test, rate, info->max_tmds_clock * 1000);
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+ ret = light_up_connector(test, drm, crtc, conn, yuv420_only_mode, &ctx);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+
+ conn_state = conn->state;
+ KUNIT_ASSERT_NOT_NULL(test, conn_state);
+
+ KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_bpc, 10);
+ KUNIT_EXPECT_EQ(test, conn_state->hdmi.output_format,
HDMI_COLORSPACE_YUV420);
+ KUNIT_EXPECT_EQ(test, conn_state->hdmi.tmds_char_rate,
+ yuv420_only_mode->clock * 1250 * 0.5);
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+}
+
/*
* Test that if:
* - We have an HDMI connector supporting both RGB and YUV422 and up to
@@ -1288,7 +1354,7 @@ static void
drm_test_check_max_tmds_rate_bpc_fallback(struct kunit *test)
* Then we will prefer to keep the RGB format with a lower bpc over
* picking YUV422.
*/
-static void drm_test_check_max_tmds_rate_format_fallback(struct kunit *test)
+static void drm_test_check_max_tmds_rate_format_fallback_yuv422(struct kunit
*test)
{
struct drm_atomic_helper_connector_hdmi_priv *priv;
struct drm_modeset_acquire_ctx ctx;
@@ -1344,6 +1410,75 @@ static void
drm_test_check_max_tmds_rate_format_fallback(struct kunit *test)
drm_modeset_acquire_fini(&ctx);
}
+/*
+ * Test that if:
+ * - We have an HDMI connector supporting both RGB and YUV420 and up to
+ * 12 bpc
+ * - The chosen mod
[PATCH v2 2/7] drm/connector: hdmi: Add support for YUV420 format verification
Provide the necessary constraints verification in
sink_supports_format_bpc() in order to support handling of YUV420
output format.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 40 +++--
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index
6bc96d5d1ab9115989e208d9899e16cd22254fb6..e99d868edc1854eddc5ebf8692ccffb9e2338268
100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include
#include
@@ -115,6 +116,12 @@ sink_supports_format_bpc(const struct drm_connector
*connector,
return false;
}
+ if (drm_mode_is_420_only(info, mode) && format !=
HDMI_COLORSPACE_YUV420) {
+ drm_dbg_kms(dev, "%s format unsupported by the sink for
VIC%u.\n",
+ drm_hdmi_connector_get_output_format_name(format),
vic);
+ return false;
+ }
+
switch (format) {
case HDMI_COLORSPACE_RGB:
drm_dbg_kms(dev, "RGB Format, checking the constraints.\n");
@@ -145,9 +152,36 @@ sink_supports_format_bpc(const struct drm_connector
*connector,
return true;
case HDMI_COLORSPACE_YUV420:
- /* TODO: YUV420 is unsupported at the moment. */
- drm_dbg_kms(dev, "YUV420 format isn't supported yet.\n");
- return false;
+ drm_dbg_kms(dev, "YUV420 format, checking the constraints.\n");
+
+ if (!(info->color_formats & DRM_COLOR_FORMAT_YCBCR420)) {
+ drm_dbg_kms(dev, "Sink doesn't support YUV420.\n");
+ return false;
+ }
+
+ if (!drm_mode_is_420(info, mode)) {
+ drm_dbg_kms(dev, "Sink doesn't support YUV420 for
VIC%u.\n", vic);
+ return false;
+ }
+
+ if (bpc == 10 && !(info->hdmi.y420_dc_modes &
DRM_EDID_YCBCR420_DC_30)) {
+ drm_dbg_kms(dev, "10 BPC but sink doesn't support Deep
Color 30.\n");
+ return false;
+ }
+
+ if (bpc == 12 && !(info->hdmi.y420_dc_modes &
DRM_EDID_YCBCR420_DC_36)) {
+ drm_dbg_kms(dev, "12 BPC but sink doesn't support Deep
Color 36.\n");
+ return false;
+ }
+
+ if (bpc == 16 && !(info->hdmi.y420_dc_modes &
DRM_EDID_YCBCR420_DC_48)) {
+ drm_dbg_kms(dev, "16 BPC but sink doesn't support Deep
Color 48.\n");
+ return false;
+ }
+
+ drm_dbg_kms(dev, "YUV420 format supported in that
configuration.\n");
+
+ return true;
case HDMI_COLORSPACE_YUV422:
drm_dbg_kms(dev, "YUV422 format, checking the constraints.\n");
--
2.48.1
Re: [PATCH v1] arm64: defconfig: mediatek: enable PHY drivers
Hi Krzysztof, On 11/03/25 12:54, Krzysztof Kozlowski wrote: On 11/03/2025 07:16, Vignesh Raman wrote: The mediatek display driver fails to probe on mt8173 and mt8183 in v6.14-rc4, with the following errors: Which boards? These are the boards, https://lava.pages.collabora.com/docs/boards/chromebooks/boards/hana/ https://lava.pages.collabora.com/docs/boards/chromebooks/boards/jacuzzi/ mt8173: platform 1401b000.dsi: deferred probe pending: mtk-dsi: Failed to get hs clock platform 14025000.hdmi: deferred probe pending: (reason unknown) i2c 1-0008: deferred probe pending: (reason unknown) mt8183: platform 14014000.dsi: deferred probe pending: mtk-dsi: Failed to get hs clock i2c 4-0058: deferred probe pending: anx7625: fail to find dsi host. Enabling CONFIG_PHY_MTK_MIPI_DSI=y in drm-ci resolves this error, but mt8173 still fails with, [drm:mtk_dsi_host_attach] *ERROR* failed to add dsi_host component: -517 panel-simple-dp-aux aux-1-0008: DP AUX done_probing() can't defer panel-simple-dp-aux aux-1-0008: probe with driver panel-simple-dp-aux failed with error -22 Enabling CONFIG_PHY_MTK_XSPHY=y and CONFIG_PHY_MTK_HDMI=y in drm-ci resolves this issue for mt8173. So enable these PHY configs for mediatek platforms. Just say which boards need it for which functionality/features. Three sentences are enough. Sure, will update the commit message. Thanks. Regards, Vignesh Best regards, Krzysztof
Re: [PATCH 04/10] drm/i915/display: Add filter lut values
On 3/4/2025 3:58 PM, Nemesa Garg wrote:
Add the register bits related to filter lut values
and populate the table.
Lets have some more details about the LUT values and the fact that they
are only needed to be loaded once.
With that fixed this looks good to me.
Reviewed-by: Ankit Nautiyal
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_casf.c | 22 +++
drivers/gpu/drm/i915/display/intel_casf.h | 3 +++
.../gpu/drm/i915/display/intel_casf_regs.h| 11 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_casf.c
b/drivers/gpu/drm/i915/display/intel_casf.c
index 2c406e7c5fb6..ed72bccbb93f 100644
--- a/drivers/gpu/drm/i915/display/intel_casf.c
+++ b/drivers/gpu/drm/i915/display/intel_casf.c
@@ -25,6 +25,28 @@
* to original image.
*/
+/* Default LUT values to be loaded one time. */
+static const u16 sharpness_lut[] = {
+ 4095, 2047, 1364, 1022, 816, 678, 579,
+ 504, 444, 397, 357, 323, 293, 268, 244, 224,
+ 204, 187, 170, 154, 139, 125, 111, 98, 85,
+ 73, 60, 48, 36, 24, 12, 0
+};
+
+void intel_filter_lut_load(struct intel_crtc *crtc,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_display *display = to_intel_display(crtc_state);
+ int i;
+
+ intel_de_write(display, SHRPLUT_INDEX(crtc->pipe),
+ INDEX_AUTO_INCR | INDEX_VALUE(0));
+
+ for (i = 0; i < ARRAY_SIZE(sharpness_lut); i++)
+ intel_de_write(display, SHRPLUT_DATA(crtc->pipe),
+ sharpness_lut[i]);
+}
+
void intel_casf_update_strength(struct intel_crtc_state *crtc_state)
{
struct intel_display *display = to_intel_display(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_casf.h
b/drivers/gpu/drm/i915/display/intel_casf.h
index 6e308c367c17..faeed50de2ba 100644
--- a/drivers/gpu/drm/i915/display/intel_casf.h
+++ b/drivers/gpu/drm/i915/display/intel_casf.h
@@ -9,8 +9,11 @@
#include
struct intel_crtc_state;
+struct intel_crtc;
int intel_casf_compute_config(struct intel_crtc_state *crtc_state);
void intel_casf_update_strength(struct intel_crtc_state *new_crtc_state);
+void intel_filter_lut_load(struct intel_crtc *crtc,
+ const struct intel_crtc_state *crtc_state);
#endif /* __INTEL_CASF_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_casf_regs.h
b/drivers/gpu/drm/i915/display/intel_casf_regs.h
index e5fa4d9bb309..c61755a401ff 100644
--- a/drivers/gpu/drm/i915/display/intel_casf_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_casf_regs.h
@@ -19,5 +19,16 @@
#define SHARPNESS_FILTER_SIZE_5X5REG_FIELD_PREP(FILTER_SIZE_MASK, 1)
#define SHARPNESS_FILTER_SIZE_7X7REG_FIELD_PREP(FILTER_SIZE_MASK, 2)
+#define _SHRPLUT_DATA_A0x682B8
+#define _SHRPLUT_DATA_B0x68AB8
+#define SHRPLUT_DATA(pipe) _MMIO_PIPE(pipe, _SHRPLUT_DATA_A,
_SHRPLUT_DATA_B)
+
+#define _SHRPLUT_INDEX_A 0x682B4
+#define _SHRPLUT_INDEX_B 0x68AB4
+#define SHRPLUT_INDEX(pipe)_MMIO_PIPE(pipe, _SHRPLUT_INDEX_A,
_SHRPLUT_INDEX_B)
+#define INDEX_AUTO_INCR REG_BIT(10)
+#define INDEX_VALUE_MASK REG_GENMASK(4, 0)
+#define INDEX_VALUE(x) REG_FIELD_PREP(INDEX_VALUE_MASK, (x))
+
#endif /* __INTEL_CASF_REGS__ */
Re: [PATCH 05/10] drm/i915/display: Compute the scaler filter coefficients
On 3/4/2025 3:58 PM, Nemesa Garg wrote:
The sharpness property requires the use of one of the scaler
so need to set the sharpness scaler coefficient values.
These values are based on experiments and vary for different
tap value/win size. These values are normalized by taking the
sum of all values and then dividing each value with a sum.
v2: Fix ifndef header naming issue reported by kernel test robot
v3: Rename file name[Arun]
Replace array size number with macro[Arun]
v4: Correct the register format[Jani]
Add brief comment and expalin about file[Jani]
Remove coefficient value from crtc_state[Jani]
v5: Fix build issue
v6: Add new function for writing coefficients[Ankit]
v7: Add cooments and add a scaler id check [Ankit]
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_casf.c | 124 ++
drivers/gpu/drm/i915/display/intel_casf.h | 2 +
.../gpu/drm/i915/display/intel_casf_regs.h| 7 +
.../drm/i915/display/intel_display_types.h| 8 ++
4 files changed, 141 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_casf.c
b/drivers/gpu/drm/i915/display/intel_casf.c
index ed72bccbb93f..ff34e390c8fe 100644
--- a/drivers/gpu/drm/i915/display/intel_casf.c
+++ b/drivers/gpu/drm/i915/display/intel_casf.c
@@ -12,6 +12,13 @@
#define MAX_PIXELS_FOR_3_TAP_FILTER (1920 * 1080)
#define MAX_PIXELS_FOR_5_TAP_FILTER (3840 * 2160)
+#define FILTER_COEFF_0_125 125
+#define FILTER_COEFF_0_25 250
+#define FILTER_COEFF_0_5 500
+#define FILTER_COEFF_1_0 1000
+#define FILTER_COEFF_0_0 0
+#define SET_POSITIVE_SIGN(x) ((x) & (~SIGN))
+
/**
* DOC: Content Adaptive Sharpness Filter (CASF)
*
@@ -33,6 +40,24 @@ static const u16 sharpness_lut[] = {
73, 60, 48, 36, 24, 12, 0
};
+const u16 filtercoeff_1[] = {
+ FILTER_COEFF_0_0, FILTER_COEFF_0_0, FILTER_COEFF_0_5,
+ FILTER_COEFF_1_0, FILTER_COEFF_0_5, FILTER_COEFF_0_0,
+ FILTER_COEFF_0_0,
+};
+
+const u16 filtercoeff_2[] = {
+ FILTER_COEFF_0_0, FILTER_COEFF_0_25, FILTER_COEFF_0_5,
+ FILTER_COEFF_1_0, FILTER_COEFF_0_5, FILTER_COEFF_0_25,
+ FILTER_COEFF_0_0,
+};
+
+const u16 filtercoeff_3[] = {
+ FILTER_COEFF_0_125, FILTER_COEFF_0_25, FILTER_COEFF_0_5,
+ FILTER_COEFF_1_0, FILTER_COEFF_0_5, FILTER_COEFF_0_25,
+ FILTER_COEFF_0_125,
+};
+
void intel_filter_lut_load(struct intel_crtc *crtc,
const struct intel_crtc_state *crtc_state)
{
@@ -88,3 +113,102 @@ int intel_casf_compute_config(struct intel_crtc_state
*crtc_state)
return 0;
}
+
+static int casf_coeff_tap(int i)
+{
+ return i % SCALER_FILTER_NUM_TAPS;
+}
+
+static u16 casf_coeff(struct intel_crtc_state *crtc_state, int t)
+{
+ struct scaler_filter_coeff value;
+ u16 coeff;
+
+ value = crtc_state->hw.casf_params.coeff[t];
+ coeff = SET_POSITIVE_SIGN(0) | EXPONENT(value.exp) |
MANTISSA(value.mantissa);
+ return coeff;
+}
+
+/*
+ * 17 phase of 7 taps requires 119 coefficients in 60 dwords per set.
+ * To enable casf: program scaler coefficients with the coeffients
+ * that are calculated and stored in hw.casf_params.coeff as per
+ * SCALER_COEFFICIENT_FORMAT
+ */
+
Remove extra line from here.
+static void intel_casf_write_coeff(struct intel_crtc_state *crtc_state)
+{
+ struct intel_display *display = to_intel_display(crtc_state);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ int id = crtc_state->scaler_state.scaler_id;
+ int i;
+
+ if (id != 1) {
+ drm_WARN(display->drm, 0, "Second scaler not enabled\n");
+ return;
+ }
+
+ intel_de_write_fw(display, GLK_PS_COEF_INDEX_SET(crtc->pipe, id, 0),
+ PS_COEF_INDEX_AUTO_INC);
+
+ for (i = 0; i < 17 * SCALER_FILTER_NUM_TAPS; i += 2) {
+ u32 tmp;
+ int t;
+
+ t = casf_coeff_tap(i);
+ tmp = casf_coeff(crtc_state, t);
+
+ t = casf_coeff_tap(i + 1);
+ tmp |= casf_coeff(crtc_state, t) << 16;
+
+ intel_de_write_fw(display, GLK_PS_COEF_DATA_SET(crtc->pipe, id,
0),
+ tmp);
+ }
+}
+
+static void convert_sharpness_coef_binary(struct scaler_filter_coeff *coeff,
+ u16 coefficient)
+{
+ if (coefficient < 25) {
+ coeff->mantissa = (coefficient * 2048) / 100;
+ coeff->exp = 3;
+ } else if (coefficient < 50) {
+ coeff->mantissa = (coefficient * 1024) / 100;
+ coeff->exp = 2;
+ } else if (coefficient < 100) {
+ coeff->mantissa = (coefficient * 512) / 100;
+ coeff->exp = 1;
+ } else {
+ coeff->mantissa = (coefficient * 256) / 100;
+ coeff->exp = 0;
+ }
+}
+
+void intel_casf_scaler_compute_config(struct intel_crtc_state *crtc_state)
+{
+
Re: [PATCH 06/10] drm/i915/display: Add and compute scaler parameter
On 3/4/2025 3:58 PM, Nemesa Garg wrote:
Compute the values for second scaler for sharpness.
Fill the register bits corresponding to the scaler.
v1: Rename the title of patch [Ankit]
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_casf.c | 3 ++
drivers/gpu/drm/i915/display/skl_scaler.c | 46 +++
drivers/gpu/drm/i915/display/skl_scaler.h | 1 +
3 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_casf.c
b/drivers/gpu/drm/i915/display/intel_casf.c
index ff34e390c8fe..15ae555e571e 100644
--- a/drivers/gpu/drm/i915/display/intel_casf.c
+++ b/drivers/gpu/drm/i915/display/intel_casf.c
@@ -8,6 +8,7 @@
#include "intel_casf_regs.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "skl_scaler.h"
#define MAX_PIXELS_FOR_3_TAP_FILTER (1920 * 1080)
#define MAX_PIXELS_FOR_5_TAP_FILTER (3840 * 2160)
@@ -211,4 +212,6 @@ void intel_casf_scaler_compute_config(struct
intel_crtc_state *crtc_state)
void intel_casf_enable(struct intel_crtc_state *crtc_state)
{
intel_casf_write_coeff(crtc_state);
+
+ skl_scaler_setup_casf(crtc_state);
}
Remove from this patch and add this where casf_enable is introduced later.
Otherwise looks good to me.
Reviewed-by: Ankit Nautiyal
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index f0cf966211c9..39fc537e54f0 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -133,6 +133,13 @@ static void skl_scaler_max_dst_size(struct intel_crtc
*crtc,
}
}
+#define CASF_SCALER_FILTER_SELECT \
+ (PS_FILTER_PROGRAMMED | \
+ PS_Y_VERT_FILTER_SELECT(0) | \
+ PS_Y_HORZ_FILTER_SELECT(0) | \
+ PS_UV_VERT_FILTER_SELECT(0) | \
+ PS_UV_HORZ_FILTER_SELECT(0))
+
static int
skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
unsigned int scaler_user, int *scaler_id,
@@ -722,6 +729,45 @@ static void skl_scaler_setup_filter(struct intel_display
*display,
}
}
+void skl_scaler_setup_casf(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct intel_display *display = to_intel_display(crtc);
+ struct drm_display_mode *adjusted_mode =
+ &crtc_state->hw.adjusted_mode;
+ struct intel_crtc_scaler_state *scaler_state =
+ &crtc_state->scaler_state;
+ struct drm_rect src, dest;
+ int id, width, height;
+ int x = 0, y = 0;
+ enum pipe pipe = crtc->pipe;
+ u32 ps_ctrl;
+
+ width = adjusted_mode->crtc_hdisplay;
+ height = adjusted_mode->crtc_vdisplay;
+
+ drm_rect_init(&dest, x, y, width, height);
+
+ width = drm_rect_width(&dest);
+ height = drm_rect_height(&dest);
+ id = scaler_state->scaler_id;
+
+ drm_rect_init(&src, 0, 0,
+ drm_rect_width(&crtc_state->pipe_src) << 16,
+ drm_rect_height(&crtc_state->pipe_src) << 16);
+
+ trace_intel_pipe_scaler_update_arm(crtc, id, x, y, width, height);
+
+ ps_ctrl = PS_SCALER_EN | PS_BINDING_PIPE |
scaler_state->scalers[id].mode |
+ CASF_SCALER_FILTER_SELECT;
+
+ intel_de_write_fw(display, SKL_PS_CTRL(pipe, id), ps_ctrl);
+ intel_de_write_fw(display, SKL_PS_WIN_POS(pipe, id),
+ PS_WIN_XPOS(x) | PS_WIN_YPOS(y));
+ intel_de_write_fw(display, SKL_PS_WIN_SZ(pipe, id),
+ PS_WIN_XSIZE(width) | PS_WIN_YSIZE(height));
+}
+
void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
{
struct intel_display *display = to_intel_display(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.h
b/drivers/gpu/drm/i915/display/skl_scaler.h
index 355ea15260ca..22fcfe78b506 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.h
+++ b/drivers/gpu/drm/i915/display/skl_scaler.h
@@ -31,5 +31,6 @@ void skl_detach_scalers(struct intel_dsb *dsb,
void skl_scaler_disable(const struct intel_crtc_state *old_crtc_state);
void skl_scaler_get_config(struct intel_crtc_state *crtc_state);
+void skl_scaler_setup_casf(struct intel_crtc_state *crtc_state);
#endif
Re: [PATCH v3 2/2] mfd: lm3533: convert to use OF
On Sat, 08 Mar 2025, Jonathan Cameron wrote:
> On Wed, 5 Mar 2025 16:18:38 +0200
> Svyatoslav Ryhel wrote:
>
> > ср, 5 бер. 2025 р. о 15:45 Jonathan Cameron пише:
> > >
> > > On Fri, 28 Feb 2025 11:30:51 +0200
> > > Svyatoslav Ryhel wrote:
> > >
> > > > пт, 28 лют. 2025 р. о 10:59 Lee Jones пише:
> > > > >
> > > > > On Mon, 24 Feb 2025, Svyatoslav Ryhel wrote:
> > > > >
> > > > > > Remove platform data and fully relay on OF and device tree
> > > > > > parsing and binding devices.
> > > > > >
> > > > > > Signed-off-by: Svyatoslav Ryhel
> > > > > > ---
> > > > > > drivers/iio/light/lm3533-als.c | 40 ---
> > > > > > drivers/leds/leds-lm3533.c | 46 +---
> > > > > > drivers/mfd/lm3533-core.c | 159
> > > > > >
> > > > > > drivers/video/backlight/lm3533_bl.c | 71 ++---
> > > > > > include/linux/mfd/lm3533.h | 35 +-
> > > > > > 5 files changed, 164 insertions(+), 187 deletions(-)
> > > > > >
> > ...
> > > > > > /* ALS input is always high impedance in PWM-mode. */
> > > > > > - if (!pdata->pwm_mode) {
> > > > > > - ret = lm3533_als_set_resistor(als, pdata->r_select);
> > > > > > + if (!als->pwm_mode) {
> > > > > > + ret = lm3533_als_set_resistor(als, als->r_select);
> > > > >
> > > > > You're already passing 'als'.
> > > > >
> > > > > Just teach lm3533_als_set_resistor that 'r_select' is now contained.
> > > > >
> > > >
> > > > This is not scope of this patchset. I was already accused in too much
> > > > changes which make it unreadable. This patchset is dedicated to
> > > > swapping platform data to use of the device tree. NOT improving
> > > > functions, NOT rewriting arbitrary mechanics. If you feed a need for
> > > > this change, then propose a followup. I need from this driver only one
> > > > thing, that it could work with device tree. But it seems that it is
> > > > better that it just rots in the garbage bin until removed cause no one
> > > > cared.
> > >
> > > This is not an unreasonable request as you added r_select to als.
> > > Perhaps it belongs in a separate follow up patch.
> >
> > I have just moved values used in pdata to private structs of each
> > driver. Without changing names or purpose.
> >
> > > However
> > > it is worth remembering the motivation here is that you want get
> > > this code upstream, the maintainers don't have that motivation.
> >
> > This driver is already upstream and it is useless and incompatible
> > with majority of supported devices. Maintainers should encourage those
> > who try to help and instead we have what? A total discouragement. Well
> > defined path into nowhere.
>
> That is not how I read the situation. A simple request was made to
> result in more maintainable code as a direct result of that
> improvement being enabled by code changes you were making.
> I'm sorry to hear that discouraged you.
>
> >
> > >
> > > Greg KH has given various talks on the different motivations in the
> > > past. It maybe worth a watch.
> > >
> > >
> > > >
> > > > > > if (ret)
> > > > > > return ret;
> > > > > > }
> > > > > > @@ -828,22 +833,16 @@ static const struct iio_info lm3533_als_info
> > > > > > = {
> > > > > >
> > > > > > static int lm3533_als_probe(struct platform_device *pdev)
> > > > > > {
> > > > > > - const struct lm3533_als_platform_data *pdata;
> > > > > > struct lm3533 *lm3533;
> > > > > > struct lm3533_als *als;
> > > > > > struct iio_dev *indio_dev;
> > > > > > + u32 val;
> > > > >
> > > > > Value of what, potatoes?
> > > > >
> > > >
> > > > Oranges.
> > >
> > > A well named variable would avoid need for any discussion of
> > > what it is the value of.
> > >
> >
> > This is temporary placeholder used to get values from the tree and
> > then pass it driver struct.
>
> Better if it is a temporary placeholder with a meaningful name.
>
> >
> > > >
> > > > > > int ret;
> > > > > >
> > > > > > lm3533 = dev_get_drvdata(pdev->dev.parent);
> > > > > > if (!lm3533)
> > > > > > return -EINVAL;
> > > > > >
> > > > > > - pdata = dev_get_platdata(&pdev->dev);
> > > > > > - if (!pdata) {
> > > > > > - dev_err(&pdev->dev, "no platform data\n");
> > > > > > - return -EINVAL;
> > > > > > - }
> > > > > > -
> > > > > > indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*als));
> > > > > > if (!indio_dev)
> > > > > > return -ENOMEM;
> > > > > > @@ -864,13 +863,21 @@ static int lm3533_als_probe(struct
> > > > > > platform_device *pdev)
> > > > > >
> > > > > > platform_set_drvdata(pdev, indio_dev);
> > > > > >
> > > > > > + val = 200 * KILO; /* 200kOhm */
> > > > >
> > > > > Better to #define magic numbers; DEFAULT_{DESCRIPTION}_OHMS
> > > > >
> > > >
> > > > Why? that is not needed.
> > > If this variable had a more useful name the
Re: [PATCH v3 18/21] drm/msm/dpu: Implement 10-bit color alpha for v12.0 DPU
On 21/02/2025 17:25, Dmitry Baryshkov wrote:
>> -static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
>> -struct dpu_plane_state *pstate, const struct msm_format *format)
>> +static void _dpu_crtc_setup_blend_cfg(const struct dpu_hw_ctl *ctl,
>> + struct dpu_crtc_mixer *mixer,
>> + struct dpu_plane_state *pstate,
>> + const struct msm_format *format)
>> {
>> struct dpu_hw_mixer *lm = mixer->hw_lm;
>> uint32_t blend_op;
>> -uint32_t fg_alpha, bg_alpha;
>> +uint32_t fg_alpha, bg_alpha, max_alpha;
>>
>> fg_alpha = pstate->base.alpha >> 8;
>> -bg_alpha = 0xff - fg_alpha;
>> +if (ctl->mdss_ver->core_major_ver < 12)
>> +max_alpha = 0xff;
>> +else
>> +max_alpha = 0x3ff;
>
> So, CTL is passed only to get struct dpu_mdss_version? It can either be
> passed directly or fetched via dpu_kms->catalog->mdss_ver
Ack.
>
>> +bg_alpha = max_alpha - fg_alpha;
>>
>> /* default to opaque blending */
>> if (pstate->base.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
>> @@ -337,7 +343,7 @@ static void _dpu_crtc_setup_blend_cfg(struct
>> dpu_crtc_mixer *mixer,
>> } else if (pstate->base.pixel_blend_mode == DRM_MODE_BLEND_PREMULTI) {
>> blend_op = DPU_BLEND_FG_ALPHA_FG_CONST |
>> DPU_BLEND_BG_ALPHA_FG_PIXEL;
>> -if (fg_alpha != 0xff) {
>> +if (fg_alpha != max_alpha) {
>> bg_alpha = fg_alpha;
>> blend_op |= DPU_BLEND_BG_MOD_ALPHA |
>> DPU_BLEND_BG_INV_MOD_ALPHA;
>> @@ -348,7 +354,7 @@ static void _dpu_crtc_setup_blend_cfg(struct
>> dpu_crtc_mixer *mixer,
>> /* coverage blending */
>> blend_op = DPU_BLEND_FG_ALPHA_FG_PIXEL |
>> DPU_BLEND_BG_ALPHA_FG_PIXEL;
>> -if (fg_alpha != 0xff) {
>> +if (fg_alpha != max_alpha) {
>> bg_alpha = fg_alpha;
>> blend_op |= DPU_BLEND_FG_MOD_ALPHA |
>> DPU_BLEND_FG_INV_MOD_ALPHA |
>> @@ -482,7 +488,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
>> *crtc,
>>
>> /* blend config update */
>> for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
>> -_dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate,
>> format);
>> +_dpu_crtc_setup_blend_cfg(ctl, mixer + lm_idx, pstate,
>> format);
>>
>> if (bg_alpha_enable && !format->alpha_enable)
>> mixer[lm_idx].mixer_op_mode = 0;
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
>> index
>> 3bfb61cb83672dca4236bdbbbfb1e442223576d2..75bf3521b03c8e243ccfe1fc226aa71f23b296df
>> 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
>> @@ -19,12 +19,20 @@
>>
>> /* These register are offset to mixer base + stage base */
>> #define LM_BLEND0_OP 0x00
>> +
>> +/* > #define LM_BLEND0_CONST_ALPHA0x04
>> #define LM_FG_COLOR_FILL_COLOR_0 0x08
>> #define LM_FG_COLOR_FILL_COLOR_1 0x0C
>
> lowercase hex
Ack
>
>> #define LM_FG_COLOR_FILL_SIZE0x10
>> #define LM_FG_COLOR_FILL_XY 0x14
>>
>> +/* >= v12 DPU */
>> +#define LM_BORDER_COLOR_0_V12 0x1C
>
> lowercase hex
>
>> +#define LM_BORDER_COLOR_1_V12 0x20
>> +
>> +/* >= v12 DPU with offset to mixer base + stage base */
>> +#define LM_BLEND0_CONST_ALPHA_V12 0x08
>
> This doesn't seem to be aligned properly
That's only patch view... because I used tabs. I think existing code
uses spaces, so I will switch to spaces.
Best regards,
Krzysztof
[PATCH 5.4 120/328] m68k: vga: Fix I/O defines
5.4-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream.
Including m68k's in vga.h on nommu platforms results
in conflicting defines with io_no.h for various I/O macros from the
__raw_read and __raw_write families. An example error is
In file included from arch/m68k/include/asm/vga.h:12,
from include/video/vga.h:22,
from include/linux/vgaarb.h:34,
from drivers/video/aperture.c:12:
>> arch/m68k/include/asm/raw_io.h:39: warning: "__raw_readb" redefined
39 | #define __raw_readb in_8
|
In file included from arch/m68k/include/asm/io.h:6,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from include/asm-generic/hardirq.h:17,
from ./arch/m68k/include/generated/asm/hardirq.h:1,
from include/linux/hardirq.h:11,
from include/linux/interrupt.h:11,
from include/linux/trace_recursion.h:5,
from include/linux/ftrace.h:10,
from include/linux/kprobes.h:28,
from include/linux/kgdb.h:19,
from include/linux/fb.h:6,
from drivers/video/aperture.c:5:
arch/m68k/include/asm/io_no.h:16: note: this is the location of the previous
definition
16 | #define __raw_readb(addr) \
|
Include , which avoids raw_io.h on nommu platforms.
Also change the defined values of some of the read/write symbols in
vga.h to __raw_read/__raw_write as the raw_in/raw_out symbols are not
generally available.
Signed-off-by: Thomas Zimmermann
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202501071629.dneswlm8-...@intel.com/
Fixes: 5c3f968712ce ("m68k/video: Create ")
Cc: Geert Uytterhoeven
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Helge Deller
Cc: sta...@vger.kernel.org # v3.5+
Reviewed-by: Geert Uytterhoeven
Link: https://lore.kernel.org/20250107095912.130530-1-tzimmerm...@suse.de
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman
---
arch/m68k/include/asm/vga.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/m68k/include/asm/vga.h
+++ b/arch/m68k/include/asm/vga.h
@@ -9,7 +9,7 @@
*/
#ifndef CONFIG_PCI
-#include
+#include
#include
/*
@@ -29,9 +29,9 @@
#define inw_p(port)0
#define outb_p(port, val) do { } while (0)
#define outw(port, val)do { } while (0)
-#define readb raw_inb
-#define writeb raw_outb
-#define writew raw_outw
+#define readb __raw_readb
+#define writeb __raw_writeb
+#define writew __raw_writew
#endif /* CONFIG_PCI */
#endif /* _ASM_M68K_VGA_H */
Re: [PATCH v3 00/18] Imagination BXS-4-64 MC1 GPU support
On Mon, 10 Mar 2025 13:10:24 +, Matt Coster wrote: > This GPU is found in the TI AM68 family of SoCs, with initial support > added to the k3-j721s2 devicetree and tested on a TI SK-AM68 board. > > A suitable firmware binary can currently be found in the IMG > linux-firmware repository[1] as powervr/rogue_36.53.104.796_v1.fw. > > No new UAPI will be necessary for this platform as it is sufficiently > similar to the already supported AXE-1-16M. > > UMD support is close to being complete. We're now able to pass >90% of > Vulkan conformance on our Mesa development branch. The compiler has been > undergoing a significant rework needed to accomodate the BXS-4-64, as > well as to make it more flexible to support additional Rogue GPUs going > forward. The first part of this rework landed in Mesa in [2], and more > MRs will follow in the coming weeks. > > There are several dt-bindings changes at the beginning of this series. > We expect the result to be versatile enough to handle all Imagination > Rogue GPUs while being a strong foundation to build bindings for the > newer Volcanic architecture (for which we're currently developing > support). > > The DTS changes at the end of the series are marked [DO NOT MERGE]. Once > the series is reviewed, we will request these be taken through the > relevant tree. > > [1]: https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr > [3]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32258 > > --- > Changes in v3: > - Reorder some patches to ensure the proper sequencing > - Update status of UMD support (cover) > - Don't use more specific compatible strings when not required (P1) > - Avoid ABI break by limiting new required properties to new compatible > strings (P2) > - Move power domain changes to the patch in which they're used (P2/P5) > - Update register definitions (P3) [Thanks, Alessio!] > - Don't use more specific compatible strings when not required (P4) > - Enhanced commit messages (P4) > - Remove unnecessary example (P5) > - Add proper fixes for threaded IRQs (P6) [Thanks, Alessio!] > - Include fix for a separate IRQ issue (P7) [Thanks, Alessio!] > - Don't enable firmware debug module (was P13 in v2, also in P14) > - Change from a workaround to a regular codepath (P15) > - Drop platform overrides framework (was P18 in v2, also in P16) > - Mark DTS changes [DO NOT MERGE] (P17/P18) > - Link to v2: > https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-0-3fd45d9fb...@imgtec.com > > Changes in v2: > - Clarified justification for compatible strings (P1) > - Simplified clocks constraints (P2) > - Simplified power-domains constraints (P3/P4) > - Use normal reg syntax for 64-bit values (P8/P21) > - Link to v1: > https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-0-4ed30e865...@imgtec.com > > --- > Alessio Belle (3): > drm/imagination: Update register defs for newer GPUs > drm/imagination: Mask GPU IRQs in threaded handler > drm/imagination: Handle Rogue safety event IRQs > > Matt Coster (14): > dt-bindings: gpu: img: Future-proofing enhancements > dt-bindings: gpu: img: Add BXS-4-64 devicetree bindings > drm/imagination: Use new generic compatible string > drm/imagination: Add power domain control > drm/imagination: Remove firmware enable_reg > drm/imagination: Rename event_mask -> status_mask > drm/imagination: Make has_fixed_data_addr a value > drm/imagination: Use a lookup table for fw defs > drm/imagination: Use callbacks for fw irq handling > drm/imagination: Move ELF fw utils to common file > drm/imagination: Use cached memory with dma_coherent > drm/imagination: Add support for TI AM68 GPU > [DO NOT MERGE] arm64: dts: ti: k3-am62: New GPU binding details > [DO NOT MERGE] arm64: dts: ti: k3-j721s2: Add GPU node > > Sarah Walker (1): > drm/imagination: Add RISC-V firmware processor support > > .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 77 +- > arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 3 +- > arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 12 ++ > drivers/gpu/drm/imagination/Makefile | 2 + > drivers/gpu/drm/imagination/pvr_device.c | 124 ++-- > drivers/gpu/drm/imagination/pvr_device.h | 31 +++- > drivers/gpu/drm/imagination/pvr_drv.c | 16 ++ > drivers/gpu/drm/imagination/pvr_fw.c | 28 +++- > drivers/gpu/drm/imagination/pvr_fw.h | 85 +-- > drivers/gpu/drm/imagination/pvr_fw_meta.c | 23 +-- > drivers/gpu/drm/imagination/pvr_fw_mips.c | 82 ++- > drivers/gpu/drm/imagination/pvr_fw_riscv.c | 163 > + > drivers/gpu/drm/imagination/pvr_fw_startstop.c | 17 +++ > drivers/gpu/drm/imagination/pvr_fw_util.c | 67 + > drivers/gpu/drm/imagination/pvr_gem.c | 10 +- > driver
Re: [PATCH v3 02/18] dt-bindings: gpu: img: Add BXS-4-64 devicetree bindings
On Mon, Mar 10, 2025 at 01:10:26PM +, Matt Coster wrote: > Unlike AXE-1-16M, BXS-4-64 uses two power domains. > > Like the existing AXE-1-16M integration, BXS-4-64 uses the single clock > integration in the TI k3-j721s2. > > Signed-off-by: Matt Coster > --- > Changes in v3: > - Include adding the second power domain so it's in context > - Remove unnecessary example > - Link to v2: > https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-8-3fd45d9fb...@imgtec.com > Changes in v2: > - Use normal reg syntax for 64-bit values > - Link to v1: > https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-8-4ed30e865...@imgtec.com > --- > .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 34 > +- > 1 file changed, 33 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > index > 5c16b2881447c9cda78e5bb46569e2f675d740c4..d9409d33154d429019776ddbf9d123b33f8c9740 > 100644 > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > @@ -18,6 +18,11 @@ properties: >- ti,am62-gpu >- const: img,img-axe-1-16m >- const: img,img-rogue > + - items: > + - enum: > + - ti,j721s2-gpu > + - const: img,img-bxs-4-64 > + - const: img,img-rogue > ># This legacy combination of compatible strings was introduced early on ># before the more specific GPU identifiers were used. > @@ -49,6 +54,7 @@ properties: >power-domain-names: > items: >- const: a > + - const: b No, you just affected old device claiming it has two items. What's more, it's not synced with power-domains. Both properties must have the same constraints, but above power domains have "anything". > >dma-coherent: true > > @@ -74,12 +80,38 @@ allOf: > - power-domains > - power-domain-names > > + # Cores with one power domain Drop > + - if: > + properties: > +compatible: > + contains: > +const: img,img-axe-1-16m > +then: > + properties: > +power-domain-names: > + minItems: 1 Drop > + maxItems: 1 > + > + # Cores with two power domains Drop > + - if: > + properties: > +compatible: > + contains: > +const: img,img-bxs-4-64 > +then: > + properties: > +power-domain-names: > + minItems: 2 > + maxItems: 2 Missing constraints for power-domains. Best regards, Krzysztof
Re: [PATCH v1 5/6] drm/panfrost: Enable AARCH64_4K page table format on mediatek_mt8188
On Mon, 10 Mar 2025 16:59:20 -0300
Ariel D'Alessandro wrote:
> Now that Panfrost supports AARCH64_4K page table format, let's enable it
> on Mediatek MT8188.
Can you maybe give more details on why this is needed
(legacy shareability/cacheability not suitable for this GPU?)?
>
> Signed-off-by: Ariel D'Alessandro
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 0f3935556ac76..d7b8bded6d784 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -824,6 +824,7 @@ static const struct panfrost_compatible
> mediatek_mt8188_data = {
> .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
> .pm_domain_names = mediatek_mt8183_pm_domains,
> .pm_features = BIT(GPU_PM_CLK_DIS) | BIT(GPU_PM_VREG_OFF),
> + .gpu_configs = BIT(GPU_CONFIG_AARCH64_4K),
> };
>
> static const char * const mediatek_mt8192_supplies[] = { "mali", NULL };
Re: [PATCH 3/4] drm/vc4: use new helper to get ACR values
On Mon, Mar 10, 2025 at 10:18:04PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 10, 2025 at 03:51:53PM +0100, Maxime Ripard wrote:
> > On Sun, Mar 09, 2025 at 10:13:58AM +0200, Dmitry Baryshkov wrote:
> > > From: Dmitry Baryshkov
> > >
> > > Use drm_hdmi_acr_get_n_cts() helper instead of calculating N and CTS
> > > values in the VC4 driver.
> > >
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
> > > drivers/gpu/drm/vc4/vc4_hdmi.h | 7 +++
> > > 2 files changed, 10 insertions(+), 7 deletions(-)
> > >
>
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h
> > > b/drivers/gpu/drm/vc4/vc4_hdmi.h
> > > index
> > > e3d989ca302b72533c374dfa3fd0d5bd7fe64a82..0a775dbfe99d45521f3d0a2016555aefa81d7934
> > > 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> > > @@ -211,6 +211,13 @@ struct vc4_hdmi {
> > >* KMS hooks. Protected by @mutex.
> > >*/
> > > enum hdmi_colorspace output_format;
> > > +
> > > + /**
> > > + * @tmds_char_rate: Copy of
> > > + * @drm_connector_state.hdmi.tmds_char_rate for use outside of
> > > + * KMS hooks. Protected by @mutex.
> > > + */
> > > + unsigned long long tmds_char_rate;
> > > };
> >
> > This should be in drm_connector_hdmi if it's useful
>
> That would mean bringing the state to a non-state structure on the
> framework level. Is it fine from your POV?
Sorry, I'm changing my mind a little bit, but it's pretty much the same
case than for accessing the infoframes from debugfs: we want to get some
information stored in the state from outside of KMS.
What we did for the infoframes is that we're actually just taking the
connection_mutex from the DRM device and access the drm_connector->state
pointer.
I guess it would also work for ALSA?
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v2 4/6] dt-bindings: gpu: v3d: Add SMS to the registers' list
On 10/03/2025 21:07, Maíra Canal wrote: > > From my understanding, I'm keeping the ABI preserved, as brcm,7268-v3d > needs to have a GCA register (otherwise, you won't be able to flush the > cache) and brcm,2711-v3d doesn't even have this piece of hardware. > > I understand that now I'm imposing per-compatible restrictions that > didn't exist in the spec, but the new restrictions are compatible to the > hardware specification. I'd like to understand if I can: > > 1. Use two register items (gca and sms) to preserve the semantics of the > register names. Sure, that's fine. > > 2. Can I add per-compatible restrictions to the DT even if the original > bindings didn't do it? If not, can I just add a new register to the > register list? Like: Yes, constraints are expected and it does not matter that original binding forgot them. > > reg-names: > items: > - const: hub > - const: core0 > - - enum: [ bridge, gca ] > - - enum: [ bridge, gca ] > + - enum: [ bridge, gca, sms ] > + - enum: [ bridge, gca, sms ] > + - enum: [ bridge, gca, sms ] This does not look right, because there is no device from your description which has 5 items. Best regards, Krzysztof
Re: [PATCH v1 4/6] drm/panfrost: Add support for AARCH64_4K page table format
On Mon, 10 Mar 2025 16:59:19 -0300
Ariel D'Alessandro wrote:
> Currently, Panfrost only supports MMU configuration in "LEGACY" (as
> Bifrost calls it) mode, a (modified) version of LPAE "Large Physical
> Address Extension", which in Linux we've called "mali_lpae".
>
> This commit adds support for conditionally enabling AARCH64_4K page
> table format. To achieve that, a "GPU optional configurations" field was
> added to `struct panfrost_features` with the related flag.
>
> Note that, in order to enable AARCH64_4K mode, the GPU variant must have
> the HW_FEATURE_AARCH64_MMU feature flag present.
>
> Signed-off-by: Ariel D'Alessandro
> ---
> drivers/gpu/drm/panfrost/panfrost_device.h | 16 +++
> drivers/gpu/drm/panfrost/panfrost_mmu.c| 132 +++--
> drivers/gpu/drm/panfrost/panfrost_regs.h | 34 ++
> 3 files changed, 169 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index cffcb0ac7c111..0385702aa43c7 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -42,6 +42,14 @@ enum panfrost_gpu_pm {
> GPU_PM_VREG_OFF,
> };
>
> +/**
> + * enum panfrost_gpu_config - GPU optional configurations
> + * @GPU_CONFIG_AARCH64_4K: Use AARCH64_4K page table format
> + */
> +enum panfrost_gpu_config {
> + GPU_CONFIG_AARCH64_4K,
> +};
> +
> struct panfrost_features {
> u16 id;
> u16 revision;
> @@ -95,6 +103,9 @@ struct panfrost_compatible {
>
> /* Allowed PM features */
> u8 pm_features;
> +
> + /* GPU features */
> + u8 gpu_configs;
I would probably name this gpu_quirks, with the GPU_CONFIG_AARCH64_4K
flag renamed GPU_QUIRK_FORCE_AARCH64_PAGE_TABLE.
> };
>
> struct panfrost_device {
> @@ -162,6 +173,11 @@ struct panfrost_mmu {
> int as;
> atomic_t as_count;
> struct list_head list;
> + struct {
> + u64 transtab;
> + u64 memattr;
> + u64 transcfg;
> + } cfg;
> };
>
> struct panfrost_engine_usage {
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index 31df3a96f89bd..4a9b8de2ff987 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -26,6 +26,48 @@
> #define mmu_write(dev, reg, data) writel(data, dev->iomem + reg)
> #define mmu_read(dev, reg) readl(dev->iomem + reg)
>
> +static u64 mair_to_memattr(u64 mair, bool coherent)
> +{
> + u64 memattr = 0;
> + u32 i;
> +
> + for (i = 0; i < 8; i++) {
> + u8 in_attr = mair >> (8 * i), out_attr;
> + u8 outer = in_attr >> 4, inner = in_attr & 0xf;
> +
> + /* For caching to be enabled, inner and outer caching policy
> + * have to be both write-back, if one of them is write-through
> + * or non-cacheable, we just choose non-cacheable. Device
> + * memory is also translated to non-cacheable.
> + */
> + if (!(outer & 3) || !(outer & 4) || !(inner & 4)) {
> + out_attr = AS_MEMATTR_AARCH64_INNER_OUTER_NC |
> +AS_MEMATTR_AARCH64_SH_MIDGARD_INNER |
> +AS_MEMATTR_AARCH64_INNER_ALLOC_EXPL(false,
> false);
> + } else {
> + out_attr = AS_MEMATTR_AARCH64_INNER_OUTER_WB |
> +AS_MEMATTR_AARCH64_INNER_ALLOC_EXPL(inner &
> 1, inner & 2);
> + /* Use SH_MIDGARD_INNER mode when device isn't coherent,
> + * so SH_IS, which is used when IOMMU_CACHE is set, maps
> + * to Mali's internal-shareable mode. As per the Mali
> + * Spec, inner and outer-shareable modes aren't allowed
> + * for WB memory when coherency is disabled.
> + * Use SH_CPU_INNER mode when coherency is enabled, so
> + * that SH_IS actually maps to the standard definition
> of
> + * inner-shareable.
> + */
> + if (!coherent)
> + out_attr |= AS_MEMATTR_AARCH64_SH_MIDGARD_INNER;
> + else
> + out_attr |= AS_MEMATTR_AARCH64_SH_CPU_INNER;
> + }
> +
> + memattr |= (u64)out_attr << (8 * i);
> + }
> +
> + return memattr;
> +}
> +
> static int wait_ready(struct panfrost_device *pfdev, u32 as_nr)
> {
> int ret;
> @@ -121,9 +163,57 @@ static int mmu_hw_do_operation(struct panfrost_device
> *pfdev,
> return ret;
> }
>
> +static void mmu_cfg_init_mali_lpae(struct panfrost_mmu *mmu)
> +{
> + struct io_pgtable_cfg *pgtbl_cfg = &mmu->pgtbl_cfg;
> +
> + /* TODO: The following fields are duplicated between the MMU and Page
> + * Table config structs. Idea
linux-next: manual merge of the rust tree with the drm tree
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
drivers/gpu/drm/drm_panic_qr.rs
between commit:
dbed4a797e00 ("drm/panic: Better binary encoding in QR code")
from the drm tree and commit:
fc2f191f850d ("panic_qr: use new #[export] macro")
from the rust tree.
I fixed it up (I guess - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/drm_panic_qr.rs
index 5d21f6d10bcb,ecd87e8ffe05..
--- a/drivers/gpu/drm/drm_panic_qr.rs
+++ b/drivers/gpu/drm/drm_panic_qr.rs
@@@ -27,7 -26,8 +27,7 @@@
//! *
//! *
- use kernel::str::CStr;
-use core::cmp;
+ use kernel::{prelude::*, str::CStr};
#[derive(Debug, Clone, Copy, PartialEq, Eq, Ord, PartialOrd)]
struct Version(usize);
pgpmOnpnTgzFS.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the rust tree with the drm tree
On Tue, Mar 11, 2025 at 10:17 AM Stephen Rothwell wrote: > > I fixed it up (I guess - see below) and can carry the fix as necessary. Looks good to me, thanks! Cheers, Miguel
Re: [PATCH v3 02/18] dt-bindings: gpu: img: Add BXS-4-64 devicetree bindings
On 11/03/2025 07:51, Krzysztof Kozlowski wrote: > On Mon, Mar 10, 2025 at 01:10:26PM +, Matt Coster wrote: >> Unlike AXE-1-16M, BXS-4-64 uses two power domains. >> >> Like the existing AXE-1-16M integration, BXS-4-64 uses the single clock >> integration in the TI k3-j721s2. >> >> Signed-off-by: Matt Coster >> --- >> Changes in v3: >> - Include adding the second power domain so it's in context >> - Remove unnecessary example >> - Link to v2: >> https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-8-3fd45d9fb...@imgtec.com >> Changes in v2: >> - Use normal reg syntax for 64-bit values >> - Link to v1: >> https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-8-4ed30e865...@imgtec.com >> --- >> .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 34 >> +- >> 1 file changed, 33 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml >> b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml >> index >> 5c16b2881447c9cda78e5bb46569e2f675d740c4..d9409d33154d429019776ddbf9d123b33f8c9740 >> 100644 >> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml >> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml >> @@ -18,6 +18,11 @@ properties: >>- ti,am62-gpu >>- const: img,img-axe-1-16m >>- const: img,img-rogue >> + - items: >> + - enum: >> + - ti,j721s2-gpu >> + - const: img,img-bxs-4-64 >> + - const: img,img-rogue >> >># This legacy combination of compatible strings was introduced early >> on >># before the more specific GPU identifiers were used. >> @@ -49,6 +54,7 @@ properties: >>power-domain-names: >> items: >>- const: a >> + - const: b > > No, you just affected old device claiming it has two items. What's more, > it's not synced with power-domains. Both properties must have the same > constraints, but above power domains have "anything". My mistake. This is tied to to my misunderstanding below. > >> >>dma-coherent: true >> >> @@ -74,12 +80,38 @@ allOf: >> - power-domains >> - power-domain-names >> >> + # Cores with one power domain > > Drop Ack > >> + - if: >> + properties: >> +compatible: >> + contains: >> +const: img,img-axe-1-16m >> +then: >> + properties: >> +power-domain-names: >> + minItems: 1 > > Drop Ack > >> + maxItems: 1 >> + >> + # Cores with two power domains > > Drop Ack > >> + - if: >> + properties: >> +compatible: >> + contains: >> +const: img,img-bxs-4-64 >> +then: >> + properties: >> +power-domain-names: >> + minItems: 2 >> + maxItems: 2 > > Missing constraints for power-domains. My mistake, I misunderstood your comment on the V2 series as meaning replace power-domains, not add to. Thank you for taking the time to look through these patches again! Cheers, Matt > > Best regards, > Krzysztof > -- Matt Coster E: matt.cos...@imgtec.com OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 2/2] drm/msm/dp: reuse generic HDMI codec implementation
Hi,
On Mon, Mar 10, 2025 at 08:53:24PM +0200, Dmitry Baryshkov wrote:
> On Mon, 10 Mar 2025 at 17:08, Maxime Ripard wrote:
> >
> > On Fri, Mar 07, 2025 at 07:55:53AM +0200, Dmitry Baryshkov wrote:
> > > From: Dmitry Baryshkov
> > >
> > > The MSM DisplayPort driver implements several HDMI codec functions
> > > in the driver, e.g. it manually manages HDMI codec device registration,
> > > returning ELD and plugged_cb support. In order to reduce code
> > > duplication reuse drm_hdmi_audio_* helpers and drm_bridge_connector
> > > integration.
> > >
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/msm/Kconfig | 1 +
> > > drivers/gpu/drm/msm/dp/dp_audio.c | 131
> > >
> > > drivers/gpu/drm/msm/dp/dp_audio.h | 27 ++--
> > > drivers/gpu/drm/msm/dp/dp_display.c | 28 ++--
> > > drivers/gpu/drm/msm/dp/dp_display.h | 6 --
> > > drivers/gpu/drm/msm/dp/dp_drm.c | 8 +++
> > > 6 files changed, 31 insertions(+), 170 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> > > index
> > > 974bc7c0ea761147d3326bdce9039d6f26f290d0..7f127e2ae44292f8f5c7ff6a9251c3d7ec8c9f58
> > > 100644
> > > --- a/drivers/gpu/drm/msm/Kconfig
> > > +++ b/drivers/gpu/drm/msm/Kconfig
> > > @@ -104,6 +104,7 @@ config DRM_MSM_DPU
> > > config DRM_MSM_DP
> > > bool "Enable DisplayPort support in MSM DRM driver"
> > > depends on DRM_MSM
> > > + select DRM_DISPLAY_HDMI_AUDIO_HELPER
> > > select RATIONAL
> > > default y
> > > help
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
> > > b/drivers/gpu/drm/msm/dp/dp_audio.c
> > > index
> > > 70fdc9fe228a7149546accd8479a9e4397f3d5dd..f8bfb908f9b4bf93ad5480f0785e3aed23dde160
> > > 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_audio.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_audio.c
> > > @@ -13,13 +13,13 @@
> > >
> > > #include "dp_catalog.h"
> > > #include "dp_audio.h"
> > > +#include "dp_drm.h"
> > > #include "dp_panel.h"
> > > #include "dp_reg.h"
> > > #include "dp_display.h"
> > > #include "dp_utils.h"
> > >
> > > struct msm_dp_audio_private {
> > > - struct platform_device *audio_pdev;
> > > struct platform_device *pdev;
> > > struct drm_device *drm_dev;
> > > struct msm_dp_catalog *catalog;
> > > @@ -160,24 +160,11 @@ static void msm_dp_audio_enable(struct
> > > msm_dp_audio_private *audio, bool enable)
> > > msm_dp_catalog_audio_enable(catalog, enable);
> > > }
> > >
> > > -static struct msm_dp_audio_private *msm_dp_audio_get_data(struct
> > > platform_device *pdev)
> > > +static struct msm_dp_audio_private *msm_dp_audio_get_data(struct msm_dp
> > > *msm_dp_display)
> > > {
> > > struct msm_dp_audio *msm_dp_audio;
> > > - struct msm_dp *msm_dp_display;
> > > -
> > > - if (!pdev) {
> > > - DRM_ERROR("invalid input\n");
> > > - return ERR_PTR(-ENODEV);
> > > - }
> > > -
> > > - msm_dp_display = platform_get_drvdata(pdev);
> > > - if (!msm_dp_display) {
> > > - DRM_ERROR("invalid input\n");
> > > - return ERR_PTR(-ENODEV);
> > > - }
> > >
> > > msm_dp_audio = msm_dp_display->msm_dp_audio;
> > > -
> > > if (!msm_dp_audio) {
> > > DRM_ERROR("invalid msm_dp_audio data\n");
> > > return ERR_PTR(-EINVAL);
> > > @@ -186,68 +173,16 @@ static struct msm_dp_audio_private
> > > *msm_dp_audio_get_data(struct platform_device
> > > return container_of(msm_dp_audio, struct msm_dp_audio_private,
> > > msm_dp_audio);
> > > }
> > >
> > > -static int msm_dp_audio_hook_plugged_cb(struct device *dev, void *data,
> > > - hdmi_codec_plugged_cb fn,
> > > - struct device *codec_dev)
> > > -{
> > > -
> > > - struct platform_device *pdev;
> > > - struct msm_dp *msm_dp_display;
> > > -
> > > - pdev = to_platform_device(dev);
> > > - if (!pdev) {
> > > - pr_err("invalid input\n");
> > > - return -ENODEV;
> > > - }
> > > -
> > > - msm_dp_display = platform_get_drvdata(pdev);
> > > - if (!msm_dp_display) {
> > > - pr_err("invalid input\n");
> > > - return -ENODEV;
> > > - }
> > > -
> > > - return msm_dp_display_set_plugged_cb(msm_dp_display, fn, codec_dev);
> > > -}
> > > -
> > > -static int msm_dp_audio_get_eld(struct device *dev,
> > > - void *data, uint8_t *buf, size_t len)
> > > -{
> > > - struct platform_device *pdev;
> > > - struct msm_dp *msm_dp_display;
> > > -
> > > - pdev = to_platform_device(dev);
> > > -
> > > - if (!pdev) {
> > > - DRM_ERROR("invalid input\n");
> > > - return -ENODEV;
> > > - }
> > > -
> > > - msm_dp_display = platform_get_drvdata(pdev);
> > > - if (!msm_dp_display) {
> > > - DRM_ERROR("invalid input\n");
> > > - return -ENODEV;
> > > - }
> > > -
> > > - mutex_lock(&msm_
Re: [PATCH 1/4] drm/display: hdmi: provide central data authority for ACR params
On Mon, Mar 10, 2025 at 10:14:52PM +0200, Dmitry Baryshkov wrote:
> On Mon, Mar 10, 2025 at 03:46:33PM +0100, Maxime Ripard wrote:
> > On Sun, Mar 09, 2025 at 10:13:56AM +0200, Dmitry Baryshkov wrote:
> > > From: Dmitry Baryshkov
> > >
> > > HDMI standard defines recommended N and CTS values for Audio Clock
> > > Regeneration. Currently each driver implements those, frequently in
> > > somewhat unique way. Provide a generic helper for getting those values
> > > to be used by the HDMI drivers.
> > >
> > > The helper is added to drm_hdmi_helper.c rather than drm_hdmi_audio.c
> > > since HDMI drivers can be using this helper function even without
> > > switching to DRM HDMI Audio helpers.
> > >
> > > Note: currently this only handles the values per HDMI 1.4b Section 7.2
> > > and HDMI 2.0 Section 9.2.1. Later the table can be expanded to
> > > accommodate for Deep Color TMDS char rates per HDMI 1.4 Appendix D
> > > and/or HDMI 2.0 / 2.1 Appendix C).
> > >
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/display/drm_hdmi_helper.c | 164
> > > ++
> > > include/drm/display/drm_hdmi_helper.h | 6 ++
> > > 2 files changed, 170 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > index
> > > 74dd4d01dd9bb2c9e69ec1c60b0056bd69417e8a..89d25571bfd21c56c6835821d2272a12c816a76e
> > > 100644
> > > --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> > > @@ -256,3 +256,167 @@ drm_hdmi_compute_mode_clock(const struct
> > > drm_display_mode *mode,
> > > return DIV_ROUND_CLOSEST_ULL(clock * bpc, 8);
> > > }
> > > EXPORT_SYMBOL(drm_hdmi_compute_mode_clock);
> > > +
> > > +struct drm_hdmi_acr_n_cts_entry {
> > > + unsigned int n;
> > > + unsigned int cts;
> > > +};
> > > +
> > > +struct drm_hdmi_acr_data {
> > > + unsigned long tmds_clock_khz;
> > > + struct drm_hdmi_acr_n_cts_entry n_cts_32k,
> > > + n_cts_44k1,
> > > + n_cts_48k;
> > > +};
> > > +
> > > +static const struct drm_hdmi_acr_data hdmi_acr_n_cts[] = {
> > > + {
> > > + /* "Other" entry */
> > > + .n_cts_32k = { .n = 4096, },
> > > + .n_cts_44k1 = { .n = 6272, },
> > > + .n_cts_48k = { .n = 6144, },
> > > + }, {
> > > + .tmds_clock_khz = 25175,
> > > + .n_cts_32k = { .n = 4576, .cts = 28125, },
> > > + .n_cts_44k1 = { .n = 7007, .cts = 31250, },
> > > + .n_cts_48k = { .n = 6864, .cts = 28125, },
> > > + }, {
> > > + .tmds_clock_khz = 25200,
> > > + .n_cts_32k = { .n = 4096, .cts = 25200, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 28000, },
> > > + .n_cts_48k = { .n = 6144, .cts = 25200, },
> > > + }, {
> > > + .tmds_clock_khz = 27000,
> > > + .n_cts_32k = { .n = 4096, .cts = 27000, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 3, },
> > > + .n_cts_48k = { .n = 6144, .cts = 27000, },
> > > + }, {
> > > + .tmds_clock_khz = 27027,
> > > + .n_cts_32k = { .n = 4096, .cts = 27027, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 30030, },
> > > + .n_cts_48k = { .n = 6144, .cts = 27027, },
> > > + }, {
> > > + .tmds_clock_khz = 54000,
> > > + .n_cts_32k = { .n = 4096, .cts = 54000, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 6, },
> > > + .n_cts_48k = { .n = 6144, .cts = 54000, },
> > > + }, {
> > > + .tmds_clock_khz = 54054,
> > > + .n_cts_32k = { .n = 4096, .cts = 54054, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 60060, },
> > > + .n_cts_48k = { .n = 6144, .cts = 54054, },
> > > + }, {
> > > + .tmds_clock_khz = 74176,
> > > + .n_cts_32k = { .n = 11648, .cts = 210937, }, /* and 210938 */
> > > + .n_cts_44k1 = { .n = 17836, .cts = 234375, },
> > > + .n_cts_48k = { .n = 11648, .cts = 140625, },
> > > + }, {
> > > + .tmds_clock_khz = 74250,
> > > + .n_cts_32k = { .n = 4096, .cts = 74250, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 82500, },
> > > + .n_cts_48k = { .n = 6144, .cts = 74250, },
> > > + }, {
> > > + .tmds_clock_khz = 148352,
> > > + .n_cts_32k = { .n = 11648, .cts = 421875, },
> > > + .n_cts_44k1 = { .n = 8918, .cts = 234375, },
> > > + .n_cts_48k = { .n = 5824, .cts = 140625, },
> > > + }, {
> > > + .tmds_clock_khz = 148500,
> > > + .n_cts_32k = { .n = 4096, .cts = 148500, },
> > > + .n_cts_44k1 = { .n = 6272, .cts = 165000, },
> > > + .n_cts_48k = { .n = 6144, .cts = 148500, },
> > > + }, {
> > > + .tmds_clock_khz = 296703,
> > > + .n_cts_32k = { .n = 5824, .cts = 421875, },
> > > + .n_cts_44k1 = { .n = 4459, .cts = 234375, },
> > > + .n_cts_48k = { .n = 582
Re: [PATCH 07/10] drm/i915/display: Configure the second scaler for sharpness
On 3/4/2025 3:58 PM, Nemesa Garg wrote:
As only second scaler can be used for sharpness check if it
is available and also check if panel fitting is also not enabled,
then set the sharpness. Panel fitting will have the preference
over sharpness property.
v2: Add the panel fitting check before enabling sharpness
v3: Reframe commit message[Arun]
v4: Replace string based comparison with plane_state[Jani]
v5: Rebase
v6: Fix build issue
v7: Remove scaler id from verify_crtc_state[Ankit]
v8: Change the patch title. Add code comment.
Move the config part in patch#6. [Ankit]
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_casf.c| 8 ++
drivers/gpu/drm/i915/display/intel_casf.h| 1 +
drivers/gpu/drm/i915/display/intel_display.c | 6 +++--
drivers/gpu/drm/i915/display/skl_scaler.c| 28 +++-
4 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_casf.c
b/drivers/gpu/drm/i915/display/intel_casf.c
index 15ae555e571e..1d9196c4d22f 100644
--- a/drivers/gpu/drm/i915/display/intel_casf.c
+++ b/drivers/gpu/drm/i915/display/intel_casf.c
@@ -115,6 +115,14 @@ int intel_casf_compute_config(struct intel_crtc_state
*crtc_state)
return 0;
}
+bool intel_casf_needs_scaler(const struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->hw.casf_params.casf_enable)
+ return true;
+
+ return false;
+}
+
static int casf_coeff_tap(int i)
{
return i % SCALER_FILTER_NUM_TAPS;
diff --git a/drivers/gpu/drm/i915/display/intel_casf.h
b/drivers/gpu/drm/i915/display/intel_casf.h
index 507a3fe49753..c75a4b2f3133 100644
--- a/drivers/gpu/drm/i915/display/intel_casf.h
+++ b/drivers/gpu/drm/i915/display/intel_casf.h
@@ -17,5 +17,6 @@ void intel_filter_lut_load(struct intel_crtc *crtc,
const struct intel_crtc_state *crtc_state);
void intel_casf_enable(struct intel_crtc_state *crtc_state);
void intel_casf_scaler_compute_config(struct intel_crtc_state *crtc_state);
+bool intel_casf_needs_scaler(const struct intel_crtc_state *crtc_state);
#endif /* __INTEL_CASF_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c4b0ec60fded..03acf01cac75 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -60,6 +60,7 @@
#include "intel_audio.h"
#include "intel_bo.h"
#include "intel_bw.h"
+#include "intel_casf.h"
#include "intel_cdclk.h"
#include "intel_clock_gating.h"
#include "intel_color.h"
@@ -1956,7 +1957,7 @@ static void get_crtc_power_domains(struct
intel_crtc_state *crtc_state,
set_bit(POWER_DOMAIN_PIPE(pipe), mask->bits);
set_bit(POWER_DOMAIN_TRANSCODER(cpu_transcoder), mask->bits);
if (crtc_state->pch_pfit.enabled ||
- crtc_state->pch_pfit.force_thru)
+ crtc_state->pch_pfit.force_thru ||
intel_casf_needs_scaler(crtc_state))
set_bit(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe), mask->bits);
This should be a separate patch.
This patch should be about how casf uses 2nd scaler as pipe scaler and
the changes and checks required for intel_allocate_scaler.
drm_for_each_encoder_mask(encoder, &dev_priv->drm,
@@ -2194,7 +2195,7 @@ static u32 ilk_pipe_pixel_rate(const struct
intel_crtc_state *crtc_state)
* PF-ID we'll need to adjust the pixel_rate here.
*/
- if (!crtc_state->pch_pfit.enabled)
+ if (!crtc_state->pch_pfit.enabled ||
intel_casf_needs_scaler(crtc_state))
Is this really needed? I am not very sure about this.
return pixel_rate;
drm_rect_init(&src, 0, 0,
@@ -5299,6 +5300,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_I(scaler_state.scaler_id);
PIPE_CONF_CHECK_I(pixel_rate);
+ PIPE_CONF_CHECK_BOOL(hw.casf_params.casf_enable);
Again not part of this patch.
PIPE_CONF_CHECK_X(gamma_mode);
if (IS_CHERRYVIEW(dev_priv))
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index 39fc537e54f0..93a847c05535 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -5,6 +5,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
+#include "intel_casf.h"
#include "intel_casf_regs.h"
#include "intel_de.h"
#include "intel_display_trace.h"
@@ -272,7 +273,8 @@ int skl_update_scaler_crtc(struct intel_crtc_state
*crtc_state)
drm_rect_width(&crtc_state->pipe_src),
drm_rect_height(&crtc_state->pipe_src),
width, height, NULL, 0,
-crtc_state->pch_pfit.enabled);
+crtc_state->pch_pfit.enabled ||
+intel_casf_needs_scaler(
Re: [PATCH 3/5] dt-bindings: display: simple-bridge: Document DPI color encoder
On Tue, Mar 11, 2025 at 10:38:37AM +0800, Liu Ying wrote: > On 03/10/2025, Maxime Ripard wrote: > > On Fri, Mar 07, 2025 at 11:10:00AM +0800, Liu Ying wrote: > >> On 03/06/2025, Maxime Ripard wrote: > >>> On Thu, Mar 06, 2025 at 03:02:41PM +0800, Liu Ying wrote: > On 03/06/2025, Rob Herring wrote: > > On Wed, Mar 05, 2025 at 10:35:26AM +0100, Alexander Stein wrote: > >> Hi, > >> > >> Am Dienstag, 4. März 2025, 16:23:20 CET schrieb Rob Herring: > >>> On Tue, Mar 04, 2025 at 06:15:28PM +0800, Liu Ying wrote: > A DPI color encoder, as a simple display bridge, converts input DPI > color > coding to output DPI color coding, like Adafruit Kippah DPI hat[1] > which > converts input 18-bit pixel data to 24-bit pixel data(with 2 low > padding > bits in every color component though). Document the DPI color > encoder. > >>> > >>> Why do we need a node for this? Isn't this just wired how it is wired > >>> and there's nothing for s/w to see or do? I suppose if you are trying > >>> to > >>> resolve the mode with 24-bit on one end and 18-bit on the other end, > >>> you > >>> need to allow that and not require an exact match. You still might > >>> need > >>> to figure out which pins the 18-bit data comes out on, but you have > >>> that > >>> problem with an 18-bit panel too. IOW, how is this any different if > >>> you > >>> have an 18-bit panel versus 24-bit panel? > >> > >> Especially panel-simple.c has a fixed configuration for each display, > >> such as: > >>> .bus_format = MEDIA_BUS_FMT_RGB666_1X18 > >> > >> How would you allow or even know it should be addressed as > >> MEDIA_BUS_FMT_RGB888_1X24 instead? I see different ways: > >> 1. Create a new display setting/compatible > >> 2. Add an overwrite property to the displays > >> 3. Use a (transparent) bridge (this series) > >> > >> Number 1 is IMHO out of question. > > > > Agreed. > > > >> I personally don't like number 2 as this > >> feels like adding quirks to displays, which they don't have. > > > > This is what I would do except apply it to the controller side. We know > > the panel side already. This is a board variation, so a property makes > > sense. I don't think you need any more than knowing what's on each end. > > With option 2, no matter putting a property in source side or sink side, > impacted display drivers and DT bindings need to be changed, once a board > manipulates the DPI color coding. This adds burdens and introduces new > versions of those DT bindings. Is this what we want? > >>> > >>> There's an option 4: make it a property of the OF graph endpoints. In > >>> essence, it's similar to properties that are already there like > >>> lane-mapping, and it wouldn't affect the panel drivers, or create an > >>> intermediate bridge. > >> > >> I don't see lane-mapping anywhere. Do you mean data-mapping instead? > >> data-mapping is not defined in dtschema. Only lvds-codec.yaml defines > >> data-mapping in endpoint. > > > > I meant as a general concept. The properties are data-lanes and > > clock-lanes in > > Documentation/devicetree/bindings/media/video-interfaces.yaml > > This requires referenceing video-interfaces.yaml in existing DT binding docs > and driver modifictions, which adds burdens. If burden is an issue, any new driver also adds burden, thus we shouldn't merge anything anymore and we can stop there? It's not black and white, it should be managed, and here it's manageable and / or mitigated. > >> With option 4, I guess you meant display sink drivers, i.e., panel and > >> bridge drivers, wouldn't be affected. Then, display source drivers, i.e., > >> display controller and bridge drivers, would be affected. This adds > >> burdens for driver developers/maintainers(though almost no effort from > >> DT's PoV), doesn't it? > > > > Not necessarily, panels have a phandle to the parent endpoint too so > > they can do that walk and configure their format if it's any easier. > > I'm sorry, I don't get your meaning here. I have no idea how to support > this new property in endpoint-base(graph.yaml) or video-interfaces.yaml > _without_ changing existing display source drivers. Make a helper, and drivers can always call that helper. It will be a single function call, and panel-simple will cover most of the existing user-base already. Otherwise, we have the option to use coccinelle if you want to mass convert it. > >> Moreover, why it has to be the display sink drivers which are not affected? > >> DT writers might choose to set the format at the sink endpoint, e.g., > >> setting > >> RGB666 at the sink endpoint of a RGB888 DPI panel or bridge. > > > > Why wouldn't you run the panel at the highest bpc possible? > > Because hardware designers route less data signals than re
Re: [PATCH v3 01/18] dt-bindings: gpu: img: Future-proofing enhancements
On Mon, Mar 10, 2025 at 01:10:25PM +, Matt Coster wrote: > The first compatible strings added for the AXE-1-16M are not sufficient to > accurately describe all the IMG Rogue GPUs. The current "img,img-axe" > string refers to the entire family of Series AXE GPUs, but this is > primarily a marketing term and does not denote a level of hardware > similarity any greater than just "Rogue". > > The more specific "img,img-axe-1-16m" string refers to individual AXE-1-16M > GPU. For example, unlike the rest of the Series AXE GPUs, the AXE-1-16M > only uses a single power domain. > > The situation is actually slightly worse than described in the first > paragraph, since many "series" (such as Series BXS found in the TI AM68 > among others and added later in this series) contain cores with both Rogue > and Volcanic architectures. > > Besides attempting to move away from vague groupings defined only > by marketing terms, we want to draw a line between properties inherent to > the IP core and choices made by the silicon vendor at integration time. > For instance, the number of power domains is a property of the IP core, > whereas the decision to use one or multiple clocks is a vendor one. > > In the original compatible strings, we must use "ti,am62-gpu" to constrain > both of these properties since the number of power domains cannot be fixed > for "img,img-axe". > > Work is currently underway to add support for volcanic-based Imagination > GPUs, for which bindings will be added in "img,powervr-volcanic.yaml". > As alluded to previously, the split between rogue and volcanic cores is > non-obvious at times, so add a generic top-level "img,img-rogue" compatible > string here to allow for simpler differentiation in devicetrees without > referring back to the bindings. > > The currently supported GPU (AXE-1-16M) only requires a single power > domain. Subsequent patches will add support for BXS-4-64 MC1, which has > two power domains. Add infrastructure now to allow for this. > > Also allow the dma-coherent property to be added to IMG Rogue GPUs, which > are DMA devices. The decision for coherency is made at integration time and > this property should be applied wherever it accurately describes the > vendor integration. > > Note that the new required properties for power domains are conditional on > the new base compatible string to avoid an ABI break. > > Signed-off-by: Matt Coster > --- > Changes in v3: > - Remove unnecessary example > - Remove second power domain details, add these where they're used instead > - Avoid ABI breaks by limiting new required properties to new compatible > strings and making all binding changes in a single patch. > - Links to v2: > > https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-1-3fd45d9fb...@imgtec.com > > https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-3-3fd45d9fb...@imgtec.com > > https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-4-3fd45d9fb...@imgtec.com > --- > .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 43 > ++ > 1 file changed, 36 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > index > 256e252f8087fa0d6081f771a01601d34b66fe19..5c16b2881447c9cda78e5bb46569e2f675d740c4 > 100644 > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > @@ -12,10 +12,20 @@ maintainers: > > properties: >compatible: > -items: > - - enum: > - - ti,am62-gpu > - - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable > +oneOf: > + - items: > + - enum: > + - ti,am62-gpu > + - const: img,img-axe-1-16m > + - const: img,img-rogue That's still ABI break. You got here NAK. You ust preserve img,img-axe. Your marketing troubles do not concern Linux. > + > + # This legacy combination of compatible strings was introduced early on > + # before the more specific GPU identifiers were used. > + - items: > + - enum: > + - ti,am62-gpu > + - const: img,img-axe > +deprecated: true > >reg: > maxItems: 1 > @@ -34,8 +44,13 @@ properties: >interrupts: > maxItems: 1 > > - power-domains: > -maxItems: 1 > + power-domains: true No, widest constraints always stay here. > + > + power-domain-names: > +items: > + - const: a That's not a useful name. Are you sure that datasheet calls it power domain A? > + > + dma-coherent: true Best regards, Krzysztof
Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help)
Christoph and Ryan,
Could you help check this? Thanks.
On 3/11/25 4:54 PM, Huan Yang wrote:
>
> 在 2025/3/11 16:42, Bingbu Cao 写道:
>> [You don't often get email from bingbu@linux.intel.com. Learn why this
>> is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Huan,
>>
>> Thanks for your response.
>>
>> On 3/11/25 3:12 PM, Huan Yang wrote:
>>> 在 2025/3/11 14:40, Bingbu Cao 写道:
[You don't often get email from bingbu@linux.intel.com. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]
Huan Yang and Vivek,
I am trying to use udmabuf for my test, and I cannot vmap the udmabuf
buffers now. vmap_pfn_apply() will report a warning to complain that
the pfns are invalid.
I dump the pfn numbers as below:
[ 3365.399641] pg[0] pfn 1148695
[ 3365.399642] pg[1] pfn 1145057
[ 3365.399642] pg[2] pfn 1134070
[ 3365.399643] pg[3] pfn 1148700
[ 3365.399643] pg[4] pfn 1144871
[ 3365.399643] pg[5] pfn 1408686
[ 3365.399643] pg[6] pfn 1408683
...
[ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489
vmap_pfn_apply+0xb7/0xd0
[ 3365.399667] Modules linked in:...
[ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted
6.13.0-rc2-rvp #845
[ 3365.399752] Hardware name: Intel Corporation Client Platform/, BIOS
xxxFWI1.R00.3221.D83.2408120121 08/12/2024
[ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0
[ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21
c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a
<0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00
[ 3365.399756] RSP: 0018:b9b50c32fad0 EFLAGS: 00010202
[ 3365.399757] RAX: 0001 RBX: 00118717 RCX:
[ 3365.399758] RDX: 8000 RSI: b9b50c358000 RDI:
[ 3365.399758] RBP: b9b50c32fae8 R08: b9b50c32fbd0 R09:
0001
[ 3365.399759] R10: 941602479288 R11: R12:
b9b50c32fbd0
[ 3365.399759] R13: 941618665ac0 R14: b9b50c358000 R15:
941618665ac8
[ 3365.399760] FS: 7ff9e9ddd740() GS:94196f78()
knlGS:
[ 3365.399760] CS: 0010 DS: ES: CR0: 80050033
[ 3365.399761] CR2: 55fda5dc69d9 CR3: 0001544de003 CR4:
00f72ef0
[ 3365.399762] DR0: DR1: DR2:
[ 3365.399762] DR3: DR6: 07f0 DR7:
0400
[ 3365.399763] PKRU: 5554
[ 3365.399763] Call Trace:
[ 3365.399765]
[ 3365.399769] ? show_regs+0x6d/0x80
[ 3365.399773] ? __warn+0x97/0x160
[ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0
[ 3365.399777] ? report_bug+0x1ec/0x240
[ 3365.399782] ? handle_bug+0x63/0xa0
[ 3365.399784] ? exc_invalid_op+0x1d/0x80
[ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30
[ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0
[ 3365.399791] __apply_to_page_range+0x522/0x8a0
[ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10
[ 3365.399795] apply_to_page_range+0x18/0x20
[ 3365.399796] vmap_pfn+0x77/0xd0
[ 3365.399797] vmap_udmabuf+0xc5/0x110
[ 3365.399802] dma_buf_vmap+0x96/0x130
I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04,
then I can vmap the pages. Could you help what's wrong with that?
>>> Sorry for that, as I reviewed pfn_valid, that's someting wired:
>>>
>>> /**
>>> * pfn_valid - check if there is a valid memory map entry for a PFN
>>> * @pfn: the page frame number to check
>>> *
>>> * Check if there is a valid memory map entry aka struct page for the @pfn.
>>> * Note, that availability of the memory map entry does not imply that
>>> * there is actual usable memory at that @pfn. The struct page may
>>> * represent a hole or an unusable page frame.
>>> *
>>> * Return: 1 for PFNs that have memory map entries and 0 otherwise
>>> */
>>>
>>> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn.
>>> But vmap_pfn_apply in there:
>>>
>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private)
>>> {
>>> struct vmap_pfn_data *data = private;
>>> unsigned long pfn = data->pfns[data->idx];
>>> pte_t ptent;
>>>
>>> if (WARN_ON_ONCE(pfn_valid(pfn)))
>>> return -EINVAL;
>>>
>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot));
>>> set_pte_at(&init_mm, addr, pte, ptent);
>>>
>>> data->idx++;
>>> return 0;
>>> }
>>>
>>> Do it give a wrong check? maybe should fix by:
>> I guess not, it looks more like warning when you trying to vmap a
>> pfn which already took a valid entry in pte.
>
> No, I think here check need pfn is valid, then can set it. If a pfn is
> in
Re: [PATCH v1 5/6] drm/panfrost: Enable AARCH64_4K page table format on mediatek_mt8188
Il 10/03/25 20:59, Ariel D'Alessandro ha scritto:
Now that Panfrost supports AARCH64_4K page table format, let's enable it
on Mediatek MT8188.
Signed-off-by: Ariel D'Alessandro
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 0f3935556ac76..d7b8bded6d784 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -824,6 +824,7 @@ static const struct panfrost_compatible
mediatek_mt8188_data = {
.num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
.pm_domain_names = mediatek_mt8183_pm_domains,
.pm_features = BIT(GPU_PM_CLK_DIS) | BIT(GPU_PM_VREG_OFF),
+ .gpu_configs = BIT(GPU_CONFIG_AARCH64_4K),
};
static const char * const mediatek_mt8192_supplies[] = { "mali", NULL };
Didn't that work on MT8195/8395 as well? I also recall hearing that it was
somewhat
giving ever-so-slightly better performance?
If it does, please enable it on 8195 as well :-)
also s/mediatek_mt8188/MediaTek MT8188/g
...and btw
Reviewed-by: AngeloGioacchino Del Regno
Cheers,
Angelo
Re: [PATCH v1 4/6] drm/panfrost: Add support for AARCH64_4K page table format
Il 10/03/25 20:59, Ariel D'Alessandro ha scritto:
Currently, Panfrost only supports MMU configuration in "LEGACY" (as
Bifrost calls it) mode, a (modified) version of LPAE "Large Physical
Address Extension", which in Linux we've called "mali_lpae".
This commit adds support for conditionally enabling AARCH64_4K page
table format. To achieve that, a "GPU optional configurations" field was
added to `struct panfrost_features` with the related flag.
Note that, in order to enable AARCH64_4K mode, the GPU variant must have
the HW_FEATURE_AARCH64_MMU feature flag present.
Signed-off-by: Ariel D'Alessandro
---
drivers/gpu/drm/panfrost/panfrost_device.h | 16 +++
drivers/gpu/drm/panfrost/panfrost_mmu.c| 132 +++--
drivers/gpu/drm/panfrost/panfrost_regs.h | 34 ++
3 files changed, 169 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index cffcb0ac7c111..0385702aa43c7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -42,6 +42,14 @@ enum panfrost_gpu_pm {
GPU_PM_VREG_OFF,
};
+/**
+ * enum panfrost_gpu_config - GPU optional configurations
+ * @GPU_CONFIG_AARCH64_4K: Use AARCH64_4K page table format
+ */
+enum panfrost_gpu_config {
+ GPU_CONFIG_AARCH64_4K,
+};
+
struct panfrost_features {
u16 id;
u16 revision;
@@ -95,6 +103,9 @@ struct panfrost_compatible {
/* Allowed PM features */
u8 pm_features;
+
+ /* GPU features */
+ u8 gpu_configs;
};
struct panfrost_device {
@@ -162,6 +173,11 @@ struct panfrost_mmu {
int as;
atomic_t as_count;
struct list_head list;
+ struct {
+ u64 transtab;
+ u64 memattr;
+ u64 transcfg;
+ } cfg;
};
struct panfrost_engine_usage {
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 31df3a96f89bd..4a9b8de2ff987 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -26,6 +26,48 @@
#define mmu_write(dev, reg, data) writel(data, dev->iomem + reg)
#define mmu_read(dev, reg) readl(dev->iomem + reg)
+static u64 mair_to_memattr(u64 mair, bool coherent)
+{
+ u64 memattr = 0;
+ u32 i;
+
+ for (i = 0; i < 8; i++) {
+ u8 in_attr = mair >> (8 * i), out_attr;
+ u8 outer = in_attr >> 4, inner = in_attr & 0xf;
+
+ /* For caching to be enabled, inner and outer caching policy
+* have to be both write-back, if one of them is write-through
+* or non-cacheable, we just choose non-cacheable. Device
+* memory is also translated to non-cacheable.
+*/
+ if (!(outer & 3) || !(outer & 4) || !(inner & 4)) {
+ out_attr = AS_MEMATTR_AARCH64_INNER_OUTER_NC |
+ AS_MEMATTR_AARCH64_SH_MIDGARD_INNER |
+ AS_MEMATTR_AARCH64_INNER_ALLOC_EXPL(false,
false);
+ } else {
+ out_attr = AS_MEMATTR_AARCH64_INNER_OUTER_WB |
+ AS_MEMATTR_AARCH64_INNER_ALLOC_EXPL(inner & 1,
inner & 2);
+ /* Use SH_MIDGARD_INNER mode when device isn't coherent,
+* so SH_IS, which is used when IOMMU_CACHE is set, maps
+* to Mali's internal-shareable mode. As per the Mali
+* Spec, inner and outer-shareable modes aren't allowed
+* for WB memory when coherency is disabled.
+* Use SH_CPU_INNER mode when coherency is enabled, so
+* that SH_IS actually maps to the standard definition
of
+* inner-shareable.
+*/
+ if (!coherent)
+ out_attr |= AS_MEMATTR_AARCH64_SH_MIDGARD_INNER;
+ else
+ out_attr |= AS_MEMATTR_AARCH64_SH_CPU_INNER;
+ }
+
+ memattr |= (u64)out_attr << (8 * i);
+ }
+
+ return memattr;
+}
+
static int wait_ready(struct panfrost_device *pfdev, u32 as_nr)
{
int ret;
@@ -121,9 +163,57 @@ static int mmu_hw_do_operation(struct panfrost_device
*pfdev,
return ret;
}
+static void mmu_cfg_init_mali_lpae(struct panfrost_mmu *mmu)
+{
+ struct io_pgtable_cfg *pgtbl_cfg = &mmu->pgtbl_cfg;
+
+ /* TODO: The following fields are duplicated between the MMU and Page
+* Table config structs. Ideally, should be kept in one place.
+*/
+ mmu->cfg.transtab = pgtbl_cfg->arm_mali_lpae_cfg.transtab;
+ mmu->cfg.memattr = pgtbl_cfg->arm_mali_lpae_cfg.memattr;
+ mmu->cfg.transcfg = AS_TRANSCFG_ADRMODE_LEGACY;
+}
+
+static void mmu_
