Re: [PATCH] accel/ivpu/37xx: Fix missing VPUIP interrupts
On Tue, Oct 24, 2023 at 06:19:52PM +0200, Stanislaw Gruszka wrote:
> From: Karol Wachowski
>
> Move sequence of masking and unmasking global interrupts from buttress
> interrupt handler to generic one that handles both VPUIP and BTRS
> interrupts. Unmasking global interrupts will re-trigger MSI for any
> pending interrupts.
>
> Lack of this sequence will cause the driver to miss any
> VPUIP interrupt that comes after reading VPU_37XX_HOST_SS_ICB_STATUS_0
> and before clearing all active interrupt sources.
>
> Signed-off-by: Karol Wachowski
> Reviewed-by: Stanislaw Gruszka
> Signed-off-by: Stanislaw Gruszka
Added:
Fixes: 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
Cc: sta...@vger.kernel.org
and applied to drm-misc-fixes
Thanks
Stanislaw
> ---
> drivers/accel/ivpu/ivpu_hw_37xx.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c
> b/drivers/accel/ivpu/ivpu_hw_37xx.c
> index 7e4e87aa7602..5c0246b9e522 100644
> --- a/drivers/accel/ivpu/ivpu_hw_37xx.c
> +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
> @@ -906,9 +906,6 @@ static u32 ivpu_hw_37xx_irqb_handler(struct ivpu_device
> *vdev, int irq)
> if (status == 0)
> return 0;
>
> - /* Disable global interrupt before handling local buttress interrupts */
> - REGB_WR32(VPU_37XX_BUTTRESS_GLOBAL_INT_MASK, 0x1);
> -
> if (REG_TEST_FLD(VPU_37XX_BUTTRESS_INTERRUPT_STAT, FREQ_CHANGE, status))
> ivpu_dbg(vdev, IRQ, "FREQ_CHANGE irq: %08x",
>REGB_RD32(VPU_37XX_BUTTRESS_CURRENT_PLL));
> @@ -940,9 +937,6 @@ static u32 ivpu_hw_37xx_irqb_handler(struct ivpu_device
> *vdev, int irq)
> else
> REGB_WR32(VPU_37XX_BUTTRESS_INTERRUPT_STAT, status);
>
> - /* Re-enable global interrupt */
> - REGB_WR32(VPU_37XX_BUTTRESS_GLOBAL_INT_MASK, 0x0);
> -
> if (schedule_recovery)
> ivpu_pm_schedule_recovery(vdev);
>
> @@ -954,9 +948,14 @@ static irqreturn_t ivpu_hw_37xx_irq_handler(int irq,
> void *ptr)
> struct ivpu_device *vdev = ptr;
> u32 ret_irqv, ret_irqb;
>
> + REGB_WR32(VPU_37XX_BUTTRESS_GLOBAL_INT_MASK, 0x1);
> +
> ret_irqv = ivpu_hw_37xx_irqv_handler(vdev, irq);
> ret_irqb = ivpu_hw_37xx_irqb_handler(vdev, irq);
>
> + /* Re-enable global interrupts to re-trigger MSI for pending interrupts
> */
> + REGB_WR32(VPU_37XX_BUTTRESS_GLOBAL_INT_MASK, 0x0);
> +
> return IRQ_RETVAL(ret_irqb | ret_irqv);
> }
>
> --
> 2.25.1
>
Re: [PATCH] drm: Use device_get_match_data()
On 20/10/2023 15:52, Rob Herring wrote: Use preferred device_get_match_data() instead of of_match_device() to get the driver match data in a single step. With this, adjust the includes to explicitly include the correct headers. That also serves as preparation to remove implicit includes within the DT headers (of_device.h in particular). Signed-off-by: Rob Herring --- drivers/gpu/drm/armada/armada_crtc.c| 24 +++- drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 10 -- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 9 + drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 9 - drivers/gpu/drm/mxsfb/mxsfb_drv.c | 10 +++--- drivers/gpu/drm/omapdrm/dss/dispc.c | 4 ++-- drivers/gpu/drm/omapdrm/dss/dss.c | 5 +++-- 7 files changed, 28 insertions(+), 43 deletions(-) For omapdrm: Reviewed-by: Tomi Valkeinen Tomi
Re: [PATCH v7 4/6] drm/sched: Split free_job into own work item
On 2023-10-26 00:12, Matthew Brost wrote:
> Rather than call free_job and run_job in same work item have a dedicated
> work item for each. This aligns with the design and intended use of work
> queues.
>
> v2:
>- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
> timestamp in free_job() work item (Danilo)
> v3:
> - Drop forward dec of drm_sched_select_entity (Boris)
> - Return in drm_sched_run_job_work if entity NULL (Boris)
> v4:
> - Replace dequeue with peek and invert logic (Luben)
> - Wrap to 100 lines (Luben)
> - Update comments for *_queue / *_queue_if_ready functions (Luben)
> v5:
> - Drop peek argument, blindly blindly reinit idle (Luben)
> - s/drm_sched_free_job_queue_if_ready/drm_sched_free_job_queue_if_done
> (Luben)
> - Update work_run_job & work_free_job kernel doc (Luben)
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 241 +++--
> include/drm/gpu_scheduler.h| 8 +-
> 2 files changed, 151 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index b22157e920d4..3d89420d4ffb 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -257,12 +257,89 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
>
> /**
> * drm_sched_run_job_queue - enqueue scheduler submission
> + * drm_sched_run_job_queue - enqueue run-job work
> * @sched: scheduler instance
> */
No, please, see you're introducing this in patch 2, and it is there where
you should do all changes pertaining to that function.
Basically, you want to normalize your patches--don't spread the changes
to the same new thing you're introducing to many patches--just one single
patch and in no other patch.
This makes it easy to review, easy to see what is being changed, in one
place, and not in many places, especially when it is part of the same patchset.
And for the rest of the functions.
Thanks!
Regards,
Luben
> static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
> {
> if (!READ_ONCE(sched->pause_submit))
> - queue_work(sched->submit_wq, >work_submit);
> + queue_work(sched->submit_wq, >work_run_job);
> +}
> +
> +/**
> + * drm_sched_can_queue -- Can we queue more to the hardware?
> + * @sched: scheduler instance
> + *
> + * Return true if we can push more jobs to the hw, otherwise false.
> + */
> +static bool drm_sched_can_queue(struct drm_gpu_scheduler *sched)
> +{
> + return atomic_read(>hw_rq_count) <
> + sched->hw_submission_limit;
> +}
> +
> +/**
> + * drm_sched_select_entity - Select next entity to process
> + *
> + * @sched: scheduler instance
> + *
> + * Returns the entity to process or NULL if none are found.
> + */
> +static struct drm_sched_entity *
> +drm_sched_select_entity(struct drm_gpu_scheduler *sched)
> +{
> + struct drm_sched_entity *entity;
> + int i;
> +
> + if (!drm_sched_can_queue(sched))
> + return NULL;
> +
> + /* Kernel run queue has higher priority than normal run queue*/
> + for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
> + entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
> + drm_sched_rq_select_entity_fifo(sched->sched_rq[i]) :
> + drm_sched_rq_select_entity_rr(sched->sched_rq[i]);
> + if (entity)
> + break;
> + }
> +
> + return entity;
> +}
> +
> +/**
> + * drm_sched_run_job_queue_if_ready - enqueue run-job work if ready
> + * @sched: scheduler instance
> + */
> +static void drm_sched_run_job_queue_if_ready(struct drm_gpu_scheduler *sched)
> +{
> + if (drm_sched_select_entity(sched))
> + drm_sched_run_job_queue(sched);
> +}
> +
> +/**
> + * drm_sched_free_job_queue - enqueue free-job work
> + * @sched: scheduler instance
> + */
> +static void drm_sched_free_job_queue(struct drm_gpu_scheduler *sched)
> +{
> + if (!READ_ONCE(sched->pause_submit))
> + queue_work(sched->submit_wq, >work_free_job);
> +}
> +
> +/**
> + * drm_sched_free_job_queue_if_done - enqueue free-job work if ready
> + * @sched: scheduler instance
> + */
> +static void drm_sched_free_job_queue_if_done(struct drm_gpu_scheduler *sched)
> +{
> + struct drm_sched_job *job;
> +
> + spin_lock(>job_list_lock);
> + job = list_first_entry_or_null(>pending_list,
> +struct drm_sched_job, list);
> + if (job && dma_fence_is_signaled(>s_fence->finished))
> + drm_sched_free_job_queue(sched);
> + spin_unlock(>job_list_lock);
> }
>
> /**
> @@ -284,7 +361,7 @@ static void drm_sched_job_done(struct drm_sched_job
> *s_job, int result)
> dma_fence_get(_fence->finished);
> drm_sched_fence_finished(s_fence, result);
> dma_fence_put(_fence->finished);
> - drm_sched_run_job_queue(sched);
> +
Re: [PATCH] vga_switcheroo: Fix impossible judgment condition
On Thu, Oct 26, 2023 at 10:10:57AM +0800, Su Hui wrote:
> 'id' is enum type like unsigned int, so it will never be less than zero.
>
> Fixes: 4aaf448fa975 ("vga_switcheroo: set audio client id according to bound
> GPU id")
> Signed-off-by: Su Hui
> ---
> drivers/gpu/vga/vga_switcheroo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c
> b/drivers/gpu/vga/vga_switcheroo.c
> index 365e6ddbe90f..d3064466fd3a 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -375,7 +375,7 @@ int vga_switcheroo_register_audio_client(struct pci_dev
> *pdev,
> mutex_lock(_mutex);
> if (vgasr_priv.active) {
> id = vgasr_priv.handler->get_client_id(vga_dev);
> - if (id < 0) {
> + if ((int)id < 0) {
Hi,
I feel like you're using Smatch? Which is great! Fantastic!
Have you built the cross function database? If you have there is a
command that's useful.
$ ~/smatch/smatch_db/smdb.py functions vga_switcheroo_handler get_client_id |
tee where
drivers/gpu/drm/nouveau/nouveau_acpi.c | (struct
vga_switcheroo_handler)->get_client_id | nouveau_dsm_get_client_id | 1
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | (struct
vga_switcheroo_handler)->get_client_id | amdgpu_atpx_get_client_id | 1
drivers/gpu/drm/radeon/radeon_atpx_handler.c | (struct
vga_switcheroo_handler)->get_client_id | radeon_atpx_get_client_id | 1
drivers/platform/x86/apple-gmux.c | (struct
vga_switcheroo_handler)->get_client_id | gmux_get_client_id | 1
$ make cscope
$ vim where
Use cscope to jump to each of those four functions. Move the cursor to
the nouveau_dsm_get_client_id and hit CTRL-].
They never return negatives. The enum vga_switcheroo_client_id has a
VGA_SWITCHEROO_UNKNOWN_ID define which I guess these functions are
supposed to return on error. They never do return that, but I bet
that's what we are supposed to check for. It honestly might be good
to check for both...
if ((int)id < 0 || id == VGA_SWITCHEROO_UNKNOWN_ID) {
mutex_unlock(_mutex);
return -EINVAL;
}
regards,
dan carpenter
Re: [PATCH v7 6/6] drm/sched: Add a helper to queue TDR immediately
On 2023-10-26 00:12, Matthew Brost wrote:
> Add a helper whereby a driver can invoke TDR immediately.
>
> v2:
> - Drop timeout args, rename function, use mod delayed work (Luben)
> v3:
> - s/XE/Xe (Luben)
> - present tense in commit message (Luben)
> - Adjust comment for drm_sched_tdr_queue_imm (Luben)
> v4:
> - Adjust commit message (Luben)
>
> Cc: Luben Tuikov
> Signed-off-by: Matthew Brost
> Reviewed-by: Luben Tuikov
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 18 +-
> include/drm/gpu_scheduler.h| 1 +
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index ae66cabc3162..246213963928 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -389,7 +389,7 @@ static void drm_sched_start_timeout(struct
> drm_gpu_scheduler *sched)
>
> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> !list_empty(>pending_list))
> - queue_delayed_work(sched->timeout_wq, >work_tdr,
> sched->timeout);
> + mod_delayed_work(sched->timeout_wq, >work_tdr,
> sched->timeout);
> }
>
> static void drm_sched_start_timeout_unlocked(struct drm_gpu_scheduler *sched)
> @@ -399,6 +399,22 @@ static void drm_sched_start_timeout_unlocked(struct
> drm_gpu_scheduler *sched)
> spin_unlock(>job_list_lock);
> }
>
> +/**
> + * drm_sched_tdr_queue_imm: - immediately start job timeout handler
No need for a colon char (:) after the name.
Regards,
Luben
> + *
> + * @sched: scheduler for which the timeout handling should be started.
> + *
> + * Start timeout handling immediately for the named scheduler.
> + */
> +void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched)
> +{
> + spin_lock(>job_list_lock);
> + sched->timeout = 0;
> + drm_sched_start_timeout(sched);
> + spin_unlock(>job_list_lock);
> +}
> +EXPORT_SYMBOL(drm_sched_tdr_queue_imm);
> +
> /**
> * drm_sched_fault - immediately start timeout handler
> *
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 37749f561866..e5a6166eb152 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -557,6 +557,7 @@ void drm_sched_entity_modify_sched(struct
> drm_sched_entity *entity,
> struct drm_gpu_scheduler **sched_list,
> unsigned int num_sched_list);
>
> +void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched);
> void drm_sched_job_cleanup(struct drm_sched_job *job);
> void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched);
> bool drm_sched_wqueue_ready(struct drm_gpu_scheduler *sched);
Re: [PATCH v7 4/6] drm/sched: Split free_job into own work item
On 2023-10-26 00:12, Matthew Brost wrote:
> Rather than call free_job and run_job in same work item have a dedicated
> work item for each. This aligns with the design and intended use of work
> queues.
>
> v2:
>- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
> timestamp in free_job() work item (Danilo)
> v3:
> - Drop forward dec of drm_sched_select_entity (Boris)
> - Return in drm_sched_run_job_work if entity NULL (Boris)
> v4:
> - Replace dequeue with peek and invert logic (Luben)
> - Wrap to 100 lines (Luben)
> - Update comments for *_queue / *_queue_if_ready functions (Luben)
> v5:
> - Drop peek argument, blindly blindly reinit idle (Luben)
> - s/drm_sched_free_job_queue_if_ready/drm_sched_free_job_queue_if_done
> (Luben)
> - Update work_run_job & work_free_job kernel doc (Luben)
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 241 +++--
> include/drm/gpu_scheduler.h| 8 +-
> 2 files changed, 151 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index b22157e920d4..3d89420d4ffb 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -257,12 +257,89 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
>
> /**
> * drm_sched_run_job_queue - enqueue scheduler submission
> + * drm_sched_run_job_queue - enqueue run-job work
> * @sched: scheduler instance
> */
> static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
> {
> if (!READ_ONCE(sched->pause_submit))
> - queue_work(sched->submit_wq, >work_submit);
> + queue_work(sched->submit_wq, >work_run_job);
> +}
> +
> +/**
> + * drm_sched_can_queue -- Can we queue more to the hardware?
> + * @sched: scheduler instance
> + *
> + * Return true if we can push more jobs to the hw, otherwise false.
> + */
> +static bool drm_sched_can_queue(struct drm_gpu_scheduler *sched)
> +{
> + return atomic_read(>hw_rq_count) <
> + sched->hw_submission_limit;
> +}
> +
> +/**
> + * drm_sched_select_entity - Select next entity to process
> + *
> + * @sched: scheduler instance
> + *
> + * Returns the entity to process or NULL if none are found.
> + */
> +static struct drm_sched_entity *
> +drm_sched_select_entity(struct drm_gpu_scheduler *sched)
> +{
> + struct drm_sched_entity *entity;
> + int i;
> +
> + if (!drm_sched_can_queue(sched))
> + return NULL;
> +
> + /* Kernel run queue has higher priority than normal run queue*/
> + for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
> + entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
> + drm_sched_rq_select_entity_fifo(sched->sched_rq[i]) :
> + drm_sched_rq_select_entity_rr(sched->sched_rq[i]);
> + if (entity)
> + break;
> + }
> +
> + return entity;
> +}
> +
Could you please rewrite the patch so as to not do the unnecessary move
of the drm_sched_select_entity(). This function has no changes in it,
and this move a few lines up only creates noise, when doing "git blame"
and similar data-mining.
So, just rewrite the patch without moving unchanged code up/down, so
that only the essential differences are shown by git-diff(1). This makes
it easy to review, easy to do data-mining down the road, and so on.
The rest of the patch looks good.
Thanks!
Regards,
Luben
> +/**
> + * drm_sched_run_job_queue_if_ready - enqueue run-job work if ready
> + * @sched: scheduler instance
> + */
> +static void drm_sched_run_job_queue_if_ready(struct drm_gpu_scheduler *sched)
> +{
> + if (drm_sched_select_entity(sched))
> + drm_sched_run_job_queue(sched);
> +}
> +
> +/**
> + * drm_sched_free_job_queue - enqueue free-job work
> + * @sched: scheduler instance
> + */
> +static void drm_sched_free_job_queue(struct drm_gpu_scheduler *sched)
> +{
> + if (!READ_ONCE(sched->pause_submit))
> + queue_work(sched->submit_wq, >work_free_job);
> +}
> +
> +/**
> + * drm_sched_free_job_queue_if_done - enqueue free-job work if ready
> + * @sched: scheduler instance
> + */
> +static void drm_sched_free_job_queue_if_done(struct drm_gpu_scheduler *sched)
> +{
> + struct drm_sched_job *job;
> +
> + spin_lock(>job_list_lock);
> + job = list_first_entry_or_null(>pending_list,
> +struct drm_sched_job, list);
> + if (job && dma_fence_is_signaled(>s_fence->finished))
> + drm_sched_free_job_queue(sched);
> + spin_unlock(>job_list_lock);
> }
>
> /**
> @@ -284,7 +361,7 @@ static void drm_sched_job_done(struct drm_sched_job
> *s_job, int result)
> dma_fence_get(_fence->finished);
> drm_sched_fence_finished(s_fence, result);
> dma_fence_put(_fence->finished);
> - drm_sched_run_job_queue(sched);
> +
Re: [PATCH v7 3/6] drm/sched: Convert the GPU scheduler to variable number of run-queues
On 2023-10-26 00:12, Matthew Brost wrote:
> From: Luben Tuikov
>
> The GPU scheduler has now a variable number of run-queues, which are set up at
> drm_sched_init() time. This way, each driver announces how many run-queues it
> requires (supports) per each GPU scheduler it creates. Note, that run-queues
> correspond to scheduler "priorities", thus if the number of run-queues is set
> to 1 at drm_sched_init(), then that scheduler supports a single run-queue,
> i.e. single "priority". If a driver further sets a single entity per
> run-queue, then this creates a 1-to-1 correspondence between a scheduler and
> a scheduled entity.
>
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Qiang Yu
> Cc: Rob Clark
> Cc: Abhinav Kumar
> Cc: Dmitry Baryshkov
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Boris Brezillon
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Emma Anholt
> Cc: etna...@lists.freedesktop.org
> Cc: l...@lists.freedesktop.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Luben Tuikov
> Signed-off-by: Matthew Brost
Normally, you'd add your R-B.
You should add your S-O-B tag, if you've co-authored/contributed to the commit
or are the actual committer to drm-*, as "dim" requires it, but dim will tell
you,
so generally, I don't do that unless the tool tells me to. :-)
So here, feel free to R-B the patch instead of S-O-B, on a patch post.
Regards,
Luben
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 4 +-
> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 3 +-
> drivers/gpu/drm/lima/lima_sched.c | 3 +-
> drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +-
> drivers/gpu/drm/nouveau/nouveau_sched.c| 1 +
> drivers/gpu/drm/panfrost/panfrost_job.c| 3 +-
> drivers/gpu/drm/scheduler/sched_entity.c | 18 +-
> drivers/gpu/drm/scheduler/sched_main.c | 75 ++
> drivers/gpu/drm/v3d/v3d_sched.c| 14 ++--
> include/drm/gpu_scheduler.h| 9 ++-
> 11 files changed, 102 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index b54c4d771104..94d073bfbd13 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2280,6 +2280,7 @@ static int amdgpu_device_init_schedulers(struct
> amdgpu_device *adev)
> }
>
> r = drm_sched_init(>sched, _sched_ops, NULL,
> +DRM_SCHED_PRIORITY_COUNT,
> ring->num_hw_submission, 0,
> timeout, adev->reset_domain->wq,
> ring->sched_score, ring->name,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index 78476bc75b4e..1f357198533f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -325,8 +325,8 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
> drm_gpu_scheduler *sched)
> int i;
>
> /* Signal all jobs not yet scheduled */
> - for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN;
> i--) {
> - struct drm_sched_rq *rq = >sched_rq[i];
> + for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
> + struct drm_sched_rq *rq = sched->sched_rq[i];
> spin_lock(>lock);
> list_for_each_entry(s_entity, >entities, list) {
> while ((s_job =
> to_drm_sched_job(spsc_queue_pop(_entity->job_queue {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 618a804ddc34..396334984e4d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -134,7 +134,8 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
> {
> int ret;
>
> - ret = drm_sched_init(>sched, _sched_ops, NULL,
> + ret = drm_sched_init(>sched, _sched_ops,
> + DRM_SCHED_PRIORITY_COUNT, NULL,
>etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
>msecs_to_jiffies(500), NULL, NULL,
>dev_name(gpu->dev), gpu->dev);
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index 8d858aed0e56..23a6276f1332 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -488,7 +488,8 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
> const char *name)
>
> INIT_WORK(>recover_work, lima_sched_recover_work);
>
> - return drm_sched_init(>base, _sched_ops, NULL, 1,
> + return drm_sched_init(>base, _sched_ops,
> +
Re: [PATCH v7 0/6] DRM scheduler changes for Xe
Hi, On 2023-10-26 00:12, Matthew Brost wrote: > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we > have been asked to merge our common DRM scheduler patches first. > > This a continuation of a RFC [3] with all comments addressed, ready for > a full review, and hopefully in state which can merged in the near > future. More details of this series can found in the cover letter of the > RFC [3]. > > These changes have been tested with the Xe driver. Based on drm-tip branch. > > A follow up series will be posted to address some of dakr requets for > kernel doc changes. > > v2: > - Break run job, free job, and process message in own work items > - This might break other drivers as run job and free job now can run in >parallel, can fix up if needed > > v3: > - Include missing patch 'drm/sched: Add drm_sched_submit_* helpers' > - Fix issue with setting timestamp to early > - Don't dequeue jobs for single entity after calling entity fini > - Flush pending jobs on entity fini > - Add documentation for entity teardown > - Add Matthew Brost to maintainers of DRM scheduler > > v4: > - Drop message interface > - Drop 'Flush pending jobs on entity fini' > - Drop 'Add documentation for entity teardown' > - Address all feedback > > v5: > - Address Luben's feedback > - Drop starting TDR after calling run_job() > - Drop adding Matthew Brost to maintainers of DRM scheduler > > v6: > - Address Luben's feedback > - Include base commit > > v7: > - Drop SINGLE_ENTITY mode rather pull in Luben's patch for dynamic run queues > - Address Luben's feedback for free_job work item patch > > Matt > > [1] https://gitlab.freedesktop.org/drm/xe/kernel > [2] https://patchwork.freedesktop.org/series/112188/ > [3] https://patchwork.freedesktop.org/series/116055/ > > Luben Tuikov (1): > drm/sched: Convert the GPU scheduler to variable number of run-queues > > Matthew Brost (5): > drm/sched: Add drm_sched_wqueue_* helpers > drm/sched: Convert drm scheduler to use a work queue rather than > kthread > drm/sched: Split free_job into own work item > drm/sched: Add drm_sched_start_timeout_unlocked helper > drm/sched: Add a helper to queue TDR immediately > > .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 15 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 15 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_sched.c | 1 + > drivers/gpu/drm/lima/lima_sched.c | 3 +- > drivers/gpu/drm/msm/adreno/adreno_device.c| 6 +- > drivers/gpu/drm/msm/msm_ringbuffer.c | 6 +- > drivers/gpu/drm/nouveau/nouveau_sched.c | 3 +- > drivers/gpu/drm/panfrost/panfrost_job.c | 1 + > drivers/gpu/drm/scheduler/sched_entity.c | 18 +- > drivers/gpu/drm/scheduler/sched_main.c| 444 -- > drivers/gpu/drm/v3d/v3d_sched.c | 10 +- > include/drm/gpu_scheduler.h | 29 +- > 14 files changed, 373 insertions(+), 184 deletions(-) > > > base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe I get a "bad object" doing a lookup for this object. drm-tip isn't very "stable". -- Regards, Luben
[PATCH v7 4/6] drm/sched: Split free_job into own work item
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.
v2:
- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
timestamp in free_job() work item (Danilo)
v3:
- Drop forward dec of drm_sched_select_entity (Boris)
- Return in drm_sched_run_job_work if entity NULL (Boris)
v4:
- Replace dequeue with peek and invert logic (Luben)
- Wrap to 100 lines (Luben)
- Update comments for *_queue / *_queue_if_ready functions (Luben)
v5:
- Drop peek argument, blindly blindly reinit idle (Luben)
- s/drm_sched_free_job_queue_if_ready/drm_sched_free_job_queue_if_done (Luben)
- Update work_run_job & work_free_job kernel doc (Luben)
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 241 +++--
include/drm/gpu_scheduler.h| 8 +-
2 files changed, 151 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b22157e920d4..3d89420d4ffb 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -257,12 +257,89 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
/**
* drm_sched_run_job_queue - enqueue scheduler submission
+ * drm_sched_run_job_queue - enqueue run-job work
* @sched: scheduler instance
*/
static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
{
if (!READ_ONCE(sched->pause_submit))
- queue_work(sched->submit_wq, >work_submit);
+ queue_work(sched->submit_wq, >work_run_job);
+}
+
+/**
+ * drm_sched_can_queue -- Can we queue more to the hardware?
+ * @sched: scheduler instance
+ *
+ * Return true if we can push more jobs to the hw, otherwise false.
+ */
+static bool drm_sched_can_queue(struct drm_gpu_scheduler *sched)
+{
+ return atomic_read(>hw_rq_count) <
+ sched->hw_submission_limit;
+}
+
+/**
+ * drm_sched_select_entity - Select next entity to process
+ *
+ * @sched: scheduler instance
+ *
+ * Returns the entity to process or NULL if none are found.
+ */
+static struct drm_sched_entity *
+drm_sched_select_entity(struct drm_gpu_scheduler *sched)
+{
+ struct drm_sched_entity *entity;
+ int i;
+
+ if (!drm_sched_can_queue(sched))
+ return NULL;
+
+ /* Kernel run queue has higher priority than normal run queue*/
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
+ drm_sched_rq_select_entity_fifo(sched->sched_rq[i]) :
+ drm_sched_rq_select_entity_rr(sched->sched_rq[i]);
+ if (entity)
+ break;
+ }
+
+ return entity;
+}
+
+/**
+ * drm_sched_run_job_queue_if_ready - enqueue run-job work if ready
+ * @sched: scheduler instance
+ */
+static void drm_sched_run_job_queue_if_ready(struct drm_gpu_scheduler *sched)
+{
+ if (drm_sched_select_entity(sched))
+ drm_sched_run_job_queue(sched);
+}
+
+/**
+ * drm_sched_free_job_queue - enqueue free-job work
+ * @sched: scheduler instance
+ */
+static void drm_sched_free_job_queue(struct drm_gpu_scheduler *sched)
+{
+ if (!READ_ONCE(sched->pause_submit))
+ queue_work(sched->submit_wq, >work_free_job);
+}
+
+/**
+ * drm_sched_free_job_queue_if_done - enqueue free-job work if ready
+ * @sched: scheduler instance
+ */
+static void drm_sched_free_job_queue_if_done(struct drm_gpu_scheduler *sched)
+{
+ struct drm_sched_job *job;
+
+ spin_lock(>job_list_lock);
+ job = list_first_entry_or_null(>pending_list,
+ struct drm_sched_job, list);
+ if (job && dma_fence_is_signaled(>s_fence->finished))
+ drm_sched_free_job_queue(sched);
+ spin_unlock(>job_list_lock);
}
/**
@@ -284,7 +361,7 @@ static void drm_sched_job_done(struct drm_sched_job *s_job,
int result)
dma_fence_get(_fence->finished);
drm_sched_fence_finished(s_fence, result);
dma_fence_put(_fence->finished);
- drm_sched_run_job_queue(sched);
+ drm_sched_free_job_queue(sched);
}
/**
@@ -550,7 +627,7 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
full_recovery)
drm_sched_job_done(s_job, fence->error);
else if (r)
DRM_DEV_ERROR(sched->dev, "fence add callback
failed (%d)\n",
- r);
+ r);
} else
drm_sched_job_done(s_job, -ECANCELED);
}
@@ -862,18 +939,6 @@ void drm_sched_job_cleanup(struct drm_sched_job *job)
}
EXPORT_SYMBOL(drm_sched_job_cleanup);
-/**
- * drm_sched_can_queue -- Can we queue more to the hardware?
- * @sched: scheduler instance
- *
[PATCH v7 3/6] drm/sched: Convert the GPU scheduler to variable number of run-queues
From: Luben Tuikov
The GPU scheduler has now a variable number of run-queues, which are set up at
drm_sched_init() time. This way, each driver announces how many run-queues it
requires (supports) per each GPU scheduler it creates. Note, that run-queues
correspond to scheduler "priorities", thus if the number of run-queues is set
to 1 at drm_sched_init(), then that scheduler supports a single run-queue,
i.e. single "priority". If a driver further sets a single entity per
run-queue, then this creates a 1-to-1 correspondence between a scheduler and
a scheduled entity.
Cc: Lucas Stach
Cc: Russell King
Cc: Qiang Yu
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Boris Brezillon
Cc: Alex Deucher
Cc: Christian König
Cc: Emma Anholt
Cc: etna...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 4 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 3 +-
drivers/gpu/drm/lima/lima_sched.c | 3 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_sched.c| 1 +
drivers/gpu/drm/panfrost/panfrost_job.c| 3 +-
drivers/gpu/drm/scheduler/sched_entity.c | 18 +-
drivers/gpu/drm/scheduler/sched_main.c | 75 ++
drivers/gpu/drm/v3d/v3d_sched.c| 14 ++--
include/drm/gpu_scheduler.h| 9 ++-
11 files changed, 102 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b54c4d771104..94d073bfbd13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2280,6 +2280,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
}
r = drm_sched_init(>sched, _sched_ops, NULL,
+ DRM_SCHED_PRIORITY_COUNT,
ring->num_hw_submission, 0,
timeout, adev->reset_domain->wq,
ring->sched_score, ring->name,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 78476bc75b4e..1f357198533f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,8 +325,8 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN;
i--) {
- struct drm_sched_rq *rq = >sched_rq[i];
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
while ((s_job =
to_drm_sched_job(spsc_queue_pop(_entity->job_queue {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 618a804ddc34..396334984e4d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -134,7 +134,8 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
{
int ret;
- ret = drm_sched_init(>sched, _sched_ops, NULL,
+ ret = drm_sched_init(>sched, _sched_ops,
+DRM_SCHED_PRIORITY_COUNT, NULL,
etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
msecs_to_jiffies(500), NULL, NULL,
dev_name(gpu->dev), gpu->dev);
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 8d858aed0e56..23a6276f1332 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -488,7 +488,8 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
const char *name)
INIT_WORK(>recover_work, lima_sched_recover_work);
- return drm_sched_init(>base, _sched_ops, NULL, 1,
+ return drm_sched_init(>base, _sched_ops,
+ DRM_SCHED_PRIORITY_COUNT, NULL, 1,
lima_job_hang_limit,
msecs_to_jiffies(timeout), NULL,
NULL, name, pipe->ldev->dev);
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 1097f8e93d6b..935154979fc2 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -94,7 +94,8 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
/* currently managing hangcheck ourselves: */
[PATCH v7 5/6] drm/sched: Add drm_sched_start_timeout_unlocked helper
Also add a lockdep assert to drm_sched_start_timeout.
Signed-off-by: Matthew Brost
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 3d89420d4ffb..ae66cabc3162 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -385,11 +385,20 @@ static void drm_sched_job_done_cb(struct dma_fence *f,
struct dma_fence_cb *cb)
*/
static void drm_sched_start_timeout(struct drm_gpu_scheduler *sched)
{
+ lockdep_assert_held(>job_list_lock);
+
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_empty(>pending_list))
queue_delayed_work(sched->timeout_wq, >work_tdr,
sched->timeout);
}
+static void drm_sched_start_timeout_unlocked(struct drm_gpu_scheduler *sched)
+{
+ spin_lock(>job_list_lock);
+ drm_sched_start_timeout(sched);
+ spin_unlock(>job_list_lock);
+}
+
/**
* drm_sched_fault - immediately start timeout handler
*
@@ -502,11 +511,8 @@ static void drm_sched_job_timedout(struct work_struct
*work)
spin_unlock(>job_list_lock);
}
- if (status != DRM_GPU_SCHED_STAT_ENODEV) {
- spin_lock(>job_list_lock);
- drm_sched_start_timeout(sched);
- spin_unlock(>job_list_lock);
- }
+ if (status != DRM_GPU_SCHED_STAT_ENODEV)
+ drm_sched_start_timeout_unlocked(sched);
}
/**
@@ -632,11 +638,8 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
full_recovery)
drm_sched_job_done(s_job, -ECANCELED);
}
- if (full_recovery) {
- spin_lock(>job_list_lock);
- drm_sched_start_timeout(sched);
- spin_unlock(>job_list_lock);
- }
+ if (full_recovery)
+ drm_sched_start_timeout_unlocked(sched);
drm_sched_wqueue_start(sched);
}
--
2.34.1
[PATCH v7 2/6] drm/sched: Convert drm scheduler to use a work queue rather than kthread
In Xe, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.
1. In Xe the submission order from multiple drm_sched_entity is not
guaranteed to be the same completion even if targeting the same hardware
engine. This is because in Xe we have a firmware scheduler, the GuC,
which allowed to reorder, timeslice, and preempt submissions. If a using
shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
apart as the TDR expects submission order == completion order. Using a
dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
2. In Xe submissions are done via programming a ring buffer (circular
buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the
limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow
control on the ring for free.
A problem with this design is currently a drm_gpu_scheduler uses a
kthread for submission / job cleanup. This doesn't scale if a large
number of drm_gpu_scheduler are used. To work around the scaling issue,
use a worker rather than kthread for submission / job cleanup.
v2:
- (Rob Clark) Fix msm build
- Pass in run work queue
v3:
- (Boris) don't have loop in worker
v4:
- (Tvrtko) break out submit ready, stop, start helpers into own patch
v5:
- (Boris) default to ordered work queue
v6:
- (Luben / checkpatch) fix alignment in msm_ringbuffer.c
- (Luben) s/drm_sched_submit_queue/drm_sched_wqueue_enqueue
- (Luben) Update comment for drm_sched_wqueue_enqueue
- (Luben) Positive check for submit_wq in drm_sched_init
- (Luben) s/alloc_submit_wq/own_submit_wq
v7:
- (Luben) s/drm_sched_wqueue_enqueue/drm_sched_run_job_queue
Signed-off-by: Matthew Brost
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 2 +-
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_sched.c| 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c| 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 118 ++---
drivers/gpu/drm/v3d/v3d_sched.c| 10 +-
include/drm/gpu_scheduler.h| 14 ++-
9 files changed, 82 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1aafe815f28..b54c4d771104 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2279,7 +2279,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
break;
}
- r = drm_sched_init(>sched, _sched_ops,
+ r = drm_sched_init(>sched, _sched_ops, NULL,
ring->num_hw_submission, 0,
timeout, adev->reset_domain->wq,
ring->sched_score, ring->name,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 345fec6cb1a4..618a804ddc34 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -134,7 +134,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
{
int ret;
- ret = drm_sched_init(>sched, _sched_ops,
+ ret = drm_sched_init(>sched, _sched_ops, NULL,
etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
msecs_to_jiffies(500), NULL, NULL,
dev_name(gpu->dev), gpu->dev);
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index ffd91a5ee299..8d858aed0e56 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -488,7 +488,7 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
const char *name)
INIT_WORK(>recover_work, lima_sched_recover_work);
- return drm_sched_init(>base, _sched_ops, 1,
+ return drm_sched_init(>base, _sched_ops, NULL, 1,
lima_job_hang_limit,
msecs_to_jiffies(timeout), NULL,
NULL, name, pipe->ldev->dev);
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 40c0bc35a44c..1097f8e93d6b 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -94,9 +94,10 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu
*gpu, int id,
/* currently managing hangcheck ourselves: */
sched_timeout = MAX_SCHEDULE_TIMEOUT;
- ret = drm_sched_init(>sched, _sched_ops,
- num_hw_submissions, 0, sched_timeout,
- NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev->dev);
+ ret = drm_sched_init(>sched,
[PATCH v7 6/6] drm/sched: Add a helper to queue TDR immediately
Add a helper whereby a driver can invoke TDR immediately.
v2:
- Drop timeout args, rename function, use mod delayed work (Luben)
v3:
- s/XE/Xe (Luben)
- present tense in commit message (Luben)
- Adjust comment for drm_sched_tdr_queue_imm (Luben)
v4:
- Adjust commit message (Luben)
Cc: Luben Tuikov
Signed-off-by: Matthew Brost
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 18 +-
include/drm/gpu_scheduler.h| 1 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index ae66cabc3162..246213963928 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -389,7 +389,7 @@ static void drm_sched_start_timeout(struct
drm_gpu_scheduler *sched)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_empty(>pending_list))
- queue_delayed_work(sched->timeout_wq, >work_tdr,
sched->timeout);
+ mod_delayed_work(sched->timeout_wq, >work_tdr,
sched->timeout);
}
static void drm_sched_start_timeout_unlocked(struct drm_gpu_scheduler *sched)
@@ -399,6 +399,22 @@ static void drm_sched_start_timeout_unlocked(struct
drm_gpu_scheduler *sched)
spin_unlock(>job_list_lock);
}
+/**
+ * drm_sched_tdr_queue_imm: - immediately start job timeout handler
+ *
+ * @sched: scheduler for which the timeout handling should be started.
+ *
+ * Start timeout handling immediately for the named scheduler.
+ */
+void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched)
+{
+ spin_lock(>job_list_lock);
+ sched->timeout = 0;
+ drm_sched_start_timeout(sched);
+ spin_unlock(>job_list_lock);
+}
+EXPORT_SYMBOL(drm_sched_tdr_queue_imm);
+
/**
* drm_sched_fault - immediately start timeout handler
*
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 37749f561866..e5a6166eb152 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -557,6 +557,7 @@ void drm_sched_entity_modify_sched(struct drm_sched_entity
*entity,
struct drm_gpu_scheduler **sched_list,
unsigned int num_sched_list);
+void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched);
void drm_sched_job_cleanup(struct drm_sched_job *job);
void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched);
bool drm_sched_wqueue_ready(struct drm_gpu_scheduler *sched);
--
2.34.1
[PATCH v7 1/6] drm/sched: Add drm_sched_wqueue_* helpers
Add scheduler wqueue ready, stop, and start helpers to hide the
implementation details of the scheduler from the drivers.
v2:
- s/sched_wqueue/sched_wqueue (Luben)
- Remove the extra white line after the return-statement (Luben)
- update drm_sched_wqueue_ready comment (Luben)
Cc: Luben Tuikov
Signed-off-by: Matthew Brost
Reviewed-by: Luben Tuikov
---
.../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 12 +++---
drivers/gpu/drm/msm/adreno/adreno_device.c| 6 ++-
drivers/gpu/drm/scheduler/sched_main.c| 39 ++-
include/drm/gpu_scheduler.h | 3 ++
6 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index 625db444df1c..10d56979fe3b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -290,7 +290,7 @@ static int suspend_resume_compute_scheduler(struct
amdgpu_device *adev, bool sus
for (i = 0; i < adev->gfx.num_compute_rings; i++) {
struct amdgpu_ring *ring = >gfx.compute_ring[i];
- if (!(ring && ring->sched.thread))
+ if (!(ring && drm_sched_wqueue_ready(>sched)))
continue;
/* stop secheduler and drain ring. */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index a4faea4fa0b5..a4c0bb358db7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1659,9 +1659,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file
*m, void *unused)
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
- if (!ring || !ring->sched.thread)
+ if (!ring || !drm_sched_wqueue_ready(>sched))
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_wqueue_stop(>sched);
}
seq_puts(m, "run ib test:\n");
@@ -1675,9 +1675,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file
*m, void *unused)
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
- if (!ring || !ring->sched.thread)
+ if (!ring || !drm_sched_wqueue_ready(>sched))
continue;
- kthread_unpark(ring->sched.thread);
+ drm_sched_wqueue_start(>sched);
}
up_write(>reset_domain->sem);
@@ -1897,7 +1897,8 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
ring = adev->rings[val];
- if (!ring || !ring->funcs->preempt_ib || !ring->sched.thread)
+ if (!ring || !ring->funcs->preempt_ib ||
+ !drm_sched_wqueue_ready(>sched))
return -EINVAL;
/* the last preemption failed */
@@ -1915,7 +1916,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
goto pro_end;
/* stop the scheduler */
- kthread_park(ring->sched.thread);
+ drm_sched_wqueue_stop(>sched);
/* preempt the IB */
r = amdgpu_ring_preempt_ib(ring);
@@ -1949,7 +1950,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
failure:
/* restart the scheduler */
- kthread_unpark(ring->sched.thread);
+ drm_sched_wqueue_start(>sched);
up_read(>reset_domain->sem);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 2b8356699f23..b1aafe815f28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4588,7 +4588,7 @@ bool amdgpu_device_has_job_running(struct amdgpu_device
*adev)
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
- if (!ring || !ring->sched.thread)
+ if (!ring || !drm_sched_wqueue_ready(>sched))
continue;
spin_lock(>sched.job_list_lock);
@@ -4727,7 +4727,7 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device
*adev,
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
- if (!ring || !ring->sched.thread)
+ if (!ring || !drm_sched_wqueue_ready(>sched))
continue;
/* Clear job fence from fence drv to avoid force_completion
@@ -5266,7 +5266,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = tmp_adev->rings[i];
- if (!ring || !ring->sched.thread)
+ if (!ring ||
[PATCH v7 0/6] DRM scheduler changes for Xe
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we have been asked to merge our common DRM scheduler patches first. This a continuation of a RFC [3] with all comments addressed, ready for a full review, and hopefully in state which can merged in the near future. More details of this series can found in the cover letter of the RFC [3]. These changes have been tested with the Xe driver. Based on drm-tip branch. A follow up series will be posted to address some of dakr requets for kernel doc changes. v2: - Break run job, free job, and process message in own work items - This might break other drivers as run job and free job now can run in parallel, can fix up if needed v3: - Include missing patch 'drm/sched: Add drm_sched_submit_* helpers' - Fix issue with setting timestamp to early - Don't dequeue jobs for single entity after calling entity fini - Flush pending jobs on entity fini - Add documentation for entity teardown - Add Matthew Brost to maintainers of DRM scheduler v4: - Drop message interface - Drop 'Flush pending jobs on entity fini' - Drop 'Add documentation for entity teardown' - Address all feedback v5: - Address Luben's feedback - Drop starting TDR after calling run_job() - Drop adding Matthew Brost to maintainers of DRM scheduler v6: - Address Luben's feedback - Include base commit v7: - Drop SINGLE_ENTITY mode rather pull in Luben's patch for dynamic run queues - Address Luben's feedback for free_job work item patch Matt [1] https://gitlab.freedesktop.org/drm/xe/kernel [2] https://patchwork.freedesktop.org/series/112188/ [3] https://patchwork.freedesktop.org/series/116055/ Luben Tuikov (1): drm/sched: Convert the GPU scheduler to variable number of run-queues Matthew Brost (5): drm/sched: Add drm_sched_wqueue_* helpers drm/sched: Convert drm scheduler to use a work queue rather than kthread drm/sched: Split free_job into own work item drm/sched: Add drm_sched_start_timeout_unlocked helper drm/sched: Add a helper to queue TDR immediately .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 15 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 15 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 +- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 1 + drivers/gpu/drm/lima/lima_sched.c | 3 +- drivers/gpu/drm/msm/adreno/adreno_device.c| 6 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 6 +- drivers/gpu/drm/nouveau/nouveau_sched.c | 3 +- drivers/gpu/drm/panfrost/panfrost_job.c | 1 + drivers/gpu/drm/scheduler/sched_entity.c | 18 +- drivers/gpu/drm/scheduler/sched_main.c| 444 -- drivers/gpu/drm/v3d/v3d_sched.c | 10 +- include/drm/gpu_scheduler.h | 29 +- 14 files changed, 373 insertions(+), 184 deletions(-) base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe -- 2.34.1
[pull] amdgpu drm-fixes-6.6
Hi Dave, Sima, One last fix for 6.6. The following changes since commit 05d3ef8bba77c1b5f98d941d8b2d4aeab8118ef1: Linux 6.6-rc7 (2023-10-22 12:11:21 -1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.6-2023-10-25 for you to fetch changes up to 64ffd2f1d00c6235dabe9704bbb0d9ce3e28147f: drm/amd: Disable ASPM for VI w/ all Intel systems (2023-10-25 09:53:17 -0400) amd-drm-fixes-6.6-2023-10-25: amdgpu: - Extend VI APSM quirks to more platforms Mario Limonciello (1): drm/amd: Disable ASPM for VI w/ all Intel systems drivers/gpu/drm/amd/amdgpu/vi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] drm/atomic-helper: Call stall_checks() before allocate drm_crtc_commit
From: Shixiong Ou
It is wrong to call stall_checks() after allocating memory
for struct drm_crtc_commit as it will cause memory leaks if
too many nonblock commit works return -EBUSY.
So it needs to call stall_checks() before allocate drm_crtc_commit.
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/drm_atomic_helper.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2444fc33dd7c..94ea878b240d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2283,6 +2283,10 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
funcs = state->dev->mode_config.helper_private;
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ ret = stall_checks(crtc, nonblock);
+ if (ret)
+ return ret;
+
commit = kzalloc(sizeof(*commit), GFP_KERNEL);
if (!commit)
return -ENOMEM;
@@ -2291,10 +2295,6 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
new_crtc_state->commit = commit;
- ret = stall_checks(crtc, nonblock);
- if (ret)
- return ret;
-
/*
* Drivers only send out events when at least either current or
* new CRTC state is active. Complete right away if everything
--
2.25.1
Re: [PATCH v2 10/11] drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize
[PATCH] vga_switcheroo: Fix impossible judgment condition
'id' is enum type like unsigned int, so it will never be less than zero.
Fixes: 4aaf448fa975 ("vga_switcheroo: set audio client id according to bound
GPU id")
Signed-off-by: Su Hui
---
drivers/gpu/vga/vga_switcheroo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 365e6ddbe90f..d3064466fd3a 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -375,7 +375,7 @@ int vga_switcheroo_register_audio_client(struct pci_dev
*pdev,
mutex_lock(_mutex);
if (vgasr_priv.active) {
id = vgasr_priv.handler->get_client_id(vga_dev);
- if (id < 0) {
+ if ((int)id < 0) {
mutex_unlock(_mutex);
return -EINVAL;
}
--
2.30.2
Re: [PATCH 1/1] drm/mediatek: Fix errors when reporting rotation capability
Re: [PATCH v5 5/6] soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE
On Thu, Oct 26, 2023 at 01:28:06AM +0300, Dmitry Baryshkov wrote: > Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the > same functionality for the DRM bridge chain termination. > Reviewed-by: Bjorn Andersson Acked-by: Bjorn Andersson Regards, Bjorn
Re: [PATCH 1/1] drm/mediatek: Add missing plane settings when async update
Re: [PATCH] drm/amd/display: add kernel docs for dc_stream_forward_crc_window
Hi Sagar,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.6-rc7 next-20231025]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Sagar-Vashnav/drm-amd-display-add-kernel-docs-for-dc_stream_forward_crc_window/20231026-001250
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231025140419.21180-1-sagarvashnav72427%40gmail.com
patch subject: [PATCH] drm/amd/display: add kernel docs for
dc_stream_forward_crc_window
config: csky-randconfig-002-20231026
(https://download.01.org/0day-ci/archive/20231026/202310260912.jfr01gde-...@intel.com/config)
compiler: csky-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231026/202310260912.jfr01gde-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202310260912.jfr01gde-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:536: warning: bad line:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:539: warning: bad line:
vim +536 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c
530
531 /**
532 * dc_stream_forward_crc_window() - Forward CRC window configuration to
DMUB or DMCU.
533 * @stream: The stream state to forward CRC window configuration for.
534 * @rect: Pointer to the rectangle defining the CRC window coordinates.
535 * @is_stop: Flag indicating whether the CRC capture should be stopped.
> 536
537 * This function is responsible for forwarding the CRC window
configuration
538 * for a given stream to either the DMUB or DMCU, depending on their
availability.
539
540 * Return:
541 * %true if the CRC window configuration was successfully forwarded;
542 * %false if the stream was not found or CRC forwarding is not
supported.
543 */
544 bool
545 dc_stream_forward_crc_window(struct dc_stream_state *stream,
546 struct rect *rect, bool is_stop)
547 {
548 struct dmcu *dmcu;
549 struct dc_dmub_srv *dmub_srv;
550 struct otg_phy_mux mux_mapping;
551 struct pipe_ctx *pipe;
552 int i;
553 struct dc *dc = stream->ctx->dc;
554
555 for (i = 0; i < MAX_PIPES; i++) {
556 pipe = >current_state->res_ctx.pipe_ctx[i];
557 if (pipe->stream == stream && !pipe->top_pipe &&
!pipe->prev_odm_pipe)
558 break;
559 }
560
561 /* Stream not found */
562 if (i == MAX_PIPES)
563 return false;
564
565 mux_mapping.phy_output_num = stream->link->link_enc_hw_inst;
566 mux_mapping.otg_output_num = pipe->stream_res.tg->inst;
567
568 dmcu = dc->res_pool->dmcu;
569 dmub_srv = dc->ctx->dmub_srv;
570
571 /* forward to dmub */
572 if (dmub_srv)
573 dc_stream_forward_dmub_crc_window(dmub_srv, rect,
_mapping, is_stop);
574 /* forward to dmcu */
575 else if (dmcu && dmcu->funcs->is_dmcu_initialized(dmcu))
576 dc_stream_forward_dmcu_crc_window(dmcu, rect,
_mapping, is_stop);
577 else
578 return false;
579
580 return true;
581 }
582 #endif /* CONFIG_DRM_AMD_SECURE_DISPLAY */
583
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
Hi, Jaak,
On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja wrote:
>
> On 25.10.23 16:23, Huacai Chen wrote:
> > On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > wrote:
> >>
> >> Javier, Dave, Sima,
> >>
> >> On 23.10.23 00:54, Evan Preston wrote:
> >>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> Leemhuis) wrote:
> > On 09.10.23 10:54, Huacai Chen wrote:
> >> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya
> >> wrote:
> >>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen
> wrote:
> > On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > Leemhuis) wrote:
> >> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>
> >>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated
> >>> Intel HD
> >>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a
> >>> blank
> >>> screen after boot until the display manager starts... if it does
> >>> start
> >>> at all. Using the nomodeset kernel parameter seems to be a
> >>> workaround.
> >>>
> >>> I've bisected this to commit
> >>> 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>> subsys_initcall_sync").
> >>
> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> again. So I guess the reason:
> >
> > Well, this to me still looks a lot (please correct me if I'm wrong) like
> > regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > if I understood things correctly. Or is there a proper fix for this
> > already in the works and I just missed this? Or is there some good
> > reason why this won't/can't be fixed?
>
> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> blank screen. Of course it is valuable to investigate further about
> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> I don't have a same machine.
> >>
> >> Side note: Huacai, have you tried working with Jaak to get down to the
> >> real problem? Evan, might you be able to help out here?
> > No, Jaak has no response after he 'fixed' his problem by disabling
> > SIMPLEDRM.
> >
>
> I'm sorry, what was it exactly you want me to do? Please be mindful that
> I'm not familiar with the internals of the Linux kernel and DRI, and it
> might sometimes take weeks before I have time to work and respond on this.
It doesn't matter. I hope you can do some experiments to investigate
deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
whether there is also a blank screen. If no blank screen, that
probably means SIMPLEDRM has a bug, if still blank screen, that means
the firmware may pass wrong screen information.
Huacai
>
> Jaak
>
> >>
> >> But I write this mail for a different reason:
> >>
> >>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>> screen after boot and a rapidly flashing device-access-status
> >>> indicator.
> >>
> >> This additional report makes me wonder if we should revert the culprit
> >> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >> might lead to regressions for some users? But the patch description says
> >> that this is not a common configuration, so can we maybe get away with
> >> that?
> > From my point of view, this is not a regression, 60aebc9559492c
> > doesn't cause a problem, but exposes a problem. So we need to fix the
> > real problem (SIMPLEDRM has a blank screen on some conditions). This
> > needs Jaak or Evan's help.
> >
> > Huacai
> >>
> >> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >> --
> >> Everything you wanna know about Linux kernel regression tracking:
> >> https://linux-regtracking.leemhuis.info/about/#tldr
> >> If I did something stupid, please tell me, as explained on that page.
> >>
> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware:
> Move
> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> no platform device created for SIMPLEDRM at early stage, so it seems
> also "no problem".
> >>> I don't understand above. You mean that after that commit the platform
> >>> device is also none, right?
> >> No. The
[PATCH v5 5/6] soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE
Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the
same functionality for the DRM bridge chain termination.
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 1 +
drivers/soc/qcom/pmic_glink_altmode.c | 33 ---
2 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index b3634e10f6f5..c954001ae79e 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -86,6 +86,7 @@ config QCOM_PMIC_GLINK
depends on OF
select AUXILIARY_BUS
select QCOM_PDR_HELPERS
+ select DRM_AUX_HPD_BRIDGE
help
The Qualcomm PMIC GLINK driver provides access, over GLINK, to the
USB and battery firmware running on one of the coprocessors in
diff --git a/drivers/soc/qcom/pmic_glink_altmode.c
b/drivers/soc/qcom/pmic_glink_altmode.c
index 6f8b2f7ae3cc..cb0db362447c 100644
--- a/drivers/soc/qcom/pmic_glink_altmode.c
+++ b/drivers/soc/qcom/pmic_glink_altmode.c
@@ -11,7 +11,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -76,7 +76,7 @@ struct pmic_glink_altmode_port {
struct work_struct work;
- struct drm_bridge bridge;
+ struct device *bridge;
enum typec_orientation orientation;
u16 svid;
@@ -230,10 +230,10 @@ static void pmic_glink_altmode_worker(struct work_struct
*work)
else
pmic_glink_altmode_enable_usb(altmode, alt_port);
- if (alt_port->hpd_state)
- drm_bridge_hpd_notify(_port->bridge,
connector_status_connected);
- else
- drm_bridge_hpd_notify(_port->bridge,
connector_status_disconnected);
+ drm_aux_hpd_bridge_notify(alt_port->bridge,
+ alt_port->hpd_state ?
+ connector_status_connected :
+ connector_status_disconnected);
pmic_glink_altmode_request(altmode, ALTMODE_PAN_ACK, alt_port->index);
};
@@ -365,16 +365,6 @@ static void pmic_glink_altmode_callback(const void *data,
size_t len, void *priv
}
}
-static int pmic_glink_altmode_attach(struct drm_bridge *bridge,
-enum drm_bridge_attach_flags flags)
-{
- return flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR ? 0 : -EINVAL;
-}
-
-static const struct drm_bridge_funcs pmic_glink_altmode_bridge_funcs = {
- .attach = pmic_glink_altmode_attach,
-};
-
static void pmic_glink_altmode_put_retimer(void *data)
{
typec_retimer_put(data);
@@ -464,15 +454,10 @@ static int pmic_glink_altmode_probe(struct
auxiliary_device *adev,
alt_port->index = port;
INIT_WORK(_port->work, pmic_glink_altmode_worker);
- alt_port->bridge.funcs = _glink_altmode_bridge_funcs;
- alt_port->bridge.of_node = to_of_node(fwnode);
- alt_port->bridge.ops = DRM_BRIDGE_OP_HPD;
- alt_port->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
-
- ret = devm_drm_bridge_add(dev, _port->bridge);
- if (ret) {
+ alt_port->bridge = drm_dp_hpd_bridge_register(dev,
to_of_node(fwnode));
+ if (IS_ERR(alt_port->bridge)) {
fwnode_handle_put(fwnode);
- return ret;
+ return PTR_ERR(alt_port->bridge);
}
alt_port->dp_alt.svid = USB_TYPEC_DP_SID;
--
2.42.0
[PATCH v5 6/6] usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE
Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the
same functionality for the DRM bridge chain termination.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/Kconfig| 1 +
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 41 +++
2 files changed, 7 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index 0b2993fef564..64d5421c69e6 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -80,6 +80,7 @@ config TYPEC_QCOM_PMIC
tristate "Qualcomm PMIC USB Type-C Port Controller Manager driver"
depends on ARCH_QCOM || COMPILE_TEST
depends on DRM || DRM=n
+ select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE
help
A Type-C port and Power Delivery driver which aggregates two
discrete pieces of silicon in the PM8150b PMIC block: the
diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
index 581199d37b49..1a2b4bddaa97 100644
--- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
+++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
@@ -18,7 +18,7 @@
#include
#include
-#include
+#include
#include "qcom_pmic_typec_pdphy.h"
#include "qcom_pmic_typec_port.h"
@@ -36,7 +36,6 @@ struct pmic_typec {
struct pmic_typec_port *pmic_typec_port;
boolvbus_enabled;
struct mutexlock; /* VBUS state serialization */
- struct drm_bridge bridge;
};
#define tcpc_to_tcpm(_tcpc_) container_of(_tcpc_, struct pmic_typec, tcpc)
@@ -150,35 +149,6 @@ static int qcom_pmic_typec_init(struct tcpc_dev *tcpc)
return 0;
}
-#if IS_ENABLED(CONFIG_DRM)
-static int qcom_pmic_typec_attach(struct drm_bridge *bridge,
-enum drm_bridge_attach_flags flags)
-{
- return flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR ? 0 : -EINVAL;
-}
-
-static const struct drm_bridge_funcs qcom_pmic_typec_bridge_funcs = {
- .attach = qcom_pmic_typec_attach,
-};
-
-static int qcom_pmic_typec_init_drm(struct pmic_typec *tcpm)
-{
- tcpm->bridge.funcs = _pmic_typec_bridge_funcs;
-#ifdef CONFIG_OF
- tcpm->bridge.of_node = of_get_child_by_name(tcpm->dev->of_node,
"connector");
-#endif
- tcpm->bridge.ops = DRM_BRIDGE_OP_HPD;
- tcpm->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
-
- return devm_drm_bridge_add(tcpm->dev, >bridge);
-}
-#else
-static int qcom_pmic_typec_init_drm(struct pmic_typec *tcpm)
-{
- return 0;
-}
-#endif
-
static int qcom_pmic_typec_probe(struct platform_device *pdev)
{
struct pmic_typec *tcpm;
@@ -186,6 +156,7 @@ static int qcom_pmic_typec_probe(struct platform_device
*pdev)
struct device_node *np = dev->of_node;
const struct pmic_typec_resources *res;
struct regmap *regmap;
+ struct device *bridge_dev;
u32 base[2];
int ret;
@@ -241,14 +212,14 @@ static int qcom_pmic_typec_probe(struct platform_device
*pdev)
mutex_init(>lock);
platform_set_drvdata(pdev, tcpm);
- ret = qcom_pmic_typec_init_drm(tcpm);
- if (ret)
- return ret;
-
tcpm->tcpc.fwnode = device_get_named_child_node(tcpm->dev, "connector");
if (!tcpm->tcpc.fwnode)
return -EINVAL;
+ bridge_dev = drm_dp_hpd_bridge_register(tcpm->dev,
to_of_node(tcpm->tcpc.fwnode));
+ if (IS_ERR(bridge_dev))
+ return PTR_ERR(bridge_dev);
+
tcpm->tcpm_port = tcpm_register_port(tcpm->dev, >tcpc);
if (IS_ERR(tcpm->tcpm_port)) {
ret = PTR_ERR(tcpm->tcpm_port);
--
2.42.0
[PATCH v5 2/6] phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE
Switch to using the new DRM_AUX_BRIDGE helper to create the
transparent DRM bridge device instead of handcoding corresponding
functionality.
Acked-by: Vinod Koul
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/Kconfig | 2 +-
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 ++-
2 files changed, 3 insertions(+), 43 deletions(-)
diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index d891058b7c39..846f8c99547f 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -63,7 +63,7 @@ config PHY_QCOM_QMP_COMBO
depends on DRM || DRM=n
select GENERIC_PHY
select MFD_SYSCON
- select DRM_PANEL_BRIDGE if DRM
+ select DRM_AUX_BRIDGE if DRM_BRIDGE
help
Enable this to support the QMP Combo PHY transceiver that is used
with USB3 and DisplayPort controllers on Qualcomm chips.
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 9c87845c78ec..f6c727249104 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -21,7 +21,7 @@
#include
#include
-#include
+#include
#include
@@ -1419,8 +1419,6 @@ struct qmp_combo {
struct clk_hw dp_link_hw;
struct clk_hw dp_pixel_hw;
- struct drm_bridge bridge;
-
struct typec_switch_dev *sw;
enum typec_orientation orientation;
};
@@ -3191,44 +3189,6 @@ static int qmp_combo_typec_switch_register(struct
qmp_combo *qmp)
}
#endif
-#if IS_ENABLED(CONFIG_DRM)
-static int qmp_combo_bridge_attach(struct drm_bridge *bridge,
- enum drm_bridge_attach_flags flags)
-{
- struct qmp_combo *qmp = container_of(bridge, struct qmp_combo, bridge);
- struct drm_bridge *next_bridge;
-
- if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
- return -EINVAL;
-
- next_bridge = devm_drm_of_get_bridge(qmp->dev, qmp->dev->of_node, 0, 0);
- if (IS_ERR(next_bridge)) {
- dev_err(qmp->dev, "failed to acquire drm_bridge: %pe\n",
next_bridge);
- return PTR_ERR(next_bridge);
- }
-
- return drm_bridge_attach(bridge->encoder, next_bridge, bridge,
-DRM_BRIDGE_ATTACH_NO_CONNECTOR);
-}
-
-static const struct drm_bridge_funcs qmp_combo_bridge_funcs = {
- .attach = qmp_combo_bridge_attach,
-};
-
-static int qmp_combo_dp_register_bridge(struct qmp_combo *qmp)
-{
- qmp->bridge.funcs = _combo_bridge_funcs;
- qmp->bridge.of_node = qmp->dev->of_node;
-
- return devm_drm_bridge_add(qmp->dev, >bridge);
-}
-#else
-static int qmp_combo_dp_register_bridge(struct qmp_combo *qmp)
-{
- return 0;
-}
-#endif
-
static int qmp_combo_parse_dt_lecacy_dp(struct qmp_combo *qmp, struct
device_node *np)
{
struct device *dev = qmp->dev;
@@ -3440,7 +3400,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = qmp_combo_dp_register_bridge(qmp);
+ ret = drm_aux_bridge_register(dev);
if (ret)
return ret;
--
2.42.0
[PATCH v5 4/6] drm/bridge: implement generic DP HPD bridge
Several USB-C controllers implement a pretty simple DRM bridge which
implements just the HPD notification operations. Add special helper
for creating such simple bridges.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/Kconfig | 8 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 164
include/drm/bridge/aux-bridge.h | 18 +++
4 files changed, 191 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/aux-hpd-bridge.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f12eab62799f..19d2dc05c397 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -21,6 +21,14 @@ config DRM_AUX_BRIDGE
Simple transparent bridge that is used by several non-DRM drivers to
build bridges chain.
+config DRM_AUX_HPD_BRIDGE
+ tristate
+ depends on DRM_BRIDGE && OF
+ select AUXILIARY_BUS
+ help
+ Simple bridge that terminates the bridge chain and provides HPD
+ support.
+
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 918e3bfff079..017b5832733b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_AUX_BRIDGE) += aux-bridge.o
+obj-$(CONFIG_DRM_AUX_HPD_BRIDGE) += aux-hpd-bridge.o
obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
new file mode 100644
index ..4defac8ec63f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Author: Dmitry Baryshkov
+ */
+#include
+#include
+#include
+
+#include
+#include
+
+static DEFINE_IDA(drm_aux_hpd_bridge_ida);
+
+struct drm_aux_hpd_bridge_data {
+ struct drm_bridge bridge;
+ struct device *dev;
+};
+
+static void drm_aux_hpd_bridge_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ ida_free(_aux_hpd_bridge_ida, adev->id);
+
+ of_node_put(adev->dev.platform_data);
+
+ kfree(adev);
+}
+
+static void drm_aux_hpd_bridge_unregister_adev(void *_adev)
+{
+ struct auxiliary_device *adev = _adev;
+
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+}
+
+/**
+ * drm_dp_hpd_bridge_register - Create a simple HPD DisplayPort bridge
+ * @parent: device instance providing this bridge
+ * @np: device node pointer corresponding to this bridge instance
+ *
+ * Creates a simple DRM bridge with the type set to
+ * DRM_MODE_CONNECTOR_DisplayPort, which terminates the bridge chain and is
+ * able to send the HPD events.
+ *
+ * Return: device instance that will handle created bridge or an error code
+ * encoded into the pointer.
+ */
+struct device *drm_dp_hpd_bridge_register(struct device *parent,
+ struct device_node *np)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc(sizeof(*adev), GFP_KERNEL);
+ if (!adev)
+ return ERR_PTR(-ENOMEM);
+
+ ret = ida_alloc(_aux_hpd_bridge_ida, GFP_KERNEL);
+ if (ret < 0) {
+ kfree(adev);
+ return ERR_PTR(ret);
+ }
+
+ adev->id = ret;
+ adev->name = "dp_hpd_bridge";
+ adev->dev.parent = parent;
+ adev->dev.of_node = parent->of_node;
+ adev->dev.release = drm_aux_hpd_bridge_release;
+ adev->dev.platform_data = np;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ ida_free(_aux_hpd_bridge_ida, adev->id);
+ kfree(adev);
+ return ERR_PTR(ret);
+ }
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ERR_PTR(ret);
+ }
+
+ ret = devm_add_action_or_reset(parent,
drm_aux_hpd_bridge_unregister_adev, adev);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return >dev;
+
+}
+EXPORT_SYMBOL_GPL(drm_dp_hpd_bridge_register);
+
+/**
+ * drm_aux_hpd_bridge_notify - notify hot plug detection events
+ * @dev: device created for the HPD bridge
+ * @status: output connection status
+ *
+ * A wrapper around drm_bridge_hpd_notify() that is used to report hot plug
+ * detection events for bridges created via drm_dp_hpd_bridge_register().
+ *
+ * This function shall be called in a context that can sleep.
+ */
+void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status
status)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+ struct
[PATCH v5 3/6] usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE
Switch to using the new DRM_AUX_BRIDGE helper to create the
transparent DRM bridge device instead of handcoding corresponding
functionality.
Reviewed-by: Heikki Krogerus
Acked-by: Greg Kroah-Hartman
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/mux/Kconfig | 2 +-
drivers/usb/typec/mux/nb7vpq904m.c | 44 ++
2 files changed, 3 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
index 65da61150ba7..07395161dd30 100644
--- a/drivers/usb/typec/mux/Kconfig
+++ b/drivers/usb/typec/mux/Kconfig
@@ -40,7 +40,7 @@ config TYPEC_MUX_NB7VPQ904M
tristate "On Semiconductor NB7VPQ904M Type-C redriver driver"
depends on I2C
depends on DRM || DRM=n
- select DRM_PANEL_BRIDGE if DRM
+ select DRM_AUX_BRIDGE if DRM_BRIDGE
select REGMAP_I2C
help
Say Y or M if your system has a On Semiconductor NB7VPQ904M Type-C
diff --git a/drivers/usb/typec/mux/nb7vpq904m.c
b/drivers/usb/typec/mux/nb7vpq904m.c
index cda206cf0c38..b17826713753 100644
--- a/drivers/usb/typec/mux/nb7vpq904m.c
+++ b/drivers/usb/typec/mux/nb7vpq904m.c
@@ -11,7 +11,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -70,8 +70,6 @@ struct nb7vpq904m {
bool swap_data_lanes;
struct typec_switch *typec_switch;
- struct drm_bridge bridge;
-
struct mutex lock; /* protect non-concurrent retimer & switch */
enum typec_orientation orientation;
@@ -297,44 +295,6 @@ static int nb7vpq904m_retimer_set(struct typec_retimer
*retimer, struct typec_re
return ret;
}
-#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DRM_PANEL_BRIDGE)
-static int nb7vpq904m_bridge_attach(struct drm_bridge *bridge,
- enum drm_bridge_attach_flags flags)
-{
- struct nb7vpq904m *nb7 = container_of(bridge, struct nb7vpq904m,
bridge);
- struct drm_bridge *next_bridge;
-
- if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
- return -EINVAL;
-
- next_bridge = devm_drm_of_get_bridge(>client->dev,
nb7->client->dev.of_node, 0, 0);
- if (IS_ERR(next_bridge)) {
- dev_err(>client->dev, "failed to acquire drm_bridge:
%pe\n", next_bridge);
- return PTR_ERR(next_bridge);
- }
-
- return drm_bridge_attach(bridge->encoder, next_bridge, bridge,
-DRM_BRIDGE_ATTACH_NO_CONNECTOR);
-}
-
-static const struct drm_bridge_funcs nb7vpq904m_bridge_funcs = {
- .attach = nb7vpq904m_bridge_attach,
-};
-
-static int nb7vpq904m_register_bridge(struct nb7vpq904m *nb7)
-{
- nb7->bridge.funcs = _bridge_funcs;
- nb7->bridge.of_node = nb7->client->dev.of_node;
-
- return devm_drm_bridge_add(>client->dev, >bridge);
-}
-#else
-static int nb7vpq904m_register_bridge(struct nb7vpq904m *nb7)
-{
- return 0;
-}
-#endif
-
static const struct regmap_config nb7_regmap = {
.max_register = 0x1f,
.reg_bits = 8,
@@ -461,7 +421,7 @@ static int nb7vpq904m_probe(struct i2c_client *client)
gpiod_set_value(nb7->enable_gpio, 1);
- ret = nb7vpq904m_register_bridge(nb7);
+ ret = drm_aux_bridge_register(dev);
if (ret)
goto err_disable_gpio;
--
2.42.0
[PATCH v5 1/6] drm/bridge: add transparent bridge helper
Define a helper for creating simple transparent bridges which serve the
only purpose of linking devices into the bridge chain up to the last
bridge representing the connector. This is especially useful for
DP/USB-C bridge chains, which can span across several devices, but do
not require any additional functionality from the intermediate bridges.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/Kconfig | 9 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/aux-bridge.c | 140
include/drm/bridge/aux-bridge.h | 19
4 files changed, 169 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c
create mode 100644 include/drm/bridge/aux-bridge.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ba82a1142adf..f12eab62799f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -12,6 +12,15 @@ config DRM_PANEL_BRIDGE
help
DRM bridge wrapper of DRM panels
+config DRM_AUX_BRIDGE
+ tristate
+ depends on DRM_BRIDGE && OF
+ select AUXILIARY_BUS
+ select DRM_PANEL_BRIDGE
+ help
+ Simple transparent bridge that is used by several non-DRM drivers to
+ build bridges chain.
+
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2b892b7ed59e..918e3bfff079 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DRM_AUX_BRIDGE) += aux-bridge.o
obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
diff --git a/drivers/gpu/drm/bridge/aux-bridge.c
b/drivers/gpu/drm/bridge/aux-bridge.c
new file mode 100644
index ..6245976b8fef
--- /dev/null
+++ b/drivers/gpu/drm/bridge/aux-bridge.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Author: Dmitry Baryshkov
+ */
+#include
+#include
+
+#include
+#include
+
+static DEFINE_IDA(drm_aux_bridge_ida);
+
+static void drm_aux_bridge_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ ida_free(_aux_bridge_ida, adev->id);
+
+ kfree(adev);
+}
+
+static void drm_aux_bridge_unregister_adev(void *_adev)
+{
+ struct auxiliary_device *adev = _adev;
+
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+}
+
+/**
+ * drm_aux_bridge_register - Create a simple bridge device to link the chain
+ * @parent: device instance providing this bridge
+ *
+ * Creates a simple DRM bridge that doesn't implement any drm_bridge
+ * operations. Such bridges merely fill a place in the bridge chain linking
+ * surrounding DRM bridges.
+ *
+ * Return: zero on success, negative error code on failure
+ */
+int drm_aux_bridge_register(struct device *parent)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc(sizeof(*adev), GFP_KERNEL);
+ if (!adev)
+ return -ENOMEM;
+
+ ret = ida_alloc(_aux_bridge_ida, GFP_KERNEL);
+ if (ret < 0) {
+ kfree(adev);
+ return ret;
+ }
+
+ adev->id = ret;
+ adev->name = "aux_bridge";
+ adev->dev.parent = parent;
+ adev->dev.of_node = parent->of_node;
+ adev->dev.release = drm_aux_bridge_release;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ ida_free(_aux_bridge_ida, adev->id);
+ kfree(adev);
+ return ret;
+ }
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ return devm_add_action_or_reset(parent, drm_aux_bridge_unregister_adev,
adev);
+}
+EXPORT_SYMBOL_GPL(drm_aux_bridge_register);
+
+struct drm_aux_bridge_data {
+ struct drm_bridge bridge;
+ struct drm_bridge *next_bridge;
+ struct device *dev;
+};
+
+static int drm_aux_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct drm_aux_bridge_data *data;
+
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
+ return -EINVAL;
+
+ data = container_of(bridge, struct drm_aux_bridge_data, bridge);
+
+ return drm_bridge_attach(bridge->encoder, data->next_bridge, bridge,
+DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static const struct drm_bridge_funcs drm_aux_bridge_funcs = {
+ .attach = drm_aux_bridge_attach,
+};
+
+static int drm_aux_bridge_probe(struct auxiliary_device *auxdev,
+ const struct auxiliary_device_id *id)
+{
+ struct drm_aux_bridge_data *data;
+
+ data =
[PATCH v5 0/6] drm: simplify support for transparent DRM bridges
Supporting DP/USB-C can result in a chain of several transparent bridges (PHY, redrivers, mux, etc). All attempts to implement DP support in a different way resulted either in series of hacks or in device tree not reflecting the actual hardware design. This results in drivers having similar boilerplate code for such bridges. Next, these drivers are susceptible to -EPROBE_DEFER loops: the next bridge can either be probed from the bridge->attach callback, when it is too late to return -EPROBE_DEFER, or from the probe() callback, when the next bridge might not yet be available, because it depends on the resources provided by the probing device. Device links can not fully solve this problem since there are mutual dependencies between adjancent devices. Last, but not least, this results in the the internal knowledge of DRM subsystem slowly diffusing into other subsystems, like PHY or USB/TYPEC. To solve all these issues, define a separate DRM helper, which creates separate aux device just for the bridge. During probe such aux device doesn't result in the EPROBE_DEFER loops. Instead it allows the device drivers to probe properly, according to the actual resource dependencies. The bridge auxdevs are then probed when the next bridge becomes available, sparing drivers from drm_bridge_attach() returning -EPROBE_DEFER. Changes since v4: - Added documentation for new API (Sima) - Added generic code to handle "last mile" DP bridges implementing just the HPD functionality. - Rebased on top of linux-next to be able to drop #ifdef's around drm_bridge->of_node Changes since v3: - Moved bridge driver to gpu/drm/bridge (Neil Armstrong) - Renamed it to aux-bridge (since there is already a simple_bridge driver) - Made CONFIG_OF mandatory for this driver (Neil Armstrong) - Added missing kfree and ida_free (Dan Carpenter) Changes since v2: - ifdef'ed bridge->of_node access (LKP) Changes since v1: - Added EXPORT_SYMBOL_GPL / MODULE_LICENSE / etc. to drm_simple_bridge Dmitry Baryshkov (6): drm/bridge: add transparent bridge helper phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE drm/bridge: implement generic DP HPD bridge soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE drivers/gpu/drm/bridge/Kconfig| 17 ++ drivers/gpu/drm/bridge/Makefile | 2 + drivers/gpu/drm/bridge/aux-bridge.c | 140 +++ drivers/gpu/drm/bridge/aux-hpd-bridge.c | 164 ++ drivers/phy/qualcomm/Kconfig | 2 +- drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 44 + drivers/soc/qcom/Kconfig | 1 + drivers/soc/qcom/pmic_glink_altmode.c | 33 +--- drivers/usb/typec/mux/Kconfig | 2 +- drivers/usb/typec/mux/nb7vpq904m.c| 44 + drivers/usb/typec/tcpm/Kconfig| 1 + drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 41 + include/drm/bridge/aux-bridge.h | 37 13 files changed, 383 insertions(+), 145 deletions(-) create mode 100644 drivers/gpu/drm/bridge/aux-bridge.c create mode 100644 drivers/gpu/drm/bridge/aux-hpd-bridge.c create mode 100644 include/drm/bridge/aux-bridge.h -- 2.42.0
Re: [PATCH v2 6/6] drm/vs: Add hdmi driver
On 25/10/2023 13:39, Keith Zhao wrote:
add hdmi driver as encoder and connect
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Kconfig | 8 +-
drivers/gpu/drm/verisilicon/Makefile| 1 +
drivers/gpu/drm/verisilicon/starfive_hdmi.c | 949
drivers/gpu/drm/verisilicon/starfive_hdmi.h | 295 ++
drivers/gpu/drm/verisilicon/vs_drv.c| 5 +
drivers/gpu/drm/verisilicon/vs_drv.h| 4 +
6 files changed, 1261 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c
create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h
diff --git a/drivers/gpu/drm/verisilicon/Kconfig
b/drivers/gpu/drm/verisilicon/Kconfig
index 3a361f8c8..122c786e3 100644
--- a/drivers/gpu/drm/verisilicon/Kconfig
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -12,4 +12,10 @@ config DRM_VERISILICON
setting and buffer management. It does not
provide 2D or 3D acceleration.
-
+config DRM_VERISILICON_STARFIVE_HDMI
+ bool "Starfive HDMI extensions"
+ depends on DRM_VERISILICON
+ help
+ This selects support for StarFive soc specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on JH7110 based soc, you should select this option.
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
index 1d48016ca..08350f25b 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -7,5 +7,6 @@ vs_drm-objs := vs_dc_hw.o \
vs_modeset.o \
vs_plane.o
+vs_drm-$(CONFIG_DRM_VERISILICON_STARFIVE_HDMI) += starfive_hdmi.o
obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
diff --git a/drivers/gpu/drm/verisilicon/starfive_hdmi.c b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
new file mode 100644
index 0..d296c4b71
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
@@ -0,0 +1,949 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 StarFive Technology Co., Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "starfive_hdmi.h"
+#include "vs_drv.h"
+#include "vs_crtc.h"
+
+static struct starfive_hdmi *encoder_to_hdmi(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct starfive_hdmi, encoder);
+}
+
+static struct starfive_hdmi *connector_to_hdmi(struct drm_connector *connector)
+{
+ return container_of(connector, struct starfive_hdmi, connector);
+}
+
+struct starfive_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+ /* protects the edid data when use i2c cmd to read edid */
+ struct mutex lock;
+ struct completion cmp;
+};
+
+static const struct pre_pll_config pre_pll_cfg_table[] = {
+ { 25175000, 25175000, 1, 100, 2, 3, 3, 12, 3, 3, 4, 0, 0xf5},
+ { 2520, 2520, 1, 100, 2, 3, 3, 12, 3, 3, 4, 0, 0},
+ { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
Such data structures are usually pretyt limited and hard to handle.
Could you please replace it with the runtime calculations of
+ { 27027000, 27027000, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0x170a3d},
+ { 2832, 2832, 1, 28, 2, 1, 1, 3, 0, 3, 4, 0, 0x51eb85},
+ { 3024, 3024, 1, 30, 2, 1, 1, 3, 0, 3, 4, 0, 0x3d70a3},
+ { 3150, 3150, 1, 31, 2, 1, 1, 3, 0, 3, 4, 0, 0x7f},
+ { 3375, 3375, 1, 33, 2, 1, 1, 3, 0, 3, 4, 0, 0xcf},
+ { 3600, 3600, 1, 36, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
+ { 4697, 4697, 1, 46, 2, 1, 1, 3, 0, 3, 4, 0, 0xf851eb},
+ { 4950, 4950, 1, 49, 2, 1, 1, 3, 0, 3, 4, 0, 0x7f},
+ { 4900, 4900, 1, 49, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 5000, 5000, 1, 50, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 5400, 5400, 1, 54, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 54054000, 54054000, 1, 54, 2, 1, 1, 3, 0, 3, 4, 0, 0x0dd2f1},
+ { 57284000, 57284000, 1, 57, 2, 1, 1, 3, 0, 3, 4, 0, 0x48b439},
+ { 5823, 5823, 1, 58, 2, 1, 1, 3, 0, 3, 4, 0, 0x3ae147},
+ { 59341000, 59341000, 1, 59, 2, 1, 1, 3, 0, 3, 4, 0, 0x574bc6},
+ { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
+ { 6500, 6500, 1, 130, 2, 2, 2, 12, 0, 2, 2, 0, 0},
+ { 6825, 6825, 1, 68, 2, 1, 1, 3, 0, 3, 4, 0, 0x3f},
+ { 7100, 7100, 1, 71, 2, 1, 1, 3, 0, 3, 4, 0, 0},
+ { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xe6ae6b},
+ { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
+ { 7500, 7500, 1, 75, 2, 1,
[PATCH] drm/rockchip: vop2: Add NV20 and NV30 support
Add support for the 10-bit 4:2:2 and 4:4:4 formats NV20 and NV30.
These formats can be tested using modetest [1]:
modetest -P @:1920x1080@
e.g. on a ROCK 3 Model A (rk3568):
modetest -P 43@67:1920x1080@NV20 -F tiles,tiles
modetest -P 43@67:1920x1080@NV30 -F smpte,smpte
[1] https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 5 +
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index ab944010fe14..592f9d726f2e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -326,11 +326,14 @@ static enum vop2_data_format vop2_convert_format(u32
format)
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV61:
return VOP2_FMT_YUV422SP;
+ case DRM_FORMAT_NV20:
case DRM_FORMAT_Y210:
return VOP2_FMT_YUV422SP_10;
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV42:
return VOP2_FMT_YUV444SP;
+ case DRM_FORMAT_NV30:
+ return VOP2_FMT_YUV444SP_10;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
return VOP2_FMT_VYUY422;
@@ -415,6 +418,8 @@ static bool vop2_win_uv_swap(u32 format)
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
return true;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index fdb48571efce..0b4280218a59 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -48,8 +48,10 @@ static const uint32_t formats_rk356x_esmart[] = {
DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
DRM_FORMAT_NV61, /* yuv422_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV20, /* yuv422_10bit linear mode, 2 plane, no padding */
DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
DRM_FORMAT_NV42, /* yuv444_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV30, /* yuv444_10bit linear mode, 2 plane, no padding */
DRM_FORMAT_YVYU, /* yuv422_8bit[YVYU] linear mode */
DRM_FORMAT_VYUY, /* yuv422_8bit[VYUY] linear mode */
};
--
2.42.0
Re: [PATCH v2 3/6] drm/fourcc: Add drm/vs tiled modifiers
Keith Zhao wrote:
> For each modifier, add the corresponding description
>
> Signed-off-by: Keith Zhao
> ---
> include/uapi/drm/drm_fourcc.h | 57 +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8db7fd3f7..a580a848c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -419,6 +419,7 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> +#define DRM_FORMAT_MOD_VENDOR_VERISILICON 0x0b
>
> /* add more to the end as needed */
>
> @@ -1562,6 +1563,62 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
> modifier)
> #define AMD_FMT_MOD_CLEAR(field) \
> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
>
> +#define DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL
> 0x00
> +#define DRM_FORMAT_MOD_VERISILICON_TYPE_MASK
> ((__u64)0x3 << 54)
> +
> +#define fourcc_mod_vs_code(type, val) \
> + fourcc_mod_code(VERISILICON, __u64)type) << 54) | (val)))
> +
> +#define DRM_FORMAT_MOD_VERISILICON_NORM_MODE_MASK
> 0x1F
> +
> +/*
> + * An x-major 8x8 super tile consists of 64 8x8 sub-tiles in total.
> + * Each 8x8 sub-tile consists of four standard tiles .
> + * standard tiles (see Vivante 4x4 tiling layout)
> + */
> +#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_XMAJOR_8X80x02
> +
> +/*
> + * A y-major 8x8 super tile consists of 64 8x8 sub-tiles in total.
> + * Each 8x8 sub-tile consists of four standard tiles .
> + * standard tiles (see Vivante 4x4 tiling layout)
> + */
> +#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_YMAJOR_8X80x03
> +
> +/*
> + * An 8x8 tile consists of four standard tiles
> + * that are organized in Z-order.
> + * standard tiles (see Vivante 4x4 tiling layout)
> + */
> +#define DRM_FORMAT_MOD_VERISILICON_TILE_8X8
> 0x04
> +
> +/*
> + * An 8x4 tile consists of two standard tiles
> + * that are organized in Z-order.
> + * standard tiles (see Vivante 4x4 tiling layout)
> + */
> +#define DRM_FORMAT_MOD_VERISILICON_TILE_8X4
> 0x07
> +
> +/*
> + * An x-major 8x4 super tile consists of 128 8x4 sub-tiles in total.
> + * Each 8x4 sub-tile consists of two standard tiles.
> + * two standard tiles also same with DRM_FORMAT_MOD_VS_TILE_8X4
> + * standard tiles (see Vivante 4x4 tiling layout)
> + */
> +#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_XMAJOR_8X40x0B
These indents are all over the place. Please either align them with tabs or use
a single space like the AMD defines above.
> +
> +/*
> + * A y-major 4x8 super tile consists of 128 4x8 sub-tiles in total.
> + * Each 4x8 sub-tile consists of two standard tiles.
> + * two standard tiles also same with DRM_FORMAT_MOD_VS_TILE_8X4
> + * standard tiles (see Vivante 4x4 tiling layout)
> + */
> +#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_YMAJOR_4X80x0C
> +
> +#define fourcc_mod_vs_norm_code(tile) \
> + fourcc_mod_vs_code(DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL, \
> + (tile))
> +
> #if defined(__cplusplus)
> }
> #endif
> --
> 2.34.1
>
Re: [PATCH v2 2/6] riscv: dts: starfive: jh7110: add dc controller and hdmi node
Keith Zhao wrote:
> Add the dc controller and hdmi node for the Starfive JH7110 SoC.
>
> Signed-off-by: Keith Zhao
> ---
> .../jh7110-starfive-visionfive-2.dtsi | 91 +++
> arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 +
> 2 files changed, 132 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> index de0f40a8b..97909b6d2 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> @@ -31,6 +31,25 @@ memory@4000 {
> reg = <0x0 0x4000 0x1 0x0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* vout applies for space from this CMA
> + * Without this CMA reservation,
> + * vout may not work properly.
> + */
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0x0 0x2000>;
> + alignment = <0x0 0x1000>;
> + alloc-ranges = <0x0 0x7000 0x0 0x2000>;
> + linux,cma-default;
> + };
> + };
> +
> gpio-restart {
> compatible = "gpio-restart";
> gpios = < 35 GPIO_ACTIVE_HIGH>;
> @@ -231,6 +250,41 @@ GPOEN_DISABLE,
> slew-rate = <0>;
> };
> };
> +
> + hdmi_pins: hdmi-0 {
> + hdmi-scl-pins {
> + pinmux = + GPOEN_SYS_HDMI_DDC_SCL,
> + GPI_SYS_HDMI_DDC_SCL)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-sda-pins {
> + pinmux = + GPOEN_SYS_HDMI_DDC_SDA,
> + GPI_SYS_HDMI_DDC_SDA)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-cec-pins {
> + pinmux = + GPOEN_SYS_HDMI_CEC_SDA,
> + GPI_SYS_HDMI_CEC_SDA)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-hpd-pins {
> + pinmux = + GPOEN_ENABLE,
> + GPI_SYS_HDMI_HPD)>;
> + input-enable;
> + bias-disable; /* external pull-up */
> + };
> + };
> +
Please don't break the alphabetical ordering of these nodes.
> };
>
> {
> @@ -254,3 +308,40 @@ _3 {
> _4 {
> cpu-supply = <_cpu>;
> };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + hdmi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hdmi_in_dc: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_out_hdmi>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + dc_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dc_out_hdmi: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_in_dc>;
> + };
> +
> + };
> +};
Some goes for these node references. The order is /-node, clocks, node refences
sorted alphabetically.
> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi
> b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> index 0005fa163..1670452fb 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> @@ -282,6 +282,11 @@ tdm_ext: tdm-ext-clock {
> #clock-cells = <0>;
> };
>
> + display: display-subsystem {
> + compatible = "starfive,display-subsystem";
> + ports = <_out>;
> + };
> +
> soc {
> compatible = "simple-bus";
> interrupt-parent = <>;
> @@ -613,5 +618,41 @@ voutcrg: clock-controller@295c {
> #reset-cells = <1>;
> power-domains = < JH7110_PD_VOUT>;
> };
> +
> + dc8200: lcd-controller@2940 {
> + compatible = "starfive,jh7110-dc8200";
> + reg = <0x0 0x2940 0x0 0x100>,
> + <0x0 0x29400800 0x0 0x2000>;
> + interrupts = <95>;
> + clocks = < JH7110_SYSCLK_NOC_BUS_DISP_AXI>,
> +
Re: [PATCH] drm: panel: simple: specify bpc for powertip_ph800480t013_idf02
+Cc: stable
The commit misses the Fixes tag.
On Mon, Jul 31, 2023 at 02:47:47PM +0200, Neil Armstrong wrote:
> On 27/07/2023 19:24, Dmitry Baryshkov wrote:
> > Specify bpc value for the powertip_ph800480t013_idf02 panel to stop drm
> > code from complaining about unexpected bpc value (0).
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index a247a0e7c799..4c4c24ab4d12 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -3207,6 +3207,7 @@ static const struct drm_display_mode
> > powertip_ph800480t013_idf02_mode = {
> > static const struct panel_desc powertip_ph800480t013_idf02 = {
> > .modes = _ph800480t013_idf02_mode,
> > .num_modes = 1,
> > + .bpc = 8,
> > .size = {
> > .width = 152,
> > .height = 91,
>
> Reviewed-by: Neil Armstrong
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
On 25.10.23 16:23, Huacai Chen wrote:
On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
wrote:
Javier, Dave, Sima,
On 23.10.23 00:54, Evan Preston wrote:
On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
Leemhuis) wrote:
On 09.10.23 10:54, Huacai Chen wrote:
On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya wrote:
On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen wrote:
On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
Leemhuis) wrote:
On 13.09.23 14:02, Jaak Ristioja wrote:
Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
screen after boot until the display manager starts... if it does start
at all. Using the nomodeset kernel parameter seems to be a workaround.
I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
("drivers/firmware: Move sysfb_init() from device_initcall to
subsys_initcall_sync").
As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
again. So I guess the reason:
Well, this to me still looks a lot (please correct me if I'm wrong) like
regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
if I understood things correctly. Or is there a proper fix for this
already in the works and I just missed this? Or is there some good
reason why this won't/can't be fixed?
DRM_SIMPLEDRM was enabled but it didn't work at all because there was
no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
blank screen. Of course it is valuable to investigate further about
DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
I don't have a same machine.
Side note: Huacai, have you tried working with Jaak to get down to the
real problem? Evan, might you be able to help out here?
No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
I'm sorry, what was it exactly you want me to do? Please be mindful that
I'm not familiar with the internals of the Linux kernel and DRI, and it
might sometimes take weeks before I have time to work and respond on this.
Jaak
But I write this mail for a different reason:
I am having the same issue on a Lenovo Thinkpad P70 (Intel
Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
screen after boot and a rapidly flashing device-access-status
indicator.
This additional report makes me wonder if we should revert the culprit
(60aebc9559492c ("drivers/firmware: Move sysfb_init() from
device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
might lead to regressions for some users? But the patch description says
that this is not a common configuration, so can we maybe get away with that?
From my point of view, this is not a regression, 60aebc9559492c
doesn't cause a problem, but exposes a problem. So we need to fix the
real problem (SIMPLEDRM has a blank screen on some conditions). This
needs Jaak or Evan's help.
Huacai
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
sysfb_init() from device_initcall to subsys_initcall_sync") there is
no platform device created for SIMPLEDRM at early stage, so it seems
also "no problem".
I don't understand above. You mean that after that commit the platform
device is also none, right?
No. The SIMPLEDRM driver needs a platform device to work, and that
commit makes the platform device created earlier. So, before that
commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
commit, SIMPLEDRM works, but the screen is blank.
Huacai
Confused...
--
An old man doll... just what I always wanted! - Clara
Re: [PATCH v2 4/6] drm/vs: Register DRM device
Keith Zhao wrote:
> Implement drm device registration interface
>
> Thomas Zimmermann wrote:
> You are replacing almost all of the GEM DMA object's helper code.
> Either inherit directly from drm_gem_object drop the dependency entirely,
> or you could try to fit your code into GEM DMA as well
>
> Eventually I found an answer and it was
> DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE
> After I adapt this interface, the custom gem logic interfaces can be deleted.
> It's a big shocking, clap!
>
> Signed-off-by: Keith Zhao
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/verisilicon/Kconfig | 15 ++
> drivers/gpu/drm/verisilicon/Makefile | 7 +
> drivers/gpu/drm/verisilicon/vs_drv.c | 227 +++
> drivers/gpu/drm/verisilicon/vs_drv.h | 27 +++
> drivers/gpu/drm/verisilicon/vs_modeset.c | 36
> drivers/gpu/drm/verisilicon/vs_modeset.h | 10 +
> include/uapi/drm/vs_drm.h| 50 +
> 9 files changed, 375 insertions(+)
> create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
> create mode 100644 drivers/gpu/drm/verisilicon/Makefile
> create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
> create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
> create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c
> create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h
> create mode 100644 include/uapi/drm/vs_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index afb3b2f5f..9ede80ef9 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -363,6 +363,8 @@ source "drivers/gpu/drm/solomon/Kconfig"
>
> source "drivers/gpu/drm/sprd/Kconfig"
>
> +source "drivers/gpu/drm/verisilicon/Kconfig"
> +
> config DRM_HYPERV
> tristate "DRM Support for Hyper-V synthetic video device"
> depends on DRM && PCI && MMU && HYPERV
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 7a09a89b4..6db3bc397 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -194,3 +194,4 @@ obj-y += gud/
> obj-$(CONFIG_DRM_HYPERV) += hyperv/
> obj-y+= solomon/
> obj-$(CONFIG_DRM_SPRD) += sprd/
> +obj-$(CONFIG_DRM_VERISILICON) += verisilicon/
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig
> b/drivers/gpu/drm/verisilicon/Kconfig
> new file mode 100644
> index 0..3a361f8c8
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config DRM_VERISILICON
> + tristate "DRM Support for VeriSilicon"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_GEM_DMA_HELPER
> + select CMA
> + select DMA_CMA
> + help
> + Choose this option if you have a VeriSilicon soc chipset.
> + This driver provides VeriSilicon kernel mode
> + setting and buffer management. It does not
> + provide 2D or 3D acceleration.
> +
> +
> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> b/drivers/gpu/drm/verisilicon/Makefile
> new file mode 100644
> index 0..7d3be305b
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +vs_drm-objs := vs_drv.o \
> + vs_modeset.o
> +
> +obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> +
Git complains about trailing whitespace and trailing newlines in this patch.
Here one of the instances.
> diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c
> b/drivers/gpu/drm/verisilicon/vs_drv.c
> new file mode 100644
> index 0..da7698c3d
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_drv.c
> @@ -0,0 +1,227 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "vs_drv.h"
> +#include "vs_modeset.h"
> +
> +#define DRV_NAME "verisilicon"
> +#define DRV_DESC "Verisilicon DRM driver"
> +#define DRV_DATE "20230516"
> +#define DRV_MAJOR1
> +#define DRV_MINOR0
> +
> +static int vs_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
> + struct drm_mode_create_dumb *args)
> +{
> + struct vs_drm_device *priv = to_vs_drm_private(dev);
> +
> + unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> +
> + if (args->bpp % 10)
> + args->pitch = ALIGN(pitch, priv->pitch_alignment);
> + else
> + /* for costum 10bit format with no bit gaps */
> + args->pitch = pitch;
> +
> + return drm_gem_dma_dumb_create_internal(file, dev, args);
> +}
> +
> +DEFINE_DRM_GEM_FOPS(vs_drm_fops);
> +
> +static struct drm_driver vs_drm_driver = {
> + .driver_features= DRIVER_MODESET |
Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
Thank you Harry and all other contributors for your work on this. Responses
inline -
On Mon, 23 Oct 2023, Pekka Paalanen wrote:
> On Fri, 20 Oct 2023 11:23:28 -0400
> Harry Wentland wrote:
>
> > On 2023-10-20 10:57, Pekka Paalanen wrote:
> > > On Fri, 20 Oct 2023 16:22:56 +0200
> > > Sebastian Wick wrote:
> > >
> > >> Thanks for continuing to work on this!
> > >>
> > >> On Thu, Oct 19, 2023 at 05:21:22PM -0400, Harry Wentland wrote:
> > >>> v2:
> > >>> - Update colorop visualizations to match reality (Sebastian, Alex Hung)
> > >>> - Updated wording (Pekka)
> > >>> - Change BYPASS wording to make it non-mandatory (Sebastian)
> > >>> - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
> > >>>section (Pekka)
> > >>> - Use PQ EOTF instead of its inverse in Pipeline Programming example
> > >>> (Melissa)
> > >>> - Add "Driver Implementer's Guide" section (Pekka)
> > >>> - Add "Driver Forward/Backward Compatibility" section (Sebastian,
> > >>> Pekka)
> > >
> > > ...
> > >
> > >>> +An example of a drm_colorop object might look like one of these::
> > >>> +
> > >>> +/* 1D enumerated curve */
> > >>> +Color operation 42
> > >>> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3
> > >>> matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve
> > >>> +├─ "BYPASS": bool {true, false}
> > >>> +├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ EOTF,
> > >>> PQ inverse EOTF, …}
> > >>> +└─ "NEXT": immutable color operation ID = 43
I know these are just examples, but I would also like to suggest the possibility
of an "identity" CURVE_1D_TYPE. BYPASS = true might get different results
compared to setting an identity in some cases depending on the hardware. See
below for more on this, RE: implicit format conversions.
Although NVIDIA hardware doesn't use a ROM for enumerated curves, it came up in
offline discussions that it would nonetheless be helpful to expose enumerated
curves in order to hide the vendor-specific complexities of programming
segmented LUTs from clients. In that case, we would simply refer to the
enumerated curve when calculating/choosing segmented LUT entries.
Another thing that came up in offline discussions is that we could use multiple
color operations to program a single operation in hardware. As I understand it,
AMD has a ROM-defined LUT, followed by a custom 4K entry LUT, followed by an
"HDR Multiplier". On NVIDIA we don't have these as separate hardware stages, but
we could combine them into a singular LUT in software, such that you can combine
e.g. segmented PQ EOTF with night light. One caveat is that you will lose
precision from the custom LUT where it overlaps with the linear section of the
enumerated curve, but that is unavoidable and shouldn't be an issue in most
use-cases.
Actually, the current examples in the proposal don't include a multiplier color
op, which might be useful. For AMD as above, but also for NVIDIA as the
following issue arises:
As discussed further below, the NVIDIA "degamma" LUT performs an implicit fixed
point to FP16 conversion. In that conversion, what fixed point 0x maps
to in floating point varies depending on the source content. If it's SDR
content, we want the max value in FP16 to be 1.0 (80 nits), subject to a
potential boost multiplier if we want SDR content to be brighter. If it's HDR PQ
content, we want the max value in FP16 to be 125.0 (10,000 nits). My assumption
is that this is also what AMD's "HDR Multiplier" stage is used for, is that
correct?
>From the given enumerated curves, it's not clear how they would map to the
above. Should sRGB EOTF have a max FP16 value of 1.0, and the PQ EOTF a max FP16
value of 125.0? That may work, but it tends towards the "descriptive" notion of
assuming the source content, which may not be accurate in all cases. This is
also an issue for the custom 1D LUT, as the blob will need to be converted to
FP16 in order to populate our "degamma" LUT. What should the resulting max FP16
value be, given that we no longer have any hint as to the source content?
I think a multiplier color op solves all of these issues. Named curves and
custom 1D LUTs would by default assume a max FP16 value of 1.0, which would then
be adjusted by the multiplier. For 80 nit SDR content, set it to 1, for 400
nit SDR content, set it to 5, for HDR PQ content, set it to 125, etc.
> > >>> +
> > >>> +/* custom 4k entry 1D LUT */
> > >>> +Color operation 52
> > >>> +├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3
> > >>> matrix, 3x4 matrix, 3D LUT, etc.} = 1D LUT
> > >>> +├─ "BYPASS": bool {true, false}
> > >>> +├─ "LUT_1D_SIZE": immutable range = 4096
> > >>> +├─ "LUT_1D": blob
> > >>> +└─ "NEXT": immutable color operation ID = 0
> > >
> > > ...
> > >
> > >>> +Driver Forward/Backward Compatibility
> > >>> +=
> > >>> +
> > >>> +As this is uAPI drivers can't regress color pipelines that
Re: [PATCH v2 5/6] drm/vs: Add KMS crtc
On Wed, Oct 25, 2023 at 10:28:56PM +0300, Dmitry Baryshkov wrote:
> On 25/10/2023 13:39, Keith Zhao wrote:
> > add 2 crtcs and 8 planes in vs-drm
> >
> > Signed-off-by: Keith Zhao
> > ---
> > drivers/gpu/drm/verisilicon/Makefile |8 +-
> > drivers/gpu/drm/verisilicon/vs_crtc.c | 257
> > drivers/gpu/drm/verisilicon/vs_crtc.h | 43 +
> > drivers/gpu/drm/verisilicon/vs_dc.c| 1002
> > drivers/gpu/drm/verisilicon/vs_dc.h| 80 +
> > drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959
> > drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 ++
> > drivers/gpu/drm/verisilicon/vs_drv.c |2 +
> > drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++
> > drivers/gpu/drm/verisilicon/vs_plane.h | 58 +
> > drivers/gpu/drm/verisilicon/vs_type.h | 69 +
> > 11 files changed, 4494 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h
> > create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h
> >
> > diff --git a/drivers/gpu/drm/verisilicon/Makefile
> > b/drivers/gpu/drm/verisilicon/Makefile
> > index 7d3be305b..1d48016ca 100644
> > --- a/drivers/gpu/drm/verisilicon/Makefile
> > +++ b/drivers/gpu/drm/verisilicon/Makefile
> > @@ -1,7 +1,11 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > -vs_drm-objs := vs_drv.o \
> > - vs_modeset.o
> > +vs_drm-objs := vs_dc_hw.o \
> > + vs_dc.o \
> > + vs_crtc.o \
> > + vs_drv.o \
> > + vs_modeset.o \
> > + vs_plane.o
> >
> > obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> >
> > diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
> > b/drivers/gpu/drm/verisilicon/vs_crtc.c
> > new file mode 100644
> > index 0..8a658ea77
> > --- /dev/null
> > +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
> > @@ -0,0 +1,257 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "vs_crtc.h"
> > +#include "vs_dc.h"
> > +#include "vs_drv.h"
> > +
> > +static void vs_crtc_reset(struct drm_crtc *crtc)
> > +{
> > + struct vs_crtc_state *state;
> > +
> > + if (crtc->state) {
> > + __drm_atomic_helper_crtc_destroy_state(crtc->state);
> > +
> > + state = to_vs_crtc_state(crtc->state);
> > + kfree(state);
> > + crtc->state = NULL;
> > + }
>
> You can call your crtc_destroy_state function directly here.
>
> > +
> > + state = kzalloc(sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return;
> > +
> > + __drm_atomic_helper_crtc_reset(crtc, >base);
> > +}
> > +
> > +static struct drm_crtc_state *
> > +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> > +{
> > + struct vs_crtc_state *ori_state;
>
> It might be a matter of taste, but it is usually old_state.
>
> > + struct vs_crtc_state *state;
> > +
> > + if (!crtc->state)
> > + return NULL;
> > +
> > + ori_state = to_vs_crtc_state(crtc->state);
> > + state = kzalloc(sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return NULL;
> > +
> > + __drm_atomic_helper_crtc_duplicate_state(crtc, >base);
> > +
> > + state->output_fmt = ori_state->output_fmt;
> > + state->encoder_type = ori_state->encoder_type;
> > + state->bpp = ori_state->bpp;
> > + state->underflow = ori_state->underflow;
>
> Can you use kmemdup instead?
>
> > +
> > + return >base;
> > +}
> > +
> > +static void vs_crtc_atomic_destroy_state(struct drm_crtc *crtc,
> > +struct drm_crtc_state *state)
> > +{
> > + __drm_atomic_helper_crtc_destroy_state(state);
> > + kfree(to_vs_crtc_state(state));
> > +}
> > +
> > +static int vs_crtc_enable_vblank(struct drm_crtc *crtc)
> > +{
> > + struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
> > + struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
> > +
> > + vs_dc_enable_vblank(dc, true);
> > +
> > + return 0;
> > +}
> > +
> > +static void vs_crtc_disable_vblank(struct drm_crtc *crtc)
> > +{
> > + struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
> > + struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
> > +
> > + vs_dc_enable_vblank(dc, false);
> > +}
> > +
> > +static const struct drm_crtc_funcs vs_crtc_funcs = {
> > + .set_config = drm_atomic_helper_set_config,
> > + .page_flip = drm_atomic_helper_page_flip,
>
>
Re: [PATCH v2 5/6] drm/vs: Add KMS crtc
On 25/10/2023 13:39, Keith Zhao wrote:
add 2 crtcs and 8 planes in vs-drm
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Makefile |8 +-
drivers/gpu/drm/verisilicon/vs_crtc.c | 257
drivers/gpu/drm/verisilicon/vs_crtc.h | 43 +
drivers/gpu/drm/verisilicon/vs_dc.c| 1002
drivers/gpu/drm/verisilicon/vs_dc.h| 80 +
drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959
drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 ++
drivers/gpu/drm/verisilicon/vs_drv.c |2 +
drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++
drivers/gpu/drm/verisilicon/vs_plane.h | 58 +
drivers/gpu/drm/verisilicon/vs_type.h | 69 +
11 files changed, 4494 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
index 7d3be305b..1d48016ca 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,7 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
-vs_drm-objs := vs_drv.o \
- vs_modeset.o
+vs_drm-objs := vs_dc_hw.o \
+ vs_dc.o \
+ vs_crtc.o \
+ vs_drv.o \
+ vs_modeset.o \
+ vs_plane.o
obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c b/drivers/gpu/drm/verisilicon/vs_crtc.c
new file mode 100644
index 0..8a658ea77
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_crtc.h"
+#include "vs_dc.h"
+#include "vs_drv.h"
+
+static void vs_crtc_reset(struct drm_crtc *crtc)
+{
+ struct vs_crtc_state *state;
+
+ if (crtc->state) {
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
+
+ state = to_vs_crtc_state(crtc->state);
+ kfree(state);
+ crtc->state = NULL;
+ }
You can call your crtc_destroy_state function directly here.
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return;
+
+ __drm_atomic_helper_crtc_reset(crtc, >base);
+}
+
+static struct drm_crtc_state *
+vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
+{
+ struct vs_crtc_state *ori_state;
It might be a matter of taste, but it is usually old_state.
+ struct vs_crtc_state *state;
+
+ if (!crtc->state)
+ return NULL;
+
+ ori_state = to_vs_crtc_state(crtc->state);
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, >base);
+
+ state->output_fmt = ori_state->output_fmt;
+ state->encoder_type = ori_state->encoder_type;
+ state->bpp = ori_state->bpp;
+ state->underflow = ori_state->underflow;
Can you use kmemdup instead?
+
+ return >base;
+}
+
+static void vs_crtc_atomic_destroy_state(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ __drm_atomic_helper_crtc_destroy_state(state);
+ kfree(to_vs_crtc_state(state));
+}
+
+static int vs_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+ struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
+ struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
+
+ vs_dc_enable_vblank(dc, true);
+
+ return 0;
+}
+
+static void vs_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+ struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
+ struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
+
+ vs_dc_enable_vblank(dc, false);
+}
+
+static const struct drm_crtc_funcs vs_crtc_funcs = {
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
destroy is required, see drm_mode_config_cleanup()
+ .reset = vs_crtc_reset,
+ .atomic_duplicate_state = vs_crtc_atomic_duplicate_state,
+ .atomic_destroy_state = vs_crtc_atomic_destroy_state,
please consider adding atomic_print_state to output driver-specific bits.
+ .enable_vblank = vs_crtc_enable_vblank,
+ .disable_vblank = vs_crtc_disable_vblank,
+};
+
+static u8 cal_pixel_bits(u32 bus_format)
This looks
Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023
On Tue, Oct 24, 2023 at 05:47:37PM +0200, Heiko Stübner wrote: > Hi Chris, > > Am Freitag, 20. Oktober 2023, 17:03:08 CEST schrieb Chris Morgan: > > On Thu, Oct 19, 2023 at 07:45:17PM +0200, Heiko Stübner wrote: > > > Hey Chris, > > > > > > Am Donnerstag, 19. Oktober 2023, 16:43:56 CEST schrieb Chris Morgan: > > > > On Thu, Oct 19, 2023 at 11:21:47AM +0200, Krzysztof Kozlowski wrote: > > > > > On 18/10/2023 18:18, Chris Morgan wrote: > > > > > > From: Chris Morgan > > > > > > > > > > > > The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and > > > > > > powered by the Rockchip RK3566 SoC. > > > > > > > > > > > > Signed-off-by: Chris Morgan > > > > > > --- > > > > > > Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml > > > > > > b/Documentation/devicetree/bindings/arm/rockchip.yaml > > > > > > index a349bf4da6bc..a6612185a7ff 100644 > > > > > > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml > > > > > > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > > > > > > @@ -674,6 +674,11 @@ properties: > > > > > >- const: powkiddy,rgb30 > > > > > >- const: rockchip,rk3566 > > > > > > > > > > > > + - description: Powkiddy RK2023 > > > > > > +items: > > > > > > + - const: powkiddy,rk2023 > > > > > > > > > > This cuold be just enum in previous entry :/ but I remember we talked > > > > > about this once with Heiko. > > > > > > > > For hardware that requires a different device tree, is that possible? > > > > While most of the devices I've worked on for the RK3566 series are very > > > > similar for the moment only 1 is identical (the RG353P and the RG353M) > > > > and can use the same device tree. > > > > > > In my reply I pointed to the Rock PI 4A/4A+/B/B+/C family, which also has > > > different devicetrees but is part of the same family of device designs. > > > > > > So similar Powkiddy RK3568 based gaming handhelds also sound like > > > a nice family name in the description ;-) . > > > > Gotcha, I can do that. Would you like for me to go back and do the same > > for the Anbernic devices as well? I can do it as part of a seperate > > patch series. > > that doing that for the Anberic devices would be really nice too, so > yes please :-) . > > Thanks > Heiko > > Did you want me to resubmit the series or just push the changes on top of this one? I'll get them both queued up. Thank you.
Re: [PATCH v6 4/7] drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy
Hi Matt,
On 2023-10-25 11:13, Matthew Brost wrote:
> On Mon, Oct 23, 2023 at 11:50:26PM -0400, Luben Tuikov wrote:
>> Hi,
>>
>> On 2023-10-17 11:09, Matthew Brost wrote:
>>> DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
>>> scheduler and entity. No priorities or run queue used in this mode.
>>> Intended for devices with firmware schedulers.
>>>
>>> v2:
>>> - Drop sched / rq union (Luben)
>>> v3:
>>> - Don't pick entity if stopped in drm_sched_select_entity (Danilo)
>>> v4:
>>> - Rework if statement in drm_sched_entity_init (Luben)
>>> - Update comment for drm_sched_entity_to_scheduler (Luben)
>>> - Reword a few things in DOC comment (Luben)
>>> - Do not check sched policy in for statement (Luben)
>>> v5:
>>> - Fix extra blank lines (Luben / Checkpatch)
>>>
>>> Signed-off-by: Matthew Brost
>>> ---
>>> drivers/gpu/drm/scheduler/sched_entity.c | 69 +++
>>> drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
>>> drivers/gpu/drm/scheduler/sched_main.c | 87 ++--
>>> include/drm/gpu_scheduler.h | 8 +++
>>> 4 files changed, 130 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
>>> b/drivers/gpu/drm/scheduler/sched_entity.c
>>> index cf42e2265d64..940f63dd6965 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>>> @@ -83,6 +83,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
>>> memset(entity, 0, sizeof(struct drm_sched_entity));
>>> INIT_LIST_HEAD(>list);
>>> entity->rq = NULL;
>>> + entity->single_sched = NULL;
>>> entity->guilty = guilty;
>>> entity->num_sched_list = num_sched_list;
>>> entity->priority = priority;
>>> @@ -90,8 +91,17 @@ int drm_sched_entity_init(struct drm_sched_entity
>>> *entity,
>>> RCU_INIT_POINTER(entity->last_scheduled, NULL);
>>> RB_CLEAR_NODE(>rb_tree_node);
>>>
>>> - if(num_sched_list)
>>> - entity->rq = _list[0]->sched_rq[entity->priority];
>>> + if (num_sched_list) {
>>> + if (sched_list[0]->sched_policy !=
>>> + DRM_SCHED_POLICY_SINGLE_ENTITY) {
>>> + entity->rq = _list[0]->sched_rq[entity->priority];
>>> + } else if (num_sched_list == 1 &&
>>> !sched_list[0]->single_entity) {
>>> + sched_list[0]->single_entity = entity;
>>> + entity->single_sched = sched_list[0];
>>
>> To simplify the rest of the GPU scheduler design and generalize the logic,
>> we can do
>> entity->rq = sched_list[0]->sched_rq[entity->priority];
>> where the "priority" is 0, thus having a single rq.
>>
>> We shouldn't splice scheduler and entity, but rather make it so that
>> we can set the number of rqs to 1, thus resulting in a single rq.
>>
>> (https://lore.kernel.org/r/20231023032251.164775-1-luben.tui...@amd.com)
>>
>
> I pulled out this patch [1] + previous one [2] and included your [3] to
> test this in Xe [4].
>
> It seems to work with just one rq per scheduler. We can go with this
> approach in feel like this is the route. My next post will include your
> patch [3] if we agree.
Yeah, this is good. Thanks!
I feel that the sched_rq[] static array should've been a dynamic one
from the outset--one of the hallmarks of a flexible scheduler. Then
let each driver announce how many priorities they care about. A scheduler
shouldn't be as rigid as to force drivers to care and/or support so and
so many run-queues (priorities).
For a good code design, we want to allow for more driver implementations
with minimal (or no) DRM changes--all accommodated by drm_sched_init(), yet,
accommodating a varied behaviour, and having the sched_rq be dynamic and let
each driver announce how many run-queues it wants is the minimal change we
can do now (and easiest), with best outcome for Xe and new drivers.
Regards,
Luben
>
> Matt
>
> [1] https://patchwork.freedesktop.org/patch/563094/?series=121745=8
> [2] https://patchwork.freedesktop.org/patch/563093/?series=121745=8
> [3] https://patchwork.freedesktop.org/patch/563817/?series=125433=1
> [4] https://patchwork.freedesktop.org/series/125540/
>
>>> + } else {
>>> + return -EINVAL;
>>> + }
>>> + }
>>>
>>> init_completion(>entity_idle);
>>>
>>> @@ -124,7 +134,8 @@ void drm_sched_entity_modify_sched(struct
>>> drm_sched_entity *entity,
>>> struct drm_gpu_scheduler **sched_list,
>>> unsigned int num_sched_list)
>>> {
>>> - WARN_ON(!num_sched_list || !sched_list);
>>> + WARN_ON(!num_sched_list || !sched_list ||
>>> + !!entity->single_sched);
>>
>> We wouldn't need this check.
>>
>>>
>>> entity->sched_list = sched_list;
>>> entity->num_sched_list = num_sched_list;
>>> @@ -231,13 +242,15 @@ static void drm_sched_entity_kill(struct
>>> drm_sched_entity *entity)
>>> {
>>> struct drm_sched_job
Re: [PATCH v2 2/2] drm/todo: Add entry to clean up former seltests suites
Hi Maxime, Wouldn't be nice to add to the TODO list an item regarding the deleted drm_mm tests? Something just to remember us to develop new tests for it in the future. Best Regards, - Maíra On 10/25/23 10:24, Maxime Ripard wrote: Most of those suites are undocumented and aren't really clear about what they are testing. Let's add a TODO entry as a future task to get started into KUnit and DRM. Signed-off-by: Maxime Ripard --- Documentation/gpu/todo.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 03fe5d1247be..b62c7fa0c2bc 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -621,6 +621,23 @@ Contact: Javier Martinez Canillas Level: Intermediate +Clean up and document former selftests suites +- + +Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, +drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and +drm_rect) are former selftests suites that have been converted over when KUnit +was first introduced. + +These suites were fairly undocumented, and with different goals than what unit +tests can be. Trying to identify what each test in these suites actually test +for, whether that makes sense for a unit test, and either remove it if it +doesn't or document it if it does would be of great help. + +Contact: Maxime Ripard + +Level: Intermediate + Enable trinity for DRM --
[PATCH v2 1/1] dt-bindings: backlight: mp3309c: remove two required properties
The two properties: - max-brightness - default brightness are not really required, so they can be removed from the "required" section. The "max-brightness" is no longer used in the current version of the driver (it was used only in the first version). The "default-brightness", if omitted in the DT, is managed by the device driver, using a default value. This value depends on the dimming mode used: - for the "analog mode", via I2C commands, this value is fixed by hardware (=31) - while in case of pwm mode the default used is the last value of the brightness-levels array. Also the brightness-levels array is not required: - in "analog mode", via I2C commands, the brightness-level array is fixed by hardware (0..31).; - in pwm dimming mode, the driver uses a default array of 0..255 and the "default-brightness" is the last one, which is "255" NOTE: there are no compatibility problems with the previous version, since the device driver has not yet been included in any kernel. Only this dt-binding yaml file is already included in the "for-backlight-next" branch of the "backlight" kernel repository. No developer may have used it. Other changes: - improve the backlight working mode description, in the "description" section - update the example, removing the "max-brightness" and introducing the "brightess-levels" property Signed-off-by: Flavio Suligoi --- .../bindings/leds/backlight/mps,mp3309c.yaml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml index 4191e33626f5..527a37368ed7 100644 --- a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml @@ -14,8 +14,8 @@ description: | programmable switching frequency to optimize efficiency. It supports two different dimming modes: - - analog mode, via I2C commands (default) - - PWM controlled mode. + - analog mode, via I2C commands, as default mode (32 dimming levels) + - PWM controlled mode (optional) The datasheet is available at: https://www.monolithicpower.com/en/mp3309c.html @@ -50,8 +50,6 @@ properties: required: - compatible - reg - - max-brightness - - default-brightness unevaluatedProperties: false @@ -66,8 +64,8 @@ examples: compatible = "mps,mp3309c"; reg = <0x17>; pwms = < 0 333 0>; /* 300 Hz --> (1/f) * 1*10^9 */ -max-brightness = <100>; -default-brightness = <80>; +brightness-levels = <0 4 8 16 32 64 128 255>; +default-brightness = <6>; mps,overvoltage-protection-microvolt = <2400>; }; }; -- 2.34.1
[PATCH v2 0/1] dt-bindings: backlight: mp3309c: remove two required properties
This patch remove the following two not-required properties from the "required" section: - max-brightness - default brightness These properties are not really required, so they can be removed from the "required" section. The "max-brightness" is no longer used in the current version of the driver (it was used only in the first version). The "default-brightness", if omitted in the DT, is managed by the device driver, using a default value. This value depends on the dimming mode used: - for the "analog mode", via I2C commands, this value is fixed by hardware (=31); - while in case of pwm mode the default used is the last value of the brightness-levels array. Also the brightness-levels array is not required: - in "analog mode", via I2C commands, the brightness-level array is fixed by hardware (0..31); - in pwm dimming mode, the driver uses a default array of 0..255 and the "default-brightness" is the last one, which is "255". NOTE: there are no compatibility problems with the previous version, since the device driver has not yet been included in any kernel. Only this dt-binding yaml file is already included in the "for-backlight-next" branch of the "backlight" kernel repository. No developer may have used it. Other changes: - improve the backlight working mode descripion in the "description" section - update the example, removing the "max-brightness" and introducing the "brightess-levels" property NOTE: the "brightess-levels" property is present in the last version of the common.yaml file, so it is not decalared here. For this last version of common.yaml file, see my patch: [1/1] dt-bindings: backlight: add brightness-levels related common properties commit: d5272d39995f4150062a67e6f2cef556edece740 Flavio Suligoi (1): dt-bindings: backlight: mp3309c: remove two required properties .../bindings/leds/backlight/mps,mp3309c.yaml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) -- 2.34.1
Re: [PATCH v2 4/6] drm/vs: Register DRM device
On 25/10/2023 13:39, Keith Zhao wrote:
Implement drm device registration interface
Thomas Zimmermann wrote:
You are replacing almost all of the GEM DMA object's helper code.
Either inherit directly from drm_gem_object drop the dependency entirely,
or you could try to fit your code into GEM DMA as well
Eventually I found an answer and it was DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE
After I adapt this interface, the custom gem logic interfaces can be deleted.
It's a big shocking, clap!
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/verisilicon/Kconfig | 15 ++
drivers/gpu/drm/verisilicon/Makefile | 7 +
drivers/gpu/drm/verisilicon/vs_drv.c | 227 +++
drivers/gpu/drm/verisilicon/vs_drv.h | 27 +++
drivers/gpu/drm/verisilicon/vs_modeset.c | 36
drivers/gpu/drm/verisilicon/vs_modeset.h | 10 +
include/uapi/drm/vs_drm.h| 50 +
9 files changed, 375 insertions(+)
create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
create mode 100644 drivers/gpu/drm/verisilicon/Makefile
create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h
create mode 100644 include/uapi/drm/vs_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f..9ede80ef9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -363,6 +363,8 @@ source "drivers/gpu/drm/solomon/Kconfig"
source "drivers/gpu/drm/sprd/Kconfig"
+source "drivers/gpu/drm/verisilicon/Kconfig"
+
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
depends on DRM && PCI && MMU && HYPERV
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7a09a89b4..6db3bc397 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -194,3 +194,4 @@ obj-y += gud/
obj-$(CONFIG_DRM_HYPERV) += hyperv/
obj-y += solomon/
obj-$(CONFIG_DRM_SPRD) += sprd/
+obj-$(CONFIG_DRM_VERISILICON) += verisilicon/
diff --git a/drivers/gpu/drm/verisilicon/Kconfig
b/drivers/gpu/drm/verisilicon/Kconfig
new file mode 100644
index 0..3a361f8c8
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0
+config DRM_VERISILICON
+ tristate "DRM Support for VeriSilicon"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_GEM_DMA_HELPER
+ select CMA
+ select DMA_CMA
+ help
+ Choose this option if you have a VeriSilicon soc chipset.
+ This driver provides VeriSilicon kernel mode
+ setting and buffer management. It does not
+ provide 2D or 3D acceleration.
+
+
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
new file mode 100644
index 0..7d3be305b
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+
+vs_drm-objs := vs_drv.o \
+ vs_modeset.o
+
+obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
+
diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c
b/drivers/gpu/drm/verisilicon/vs_drv.c
new file mode 100644
index 0..da7698c3d
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_drv.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_drv.h"
+#include "vs_modeset.h"
+
+#define DRV_NAME "verisilicon"
+#define DRV_DESC "Verisilicon DRM driver"
+#define DRV_DATE "20230516"
+#define DRV_MAJOR 1
+#define DRV_MINOR 0
+
+static int vs_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ struct vs_drm_device *priv = to_vs_drm_private(dev);
+
+ unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+
+ if (args->bpp % 10)
+ args->pitch = ALIGN(pitch, priv->pitch_alignment);
+ else
+ /* for costum 10bit format with no bit gaps */
? I think you meant 'custom' here. If so, please define that format and
use it explicitly here. There can be other 10bpp formats.
+ args->pitch = pitch;
+
+ return drm_gem_dma_dumb_create_internal(file, dev, args);
+}
+
+DEFINE_DRM_GEM_FOPS(vs_drm_fops);
+
+static struct drm_driver vs_drm_driver = {
+ .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
+
+ DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(vs_gem_dumb_create),
+
+ .fops = _drm_fops,
+ .name
Re: [PATCH v2 3/6] drm/fourcc: Add drm/vs tiled modifiers
Thinking about this again, it seems like you could start with just simple enumerated modifiers like Intel does, and then only switch to more complicated logic with macros and fields if there is an actual need in the future.
Re: [PATCH v2 3/6] drm/fourcc: Add drm/vs tiled modifiers
Would be good to have an overview comment to explain how bits in the modifier are used and how everything is tied up together, e.g. what the type and tile mode mean. Also some docs for DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL would be nice. (If there is no other type, this can be removed, the bits will be left as zero and can be extended later if needed.)
Re: [PATCH v2 3/6] drm/fourcc: Add drm/vs tiled modifiers
On 25/10/2023 13:39, Keith Zhao wrote:
For each modifier, add the corresponding description
Signed-off-by: Keith Zhao
---
include/uapi/drm/drm_fourcc.h | 57 +++
1 file changed, 57 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f7..a580a848c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -419,6 +419,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
+#define DRM_FORMAT_MOD_VENDOR_VERISILICON 0x0b
/* add more to the end as needed */
@@ -1562,6 +1563,62 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define AMD_FMT_MOD_CLEAR(field) \
(~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
+#define DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL 0x00
+#define DRM_FORMAT_MOD_VERISILICON_TYPE_MASK
((__u64)0x3 << 54)
+
+#define fourcc_mod_vs_code(type, val) \
+ fourcc_mod_code(VERISILICON, __u64)type) << 54) | (val)))
Please use fourcc_mode_code directly.
+
+#define DRM_FORMAT_MOD_VERISILICON_NORM_MODE_MASK
0x1F
+
+/*
+ * An x-major 8x8 super tile consists of 64 8x8 sub-tiles in total.
+ * Each 8x8 sub-tile consists of four standard tiles .
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_XMAJOR_8X8 0x02
+
+/*
+ * A y-major 8x8 super tile consists of 64 8x8 sub-tiles in total.
+ * Each 8x8 sub-tile consists of four standard tiles .
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_YMAJOR_8X8 0x03
+
+/*
+ * An 8x8 tile consists of four standard tiles
+ * that are organized in Z-order.
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_TILE_8X8
0x04
+
+/*
+ * An 8x4 tile consists of two standard tiles
+ * that are organized in Z-order.
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_TILE_8X4
0x07
+
+/*
+ * An x-major 8x4 super tile consists of 128 8x4 sub-tiles in total.
+ * Each 8x4 sub-tile consists of two standard tiles.
+ * two standard tiles also same with DRM_FORMAT_MOD_VS_TILE_8X4
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_XMAJOR_8X4 0x0B
+
+/*
+ * A y-major 4x8 super tile consists of 128 4x8 sub-tiles in total.
+ * Each 4x8 sub-tile consists of two standard tiles.
+ * two standard tiles also same with DRM_FORMAT_MOD_VS_TILE_8X4
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_YMAJOR_4X80x0C
+
+#define fourcc_mod_vs_norm_code(tile) \
+ fourcc_mod_vs_code(DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL, \
+ (tile))
1) this is not a part of uAPI
2) please use fourcc_mod_code directly.
+
#if defined(__cplusplus)
}
#endif
--
With best wishes
Dmitry
Re: [PATCH v2 10/11] drm/tests: Add test for drm_mode_addfb2()
On Tue, Oct 24, 2023 at 04:10:01PM -0300, Carlos Eduardo Gallo Filho wrote:
> Add a single KUnit test case for the drm_mode_addfb2 function.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Reorder kunit cases alphabetically.
> - Rely on drm_kunit_helper_alloc_device() for mock initialization.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 104 ++-
> 1 file changed, 103 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index dbe412d0dca4..149e1985e53f 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -341,8 +342,18 @@ static const struct drm_framebuffer_test
> drm_framebuffer_create_cases[] = {
> },
> };
>
> +/*
> + * This struct is intended to provide a way to mocked functions communicate
> + * with the outer test when it can't be achieved by using its return value.
> In
> + * this way, the functions that receive the mocked drm_device, for example,
> can
> + * grab a reference to @private and actually return something to be used on
> some
> + * expectation. Also having the @test member allows doing expectations from
> + * inside mocked functions.
> + */
> struct drm_framebuffer_test_priv {
> struct drm_device dev;
> + struct drm_file file_priv;
> + struct kunit *test;
> void *private;
> };
>
> @@ -365,14 +376,16 @@ static int drm_framebuffer_test_init(struct kunit *test)
> struct device *parent;
> struct drm_framebuffer_test_priv *priv;
> struct drm_device *dev;
> + struct drm_file *file_priv;
>
> parent = drm_kunit_helper_alloc_device(test);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, parent);
>
> priv = drm_kunit_helper_alloc_drm_device(test, parent, typeof(*priv),
> - dev, 0);
> + dev, DRIVER_MODESET);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
> dev = >dev;
> + file_priv = >file_priv;
>
> dev->mode_config.min_width = MIN_WIDTH;
> dev->mode_config.max_width = MAX_WIDTH;
> @@ -380,10 +393,22 @@ static int drm_framebuffer_test_init(struct kunit *test)
> dev->mode_config.max_height = MAX_HEIGHT;
> dev->mode_config.funcs = _config_funcs;
>
> + mutex_init(_priv->fbs_lock);
> + INIT_LIST_HEAD(_priv->fbs);
> +
mock_drm_getfile() is what you should use there
> test->priv = priv;
> +
> return 0;
> }
>
> +static void drm_framebuffer_test_exit(struct kunit *test)
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_file *file_priv = >file_priv;
> +
> + mutex_destroy(_priv->fbs_lock);
> +}
and fput(file) here, which should probably be a kunit action.
> +
> static void drm_test_framebuffer_create(struct kunit *test)
> {
> const struct drm_framebuffer_test *params = test->param_value;
> @@ -650,7 +675,83 @@ static void drm_test_framebuffer_free(struct kunit *test)
> KUNIT_EXPECT_PTR_EQ(test, obj, NULL);
> }
>
> +static struct drm_framebuffer *
> +fb_create_addfb2_mock(struct drm_device *dev, struct drm_file *file_priv,
> + const struct drm_mode_fb_cmd2 *cmd)
> +{
> + struct drm_framebuffer_test_priv *priv = container_of(dev,
> typeof(*priv), dev);
> + struct drm_framebuffer *fb;
> + struct kunit *test = priv->test;
kunit_get_current_test();
> +
> + fb = kunit_kzalloc(test, sizeof(*fb), GFP_KERNEL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fb);
That's probably a bad idea to allocate the framebuffer unit
kunit_kzalloc there. It will get freed at the end of the test but the
DRM device is still around then so it will probably result in a
use-after-free.
> +
> + fb->base.id = 1;
> +
> + priv->private = fb;
> + return fb;
Again, I don't think we should fake a buffer here, we should allocate a
real one. We want to test the behaviour of add_fb2, not whether our mock
of the framebuffer creation is good enough.
> +}
> +
> +static struct drm_mode_config_funcs config_funcs_addfb2_mock = {
> + .fb_create = fb_create_addfb2_mock,
> +};
> +
> +static void drm_test_framebuffer_addfb2(struct kunit *test)
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_device *dev = >dev;
> + struct drm_file *file_priv = >file_priv;
> + struct drm_framebuffer *fb = NULL;
> + u32 driver_features;
> + int ret;
> +
> + /* A valid cmd */
> + struct drm_mode_fb_cmd2 cmd = {
> + .width = 600, .height = 600,
> + .pixel_format = DRM_FORMAT_ABGR,
> + .handles = { 1, 0, 0 }, .pitches = { 4 * 600, 0, 0 },
> + };
> +
> + priv->test = test;
> + dev->mode_config.funcs = _funcs_addfb2_mock;
> +
> + /*
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
On 10/25/2023 4:53 PM, Andi Shyti wrote:
Hi Nirmoy,
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return guc_to_gt(guc)->i915;
+}
+
We don't want inline functions in headers files[1]. Otherwise the series
looks fine to me:
the reason for that patch is that we were including the
i915_drv.h just for that inline function and we were doing it
inside the gt/.
In this patch I am not changing any header dependency.
Sounds fair, thanks,
Nirmoy
I guess the original idea from Matt was to have a generic network
of intel_gt_needs_wa_xxx(), but it didn't develop further.
Reviewed-by: Nirmoy Das
Thanks,
Andi
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On 25/10/2023 15:44, Maxime Ripard wrote:
On Thu, Oct 19, 2023 at 02:19:51PM +0300, Dmitry Baryshkov wrote:
On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote:
On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
The MIPI DSI links do not fully fall into the DRM callbacks model.
Explaining why would help
A kind of explanation comes afterwards, but probably I should change
the order of the phrases and expand it:
The atomic_pre_enable / atomic_enable and correspondingly
atomic_disable / atomic_post_disable expect that the bridge links
follow a simple paradigm: either it is off, or it is on and streaming
video. Thus, it is fine to just enable the link at the enable time,
doing some preparations during the pre_enable.
But then it causes several issues with DSI. First, some of the DSI
bridges and most of the DSI panels would like to send commands over
the DSI link to setup the device.
What prevent them from doing it in enable when the link is enabled?
Next, some of the DSI hosts have limitations on sending the commands.
The proverbial sunxi DSI host can not send DSI commands after the
video stream has started. Thus most of the panels have opted to send
all DSI commands from pre_enable (or prepare) callback (before the
video stream has started).
I'm not sure we should account for a single driver when designing a
framework. We should focus on designing something sound, and then making
that driver work with whatever we designed, but not the other way
around. And if we can't, we should get rid of that driver because it's
de-facto unmaintainable. And I'm saying that as the author of that
driver.
That's not the only driver with strange peculiarities. For example, see
commit 8a4b2fc9c91a ("drm/bridge: tc358762: Split register programming
from pre-enable to enable"), which was one of the issues that actually
prompted me to send this this patchset (after my previous version of
this patch being rejected because of sunxi).
However this leaves no good place for the DSI host to power up the DSI
link. By default the host's pre_enable callback is called after the
DSI bridge's pre_enable. For quite some time we were powering up the
DSI link from mode_set. This doesn't look fully correct.
Yeah, it's not.
And also we got into the issue with ps8640 bridge, which requires for
the DSI link to be quiet / unpowered at the bridge's reset time.
Dave has come with the idea of pre_enable_prev_first /
prepare_prev_first flags, which attempt to solve the issue by
reversing the order of pre_enable callbacks. This mostly solves the
issue. However during this cycle it became obvious that this approach
is not ideal too. There is no way for the DSI host to know whether the
DSI panel / bridge has been updated to use this flag or not, see the
discussion at [1].
Yeah. Well, that happens. I kind of disagree with Neil here though when
he says that "A panel driver should not depend on features of a DSI
controller". Panels definitely rely on particular features, like the
number of lanes, the modes supported, etc.
In the mentioned discussion it was more about 'DSI host should not
assume panel driver features', like the panel sending commands in
pre_enable or not, or having pre_enable_prev_first.
So the pre_enable_prev_first clearly lacks feature negotiation.
Panels shouldn't depend on a particular driver *behaviour*. But the
features are fine.
For our particular discussion, I think that that kind of discussion is a
dead-end, and we just shouldn't worry about it. Yes, some panels have
not yet been updated to take the new flags into account. However, the
proper thing to do is to update them if we see a problem with that (and
thus move forward to the ideal solution), not revert the beginning of
that feature enablement (thus moving away from where we want to end up
in).
Thus comes this proposal. It allows for the panels to explicitly bring
the link up and down at the correct time, it supports automatic use
case, where no special handling is required. And last, but not least,
it allows the DSI host to note that the bridge / panel were not
updated to follow new protocol and thus the link should be powered on
at the mode_set time. This leaves us with the possibility of dropping
support for this workaround once all in-kernel drivers are updated.
I'm kind of skeptical for these kind of claims that everything will be
automatic and will be handled fine. What if we have conflicting
requirements, for example two bridges drivers that would request the
power up at different times?
Well, we do not support DSI sublinks, do we?
Also, we would still need to update every single panel driver, which is
going to create a lot of boilerplate that people might get wrong.
Yes, quite unfortunately. Another approach that I have in mind is to add
two callbacks to mipi_dsi_device. This way the DSI host will call into
the device to initialise it once the link has been powered up and just
before tearing it
Re: [PATCH v6 4/7] drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy
On Mon, Oct 23, 2023 at 11:50:26PM -0400, Luben Tuikov wrote:
> Hi,
>
> On 2023-10-17 11:09, Matthew Brost wrote:
> > DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
> > scheduler and entity. No priorities or run queue used in this mode.
> > Intended for devices with firmware schedulers.
> >
> > v2:
> > - Drop sched / rq union (Luben)
> > v3:
> > - Don't pick entity if stopped in drm_sched_select_entity (Danilo)
> > v4:
> > - Rework if statement in drm_sched_entity_init (Luben)
> > - Update comment for drm_sched_entity_to_scheduler (Luben)
> > - Reword a few things in DOC comment (Luben)
> > - Do not check sched policy in for statement (Luben)
> > v5:
> > - Fix extra blank lines (Luben / Checkpatch)
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/scheduler/sched_entity.c | 69 +++
> > drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
> > drivers/gpu/drm/scheduler/sched_main.c | 87 ++--
> > include/drm/gpu_scheduler.h | 8 +++
> > 4 files changed, 130 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> > b/drivers/gpu/drm/scheduler/sched_entity.c
> > index cf42e2265d64..940f63dd6965 100644
> > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > @@ -83,6 +83,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
> > memset(entity, 0, sizeof(struct drm_sched_entity));
> > INIT_LIST_HEAD(>list);
> > entity->rq = NULL;
> > + entity->single_sched = NULL;
> > entity->guilty = guilty;
> > entity->num_sched_list = num_sched_list;
> > entity->priority = priority;
> > @@ -90,8 +91,17 @@ int drm_sched_entity_init(struct drm_sched_entity
> > *entity,
> > RCU_INIT_POINTER(entity->last_scheduled, NULL);
> > RB_CLEAR_NODE(>rb_tree_node);
> >
> > - if(num_sched_list)
> > - entity->rq = _list[0]->sched_rq[entity->priority];
> > + if (num_sched_list) {
> > + if (sched_list[0]->sched_policy !=
> > + DRM_SCHED_POLICY_SINGLE_ENTITY) {
> > + entity->rq = _list[0]->sched_rq[entity->priority];
> > + } else if (num_sched_list == 1 &&
> > !sched_list[0]->single_entity) {
> > + sched_list[0]->single_entity = entity;
> > + entity->single_sched = sched_list[0];
>
> To simplify the rest of the GPU scheduler design and generalize the logic,
> we can do
> entity->rq = sched_list[0]->sched_rq[entity->priority];
> where the "priority" is 0, thus having a single rq.
>
> We shouldn't splice scheduler and entity, but rather make it so that
> we can set the number of rqs to 1, thus resulting in a single rq.
>
> (https://lore.kernel.org/r/20231023032251.164775-1-luben.tui...@amd.com)
>
I pulled out this patch [1] + previous one [2] and included your [3] to
test this in Xe [4].
It seems to work with just one rq per scheduler. We can go with this
approach in feel like this is the route. My next post will include your
patch [3] if we agree.
Matt
[1] https://patchwork.freedesktop.org/patch/563094/?series=121745=8
[2] https://patchwork.freedesktop.org/patch/563093/?series=121745=8
[3] https://patchwork.freedesktop.org/patch/563817/?series=125433=1
[4] https://patchwork.freedesktop.org/series/125540/
> > + } else {
> > + return -EINVAL;
> > + }
> > + }
> >
> > init_completion(>entity_idle);
> >
> > @@ -124,7 +134,8 @@ void drm_sched_entity_modify_sched(struct
> > drm_sched_entity *entity,
> > struct drm_gpu_scheduler **sched_list,
> > unsigned int num_sched_list)
> > {
> > - WARN_ON(!num_sched_list || !sched_list);
> > + WARN_ON(!num_sched_list || !sched_list ||
> > + !!entity->single_sched);
>
> We wouldn't need this check.
>
> >
> > entity->sched_list = sched_list;
> > entity->num_sched_list = num_sched_list;
> > @@ -231,13 +242,15 @@ static void drm_sched_entity_kill(struct
> > drm_sched_entity *entity)
> > {
> > struct drm_sched_job *job;
> > struct dma_fence *prev;
> > + bool single_entity = !!entity->single_sched;
> >
> > - if (!entity->rq)
> > + if (!entity->rq && !single_entity)
> > return;
> >
> > spin_lock(>rq_lock);
> > entity->stopped = true;
> > - drm_sched_rq_remove_entity(entity->rq, entity);
> > + if (!single_entity)
> > + drm_sched_rq_remove_entity(entity->rq, entity);
> > spin_unlock(>rq_lock);
>
> We should be able to carry on the existing infrastructure when
> having num_rqs = 1, with dynamic rqs. So we shouldn't warrant
> any changes here.
>
> >
> > /* Make sure this entity is not used by the scheduler at the moment */
> > @@ -259,6 +272,20 @@ static void drm_sched_entity_kill(struct
> > drm_sched_entity *entity)
> > dma_fence_put(prev);
> > }
> >
> > +/**
>
Re: [PATCH v2 09/11] drm/tests: Add test for drm_framebuffer_free()
On Tue, Oct 24, 2023 at 04:10:00PM -0300, Carlos Eduardo Gallo Filho wrote:
> Add a single KUnit test case for the drm_framebuffer_free function.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Reorder kunit cases alphabetically.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 49
> 1 file changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index eedd5e920279..dbe412d0dca4 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -602,10 +602,59 @@ static void drm_test_framebuffer_init(struct kunit
> *test)
> drm_framebuffer_cleanup();
> }
>
> +static void destroy_free_mock(struct drm_framebuffer *fb)
> +{
> + struct drm_framebuffer_test_priv *priv = container_of(fb->dev,
> typeof(*priv), dev);
> + int *buffer_freed = priv->private;
> + *buffer_freed = 1;
> +}
Yeah, definitely not a fan of a pointer being used for multiple things
depending on the caller.
Just add another boolean to drm_framebuffer_test_priv, that way it will
be obvious to anyone, and it will be simpler if we ever rework that part
of the tests.
> +static struct drm_framebuffer_funcs framebuffer_funcs_free_mock = {
> + .destroy = destroy_free_mock,
> +};
> +
> +static void drm_test_framebuffer_free(struct kunit *test)
I'm sure you get the idea now :)
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_device *dev = >dev;
> + struct drm_mode_object *obj;
> + struct drm_framebuffer fb = {
> + .dev = dev,
> + .funcs = _funcs_free_mock,
> + };
> + int buffer_freed = 0;
> + int id, ret;
> +
> + priv->private = _freed;
> +
> + /*
> + * Case where the fb isn't registered. Just test if
> + * drm_framebuffer_free calls fb->funcs->destroy
> + */
> + drm_framebuffer_free();
> + KUNIT_EXPECT_EQ(test, buffer_freed, 1);
> +
> + buffer_freed = 0;
> +
> + ret = drm_mode_object_add(dev, , DRM_MODE_OBJECT_FB);
> + KUNIT_ASSERT_EQ(test, ret, 0);
> + id = fb.base.id;
> +
> + /* Now, test with the fb registered, that must end unregistered */
> + drm_framebuffer_free();
> + KUNIT_EXPECT_EQ(test, fb.base.id, 0);
> + KUNIT_EXPECT_EQ(test, buffer_freed, 1);
> +
> + /* Test if the old id of the fb was really removed from the idr pool */
> + obj = drm_mode_object_find(dev, NULL, id, DRM_MODE_OBJECT_FB);
> + KUNIT_EXPECT_PTR_EQ(test, obj, NULL);
> +}
And for that as well, these should all be separate tests.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v2 08/11] drm/tests: Add test for drm_framebuffer_init()
On Tue, Oct 24, 2023 at 04:09:59PM -0300, Carlos Eduardo Gallo Filho wrote:
> Add a single KUnit test case for the drm_framebuffer_init function.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Reorder kunit cases alphabetically.
> - Let fb1.dev unset instead of set it to wrong_drm to test mismatched
> drm_device passed as drm_framebuffer_init() argument.
> - Clean the framebuffer object.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 52
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index fb9589dd8aed..eedd5e920279 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -551,10 +551,62 @@ static void drm_test_framebuffer_lookup(struct kunit
> *test)
> drm_framebuffer_cleanup();
> }
>
> +static void drm_test_framebuffer_init(struct kunit *test)
Documentation
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_device *dev = >dev;
> + struct drm_format_info format = { };
> + struct drm_framebuffer fb1 = { .format = };
> + struct drm_framebuffer *fb2;
> + struct drm_framebuffer_funcs funcs = { };
> + int ret;
> +
> + /* Fails if fb->dev doesn't point to the drm_device passed on first arg
> */
> + ret = drm_framebuffer_init(dev, , );
> + KUNIT_ASSERT_EQ(test, ret, -EINVAL);
> + fb1.dev = dev;
> +
> + /* Fails if fb.format isn't set */
> + fb1.format = NULL;
> + ret = drm_framebuffer_init(dev, , );
> + KUNIT_ASSERT_EQ(test, ret, -EINVAL);
> + fb1.format =
> +
> + ret = drm_framebuffer_init(dev, , );
> + KUNIT_ASSERT_EQ(test, ret, 0);
> +
> + /*
> + * Check if fb->funcs is actually set to the drm_framebuffer_funcs
> + * passed to it
> + */
> + KUNIT_EXPECT_PTR_EQ(test, fb1.funcs, );
> +
> + /* The fb->comm must be set to the current running process */
> + KUNIT_EXPECT_STREQ(test, fb1.comm, current->comm);
> +
> + /* The fb->base must be successfully initialized */
> + KUNIT_EXPECT_NE(test, fb1.base.id, 0);
> + KUNIT_EXPECT_EQ(test, fb1.base.type, DRM_MODE_OBJECT_FB);
> + KUNIT_EXPECT_EQ(test, kref_read(), 1);
> + KUNIT_EXPECT_PTR_EQ(test, fb1.base.free_cb, _framebuffer_free);
> +
> + /* Checks if the fb is really published and findable */
> + fb2 = drm_framebuffer_lookup(dev, NULL, fb1.base.id);
> + KUNIT_EXPECT_PTR_EQ(test, fb2, );
> +
> + /* There must be just that one fb initialized */
> + KUNIT_EXPECT_EQ(test, dev->mode_config.num_fb, 1);
> + KUNIT_EXPECT_PTR_EQ(test, dev->mode_config.fb_list.prev, );
> + KUNIT_EXPECT_PTR_EQ(test, dev->mode_config.fb_list.next, );
> +
> + drm_framebuffer_cleanup();
> +}
You're testing different failure cases, so these should all be their own
tests. Otherwise, you'll just get a single test failure that doesn't
really provide any feedback on what went wrong.
Maxime
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
Hi Nirmoy,
> > +static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
> > +{
> > + return guc_to_gt(guc)->i915;
> > +}
> > +
>
> We don't want inline functions in headers files[1]. Otherwise the series
> looks fine to me:
the reason for that patch is that we were including the
i915_drv.h just for that inline function and we were doing it
inside the gt/.
In this patch I am not changing any header dependency.
I guess the original idea from Matt was to have a generic network
of intel_gt_needs_wa_xxx(), but it didn't develop further.
> Reviewed-by: Nirmoy Das
Thanks,
Andi
Re: [PATCH v2 07/11] drm/tests: Add test for drm_framebuffer_lookup()
Hi,
On Tue, Oct 24, 2023 at 04:09:58PM -0300, Carlos Eduardo Gallo Filho wrote:
> Add a single KUnit test case for the drm_framebuffer_lookup function.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Reorder kunit cases alphabetically.
> - Replace drm_mode_object_add() call to drm_framebuffer_init().
> - Rely on drm_kunit_helper_alloc_device() for mock initialization.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 26
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index a63f30985f75..fb9589dd8aed 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -526,10 +526,36 @@ static void drm_test_framebuffer_cleanup(struct kunit
> *test)
> KUNIT_ASSERT_EQ(test, dev->mode_config.num_fb, 0);
> }
>
> +static void drm_test_framebuffer_lookup(struct kunit *test)
Again, documentation.
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_device *dev = >dev;
> + struct drm_format_info format = { };
> + struct drm_framebuffer fb1 = { .dev = dev, .format = };
> + struct drm_framebuffer *fb2;
> + uint32_t id = 0;
> + int ret;
> +
> + ret = drm_framebuffer_init(dev, , NULL);
> + KUNIT_ASSERT_EQ(test, ret, 0);
> + id = fb1.base.id;
> +
> + /* Looking for fb1 */
> + fb2 = drm_framebuffer_lookup(dev, NULL, id);
> + KUNIT_EXPECT_PTR_EQ(test, fb2, );
I would rename the variables to expected_fb and fb (or returned_fb);
You also need to call drm_framebuffer_put on fb2.
> + /* Looking for an inexistent framebuffer */
> + fb2 = drm_framebuffer_lookup(dev, NULL, id + 1);
> + KUNIT_EXPECT_NULL(test, fb2);
This should be a separate test
Maxime
signature.asc
Description: PGP signature
Re: [PATCH] drm/atomic: Spelling fix in comments
Hi Kunwu, Can you make the tagline something along the lines of `drm/atomic helper: fix spelling mistake "preceeding" -> "preceding"`, in general to determine an appropriate prefix, you can see what previous commits used when making changes to files in your particular patch, e.g. using the following: $ git log drivers/gpu/drm/drm_atomic_helper.c On 10/25/23 04:26, Kunwu Chan wrote: fix a typo in a comments. For patch descriptions you should try to more descriptive. So, something like "There is a spelling mistake in drm_atomic_helper_wait_for_dependencies()'s kernel doc. Fix it." would be better. Signed-off-by: Kunwu Chan --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 2444fc33dd7c..c3f677130def 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2382,10 +2382,10 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, EXPORT_SYMBOL(drm_atomic_helper_setup_commit); /** - * drm_atomic_helper_wait_for_dependencies - wait for required preceeding commits + * drm_atomic_helper_wait_for_dependencies - wait for required preceding commits * @old_state: atomic state object with old state structures * - * This function waits for all preceeding commits that touch the same CRTC as + * This function waits for all preceding commits that touch the same CRTC as * @old_state to both be committed to the hardware (as signalled by * drm_atomic_helper_commit_hw_done()) and executed by the hardware (as signalled * by calling drm_crtc_send_vblank_event() on the _crtc_state.event). -- Hamza
Re: [PATCH v2 06/11] drm/tests: Add test for drm_framebuffer_cleanup()
Hi,
On Tue, Oct 24, 2023 at 04:09:57PM -0300, Carlos Eduardo Gallo Filho wrote:
> Add a single KUnit test case for the drm_framebuffer_cleanup function.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Reorder kunit cases alphabetically.
> - Rely on drm_kunit_helper_alloc_device() for mock initialization.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 37
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index 7b51862fb0f2..a63f30985f75 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -490,8 +490,45 @@ check_src_coords_test_to_desc(const struct
> drm_framebuffer_check_src_coords_case
> KUNIT_ARRAY_PARAM(check_src_coords, drm_framebuffer_check_src_coords_cases,
> check_src_coords_test_to_desc);
>
> +static void drm_test_framebuffer_cleanup(struct kunit *test)
Again, we should document *what* we are testing here. Your commit says
that you're testing drm_framebuffer_cleanup(), but even after reading
that test I have no idea which tests have been covered or not.
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_device *dev = >dev;
> + struct list_head *fb_list = >mode_config.fb_list;
> + struct drm_framebuffer fb1 = { .dev = dev };
> + struct drm_framebuffer fb2 = { .dev = dev };
> +
> + /* This must result on [fb_list] -> fb1 -> fb2 */
> + list_add_tail(, fb_list);
> + list_add_tail(, fb_list);
> + dev->mode_config.num_fb = 2;
> +
> + KUNIT_ASSERT_PTR_EQ(test, fb_list->prev, );
> + KUNIT_ASSERT_PTR_EQ(test, fb_list->next, );
> + KUNIT_ASSERT_PTR_EQ(test, fb1.head.prev, fb_list);
> + KUNIT_ASSERT_PTR_EQ(test, fb1.head.next, );
> + KUNIT_ASSERT_PTR_EQ(test, fb2.head.prev, );
> + KUNIT_ASSERT_PTR_EQ(test, fb2.head.next, fb_list);
> +
> + drm_framebuffer_cleanup();
I think that for that test to be meaningful, we should first have init
the framebuffer using drm_framebuffer_init. Otherwise we will just
chasing our tail trying to mock drm_framebuffer_init. Plus, we don't
want to test if drm_framebuffer_cleanup works if we hand-crafted a
framebuffer.
Maxime
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
Hi Andi,
On 10/25/2023 4:35 PM, Andi Shyti wrote:
Given a reference to "guc", the guc_to_i915() returns the
pointer to "i915" private data.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
8 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a..12a638f05d63 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -114,6 +114,11 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return guc_to_gt(guc)->i915;
+}
+
We don't want inline functions in headers files[1]. Otherwise the series
looks fine to me:
Reviewed-by: Nirmoy Das
[1] https://patchwork.freedesktop.org/series/124069/
Regards,
Nirmoy
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 3f3df1166b86..2b450c43bbd7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -330,7 +330,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
static u32 guc_ctl_devid(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
return (INTEL_DEVID(i915) << 16) | INTEL_REVID(i915);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a4da0208c883..a1cd40d80517 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -355,7 +355,7 @@ guc_capture_alloc_steered_lists(struct intel_guc *guc,
static const struct __guc_mmio_reg_descr_group *
guc_capture_get_device_reglist(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
const struct __guc_mmio_reg_descr_group *lists;
if (GRAPHICS_VER(i915) >= 12)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 89e314b3756b..4e147de5118f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -265,7 +265,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
u32 *cmds;
int err;
- err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
+ err = i915_inject_probe_error(guc_to_i915(guc), -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 55bc8b55fbc0..bf16351c9349 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -520,7 +520,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
static int guc_log_relay_create(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
size_t n_subbufs, subbuf_size;
int ret;
@@ -573,7 +573,7 @@ static void guc_log_relay_destroy(struct intel_guc_log *log)
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
intel_wakeref_t wakeref;
_guc_log_copy_debuglogs_for_relay(log);
@@ -589,7 +589,7 @@ static void guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
static u32 __get_default_log_level(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
/* A negative value means "use platform/config default" */
if (i915->params.guc_log_level < 0) {
@@ -664,7 +664,7 @@ void intel_guc_log_destroy(struct intel_guc_log *log)
int intel_guc_log_set_level(struct intel_guc_log *log, u32 level)
{
struct intel_guc *guc = log_to_guc(log);
- struct
Re: [PATCH v2 04/11] drm/tests: Add test case for drm_internal_framebuffer_create()
Hi,
On Tue, Oct 24, 2023 at 04:09:55PM -0300, Carlos Eduardo Gallo Filho wrote:
> Introduce a test to cover the creation of framebuffer with
> modifier on a device that doesn't support it.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Reorder kunit cases alphabetically.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index eb76a71644e9..8a9b6d08d639 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -403,8 +403,36 @@ static void drm_framebuffer_test_to_desc(const struct
> drm_framebuffer_test *t, c
> KUNIT_ARRAY_PARAM(drm_framebuffer_create, drm_framebuffer_create_cases,
> drm_framebuffer_test_to_desc);
>
> +/*
> + * This test is very similar to drm_test_framebuffer_create, except that it
We shouldn't rely on the another test for the documentation. If
drm_test_framebuffer_create is ever removed or renamed, then the reader
won't have any clue what it was supposed to test.
We should provide a documentation that doesn't require any additional
context.
> + * set dev->mode_config.fb_modifiers_not_supported member to 1, covering
> + * the case of trying to create a framebuffer with modifiers without the
> + * device really supporting it.
> + */
So I guess something like:
Test that, if a device doesn't support modifiers, a framebuffer
allocation using them will fail.
> +static void drm_test_framebuffer_modifiers_not_supported(struct kunit *test)
> +{
> + struct drm_framebuffer_test_priv *priv = test->priv;
> + struct drm_device *dev = >dev;
> + int buffer_created = 0;
> +
> + /* A valid cmd with modifier */
> + struct drm_mode_fb_cmd2 cmd = {
> + .width = MAX_WIDTH, .height = MAX_HEIGHT,
> + .pixel_format = DRM_FORMAT_ABGR, .handles = { 1, 0, 0 },
> + .offsets = { UINT_MAX / 2, 0, 0 }, .pitches = { 4 * MAX_WIDTH,
> 0, 0 },
> + .flags = DRM_MODE_FB_MODIFIERS,
> + };
> +
> + priv->private = _created;
> + dev->mode_config.fb_modifiers_not_supported = 1;
> +
> + drm_internal_framebuffer_create(dev, , NULL);
> + KUNIT_EXPECT_EQ(test, 0, buffer_created);
We should test the returned value of drm_internal_framebuffer_create here.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v2] drm/doc: ci: Require more context for flaky tests
On 25/10/2023 11:24, Maxime Ripard wrote:
Flaky tests can be very difficult to reproduce after the facts, which
will make it even harder to ever fix.
Let's document the metadata we agreed on to provide more context to
anyone trying to address these fixes.
Link:
https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/
Acked-by: Daniel Vetter
Signed-off-by: Maxime Ripard
Acked-by: Helen Koike
---
Cc: Helen Koike
Changes from v1:
- Rephrase the sentence a bit to make it clearer we expect a bug report
by mail
---
Documentation/gpu/automated_testing.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 469b6fb65c30..792428a2bfdc 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,6 +67,19 @@ Lists the tests that for a given driver on a specific
hardware revision are
known to behave unreliably. These tests won't cause a job to fail regardless
of
the result. They will still be run.
+Each new flake entry must be associated with a link to the email reporting the
+bug to the author of the affected driver, the board name or Device Tree name of
+the board, the first kernel version affected, and an approximation of the
+failure rate.
+
+They should be provided under the following format::
+
+ # Bug Report: $LORE_OR_PATCHWORK_URL
+ # Board Name: broken-board.dtb
+ # Version: 6.6-rc1
+ # Failure Rate: 100
+ flaky-test
+
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
[PATCH v2 4/5] drm/i915: Use the new gt_to_guc() wrapper
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_debugfs_params.c | 5 +++--
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
b/drivers/gpu/drm/i915/i915_debugfs_params.c
index 614bde321589..8a385c57c0fe 100644
--- a/drivers/gpu/drm/i915/i915_debugfs_params.c
+++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
@@ -38,10 +38,11 @@ static int i915_param_int_open(struct inode *inode, struct
file *file)
static int notify_guc(struct drm_i915_private *i915)
{
+ struct intel_gt *gt = to_gt(i915);
int ret = 0;
- if (intel_uc_uses_guc_submission(_gt(i915)->uc))
- ret = intel_guc_global_policies_update(_gt(i915)->uc.guc);
+ if (intel_uc_uses_guc_submission(>uc))
+ ret = intel_guc_global_policies_update(gt_to_guc(gt));
return ret;
}
diff --git a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
index 2990dd4d4a0d..d9d8f0336702 100644
--- a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
+++ b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
@@ -65,7 +65,7 @@ int intel_selftest_modify_policy(struct intel_engine_cs
*engine,
if (!intel_engine_uses_guc(engine))
return 0;
- err = intel_guc_global_policies_update(>gt->uc.guc);
+ err = intel_guc_global_policies_update(gt_to_guc(engine->gt));
if (err)
intel_selftest_restore_policy(engine, saved);
@@ -84,7 +84,7 @@ int intel_selftest_restore_policy(struct intel_engine_cs
*engine,
if (!intel_engine_uses_guc(engine))
return 0;
- return intel_guc_global_policies_update(>gt->uc.guc);
+ return intel_guc_global_policies_update(gt_to_guc(engine->gt));
}
int intel_selftest_wait_for_rq(struct i915_request *rq)
--
2.42.0
[PATCH v2 5/5] drm/i915/guc: Use the ce_to_guc() wrapper whenever possible
Get the guc reference from the ce using the ce_to_guc() helper.
Just a leftover from previous cleanups.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 023b10ef5be4..8b6396179615 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3511,7 +3511,7 @@ static inline void sub_context_inflight_prio(struct
intel_context *ce,
static inline void update_context_prio(struct intel_context *ce)
{
- struct intel_guc *guc = >engine->gt->uc.guc;
+ struct intel_guc *guc = ce_to_guc(ce);
int i;
BUILD_BUG_ON(GUC_CLIENT_PRIORITY_KMD_HIGH != 0);
--
2.42.0
[PATCH v2 3/5] drm/i915/guc: Use the new gt_to_guc() wrapper
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 +--
drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 6 ++--
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 28 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 4 +--
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +-
9 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index e2e42b3e0d5d..3b69bc6616bd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -298,7 +298,7 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memcpy_toio(gsc->local_vaddr, src, gsc->fw.size);
memset_io(gsc->local_vaddr + gsc->fw.size, 0, gsc->local->size -
gsc->fw.size);
- intel_guc_write_barrier(>uc.guc);
+ intel_guc_write_barrier(gt_to_guc(gt));
i915_gem_object_unpin_map(gsc->fw.obj);
@@ -351,7 +351,7 @@ static int gsc_fw_query_compatibility_version(struct
intel_gsc_uc *gsc)
void *vaddr;
int err;
- err = intel_guc_allocate_and_map_vma(>uc.guc, GSC_VER_PKT_SZ * 2,
+ err = intel_guc_allocate_and_map_vma(gt_to_guc(gt), GSC_VER_PKT_SZ * 2,
, );
if (err) {
gt_err(gt, "failed to allocate vma for GSC version query\n");
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index 5f138de3c14f..765d74dbb5b5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -356,7 +356,8 @@ static int proxy_channel_alloc(struct intel_gsc_uc *gsc)
void *vaddr;
int err;
- err = intel_guc_allocate_and_map_vma(>uc.guc,
GSC_PROXY_CHANNEL_SIZE,
+ err = intel_guc_allocate_and_map_vma(gt_to_guc(gt),
+GSC_PROXY_CHANNEL_SIZE,
, );
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 63724e17829a..1ef470e64604 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -956,7 +956,7 @@ u32 intel_guc_engine_usage_offset(struct intel_guc *guc)
struct iosys_map intel_guc_engine_usage_record_map(struct intel_engine_cs
*engine)
{
- struct intel_guc *guc = >gt->uc.guc;
+ struct intel_guc *guc = gt_to_guc(engine->gt);
u8 guc_class = engine_class_to_guc_class(engine->class);
size_t offset = offsetof(struct __guc_ads_blob,
engine_usage.engines[guc_class][ilog2(engine->logical_mask)]);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a1cd40d80517..488372b71555 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1441,7 +1441,7 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *ebuf,
if (!cap || !ee->engine)
return -ENODEV;
- guc = >engine->gt->uc.guc;
+ guc = gt_to_guc(ee->engine->gt);
i915_error_printf(ebuf, "global --- GuC Error Capture on %s command
stream:\n",
ee->engine->name);
@@ -1543,7 +1543,7 @@ bool intel_guc_capture_is_matching_engine(struct intel_gt
*gt,
if (!gt || !ce || !engine)
return false;
- guc = >uc.guc;
+ guc = gt_to_guc(gt);
if (!guc->capture)
return false;
@@ -1573,7 +1573,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
if (!gt || !ee || !ce)
return;
- guc = >uc.guc;
+ guc = gt_to_guc(gt);
if (!guc->capture)
return;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index cc9569af7f0c..b67a15f74276 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -111,7 +111,7 @@ static bool has_table(struct drm_i915_private *i915)
static int guc_hwconfig_init(struct intel_gt *gt)
{
struct intel_hwconfig *hwconfig = >info.hwconfig;
- struct intel_guc *guc = >uc.guc;
+ struct intel_guc *guc = gt_to_guc(gt);
int ret;
if (!has_table(gt->i915))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 669f2892bf74..023b10ef5be4 100644
---
[PATCH v2 2/5] drm/i915/gt: Create the gt_to_guc() wrapper
We already have guc_to_gt() and getting to guc from the GT it
requires some mental effort. Add the gt_to_guc().
Given the reference to the "gt", the gt_to_guc() will return the
pinter to the "guc".
Update all the files under the gt/ directory.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +++--
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +++---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 8
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
drivers/gpu/drm/i915/gt/intel_tlb.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 +++---
10 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4a11219e560e..ea9c331a38c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -589,7 +589,7 @@ u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs
*engine, u64 value)
* NB: The GuC API only supports 32bit values. However, the limit is
further
* reduced due to internal calculations which would otherwise overflow.
*/
- if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ if (intel_guc_submission_is_wanted(gt_to_guc(engine->gt)))
value = min_t(u64, value, guc_policy_max_preempt_timeout_ms());
value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
@@ -610,7 +610,7 @@ u64 intel_clamp_timeslice_duration_ms(struct
intel_engine_cs *engine, u64 value)
* NB: The GuC API only supports 32bit values. However, the limit is
further
* reduced due to internal calculations which would otherwise overflow.
*/
- if (intel_guc_submission_is_wanted(>gt->uc.guc))
+ if (intel_guc_submission_is_wanted(gt_to_guc(engine->gt)))
value = min_t(u64, value, guc_policy_max_exec_quantum_ms());
value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 1c93e84278a0..acd0912a1abd 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -211,11 +211,8 @@ static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
- struct intel_guc *guc = >uc.guc;
-
- intel_guc_invalidate_tlb_guc(guc);
- }
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref)
+ intel_guc_invalidate_tlb_guc(gt_to_guc(gt));
}
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -226,7 +223,7 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
gen8_ggtt_invalidate(ggtt);
list_for_each_entry(gt, >gt_list, ggtt_link) {
- if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+ if (intel_guc_tlb_invalidation_is_available(gt_to_guc(gt))) {
guc_ggtt_ct_invalidate(gt);
} else if (GRAPHICS_VER(i915) >= 12) {
intel_uncore_write_fw(gt->uncore,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 12a638f05d63..228a26017851 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -119,6 +119,11 @@ static inline struct drm_i915_private *guc_to_i915(struct
intel_guc *guc)
return guc_to_gt(guc)->i915;
}
+static inline struct intel_guc *gt_to_guc(struct intel_gt *gt)
+{
+ return >uc.guc;
+}
+
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 77fb57223465..ad4c51f18d3a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -68,9 +68,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
instance,
struct intel_gt *media_gt = gt->i915->media_gt;
if (instance == OTHER_GUC_INSTANCE)
- return guc_irq_handler(>uc.guc, iir);
+ return guc_irq_handler(gt_to_guc(gt), iir);
if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
- return guc_irq_handler(_gt->uc.guc, iir);
+ return guc_irq_handler(gt_to_guc(media_gt), iir);
if (instance == OTHER_GTPM_INSTANCE)
return gen11_rps_irq_handler(>rps, iir);
@@ -442,7 +442,7 @@ void gen8_gt_irq_handler(struct intel_gt *gt, u32
master_ctl)
iir
Re: [PATCH v2 03/11] drm/tests: Replace strcpy to strscpy on drm_test_framebuffer_create test
On Tue, 24 Oct 2023 16:09:54 -0300, Carlos Eduardo Gallo Filho wrote: > Replace the use of strcpy to strscpy on the test_to_desc of the > drm_test_framebuffer_create test for better security and reliability. > > Signed-off-by: Carlos Eduardo Gallo Filho Acked-by: Maxime Ripard Thanks! Maxime
[PATCH v2 1/5] drm/i915/guc: Create the guc_to_i915() wrapper
Given a reference to "guc", the guc_to_i915() returns the
pointer to "i915" private data.
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
8 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 970bedf6b78a..12a638f05d63 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -114,6 +114,11 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc
*gsc)
return container_of(gsc, struct intel_gt, gsc);
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return guc_to_gt(guc)->i915;
+}
+
void intel_gt_common_init_early(struct intel_gt *gt);
int intel_root_gt_init_early(struct drm_i915_private *i915);
int intel_gt_assign_ggtt(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 3f3df1166b86..2b450c43bbd7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -330,7 +330,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
static u32 guc_ctl_devid(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
return (INTEL_DEVID(i915) << 16) | INTEL_REVID(i915);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a4da0208c883..a1cd40d80517 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -355,7 +355,7 @@ guc_capture_alloc_steered_lists(struct intel_guc *guc,
static const struct __guc_mmio_reg_descr_group *
guc_capture_get_device_reglist(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
const struct __guc_mmio_reg_descr_group *lists;
if (GRAPHICS_VER(i915) >= 12)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 89e314b3756b..4e147de5118f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -265,7 +265,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
u32 *cmds;
int err;
- err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
+ err = i915_inject_probe_error(guc_to_i915(guc), -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 55bc8b55fbc0..bf16351c9349 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -520,7 +520,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
static int guc_log_relay_create(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
size_t n_subbufs, subbuf_size;
int ret;
@@ -573,7 +573,7 @@ static void guc_log_relay_destroy(struct intel_guc_log *log)
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
intel_wakeref_t wakeref;
_guc_log_copy_debuglogs_for_relay(log);
@@ -589,7 +589,7 @@ static void guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
static u32 __get_default_log_level(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
/* A negative value means "use platform/config default" */
if (i915->params.guc_log_level < 0) {
@@ -664,7 +664,7 @@ void intel_guc_log_destroy(struct intel_guc_log *log)
int intel_guc_log_set_level(struct intel_guc_log *log, u32 level)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct drm_i915_private *i915 = guc_to_i915(guc);
intel_wakeref_t wakeref;
int ret = 0;
@@ -796,7 +796,7 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
static void guc_log_relay_stop(struct
[PATCH v2 0/5] Add gt_to_guc and guc_to_i915 helpers
Hi, while working on the GuC TLB invalidation these days, I just wished I had the two helpers I am submitting today: gt_to_guc() guc_to_i915() Now I have them, at the next GuC TLB invalidation my life will be easier :-) Andi Changelog: == - add the gt_to_guc() helper and change files in: - i915/gt/ - i915/gt/uc - i915/ Andi Shyti (5): drm/i915/guc: Create the guc_to_i915() wrapper drm/i915/gt: Create the gt_to_guc() wrapper drm/i915/guc: Use the new gt_to_guc() wrapper drm/i915: Use the new gt_to_guc() wrapper drm/i915/guc: Use the ce_to_guc() wrapper whenever possible drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-- drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 ++--- drivers/gpu/drm/i915/gt/intel_gt.h| 10 ++ drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 ++-- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 8 ++--- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-- drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- drivers/gpu/drm/i915/gt/intel_tlb.c | 2 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 6 ++-- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 +-- drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 8 ++--- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 10 +++--- drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 34 +-- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 +-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 4 +-- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +- drivers/gpu/drm/i915/i915_debugfs_params.c| 5 +-- .../i915/selftests/intel_scheduler_helpers.c | 4 +-- 26 files changed, 76 insertions(+), 67 deletions(-) -- 2.42.0
Re: [PATCH v2 02/11] drm/tests: Add parameters to the drm_test_framebuffer_create test
Hi,
On Tue, Oct 24, 2023 at 04:09:53PM -0300, Carlos Eduardo Gallo Filho wrote:
> Extend the existing test case to cover:
> 1. Invalid flag atribute in the struct drm_mode_fb_cmd2.
> 2. Pixel format which requires non-linear modifier with
> DRM_FORMAT_MOD_LINEAR set.
> 3. Non-zero buffer offset for an unused plane
>
> Also replace strcpy to strscpy on test_to_desc for improved security
> and reliability.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Remove strcpy to strscpy change.
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 21
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index 9c6170edd5f7..659cbd5a3be3 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -21,6 +21,8 @@
> #define MIN_HEIGHT 4
> #define MAX_HEIGHT 4096
>
> +#define DRM_MODE_FB_INVALID BIT(2)
> +
> struct drm_framebuffer_test {
> int buffer_created;
> struct drm_mode_fb_cmd2 cmd;
> @@ -85,6 +87,18 @@ static const struct drm_framebuffer_test
> drm_framebuffer_create_cases[] = {
>.pitches = { 4 * MAX_WIDTH, 0, 0 },
> }
> },
> +{ .buffer_created = 0, .name = "ABGR Non-zero buffer offset for unused
> plane",
> + .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
> DRM_FORMAT_ABGR,
> + .handles = { 1, 0, 0 }, .offsets = { UINT_MAX / 2, UINT_MAX /
> 2, 0 },
> + .pitches = { 4 * MAX_WIDTH, 0, 0 }, .flags =
> DRM_MODE_FB_MODIFIERS,
> + }
> +},
I know that the other tests are like that too, but I'd really like a
comment that explains what corner case this test is supposed to test.
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v2 01/11] drm/tests: Stop using deprecated dev_private member on drm_framebuffer tests
Hi,
On Tue, Oct 24, 2023 at 04:09:52PM -0300, Carlos Eduardo Gallo Filho wrote:
> The dev_private member of drm_device is deprecated and its use should
> be avoided. Stop using it by embedding the drm_device onto a mock struct
> with a void pointer like dev_private, using it instead.
>
> Also start using drm_kunit_helper_alloc_drm_device() for allocating
> the drm_device mock.
>
> Signed-off-by: Carlos Eduardo Gallo Filho
> ---
> v2:
> - Start using drm_kunit_helper_alloc_drm_device() for drm_device mock.
> - Rename struct drm_mock to drm_framebuffer_test_priv
> ---
> drivers/gpu/drm/tests/drm_framebuffer_test.c | 42 ++--
> 1 file changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> index f759d9f3b76e..9c6170edd5f7 100644
> --- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
> +++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
> @@ -8,8 +8,10 @@
> #include
>
> #include
> +#include
> #include
> #include
> +#include
> #include
>
> #include "../drm_crtc_internal.h"
> @@ -317,11 +319,17 @@ static const struct drm_framebuffer_test
> drm_framebuffer_create_cases[] = {
> },
> };
>
> +struct drm_framebuffer_test_priv {
> + struct drm_device dev;
> + void *private;
> +};
> +
I'm not super confident with using a void pointer to whatever the test
wants it to be. Especially since it seems like you only use it to store
whether the buffer has been created, so I guess this could just be
converted to a boolean?
> static struct drm_framebuffer *fb_create_mock(struct drm_device *dev,
> struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2
> *mode_cmd)
> {
> - int *buffer_created = dev->dev_private;
> + struct drm_framebuffer_test_priv *priv = container_of(dev,
> typeof(*priv), dev);
> + int *buffer_created = priv->private;
> *buffer_created = 1;
And then you just need to change that line to priv->buffer_created = true;
Maxime
signature.asc
Description: PGP signature
[PATCH v2] drm/doc: ci: Require more context for flaky tests
Flaky tests can be very difficult to reproduce after the facts, which
will make it even harder to ever fix.
Let's document the metadata we agreed on to provide more context to
anyone trying to address these fixes.
Link:
https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/
Acked-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
Cc: Helen Koike
Changes from v1:
- Rephrase the sentence a bit to make it clearer we expect a bug report
by mail
---
Documentation/gpu/automated_testing.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 469b6fb65c30..792428a2bfdc 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,6 +67,19 @@ Lists the tests that for a given driver on a specific
hardware revision are
known to behave unreliably. These tests won't cause a job to fail regardless of
the result. They will still be run.
+Each new flake entry must be associated with a link to the email reporting the
+bug to the author of the affected driver, the board name or Device Tree name of
+the board, the first kernel version affected, and an approximation of the
+failure rate.
+
+They should be provided under the following format::
+
+ # Bug Report: $LORE_OR_PATCHWORK_URL
+ # Board Name: broken-board.dtb
+ # Version: 6.6-rc1
+ # Failure Rate: 100
+ flaky-test
+
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
--
2.41.0
Re: [PATCH] drm/doc: ci: Require more context for flaky tests
On Wed, Oct 25, 2023 at 09:47:07AM -0300, Helen Koike wrote: > > > > > + # Version: 6.6-rc1 > > > > > + # Failure Rate: 100 > > > > > > Maybe also: > > > > > ># Pipeline url: > > > https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/1014435 > > > > Sounds like a good idea yeah :) Are those artifacts archived/deleted at > > some point or do they stick around forever? > > Good point, I asked the admins, they stick for 4 weeks (could be more, but > it is not forever) :( That's not even a release cycle :/ I guess it's too short to be useful. We can definitely revisit if that delay is extended at some point though. Maxime signature.asc Description: PGP signature
Re: [PATCH v2] drm/logicvc: Kconfig: select REGMAP and REGMAP_MMIO
Hi, On 2023/10/25 18:11, Paul Kocialkowski wrote: Hi, On Tue 20 Jun 23, 11:56, Sui Jingfeng wrote: Hi, On 2023/6/8 15:15, Paul Kocialkowski wrote: Hi, On Thu 08 Jun 23, 10:42, Sui Jingfeng wrote: drm/logicvc driver is depend on REGMAP and REGMAP_MMIO, should select this two kconfig option, otherwise the driver failed to compile on platform without REGMAP_MMIO selected: ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/gpu/drm/logicvc/logicvc-drm.ko] undefined! make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1 make: *** [Makefile:1978: modpost] Error 2 Signed-off-by: Sui Jingfeng Thanks for the fix, looks good to me! Acked-by: Paul Kocialkowski Thanks a lot, Please don't forget to push this to drm-misc or drm-tip if you has the time, as (even though trivial) it's precious for me. So I totally forgot about this and only pushed it to drm-misc-fixes now. Sincere apologies for this. Thanks again for spotting this issue and submitting the fix. Paul Nice, thanks your reply. Cheers, Paul --- drivers/gpu/drm/logicvc/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/logicvc/Kconfig b/drivers/gpu/drm/logicvc/Kconfig index fa7a88368809..1df22a852a23 100644 --- a/drivers/gpu/drm/logicvc/Kconfig +++ b/drivers/gpu/drm/logicvc/Kconfig @@ -5,5 +5,7 @@ config DRM_LOGICVC select DRM_KMS_HELPER select DRM_KMS_DMA_HELPER select DRM_GEM_DMA_HELPER + select REGMAP + select REGMAP_MMIO help DRM display driver for the logiCVC programmable logic block from Xylon -- 2.25.1 -- Jingfeng
Re: [PATCH v2 6/6] drm/vs: Add hdmi driver
On Wed, Oct 25, 2023 at 06:39:57PM +0800, Keith Zhao wrote:
> +static int starfive_hdmi_setup(struct starfive_hdmi *hdmi,
> +struct drm_display_mode *mode)
> +{
> + hdmi_modb(hdmi, STARFIVE_BIAS_CONTROL, STARFIVE_BIAS_ENABLE,
> STARFIVE_BIAS_ENABLE);
> + hdmi_writeb(hdmi, STARFIVE_RX_CONTROL, STARFIVE_RX_ENABLE);
> + hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
You're never using that variable.
> + hdmi->tmds_rate = mode->clock * 1000;
> + starfive_hdmi_phy_clk_set_rate(hdmi);
> +
> + while (!(hdmi_readb(hdmi, STARFIVE_PRE_PLL_LOCK_STATUS) & 0x1))
> + continue;
> + while (!(hdmi_readb(hdmi, STARFIVE_POST_PLL_LOCK_STATUS) & 0x1))
> + continue;
> +
> + /*turn on LDO*/
> + hdmi_writeb(hdmi, STARFIVE_LDO_CONTROL, STARFIVE_LDO_ENABLE);
> + /*turn on serializer*/
> + hdmi_writeb(hdmi, STARFIVE_SERIALIER_CONTROL,
> STARFIVE_SERIALIER_ENABLE);
> +
> + starfive_hdmi_tx_phy_power_down(hdmi);
> + starfive_hdmi_config_video_timing(hdmi, mode);
> + starfive_hdmi_tx_phy_power_on(hdmi);
> +
> + starfive_hdmi_tmds_driver_on(hdmi);
> + starfive_hdmi_sync_tmds(hdmi);
> +
> + return 0;
> +}
> +
> +static void starfive_hdmi_encoder_mode_set(struct drm_encoder *encoder,
> +struct drm_display_mode *mode,
> +struct drm_display_mode *adj_mode)
> +{
> + struct starfive_hdmi *hdmi = encoder_to_hdmi(encoder);
> +
> + drm_mode_copy(>previous_mode, adj_mode);
> +}
You're never using that field, and it's not the previous mode, but the current
mode.
> +static void starfive_hdmi_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct starfive_hdmi *hdmi = encoder_to_hdmi(encoder);
> + struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> + int ret, idx;
> + struct drm_device *drm = hdmi->connector.dev;
> +
> + if (drm && !drm_dev_enter(drm, ))
> + return;
> +
> + ret = pm_runtime_get_sync(hdmi->dev);
> + if (ret < 0)
> + return;
pm_runtime_resume_and_get is what you want here
> + mdelay(10);
???
Sprinkling delays here and there isn't great. What is the issue this is
trying to workaround?
> + starfive_hdmi_setup(hdmi, mode);
> +
> + if (drm)
> + drm_dev_exit(idx);
> +}
> +
> +static void starfive_hdmi_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct starfive_hdmi *hdmi = encoder_to_hdmi(encoder);
> +
> + int idx;
> + struct drm_device *drm = hdmi->connector.dev;
> +
> + if (drm && !drm_dev_enter(drm, ))
> + return;
> +
> + pm_runtime_put(hdmi->dev);
pm_runtime calls should be safe anytime. If you need to protect them
through a drm_dev_enter call, that call should be in the pm_runtime hook
itself.
> + if (drm)
> + drm_dev_exit(idx);
> +}
> +
> +static int
> +starfive_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state)
> +{
> + bool valid = false;
> + struct drm_display_mode *mode = _state->adjusted_mode;
> + struct vs_crtc_state *vs_crtc_state = to_vs_crtc_state(crtc_state);
> +
> + vs_crtc_state->encoder_type = encoder->encoder_type;
> + vs_crtc_state->output_fmt = MEDIA_BUS_FMT_RGB888_1X24;
Ok, so those two will always be ENCODER_TMDS and RGB888. Drop them from
your CRTC state and use the proper defines there.
> + const struct pre_pll_config *cfg = pre_pll_cfg_table;
> + int pclk = mode->clock * 1000;
> +
> + for (; cfg->pixclock != 0; cfg++) {
> + if (pclk == cfg->pixclock) {
> + if (pclk > 29700)
> + continue;
> +
> + valid = true;
> + break;
> + }
> + }
> +
> + return (valid) ? 0 : -EINVAL;
> +}
> +
> +static const struct drm_encoder_helper_funcs
> starfive_hdmi_encoder_helper_funcs = {
> + .enable = starfive_hdmi_encoder_enable,
> + .disable= starfive_hdmi_encoder_disable,
> + .mode_set = starfive_hdmi_encoder_mode_set,
> + .atomic_check = starfive_hdmi_encoder_atomic_check,
> +};
> +
> +static enum drm_connector_status
> +starfive_hdmi_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct starfive_hdmi *hdmi = connector_to_hdmi(connector);
> + struct drm_device *drm = hdmi->connector.dev;
> + int ret;
> + int idx;
> +
> + if (drm && !drm_dev_enter(drm, ))
> + return connector_status_disconnected;
> +
> + ret = pm_runtime_get_sync(hdmi->dev);
> + if (ret < 0)
> + return ret;
> +
> + ret = (hdmi_readb(hdmi, HDMI_STATUS) & m_HOTPLUG) ?
> + connector_status_connected : connector_status_disconnected;
> + pm_runtime_put(hdmi->dev);
> +
> + if
[PATCH] drm/amd/display: add kernel docs for dc_stream_forward_crc_window
Add kernel documentation for the dc_stream_forward_crc_window Signed-off-by: Sagar Vashnav --- drivers/gpu/drm/amd/display/dc/core/dc.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index 1729fb727..5ab35e482 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -528,6 +528,19 @@ dc_stream_forward_dmcu_crc_window(struct dmcu *dmcu, dmcu->funcs->forward_crc_window(dmcu, rect, mux_mapping); } +/** + * dc_stream_forward_crc_window() - Forward CRC window configuration to DMUB or DMCU. + * @stream: The stream state to forward CRC window configuration for. + * @rect: Pointer to the rectangle defining the CRC window coordinates. + * @is_stop: Flag indicating whether the CRC capture should be stopped. + + * This function is responsible for forwarding the CRC window configuration + * for a given stream to either the DMUB or DMCU, depending on their availability. + + * Return: + * %true if the CRC window configuration was successfully forwarded; + * %false if the stream was not found or CRC forwarding is not supported. + */ bool dc_stream_forward_crc_window(struct dc_stream_state *stream, struct rect *rect, bool is_stop) -- 2.34.1
Re: [PATCH v2 5/6] drm/vs: Add KMS crtc
On Wed, Oct 25, 2023 at 06:39:56PM +0800, Keith Zhao wrote:
> +static struct drm_crtc_state *
> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> +{
> + struct vs_crtc_state *ori_state;
> + struct vs_crtc_state *state;
> +
> + if (!crtc->state)
> + return NULL;
> +
> + ori_state = to_vs_crtc_state(crtc->state);
> + state = kzalloc(sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return NULL;
> +
> + __drm_atomic_helper_crtc_duplicate_state(crtc, >base);
> +
> + state->output_fmt = ori_state->output_fmt;
That field is never set in your patch.
> + state->encoder_type = ori_state->encoder_type;
That isn't either, and it's not clear why you would need the
encoder_type stored in the CRTC?
> + state->bpp = ori_state->bpp;
You seem to derive that from output_fmt, it doesn't need to be in the
CRTC state.
> + state->underflow = ori_state->underflow;
Assuming you're setting this from the interrupt handler, it's unsafe,
you shouldn't do that. What are you using it for?
> +static const struct drm_prop_enum_list vs_sync_mode_enum_list[] = {
> + { VS_SINGLE_DC, "single dc mode" },
> + { VS_MULTI_DC_PRIMARY, "primary dc for multi dc mode" },
> + { VS_MULTI_DC_SECONDARY,"secondary dc for multi dc mode" },
> +};
Custom driver properties are a no-go:
https://docs.kernel.org/gpu/drm-kms.html#requirements
And
https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
> +void vs_dc_enable(struct vs_dc *dc, struct drm_crtc *crtc)
> +{
> + struct vs_crtc_state *crtc_state = to_vs_crtc_state(crtc->state);
> + struct drm_display_mode *mode = >state->adjusted_mode;
> + struct dc_hw_display display;
Why are you rolling your own structure here, if it's exactly equivalent
to what drm_display_mode and the crtc_state provide?
> +void vs_dc_commit(struct vs_dc *dc)
> +{
> + dc_hw_enable_shadow_register(>hw, false);
> +
> + dc_hw_commit(>hw);
> +
> + if (dc->first_frame)
> + dc->first_frame = false;
> +
> + dc_hw_enable_shadow_register(>hw, true);
> +}
It's not clear to me what you're trying to do here, does the hardware
have latched registers that are only updated during vblank?
> +static int dc_bind(struct device *dev, struct device *master, void *data)
> +{
> + struct drm_device *drm_dev = data;
> + struct vs_dc *dc = dev_get_drvdata(dev);
> + struct device_node *port;
> + struct vs_crtc *crtc;
> + struct vs_dc_info *dc_info;
> + struct vs_plane *plane;
> + struct vs_plane_info *plane_info;
> + int i, ret;
> + u32 ctrc_mask = 0;
> +
> + if (!drm_dev || !dc) {
> + dev_err(dev, "devices are not created.\n");
> + return -ENODEV;
> + }
> +
> + ret = dc_init(dev);
> + if (ret < 0) {
> + drm_err(drm_dev, "Failed to initialize DC hardware.\n");
> + return ret;
> + }
> +
> + port = of_get_child_by_name(dev->of_node, "port");
> + if (!port) {
> + drm_err(drm_dev, "no port node found\n");
> + return -ENODEV;
> + }
> + of_node_put(port);
> +
> + dc_info = dc->hw.info;
> +
> + for (i = 0; i < dc_info->panel_num; i++) {
> + crtc = vs_crtc_create(drm_dev, dc_info);
> + if (!crtc) {
> + drm_err(drm_dev, "Failed to create CRTC.\n");
> + ret = -ENOMEM;
> + return ret;
> + }
> +
> + crtc->base.port = port;
> + crtc->dev = dev;
> + dc->crtc[i] = crtc;
> + ctrc_mask |= drm_crtc_mask(>base);
> + }
> +
> + for (i = 0; i < dc_info->plane_num; i++) {
> + plane_info = (struct vs_plane_info *)_info->planes[i];
> +
> + if (!strcmp(plane_info->name, "Primary") ||
> !strcmp(plane_info->name, "Cursor")) {
> + plane = vs_plane_create(drm_dev, plane_info,
> dc_info->layer_num,
> +
> drm_crtc_mask(>crtc[0]->base));
> + } else if (!strcmp(plane_info->name, "Primary_1") ||
> +!strcmp(plane_info->name, "Cursor_1")) {
Please use an enum and an id there.
> +static int vs_plane_atomic_set_property(struct drm_plane *plane,
> + struct drm_plane_state *state,
> + struct drm_property *property,
> + uint64_t val)
> +{
> + struct drm_device *dev = plane->dev;
> + struct vs_plane *vs_plane = to_vs_plane(plane);
> + struct vs_plane_state *vs_plane_state = to_vs_plane_state(state);
> + int ret = 0;
> +
> + if (property == vs_plane->degamma_mode) {
> + if (vs_plane_state->degamma != val) {
> + vs_plane_state->degamma = val;
> + vs_plane_state->degamma_changed = true;
> +
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
On 25.10.23 15:23, Huacai Chen wrote:
> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> wrote:
>>
>> Javier, Dave, Sima,
>>
>> On 23.10.23 00:54, Evan Preston wrote:
>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 09.10.23 10:54, Huacai Chen wrote:
>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya
>> wrote:
>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen
wrote:
> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> Leemhuis) wrote:
>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>
>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel
>>> HD
>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a
>>> blank
>>> screen after boot until the display manager starts... if it does
>>> start
>>> at all. Using the nomodeset kernel parameter seems to be a
>>> workaround.
>>>
>>> I've bisected this to commit
>>> 60aebc9559492cea6a9625f514a8041717e3a2e4
>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>> subsys_initcall_sync").
>>
As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
again. So I guess the reason:
>
> Well, this to me still looks a lot (please correct me if I'm wrong) like
> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> if I understood things correctly. Or is there a proper fix for this
> already in the works and I just missed this? Or is there some good
> reason why this won't/can't be fixed?
DRM_SIMPLEDRM was enabled but it didn't work at all because there was
no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
blank screen. Of course it is valuable to investigate further about
DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
I don't have a same machine.
>>
>> Side note: Huacai, have you tried working with Jaak to get down to the
>> real problem? Evan, might you be able to help out here?
> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
Yeah, understood, already suspected something like that, thx for confirming.
>> But I write this mail for a different reason:
>>
>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>> screen after boot and a rapidly flashing device-access-status
>>> indicator.
>>
>> This additional report makes me wonder if we should revert the culprit
>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>> might lead to regressions for some users? But the patch description says
>> that this is not a common configuration, so can we maybe get away with that?
>>From my point of view, this is not a regression, 60aebc9559492c
> doesn't cause a problem, but exposes a problem.
>From my understanding of Linus stance in cases like this I think that
aspect doesn't matter. To for example quote
https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xbamgkf2kpguzpb5ama...@mail.gmail.com/
""
But it ended up exposing another problem, and as such caused a kernel
upgrade to fail for a user. So it got reverted.
"""
For other examples of his view see the bottom half of
https://docs.kernel.org/process/handling-regressions.html
We could bring Linus in to clarify if needed, but I for now didn't CC
him, as I hope we can solve this without him.
> So we need to fix the
> real problem (SIMPLEDRM has a blank screen on some conditions). This
> needs Jaak or Evan's help.
I'm all for solving the real problem, but if that is not possible within
a reasonable timeframe (which seems to be the case here) I assume Linus
in cases like this would want the culprit to be reverted. Unless of
cause that itself might cause a regression (which is possible, as the
commit made it into 6.5), then things become tricky.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
sysfb_init() from device_initcall to subsys_initcall_sync") there is
no platform device created for SIMPLEDRM at early stage, so it seems
also "no problem".
>>> I don't understand above. You mean that after that commit the
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
Huacai Chen writes:
Hello,
> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> wrote:
[...]
>>
>> This additional report makes me wonder if we should revert the culprit
>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>> might lead to regressions for some users? But the patch description says
>> that this is not a common configuration, so can we maybe get away with that?
> From my point of view, this is not a regression, 60aebc9559492c
> doesn't cause a problem, but exposes a problem. So we need to fix the
> real problem (SIMPLEDRM has a blank screen on some conditions). This
> needs Jaak or Evan's help.
>
I agree with this.
> Huacai
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
[PATCH v2 2/2] drm/todo: Add entry to clean up former seltests suites
Most of those suites are undocumented and aren't really clear about what they are testing. Let's add a TODO entry as a future task to get started into KUnit and DRM. Signed-off-by: Maxime Ripard --- Documentation/gpu/todo.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 03fe5d1247be..b62c7fa0c2bc 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -621,6 +621,23 @@ Contact: Javier Martinez Canillas Level: Intermediate +Clean up and document former selftests suites +- + +Some KUnit test suites (drm_buddy, drm_cmdline_parser, drm_damage_helper, +drm_format, drm_framebuffer, drm_dp_mst_helper, drm_mm, drm_plane_helper and +drm_rect) are former selftests suites that have been converted over when KUnit +was first introduced. + +These suites were fairly undocumented, and with different goals than what unit +tests can be. Trying to identify what each test in these suites actually test +for, whether that makes sense for a unit test, and either remove it if it +doesn't or document it if it does would be of great help. + +Contact: Maxime Ripard + +Level: Intermediate + Enable trinity for DRM -- -- 2.41.0
[PATCH v2 1/2] drm/tests: Remove slow tests
Both the drm_buddy and drm_mm tests have been converted from selftest to
kunit recently.
However, a significant portion of them are trying to exert some part of
their API over a huge number of iterations and with random variations of
their parameters. They are thus more a way to discover new bugs than
actual unit tests.
This is fine in itself but leads to very slow runtime (up to 25s for
some drm_test_mm_reserve and drm_test_mm_insert on a Ryzen 7950x while
running the tests in qemu) which make them a poor fit for kunit.
Let's remove those tests from the drm_mm and drm_buddy test suites for
now, and if it's ever needed we can always create proper unit tests for
them later on.
This made the entire DRM tests execution time (as of v6.6-rc1) come from
65s to less than .5s on a Ryzen 7950x system when running under qemu,
and from 9 minutes to about 4s on a RaspberryPi4.
Suggested-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
Changes since v1:
- Don't remove all the tests but only the ones taking too long
---
drivers/gpu/drm/tests/drm_buddy_test.c | 465 --
drivers/gpu/drm/tests/drm_mm_test.c| 1904
2 files changed, 2369 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index 09ee6f6af896..ea2af6bd9abe 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -13,315 +13,11 @@
#include "../lib/drm_random.h"
-#define TIMEOUT(name__)
\
- unsigned long name__ = jiffies + MAX_SCHEDULE_TIMEOUT
-
-static unsigned int random_seed;
-
static inline u64 get_size(int order, u64 chunk_size)
{
return (1 << order) * chunk_size;
}
-__printf(2, 3)
-static bool __timeout(unsigned long timeout, const char *fmt, ...)
-{
- va_list va;
-
- if (!signal_pending(current)) {
- cond_resched();
- if (time_before(jiffies, timeout))
- return false;
- }
-
- if (fmt) {
- va_start(va, fmt);
- vprintk(fmt, va);
- va_end(va);
- }
-
- return true;
-}
-
-static void __dump_block(struct kunit *test, struct drm_buddy *mm,
-struct drm_buddy_block *block, bool buddy)
-{
- kunit_err(test, "block info: header=%llx, state=%u, order=%d,
offset=%llx size=%llx root=%d buddy=%d\n",
- block->header, drm_buddy_block_state(block),
- drm_buddy_block_order(block),
drm_buddy_block_offset(block),
- drm_buddy_block_size(mm, block), !block->parent,
buddy);
-}
-
-static void dump_block(struct kunit *test, struct drm_buddy *mm,
- struct drm_buddy_block *block)
-{
- struct drm_buddy_block *buddy;
-
- __dump_block(test, mm, block, false);
-
- buddy = drm_get_buddy(block);
- if (buddy)
- __dump_block(test, mm, buddy, true);
-}
-
-static int check_block(struct kunit *test, struct drm_buddy *mm,
- struct drm_buddy_block *block)
-{
- struct drm_buddy_block *buddy;
- unsigned int block_state;
- u64 block_size;
- u64 offset;
- int err = 0;
-
- block_state = drm_buddy_block_state(block);
-
- if (block_state != DRM_BUDDY_ALLOCATED &&
- block_state != DRM_BUDDY_FREE && block_state != DRM_BUDDY_SPLIT) {
- kunit_err(test, "block state mismatch\n");
- err = -EINVAL;
- }
-
- block_size = drm_buddy_block_size(mm, block);
- offset = drm_buddy_block_offset(block);
-
- if (block_size < mm->chunk_size) {
- kunit_err(test, "block size smaller than min size\n");
- err = -EINVAL;
- }
-
- /* We can't use is_power_of_2() for a u64 on 32-bit systems. */
- if (block_size & (block_size - 1)) {
- kunit_err(test, "block size not power of two\n");
- err = -EINVAL;
- }
-
- if (!IS_ALIGNED(block_size, mm->chunk_size)) {
- kunit_err(test, "block size not aligned to min size\n");
- err = -EINVAL;
- }
-
- if (!IS_ALIGNED(offset, mm->chunk_size)) {
- kunit_err(test, "block offset not aligned to min size\n");
- err = -EINVAL;
- }
-
- if (!IS_ALIGNED(offset, block_size)) {
- kunit_err(test, "block offset not aligned to block size\n");
- err = -EINVAL;
- }
-
- buddy = drm_get_buddy(block);
-
- if (!buddy && block->parent) {
- kunit_err(test, "buddy has gone fishing\n");
- err = -EINVAL;
- }
-
- if (buddy) {
- if (drm_buddy_block_offset(buddy) != (offset ^ block_size)) {
- kunit_err(test, "buddy has wrong offset\n");
- err = -EINVAL;
- }
-
-
Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570
On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
wrote:
>
> Javier, Dave, Sima,
>
> On 23.10.23 00:54, Evan Preston wrote:
> > On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >> Leemhuis) wrote:
> >>> On 09.10.23 10:54, Huacai Chen wrote:
> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya
> wrote:
> > On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen
> >> wrote:
> >>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>> Leemhuis) wrote:
> On 13.09.23 14:02, Jaak Ristioja wrote:
> >
> > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel
> > HD
> > Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a
> > blank
> > screen after boot until the display manager starts... if it does
> > start
> > at all. Using the nomodeset kernel parameter seems to be a
> > workaround.
> >
> > I've bisected this to commit
> > 60aebc9559492cea6a9625f514a8041717e3a2e4
> > ("drivers/firmware: Move sysfb_init() from device_initcall to
> > subsys_initcall_sync").
>
> >> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >> again. So I guess the reason:
> >>>
> >>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>> if I understood things correctly. Or is there a proper fix for this
> >>> already in the works and I just missed this? Or is there some good
> >>> reason why this won't/can't be fixed?
> >>
> >> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >> blank screen. Of course it is valuable to investigate further about
> >> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >> I don't have a same machine.
>
> Side note: Huacai, have you tried working with Jaak to get down to the
> real problem? Evan, might you be able to help out here?
No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
>
> But I write this mail for a different reason:
>
> > I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > screen after boot and a rapidly flashing device-access-status
> > indicator.
>
> This additional report makes me wonder if we should revert the culprit
> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> might lead to regressions for some users? But the patch description says
> that this is not a common configuration, so can we maybe get away with that?
>From my point of view, this is not a regression, 60aebc9559492c
doesn't cause a problem, but exposes a problem. So we need to fix the
real problem (SIMPLEDRM has a blank screen on some conditions). This
needs Jaak or Evan's help.
Huacai
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> >> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >> no platform device created for SIMPLEDRM at early stage, so it seems
> >> also "no problem".
> > I don't understand above. You mean that after that commit the platform
> > device is also none, right?
> No. The SIMPLEDRM driver needs a platform device to work, and that
> commit makes the platform device created earlier. So, before that
> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> commit, SIMPLEDRM works, but the screen is blank.
>
> Huacai
> >
> > Confused...
> >
> > --
> > An old man doll... just what I always wanted! - Clara
>
>
> >
> >
[PATCH 2/2] drm/logicvc: Define max dimensions from USHRT_MAX
Use the existing macro instead of redefining it. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/logicvc/logicvc_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/logicvc/logicvc_regs.h b/drivers/gpu/drm/logicvc/logicvc_regs.h index 4aae27e9ba2b..0fc413fef6dd 100644 --- a/drivers/gpu/drm/logicvc/logicvc_regs.h +++ b/drivers/gpu/drm/logicvc/logicvc_regs.h @@ -10,7 +10,7 @@ #ifndef _LOGICVC_REGS_H_ #define _LOGICVC_REGS_H_ -#define LOGICVC_DIMENSIONS_MAX (BIT(16) - 1) +#define LOGICVC_DIMENSIONS_MAX USHRT_MAX #define LOGICVC_HSYNC_FRONT_PORCH_REG 0x00 #define LOGICVC_HSYNC_REG 0x08 -- 2.42.0
[PATCH 1/2] drm/logicvc: Avoid possible overflow in layer buffer setup variables
The buffer_sel, voffset and hoffset values are calculated from u32
values and might overflow under certain conditions.
Move them to u32 definitions instead of u8/u16 to avoid the issue.
Signed-off-by: Paul Kocialkowski
Reported-by: Dan Carpenter
Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller")
---
drivers/gpu/drm/logicvc/logicvc_layer.c | 6 +++---
drivers/gpu/drm/logicvc/logicvc_layer.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.c
b/drivers/gpu/drm/logicvc/logicvc_layer.c
index 464000aea765..eea22379d042 100644
--- a/drivers/gpu/drm/logicvc/logicvc_layer.c
+++ b/drivers/gpu/drm/logicvc/logicvc_layer.c
@@ -268,9 +268,9 @@ int logicvc_layer_buffer_find_setup(struct logicvc_drm
*logicvc,
u32 layer_stride = layer_bytespp * logicvc->config.row_stride;
u32 base_offset = layer->config.base_offset * layer_stride;
u32 buffer_offset = layer->config.buffer_offset * layer_stride;
- u8 buffer_sel = 0;
- u16 voffset = 0;
- u16 hoffset = 0;
+ u32 buffer_sel = 0;
+ u32 voffset = 0;
+ u32 hoffset = 0;
phys_addr_t fb_addr;
u32 fb_offset;
u32 gap;
diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.h
b/drivers/gpu/drm/logicvc/logicvc_layer.h
index 4a4b02e9b819..a06feeda3abf 100644
--- a/drivers/gpu/drm/logicvc/logicvc_layer.h
+++ b/drivers/gpu/drm/logicvc/logicvc_layer.h
@@ -18,9 +18,9 @@
#define LOGICVC_LAYER_ALPHA_PIXEL 1
struct logicvc_layer_buffer_setup {
- u8 buffer_sel;
- u16 voffset;
- u16 hoffset;
+ u32 buffer_sel;
+ u32 voffset;
+ u32 hoffset;
};
struct logicvc_layer_config {
--
2.42.0
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending
On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote: On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote: On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote: Thanks for taking the time to review this Tvrtko, replies inline below. alan:snip Main concern is that we need to be sure there are no possible ill-effects, like letting the GPU/GuC scribble on some memory we unmapped (or will unmap), having let the suspend continue after timing out, and not perhaps doing the forced wedge like wait_for_suspend() does on the existing timeout path. alan: this will not happen because the held wakeref is never force-released after the timeout - so what happens is the kernel would bail the suspend. How does it know to fail the suspend when there is no error code returned with this timeout? Maybe a stupid question.. my knowledge of suspend-resume paths was not great even before I forgot it all. alan:Tvrtko, you and I both sir. (apologies for the tardy response yet again busy week). So i did trace back the gt->wakeref before i posted these patches and discovered that runtime get/put call, i believe that the first 'get' leads to __intel_wakeref_get_first which calls intel_runtime_pm_get via rpm_get helper and eventually executes a pm_runtime_get_sync(rpm->kdev); (hanging off i915). (ofc, there is a corresponding for '_put_last') - so non-first, non-last increases the counter for the gt... but this last miss will mean kernel knows i915 hasnt 'put' everything. alan:snip Recap: so in both cases (original vs this patch), if we had a buggy gt-wakeref leak, we dont get invalid guc-accesses, but without this patch, we wait forever, and with this patch, we get some messages and eventually bail the suspend. It is not possible to wait for lost G2H in something like intel_uc_suspend() and simply declare "bad things happened" if it times out there, and forcibly clean it all up? (Which would include releasing all the abandoned pm refs, so this patch wouldn't be needed.) alan: I'm not sure if intel_uc_suspend should be held up by gt-level wakeref check unless huc/guc/gsc-uc are the only ones ever taking a gt wakeref. As we already know, what we do know from a uc-perspective: - ensure the outstanding guc related workers is flushed which we didnt before (addressed by patch #1). - any further late H2G-SchedDisable is not leaking wakerefs when calling H2G and not realizing it failed (addressed by patch #2). - (we already), "forcibly clean it all up" at the end of the intel_uc_suspend when we do the guc reset and cleanup all guc-ids. (pre-existing upstream code) - we previously didnt have a coherrent guarantee that "this is the end" i.e. no more new request after intel_uc_suspend. I mean by code logic, we thought we did (thats why intel_uc_suspend ends wth a guc reset), but we now know otherwise. So we that fix by adding the additional rcu_barrier (also part of patch #2). It is not clear to me from the above if that includes cleaning up the outstanding CT replies or no. But anyway.. That said, patch-3 is NOT fixing a bug in guc -its about "if we ever have a future racy gt-wakeref late-leak somewhere - no matter which subsystem took it (guc is not the only subsystem taking gt wakerefs), we at least don't hang forever in this code. Ofc, based on that, even without patch-3 i am confident the issue is resolved anyway. So we could just drop patch-3 is you prefer? .. given this it does sound to me that if you are confident patch 3 isn't fixing anything today that it should be dropped. Regards, Tvrtko
Re: [PATCH v2 1/6] dt-bindings: display: Add yamls for JH7110 display system
On 25/10/2023 12:39, Keith Zhao wrote:
> StarFive SoCs JH7110 display system:
A nit, subject: drop second/last, redundant "yamls for". The
"dt-bindings" prefix is already stating that these are bindings, so
format is fixed.
> lcd-controller bases verisilicon dc8200 IP,
> and hdmi bases Innosilicon IP. Add bindings for them.
Please make it a proper sentences, with proper wrapping.
>
> also update MAINTAINERS for dt-bindings
Not a sentence, but also not really needed.
>
> about this patch, I tested the dtbs_check and dt_binding_check
> with the result pass.
> Based on the feedback of the previous version, the corresponding arrangement
> is made
Not relevant, so not really suitable for commit msg.
>
> Signed-off-by: Keith Zhao
> ---
> .../starfive/starfive,display-subsystem.yaml | 41 +++
> .../starfive/starfive,jh7110-dc8200.yaml | 109 ++
> .../starfive/starfive,jh7110-inno-hdmi.yaml | 85 ++
> MAINTAINERS | 7 ++
> 4 files changed, 242 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.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
>
> diff --git
> a/Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
>
> b/Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
> new file mode 100644
> index 0..f45b97b08
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/display/starfive/starfive,display-subsystem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Starfive DRM master device
What is DRM in hardware? I know Digital Rights Management, but then
subsystem seems wrong. If you mean Linux DRM, then Linux is not a
hardware, so drop all Linuxisms and describe hardware.
> +
> +maintainers:
> + - Keith Zhao
> + - ShengYang Chen
> +
> +description:
> + The Starfive DRM master device is a virtual device needed to list all
Virtual device? Then not suitable for bindings, sorry.
> + display controller or other display interface nodes that comprise the
> + graphics subsystem.
> +
> +properties:
> + compatible:
> +const: starfive,display-subsystem
> +
> + ports:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
No, ports is not phandle-array. ports is object, always.
> +description:
> + Should contain a list of phandles pointing to display interface ports
> + of display controller devices. Display controller definitions as
> defined
> + in Documentation/devicetree/bindings/display/starfive/
> + starfive,jh7110-dc8200.yaml
Use standard graph ports, not some own, custom property.
Anyway, entire binding should be dropped. You do not need it even.
> +
> +required:
> + - compatible
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +display-subsystem {
> +compatible = "starfive,display-subsystem";
> +ports = <_out>;
> +};
> diff --git
> a/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
>
> b/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
> new file mode 100644
> index 0..87051cddf
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/display/starfive/starfive,jh7110-dc8200.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: StarFive display controller
> +
> +description:
> + The StarFive SoC uses the display controller based on Verisilicon IP
> + to transfer the image data from a video memory buffer to an external
> + LCD interface.
> +
> +maintainers:
> + - Keith Zhao
> +
> +properties:
> + compatible:
> +const: starfive,jh7110-dc8200
> +
> + reg:
> +minItems: 1
> +items:
> + - description:
> + host interface
In one line.
- description: host interface
> + - description:
> + display physical base address and length.
Drop redundant parts: base address and length. Everything in reg for
MMIO would have it...
> +
> + interrupts:
> +items:
> + - description: The interrupt will be generated when DC finish one frame
> +
> + clocks:
> +items:
> + - description: Clock for display system noc bus.
> + - description: Pixel clock for display channel 0.
> + - description: Pixel clock for display channel 1.
> + - description: Core clock for display
Re: [PATCH] drm/doc: ci: Require more context for flaky tests
On 23/10/2023 12:09, Maxime Ripard wrote: On Fri, Oct 20, 2023 at 01:33:59AM -0300, Helen Koike wrote: On 19/10/2023 13:51, Helen Koike wrote: On 19/10/2023 06:46, Maxime Ripard wrote: Flaky tests can be very difficult to reproduce after the facts, which will make it even harder to ever fix. Let's document the metadata we agreed on to provide more context to anyone trying to address these fixes. Link: https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/ Signed-off-by: Maxime Ripard --- Documentation/gpu/automated_testing.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/gpu/automated_testing.rst b/Documentation/gpu/automated_testing.rst index 469b6fb65c30..2dd0e221c2c3 100644 --- a/Documentation/gpu/automated_testing.rst +++ b/Documentation/gpu/automated_testing.rst @@ -67,6 +67,19 @@ Lists the tests that for a given driver on a specific hardware revision are known to behave unreliably. These tests won't cause a job to fail regardless of the result. They will still be run. +Each new flake entry must be associated with a link to a bug report to What do you mean by but report? Just a link to an email to the mailing list is enough? Also, I had made a mistake to the first flakes lists, which I corrected with https://www.spinics.net/lists/kernel/msg4959629.html (there was a bug in my script which ended up erroneous adding a bunch of tests in the flake list, so I cleaned them up), I would like to kind request to let me add those documentation in a future patch to not block that patch series. Thanks Helen +the author of the affected driver, the board name or Device Tree name of +the board, the first kernel version affected, and an approximation of +the failure rate. + +They should be provided under the following format:: + + # Bug Report: $LORE_OR_PATCHWORK_URL I wonder if the commit adding the test into the flakes.txt file with and Acked-by from the device maintainer shouldn't be already considered the Bug Report. I guess it could, yes. I think I'd still prefer the link since it would allow to also evaluate if the issue is fixed or not now. + # Board Name: broken-board.dtb Maybe Board Name isn't required, since it is already in the name of the file. I have no idea how the i915 naming works, but on ARM at least the name of the file contains the name of the SoC, not the board where it was observed. right, yeah we could use the dtb to be more clear/precise, no problem. + # Version: 6.6-rc1 + # Failure Rate: 100 Maybe also: # Pipeline url: https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/1014435 Sounds like a good idea yeah :) Are those artifacts archived/deleted at some point or do they stick around forever? Good point, I asked the admins, they stick for 4 weeks (could be more, but it is not forever) :( All this info will complicated a bit the update-xfails.py script, but well, we can handle... (see https://patchwork.kernel.org/project/dri-devel/patch/20231020034124.136295-4-helen.ko...@collabora.com/ ) We need to update that script to make life easier. I guess we could just add a template for now? It would keep the script easy and yet still hint its user that we want more data ack Thanks Helen Vignesh sent a patch adding at least the pipeline url to the file https://patchwork.kernel.org/project/linux-arm-msm/patch/20231019070650.61159-9-vignesh.ra...@collabora.com/ but to meet this doc that needs to be updated too. Sure, I'll update it Maxime
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Thu, Oct 19, 2023 at 02:19:51PM +0300, Dmitry Baryshkov wrote: > On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote: > > > > On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote: > > > The MIPI DSI links do not fully fall into the DRM callbacks model. > > > > Explaining why would help > > A kind of explanation comes afterwards, but probably I should change > the order of the phrases and expand it: > > The atomic_pre_enable / atomic_enable and correspondingly > atomic_disable / atomic_post_disable expect that the bridge links > follow a simple paradigm: either it is off, or it is on and streaming > video. Thus, it is fine to just enable the link at the enable time, > doing some preparations during the pre_enable. > > But then it causes several issues with DSI. First, some of the DSI > bridges and most of the DSI panels would like to send commands over > the DSI link to setup the device. What prevent them from doing it in enable when the link is enabled? > Next, some of the DSI hosts have limitations on sending the commands. > The proverbial sunxi DSI host can not send DSI commands after the > video stream has started. Thus most of the panels have opted to send > all DSI commands from pre_enable (or prepare) callback (before the > video stream has started). I'm not sure we should account for a single driver when designing a framework. We should focus on designing something sound, and then making that driver work with whatever we designed, but not the other way around. And if we can't, we should get rid of that driver because it's de-facto unmaintainable. And I'm saying that as the author of that driver. > However this leaves no good place for the DSI host to power up the DSI > link. By default the host's pre_enable callback is called after the > DSI bridge's pre_enable. For quite some time we were powering up the > DSI link from mode_set. This doesn't look fully correct. Yeah, it's not. > And also we got into the issue with ps8640 bridge, which requires for > the DSI link to be quiet / unpowered at the bridge's reset time. > > Dave has come with the idea of pre_enable_prev_first / > prepare_prev_first flags, which attempt to solve the issue by > reversing the order of pre_enable callbacks. This mostly solves the > issue. However during this cycle it became obvious that this approach > is not ideal too. There is no way for the DSI host to know whether the > DSI panel / bridge has been updated to use this flag or not, see the > discussion at [1]. Yeah. Well, that happens. I kind of disagree with Neil here though when he says that "A panel driver should not depend on features of a DSI controller". Panels definitely rely on particular features, like the number of lanes, the modes supported, etc. Panels shouldn't depend on a particular driver *behaviour*. But the features are fine. For our particular discussion, I think that that kind of discussion is a dead-end, and we just shouldn't worry about it. Yes, some panels have not yet been updated to take the new flags into account. However, the proper thing to do is to update them if we see a problem with that (and thus move forward to the ideal solution), not revert the beginning of that feature enablement (thus moving away from where we want to end up in). > Thus comes this proposal. It allows for the panels to explicitly bring > the link up and down at the correct time, it supports automatic use > case, where no special handling is required. And last, but not least, > it allows the DSI host to note that the bridge / panel were not > updated to follow new protocol and thus the link should be powered on > at the mode_set time. This leaves us with the possibility of dropping > support for this workaround once all in-kernel drivers are updated. I'm kind of skeptical for these kind of claims that everything will be automatic and will be handled fine. What if we have conflicting requirements, for example two bridges drivers that would request the power up at different times? Also, we would still need to update every single panel driver, which is going to create a lot of boilerplate that people might get wrong. I have the feeling that we should lay out the problem without talking about any existing code base first. So, what does the MIPI-DSI spec requires and what does panels and bridges expect? Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/i915/mtl: avoid stringop-overflow warning
On Tue, 24 Oct 2023, Andi Shyti wrote:
> Hi Jani,
>
>> > static void rc6_res_reg_init(struct intel_rc6 *rc6)
>> > {
>> > - memset(rc6->res_reg, INVALID_MMIO_REG.reg, sizeof(rc6->res_reg));
>>
>> That's just bollocks. memset() is byte granularity, while
>> INVALID_MMIO_REG.reg is u32. If the value was anything other than 0,
>> this would break.
>
> Actually it's:
>
>void *memset(void *s, int c, size_t count)
And? It still sets each byte in s to (the lowest 8 bits of) c.
>
>> And you're not supposed to look at the guts of i915_reg_t to begin with,
>> that's why it's a typedef. Basically any code that accesses the members
>> of i915_reg_t outside of its implementation are doing it wrong.
>>
>> Reviewed-by: Jani Nikula
>
> in any case, I agree with your argument, but why can't we simply
> do:
>
>memset(rc6->res_reg, 0, sizeof(rc6->res_reg));
>
> ?
We can simply do a lot of things in C, but IMO that's semantically
wrong. i915_reg_t is supposed to be an opaque type. We're not supposed
to know what it contains, and what values are valid or invalid for it.
That's one of the reasons we have i915_reg_t in the first place (type
safety being the primary one).
Basically you should be able to do
-#define INVALID_MMIO_REG _MMIO(0)
+#define INVALID_MMIO_REG _MMIO(0xdeadbeef)
and expect everything to still work.
BR,
Jani.
>
> The patch looks to me like it's being more complex that it
> should.
>
> Andi
--
Jani Nikula, Intel
Re: [PATCH v5 7/7] drm/i915: Implement fbdev emulation as in-kernel client
Hi Thomas, couple of minor comments and a question below.
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Replace all code that initializes or releases fbdev emulation
> throughout the driver. Instead initialize the fbdev client by a
> single call to i915_fbdev_setup() after i915 has registered its
intel_fbdev_setup
> DRM device. Just like similar code in other drivers, i915 fbdev
> emulation now acts as a regular DRM client.
>
> The fbdev client setup consists of the initial preparation and the
> hot-plugging of the display. The latter creates the fbdev device
> and sets up the fbdev framebuffer. The setup performs display
> hot-plugging once. If no display can be detected, DRM probe helpers
> re-run the detection on each hotplug event.
>
> A call to drm_dev_unregister() releases the client automatically.
> No further action is required within i915. If the fbdev framebuffer
> has been fully set up, struct fb_ops.fb_destroy implements the
> release. For partially initialized emulation, the fbdev client
> reverts the initial setup.
>
> v3:
> * as before, silently ignore devices without displays
> v2:
> * let drm_client_register() handle initial hotplug
> * fix driver name in error message (Jani)
> * fix non-fbdev build (kernel test robot)
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> .../drm/i915/display/intel_display_driver.c | 18 --
> drivers/gpu/drm/i915/display/intel_fbdev.c | 180
> --
> drivers/gpu/drm/i915/display/intel_fbdev.h | 20 +-
> drivers/gpu/drm/i915/i915_driver.c | 2 +
> 5 files changed, 83 insertions(+), 138 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index edbcf5968804d..7efa8d2787c39 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -81,7 +81,6 @@
> #include "intel_dvo.h"
> #include "intel_fb.h"
> #include "intel_fbc.h"
> -#include "intel_fbdev.h"
> #include "intel_fdi.h"
> #include "intel_fifo_underrun.h"
> #include "intel_frontbuffer.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index ffdcddd1943e0..213a4ee93ffc2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -364,10 +364,6 @@ int intel_display_driver_probe(struct
> drm_i915_private *i915)
>
> intel_overlay_setup(i915);
>
> - ret = intel_fbdev_init(>drm);
> - if (ret)
> - return ret;
> -
> /* Only enable hotplug handling once the fbdev is fully set
> up. */
> intel_hpd_init(i915);
> intel_hpd_poll_disable(i915);
> @@ -392,16 +388,6 @@ void intel_display_driver_register(struct
> drm_i915_private *i915)
>
> intel_display_debugfs_register(i915);
>
> - /*
> - * Some ports require correctly set-up hpd registers for
> - * detection to work properly (leading to ghost connected
> - * connector status), e.g. VGA on gm45. Hence we can only
> set
> - * up the initial fbdev config after hpd irqs are fully
> - * enabled. We do it last so that the async config cannot run
> - * before the connectors are registered.
> - */
> - intel_fbdev_initial_config_async(i915);
> -
> /*
> * We need to coordinate the hotplugs with the asynchronous
> * fbdev configuration, for which we use the
> @@ -445,9 +431,6 @@ void intel_display_driver_remove_noirq(struct
> drm_i915_private *i915)
> */
> intel_hpd_poll_fini(i915);
>
> - /* poll work can call into fbdev, hence clean that up
> afterwards */
> - intel_fbdev_fini(i915);
> -
> intel_unregister_dsm_handler();
>
> /* flush any delayed tasks or pending work */
> @@ -484,7 +467,6 @@ void intel_display_driver_unregister(struct
> drm_i915_private *i915)
> if (!HAS_DISPLAY(i915))
> return;
>
> - intel_fbdev_unregister(i915);
> intel_audio_deinit(i915);
>
> /*
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 39de61d4e7906..100a4aaf1b7e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -24,7 +24,6 @@
> * David Airlie
> */
>
> -#include
> #include
> #include
> #include
> @@ -39,6 +38,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -58,7 +58,6 @@ struct intel_fbdev {
> struct intel_framebuffer *fb;
> struct i915_vma *vma;
> unsigned long vma_flags;
> - async_cookie_t cookie;
> int preferred_bpp;
>
> /* Whether or not fbdev hpd processing is temporarily
> suspended */
Re: Evoc proposal
Hi David, EVoC is on hold at the current moment due to some bureaucracy issues. I'm CCing other possible mentors, but at the moment, I'm not sure if a EVoC project is possible. Best Regards, - Maíra On 10/24/23 22:57, DAVID WALTERS wrote: Hello, I have a draft of a proposal that I would like feedback on from Maíra Canal (or another mentor). If you could please let me know their email address (or I could send you the draft and you could forward it to them). It's for the KUnit and DRM project. Thanks, David Walters.
[PATCH v2 2/6] riscv: dts: starfive: jh7110: add dc controller and hdmi node
Add the dc controller and hdmi node for the Starfive JH7110 SoC.
Signed-off-by: Keith Zhao
---
.../jh7110-starfive-visionfive-2.dtsi | 91 +++
arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 +
2 files changed, 132 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
index de0f40a8b..97909b6d2 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -31,6 +31,25 @@ memory@4000 {
reg = <0x0 0x4000 0x1 0x0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* vout applies for space from this CMA
+* Without this CMA reservation,
+* vout may not work properly.
+*/
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x0 0x2000>;
+ alignment = <0x0 0x1000>;
+ alloc-ranges = <0x0 0x7000 0x0 0x2000>;
+ linux,cma-default;
+ };
+ };
+
gpio-restart {
compatible = "gpio-restart";
gpios = < 35 GPIO_ACTIVE_HIGH>;
@@ -231,6 +250,41 @@ GPOEN_DISABLE,
slew-rate = <0>;
};
};
+
+ hdmi_pins: hdmi-0 {
+ hdmi-scl-pins {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ hdmi-sda-pins {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ hdmi-cec-pins {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ hdmi-hpd-pins {
+ pinmux = ;
+ input-enable;
+ bias-disable; /* external pull-up */
+ };
+ };
+
};
{
@@ -254,3 +308,40 @@ _3 {
_4 {
cpu-supply = <_cpu>;
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_dc: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_hdmi>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ dc_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dc_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in_dc>;
+ };
+
+ };
+};
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi
b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 0005fa163..1670452fb 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -282,6 +282,11 @@ tdm_ext: tdm-ext-clock {
#clock-cells = <0>;
};
+ display: display-subsystem {
+ compatible = "starfive,display-subsystem";
+ ports = <_out>;
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <>;
@@ -613,5 +618,41 @@ voutcrg: clock-controller@295c {
#reset-cells = <1>;
power-domains = < JH7110_PD_VOUT>;
};
+
+ dc8200: lcd-controller@2940 {
+ compatible = "starfive,jh7110-dc8200";
+ reg = <0x0 0x2940 0x0 0x100>,
+ <0x0 0x29400800 0x0 0x2000>;
+ interrupts = <95>;
+ clocks = < JH7110_SYSCLK_NOC_BUS_DISP_AXI>,
+ < JH7110_VOUTCLK_DC8200_PIX0>,
+ < JH7110_VOUTCLK_DC8200_PIX1>,
+ < JH7110_VOUTCLK_DC8200_CORE>,
+ < JH7110_VOUTCLK_DC8200_AXI>,
+ < JH7110_VOUTCLK_DC8200_AHB>,
+ <_pixelclk>,
+ < JH7110_VOUTCLK_DC8200_PIX>;
+ clock-names = "noc_bus", "channel0", "channel1",
+ "dc_core", "axi_core", "ahb",
+ "hdmi_tx", "dc_parent";
+ resets = < JH7110_VOUTRST_DC8200_AXI>,
+< JH7110_VOUTRST_DC8200_AHB>,
+< JH7110_VOUTRST_DC8200_CORE>;
+
[PATCH v2 3/6] drm/fourcc: Add drm/vs tiled modifiers
For each modifier, add the corresponding description
Signed-off-by: Keith Zhao
---
include/uapi/drm/drm_fourcc.h | 57 +++
1 file changed, 57 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f7..a580a848c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -419,6 +419,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
+#define DRM_FORMAT_MOD_VENDOR_VERISILICON 0x0b
/* add more to the end as needed */
@@ -1562,6 +1563,62 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define AMD_FMT_MOD_CLEAR(field) \
(~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
+#define DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL
0x00
+#define DRM_FORMAT_MOD_VERISILICON_TYPE_MASK
((__u64)0x3 << 54)
+
+#define fourcc_mod_vs_code(type, val) \
+ fourcc_mod_code(VERISILICON, __u64)type) << 54) | (val)))
+
+#define DRM_FORMAT_MOD_VERISILICON_NORM_MODE_MASK
0x1F
+
+/*
+ * An x-major 8x8 super tile consists of 64 8x8 sub-tiles in total.
+ * Each 8x8 sub-tile consists of four standard tiles .
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_XMAJOR_8X8 0x02
+
+/*
+ * A y-major 8x8 super tile consists of 64 8x8 sub-tiles in total.
+ * Each 8x8 sub-tile consists of four standard tiles .
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_YMAJOR_8X8 0x03
+
+/*
+ * An 8x8 tile consists of four standard tiles
+ * that are organized in Z-order.
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_TILE_8X8
0x04
+
+/*
+ * An 8x4 tile consists of two standard tiles
+ * that are organized in Z-order.
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_TILE_8X4
0x07
+
+/*
+ * An x-major 8x4 super tile consists of 128 8x4 sub-tiles in total.
+ * Each 8x4 sub-tile consists of two standard tiles.
+ * two standard tiles also same with DRM_FORMAT_MOD_VS_TILE_8X4
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_XMAJOR_8X4 0x0B
+
+/*
+ * A y-major 4x8 super tile consists of 128 4x8 sub-tiles in total.
+ * Each 4x8 sub-tile consists of two standard tiles.
+ * two standard tiles also same with DRM_FORMAT_MOD_VS_TILE_8X4
+ * standard tiles (see Vivante 4x4 tiling layout)
+ */
+#define DRM_FORMAT_MOD_VERISILICON_SUPER_TILED_YMAJOR_4X80x0C
+
+#define fourcc_mod_vs_norm_code(tile) \
+ fourcc_mod_vs_code(DRM_FORMAT_MOD_VERISILICON_TYPE_NORMAL, \
+ (tile))
+
#if defined(__cplusplus)
}
#endif
--
2.34.1
[PATCH] drm: mediatek: mtk_disp_gamma: Fix breakage due to merge issue
While the commit that was sent to the mailing lists was fine, something
happened during merge and the mtk_gamma_set() function got broken as
a writel() was turned into a readl().
Fix that by changing that back to the expected writel().
Fixes: a6b39cd248f3 ("drm/mediatek: De-commonize disp_aal/disp_gamma gamma_set
functions")
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 2fada9d6c95f..52c752bc5f41 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -203,7 +203,7 @@ void mtk_gamma_set(struct device *dev, struct
drm_crtc_state *state)
/* Disable RELAY mode to pass the processed image */
cfg_val &= ~GAMMA_RELAY_MODE;
- cfg_val = readl(gamma->regs + DISP_GAMMA_CFG);
+ writel(cfg_val, gamma->regs + DISP_GAMMA_CFG);
}
void mtk_gamma_config(struct device *dev, unsigned int w,
--
2.42.0
Re: [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Hello, On Wed, Oct 25, 2023 at 10:53:27AM +0100, Sean Young wrote: > On Mon, Oct 23, 2023 at 02:34:17PM +0100, Daniel Thompson wrote: > > On Sun, Oct 22, 2023 at 11:46:22AM +0100, Sean Young wrote: > > > On Sat, Oct 21, 2023 at 11:08:22AM +0200, Hans de Goede wrote: > > > > On 10/19/23 12:51, Uwe Kleine-König wrote: > > > > > On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: > > > > >> On 10/17/23 11:17, Sean Young wrote: > > > > > I think it's very subjective if you consider this > > > > > churn or not. > > > > > > > > I consider it churn because I don't think adding a postfix > > > > for what is the default/expected behavior is a good idea > > > > (with GPIOs not sleeping is the expected behavior). > > > > > > > > I agree that this is very subjective and very much goes > > > > into the territory of bikeshedding. So please consider > > > > the above my 2 cents on this and lets leave it at that. > > > > > > You have a valid point. Let's focus on having descriptive function names. > > > > For a couple of days I've been trying to resist the bikeshedding (esp. > > given the changes to backlight are tiny) so I'll try to keep it as > > brief as I can: > > > > 1. I dislike the do_it() and do_it_cansleep() pairing. It is > >difficult to detect when a client driver calls do_it() by mistake. > >In fact a latent bug of this nature can only be detected by runtime > >testing with the small number of PWMs that do not support > >configuration from an atomic context. > > > >In contrast do_it() and do_it_atomic()[*] means that although > >incorrectly calling do_it() from an atomic context can be pretty > >catastrophic it is also trivially detected (with any PWM driver) > >simply by running with CONFIG_DEBUG_ATOMIC_SLEEP. Wrongly calling the atomic variant (no matter how it's named) in a context where sleeping is possible is only a minor issue. Being faster than necessary is hardly a problem, so it only hurts by not being an preemption point with PREEMPT_VOLUNTARY which might not even be relevant because we're near to a system call anyhow. For me the naming is only very loosely related to the possible bugs. I think calling the wrong function happens mainly because the driver author isn't aware in which context the call happens and not because of wrong assumptions about the sleepiness of a certain function call. If you consider this an argument however, do_it + do_it_cansleep is better than do_it_atomic + do_it as wrongly assuming do_it would sleep is less bad than wrongly assuming do_it wouldn't sleep. (The latter is catched by CONFIG_DEBUG_ATOMIC_SLEEP, but only if it's enabled.) Having said that while my subjective preference ordering is (with first = best): do_it + do_it_cansleep do_it_atomic + do_it_cansleep do_it_atomic + do_it wi(th a _might_sleep or _mightsleep suffix ranging below _cansleep) I wouldn't get sleepless nights when I get overruled here (uwe_cansleep :-). > >No objections (beyond churn) to fully spelt out pairings such as > >do_it_cansleep() and do_it_atomic()[*]! > > I must say I do like the look of this. Uwe, how do you feel about: > pwm_apply_cansleep() and pwm_apply_atomic()? I know we've talked about > pwm_apply_atomic in the past, however I think this this the best > option I've seen so far. > > > 2. If there is an API rename can we make sure the patch contains no > >other changes (e.g. don't introduce any new API in the same patch). > >Seperating renames makes the patches easier to review! > >It makes each one smaller and easier to review! > > Yes, this should have been separated out. Will fix for next version. +1 Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH v2 0/6] DRM driver for verisilicon
This patch is a drm driver for Starfive Soc JH7110, I am sending Drm driver part and HDMI driver part. We used GEM framework for buffer management , and for buffer allocation,we use DMA APIs. the Starfive HDMI servers as interface between a LCD Controller and a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and one HDMI transmitter PHY. (Sound support is not include in this patch) This patchset should be applied after the patchset: https://patchwork.kernel.org/project/linux-clk/cover/20230713113902.56519-1-xingyu...@starfivetech.com/ 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 struct vs_crtc_funcs_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 Keith Zhao (6): dt-bindings: display: Add yamls for JH7110 display system riscv: dts: starfive: jh7110: add dc controller and hdmi node drm/fourcc: Add drm/vs tiled modifiers drm/vs: Register DRM device drm/vs: Add KMS crtc drm/vs: Add hdmi driver .../starfive/starfive,display-subsystem.yaml | 41 + .../starfive/starfive,jh7110-dc8200.yaml | 109 + .../starfive/starfive,jh7110-inno-hdmi.yaml | 85 + MAINTAINERS |7 + .../jh7110-starfive-visionfive-2.dtsi | 91 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 + drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/verisilicon/Kconfig | 21 + drivers/gpu/drm/verisilicon/Makefile | 12 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 949 drivers/gpu/drm/verisilicon/starfive_hdmi.h | 295 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 257 +++ drivers/gpu/drm/verisilicon/vs_crtc.h | 43 + drivers/gpu/drm/verisilicon/vs_dc.c | 1002 + drivers/gpu/drm/verisilicon/vs_dc.h | 80 + drivers/gpu/drm/verisilicon/vs_dc_hw.c| 1959 + drivers/gpu/drm/verisilicon/vs_dc_hw.h| 492 + drivers/gpu/drm/verisilicon/vs_drv.c | 234 ++ drivers/gpu/drm/verisilicon/vs_drv.h | 31 + drivers/gpu/drm/verisilicon/vs_modeset.c | 36 + drivers/gpu/drm/verisilicon/vs_modeset.h | 10 + drivers/gpu/drm/verisilicon/vs_plane.c| 526 + drivers/gpu/drm/verisilicon/vs_plane.h| 58 + drivers/gpu/drm/verisilicon/vs_type.h | 69 + include/uapi/drm/drm_fourcc.h | 57 + include/uapi/drm/vs_drm.h | 50 + 27 files changed, 6558 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.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/verisilicon/Kconfig create mode 100644 drivers/gpu/drm/verisilicon/Makefile create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h create mode 100644 include/uapi/drm/vs_drm.h -- 2.34.1
[PATCH v2 4/6] drm/vs: Register DRM device
Implement drm device registration interface
Thomas Zimmermann wrote:
You are replacing almost all of the GEM DMA object's helper code.
Either inherit directly from drm_gem_object drop the dependency entirely,
or you could try to fit your code into GEM DMA as well
Eventually I found an answer and it was DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE
After I adapt this interface, the custom gem logic interfaces can be deleted.
It's a big shocking, clap!
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/verisilicon/Kconfig | 15 ++
drivers/gpu/drm/verisilicon/Makefile | 7 +
drivers/gpu/drm/verisilicon/vs_drv.c | 227 +++
drivers/gpu/drm/verisilicon/vs_drv.h | 27 +++
drivers/gpu/drm/verisilicon/vs_modeset.c | 36
drivers/gpu/drm/verisilicon/vs_modeset.h | 10 +
include/uapi/drm/vs_drm.h| 50 +
9 files changed, 375 insertions(+)
create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
create mode 100644 drivers/gpu/drm/verisilicon/Makefile
create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h
create mode 100644 include/uapi/drm/vs_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f..9ede80ef9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -363,6 +363,8 @@ source "drivers/gpu/drm/solomon/Kconfig"
source "drivers/gpu/drm/sprd/Kconfig"
+source "drivers/gpu/drm/verisilicon/Kconfig"
+
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
depends on DRM && PCI && MMU && HYPERV
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7a09a89b4..6db3bc397 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -194,3 +194,4 @@ obj-y += gud/
obj-$(CONFIG_DRM_HYPERV) += hyperv/
obj-y += solomon/
obj-$(CONFIG_DRM_SPRD) += sprd/
+obj-$(CONFIG_DRM_VERISILICON) += verisilicon/
diff --git a/drivers/gpu/drm/verisilicon/Kconfig
b/drivers/gpu/drm/verisilicon/Kconfig
new file mode 100644
index 0..3a361f8c8
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0
+config DRM_VERISILICON
+ tristate "DRM Support for VeriSilicon"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_GEM_DMA_HELPER
+ select CMA
+ select DMA_CMA
+ help
+ Choose this option if you have a VeriSilicon soc chipset.
+ This driver provides VeriSilicon kernel mode
+ setting and buffer management. It does not
+ provide 2D or 3D acceleration.
+
+
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
new file mode 100644
index 0..7d3be305b
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+
+vs_drm-objs := vs_drv.o \
+ vs_modeset.o
+
+obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
+
diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c
b/drivers/gpu/drm/verisilicon/vs_drv.c
new file mode 100644
index 0..da7698c3d
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_drv.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_drv.h"
+#include "vs_modeset.h"
+
+#define DRV_NAME "verisilicon"
+#define DRV_DESC "Verisilicon DRM driver"
+#define DRV_DATE "20230516"
+#define DRV_MAJOR 1
+#define DRV_MINOR 0
+
+static int vs_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ struct vs_drm_device *priv = to_vs_drm_private(dev);
+
+ unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+
+ if (args->bpp % 10)
+ args->pitch = ALIGN(pitch, priv->pitch_alignment);
+ else
+ /* for costum 10bit format with no bit gaps */
+ args->pitch = pitch;
+
+ return drm_gem_dma_dumb_create_internal(file, dev, args);
+}
+
+DEFINE_DRM_GEM_FOPS(vs_drm_fops);
+
+static struct drm_driver vs_drm_driver = {
+ .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
+
+ DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(vs_gem_dumb_create),
+
+ .fops = _drm_fops,
+ .name = DRV_NAME,
+ .desc = DRV_DESC,
+ .date = DRV_DATE,
+ .major = DRV_MAJOR,
+ .minor =
[PATCH v2 5/6] drm/vs: Add KMS crtc
add 2 crtcs and 8 planes in vs-drm
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/verisilicon/Makefile |8 +-
drivers/gpu/drm/verisilicon/vs_crtc.c | 257
drivers/gpu/drm/verisilicon/vs_crtc.h | 43 +
drivers/gpu/drm/verisilicon/vs_dc.c| 1002
drivers/gpu/drm/verisilicon/vs_dc.h| 80 +
drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959
drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 ++
drivers/gpu/drm/verisilicon/vs_drv.c |2 +
drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++
drivers/gpu/drm/verisilicon/vs_plane.h | 58 +
drivers/gpu/drm/verisilicon/vs_type.h | 69 +
11 files changed, 4494 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h
create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h
diff --git a/drivers/gpu/drm/verisilicon/Makefile
b/drivers/gpu/drm/verisilicon/Makefile
index 7d3be305b..1d48016ca 100644
--- a/drivers/gpu/drm/verisilicon/Makefile
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -1,7 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
-vs_drm-objs := vs_drv.o \
- vs_modeset.o
+vs_drm-objs := vs_dc_hw.o \
+ vs_dc.o \
+ vs_crtc.o \
+ vs_drv.o \
+ vs_modeset.o \
+ vs_plane.o
obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
b/drivers/gpu/drm/verisilicon/vs_crtc.c
new file mode 100644
index 0..8a658ea77
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vs_crtc.h"
+#include "vs_dc.h"
+#include "vs_drv.h"
+
+static void vs_crtc_reset(struct drm_crtc *crtc)
+{
+ struct vs_crtc_state *state;
+
+ if (crtc->state) {
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
+
+ state = to_vs_crtc_state(crtc->state);
+ kfree(state);
+ crtc->state = NULL;
+ }
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return;
+
+ __drm_atomic_helper_crtc_reset(crtc, >base);
+}
+
+static struct drm_crtc_state *
+vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
+{
+ struct vs_crtc_state *ori_state;
+ struct vs_crtc_state *state;
+
+ if (!crtc->state)
+ return NULL;
+
+ ori_state = to_vs_crtc_state(crtc->state);
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, >base);
+
+ state->output_fmt = ori_state->output_fmt;
+ state->encoder_type = ori_state->encoder_type;
+ state->bpp = ori_state->bpp;
+ state->underflow = ori_state->underflow;
+
+ return >base;
+}
+
+static void vs_crtc_atomic_destroy_state(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ __drm_atomic_helper_crtc_destroy_state(state);
+ kfree(to_vs_crtc_state(state));
+}
+
+static int vs_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+ struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
+ struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
+
+ vs_dc_enable_vblank(dc, true);
+
+ return 0;
+}
+
+static void vs_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+ struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
+ struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
+
+ vs_dc_enable_vblank(dc, false);
+}
+
+static const struct drm_crtc_funcs vs_crtc_funcs = {
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = vs_crtc_reset,
+ .atomic_duplicate_state = vs_crtc_atomic_duplicate_state,
+ .atomic_destroy_state = vs_crtc_atomic_destroy_state,
+ .enable_vblank = vs_crtc_enable_vblank,
+ .disable_vblank = vs_crtc_disable_vblank,
+};
+
+static u8 cal_pixel_bits(u32 bus_format)
+{
+ u8 bpp;
+
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ bpp = 16;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB666_1X24_CPADHI:
+ bpp = 18;
+ break;
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ bpp
[PATCH v2 1/6] dt-bindings: display: Add yamls for JH7110 display system
StarFive SoCs JH7110 display system:
lcd-controller bases verisilicon dc8200 IP,
and hdmi bases Innosilicon IP. Add bindings for them.
also update MAINTAINERS for dt-bindings
about this patch, I tested the dtbs_check and dt_binding_check
with the result pass.
Based on the feedback of the previous version, the corresponding arrangement is
made
Signed-off-by: Keith Zhao
---
.../starfive/starfive,display-subsystem.yaml | 41 +++
.../starfive/starfive,jh7110-dc8200.yaml | 109 ++
.../starfive/starfive,jh7110-inno-hdmi.yaml | 85 ++
MAINTAINERS | 7 ++
4 files changed, 242 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.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
diff --git
a/Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
b/Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
new file mode 100644
index 0..f45b97b08
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/starfive/starfive,display-subsystem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Starfive DRM master device
+
+maintainers:
+ - Keith Zhao
+ - ShengYang Chen
+
+description:
+ The Starfive DRM master device is a virtual device needed to list all
+ display controller or other display interface nodes that comprise the
+ graphics subsystem.
+
+properties:
+ compatible:
+const: starfive,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+ Should contain a list of phandles pointing to display interface ports
+ of display controller devices. Display controller definitions as defined
+ in Documentation/devicetree/bindings/display/starfive/
+ starfive,jh7110-dc8200.yaml
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+display-subsystem {
+compatible = "starfive,display-subsystem";
+ports = <_out>;
+};
diff --git
a/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
b/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
new file mode 100644
index 0..87051cddf
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/starfive/starfive,jh7110-dc8200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive display controller
+
+description:
+ The StarFive SoC uses the display controller based on Verisilicon IP
+ to transfer the image data from a video memory buffer to an external
+ LCD interface.
+
+maintainers:
+ - Keith Zhao
+
+properties:
+ compatible:
+const: starfive,jh7110-dc8200
+
+ reg:
+minItems: 1
+items:
+ - description:
+ host interface
+ - description:
+ display physical base address and length.
+
+ interrupts:
+items:
+ - description: The interrupt will be generated when DC finish one frame
+
+ clocks:
+items:
+ - description: Clock for display system noc bus.
+ - description: Pixel clock for display channel 0.
+ - description: Pixel clock for display channel 1.
+ - description: Core clock for display controller.
+ - description: Clock for axi bus to access ddr.
+ - description: Clock for ahb bus to R/W the phy regs.
+ - description: External HDMI pixel clock.
+ - description: Parent clock for pixel clock
+
+ clock-names:
+items:
+ - const: noc_bus
+ - const: channel0
+ - const: channel1
+ - const: dc_core
+ - const: axi_core
+ - const: ahb
+ - const: hdmi_tx
+ - const: dc_parent
+
+ resets:
+items:
+ - description: Reset for axi bus.
+ - description: Reset for ahb bus.
+ - description: Core reset of display controller.
+
+ reset-names:
+items:
+ - const: axi
+ - const: ahb
+ - const: core
+
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+dc8200: lcd-controller@2940 {
+compatible = "starfive,jh7110-dc8200";
+reg = <0x2940 0x100>, <0x29400800 0x2000>;
+interrupts = <95>;
+clocks = < 60>,
+ < 7>,
+ < 8>,
+
