Re: [PATCH v4 07/16] drm/i915/dg2: Tile 4 plane format support
On 2021-12-10 at 09:33:07 +0200, Lisovskiy, Stanislav wrote:
> On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> > From: Stanislav Lisovskiy
> >
> > Tile4 in bspec format is 4K tile organized into
> > 64B subtiles with same basic shape as for legacy TileY
> > which will be supported by Display13.
> >
> > v2: - Moved Tile4 associating struct for modifier/display to
> > the beginning(Imre Deak)
> > - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
> > checks(Imre Deak)
> > - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
> > (Imre Deak)
> >
> > v3: - Rebased patch on top of new changes related to plane_caps.
> > - Added static assert to check that PLANE_CTL_TILING_YF
> > matches PLANE_CTL_TILING_4(Nanley Chery)
> > - Fixed naming and layout description for Tile 4 in drm uapi
> > header(Nanley Chery)
>
> Hi Ramalingam,
>
> This is probably wrong patch to use as I've sent a newer series,
> where drm_fourcc.h changes are separately introducing new tiling
> format.
> I would be also resending this series today as Nanley Chery
> suggested that drm_foucc changes should be introduced after
> the kernel support is introduced.
Hi Stan,
this patch is added here to fulfil the dependancies. Please continue the
review of the original patch. When that is merged, this patch will be
dropped from this series.
Ram.
>
> Stan
>
> >
> > Cc: Matt Roper
> > Cc: Maarten Lankhorst
> > Signed-off-by: Stanislav Lisovskiy
> > Signed-off-by: Matt Roper
> > Signed-off-by: Juha-Pekka Heikkilä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 1 +
> > drivers/gpu/drm/i915/display/intel_fb.c | 15 +++-
> > drivers/gpu/drm/i915/display/intel_fb.h | 1 +
> > drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
> > .../drm/i915/display/intel_plane_initial.c| 1 +
> > .../drm/i915/display/skl_universal_plane.c| 23 ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_pci.c | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_device_info.h | 1 +
> > drivers/gpu/drm/i915/intel_pm.c | 1 +
> > include/uapi/drm/drm_fourcc.h | 11 +
> > 12 files changed, 49 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 128d4943a43b..83253c62b6d6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -,6 +,7 @@ static int intel_atomic_check_async(struct
> > intel_atomic_state *state, struct int
> > case I915_FORMAT_MOD_X_TILED:
> > case I915_FORMAT_MOD_Y_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > + case I915_FORMAT_MOD_4_TILED:
> > break;
> > default:
> > drm_dbg_kms(&i915->drm,
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> > b/drivers/gpu/drm/i915/display/intel_fb.c
> > index 23cfe2e5ce2a..46505c69fe72 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -135,11 +135,16 @@ struct intel_modifier_desc {
> > INTEL_PLANE_CAP_CCS_MC)
> > #define INTEL_PLANE_CAP_TILING_MASK(INTEL_PLANE_CAP_TILING_X | \
> > INTEL_PLANE_CAP_TILING_Y | \
> > -INTEL_PLANE_CAP_TILING_Yf)
> > +INTEL_PLANE_CAP_TILING_Yf | \
> > +INTEL_PLANE_CAP_TILING_4)
> > #define INTEL_PLANE_CAP_TILING_NONE0
> >
> > static const struct intel_modifier_desc intel_modifiers[] = {
> > {
> > + .modifier = I915_FORMAT_MOD_4_TILED,
> > + .display_ver = { 13, 14 },
> > + .plane_caps = INTEL_PLANE_CAP_TILING_4,
> > + }, {
> > .modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > .display_ver = { 12, 13 },
> > .plane_caps = INTEL_PLANE_CAP_TILING_Y | INTEL_PLANE_CAP_CCS_MC,
> > @@ -545,6 +550,12 @@ intel_tile_width_bytes(const struct drm_framebuffer
> > *fb, int color_plane)
> > return 128;
> > else
> > return 512;
> > + case I915_FORMAT_MOD_4_TILED:
> > + /*
> > +* Each 4K tile consists of 64B(8*8) subtiles, with
> > +* same shape as Y Tile(i.e 4*16B OWords)
> > +*/
> > + return 128;
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > if (intel_fb_is_ccs_aux_plane(fb, color_plane))
> > return 128;
> > @@ -650,6 +661,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> > fb_modifier)
> > return I915_TILING_Y;
> > case INTEL_PLANE_CAP_TILING_X:
> >
Re: [PATCH 2/9] drm/i915/gvt: Constify intel_gvt_gtt_pte_ops
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 62 +-
> drivers/gpu/drm/i915/gvt/gtt.h | 2 +-
> 2 files changed, 32 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 6efa48727052..c8cd6bf28ea8 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -499,7 +499,7 @@ DEFINE_PPGTT_GMA_TO_INDEX(gen8, l3_pdp, (gma >> 30 &
> 0x3));
> DEFINE_PPGTT_GMA_TO_INDEX(gen8, l4_pdp, (gma >> 30 & 0x1ff));
> DEFINE_PPGTT_GMA_TO_INDEX(gen8, pml4, (gma >> 39 & 0x1ff));
>
> -static struct intel_gvt_gtt_pte_ops gen8_gtt_pte_ops = {
> +static const struct intel_gvt_gtt_pte_ops gen8_gtt_pte_ops = {
> .get_entry = gtt_get_entry64,
> .set_entry = gtt_set_entry64,
> .clear_present = gtt_entry_clear_present,
> @@ -526,7 +526,7 @@ static const struct intel_gvt_gtt_gma_ops
> gen8_gtt_gma_ops = {
> };
>
> /* Update entry type per pse and ips bit. */
> -static void update_entry_type_for_real(struct intel_gvt_gtt_pte_ops *pte_ops,
> +static void update_entry_type_for_real(const struct intel_gvt_gtt_pte_ops
> *pte_ops,
> struct intel_gvt_gtt_entry *entry, bool ips)
> {
> switch (entry->type) {
> @@ -553,7 +553,7 @@ static void _ppgtt_get_root_entry(struct intel_vgpu_mm
> *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index,
> bool guest)
> {
> - struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *pte_ops =
> mm->vgpu->gvt->gtt.pte_ops;
>
> GEM_BUG_ON(mm->type != INTEL_GVT_MM_PPGTT);
>
> @@ -580,7 +580,7 @@ static void _ppgtt_set_root_entry(struct intel_vgpu_mm
> *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index,
> bool guest)
> {
> - struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *pte_ops =
> mm->vgpu->gvt->gtt.pte_ops;
>
> pte_ops->set_entry(guest ? mm->ppgtt_mm.guest_pdps :
> mm->ppgtt_mm.shadow_pdps,
> @@ -596,7 +596,7 @@ static inline void ppgtt_set_shadow_root_entry(struct
> intel_vgpu_mm *mm,
> static void ggtt_get_guest_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> - struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *pte_ops =
> mm->vgpu->gvt->gtt.pte_ops;
>
> GEM_BUG_ON(mm->type != INTEL_GVT_MM_GGTT);
>
> @@ -608,7 +608,7 @@ static void ggtt_get_guest_entry(struct intel_vgpu_mm *mm,
> static void ggtt_set_guest_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> - struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *pte_ops =
> mm->vgpu->gvt->gtt.pte_ops;
>
> GEM_BUG_ON(mm->type != INTEL_GVT_MM_GGTT);
>
> @@ -619,7 +619,7 @@ static void ggtt_set_guest_entry(struct intel_vgpu_mm *mm,
> static void ggtt_get_host_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> - struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *pte_ops =
> mm->vgpu->gvt->gtt.pte_ops;
>
> GEM_BUG_ON(mm->type != INTEL_GVT_MM_GGTT);
>
> @@ -629,7 +629,7 @@ static void ggtt_get_host_entry(struct intel_vgpu_mm *mm,
> static void ggtt_set_host_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> - struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *pte_ops =
> mm->vgpu->gvt->gtt.pte_ops;
> unsigned long offset = index;
>
> GEM_BUG_ON(mm->type != INTEL_GVT_MM_GGTT);
> @@ -655,7 +655,7 @@ static inline int ppgtt_spt_get_entry(
> bool guest)
> {
> struct intel_gvt *gvt = spt->vgpu->gvt;
> - struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
> int ret;
>
> e->type = get_entry_type(type);
> @@ -684,7 +684,7 @@ static inline int ppgtt_spt_set_entry(
> bool guest)
> {
> struct intel_gvt *gvt = spt->vgpu->gvt;
> - struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
> + const struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
>
> if (WARN(!gtt_type_is_entry(e->type), "invalid entry type\n"))
> return -EINVAL;
> @@ -947,7 +947,7 @@ static int ppgtt_invalidate_spt_by_shadow_entry(struct
> intel_vgpu *vgpu,
> struct inte
Re: [PATCH 3/9] drm/i915/gvt: Constify intel_gvt_irq_ops
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/interrupt.c | 10 +-
> drivers/gpu/drm/i915/gvt/interrupt.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
> b/drivers/gpu/drm/i915/gvt/interrupt.c
> index 614b951d919f..9ccc6b1ecc28 100644
> --- a/drivers/gpu/drm/i915/gvt/interrupt.c
> +++ b/drivers/gpu/drm/i915/gvt/interrupt.c
> @@ -176,7 +176,7 @@ int intel_vgpu_reg_imr_handler(struct intel_vgpu *vgpu,
> unsigned int reg, void *p_data, unsigned int bytes)
> {
> struct intel_gvt *gvt = vgpu->gvt;
> - struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> + const struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> u32 imr = *(u32 *)p_data;
>
> trace_write_ir(vgpu->id, "IMR", reg, imr, vgpu_vreg(vgpu, reg),
> @@ -206,7 +206,7 @@ int intel_vgpu_reg_master_irq_handler(struct intel_vgpu
> *vgpu,
> unsigned int reg, void *p_data, unsigned int bytes)
> {
> struct intel_gvt *gvt = vgpu->gvt;
> - struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> + const struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> u32 ier = *(u32 *)p_data;
> u32 virtual_ier = vgpu_vreg(vgpu, reg);
>
> @@ -246,7 +246,7 @@ int intel_vgpu_reg_ier_handler(struct intel_vgpu *vgpu,
> {
> struct intel_gvt *gvt = vgpu->gvt;
> struct drm_i915_private *i915 = gvt->gt->i915;
> - struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> + const struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> struct intel_gvt_irq_info *info;
> u32 ier = *(u32 *)p_data;
>
> @@ -604,7 +604,7 @@ static void gen8_init_irq(
> SET_BIT_INFO(irq, 25, PCU_PCODE2DRIVER_MAILBOX, INTEL_GVT_IRQ_INFO_PCU);
> }
>
> -static struct intel_gvt_irq_ops gen8_irq_ops = {
> +static const struct intel_gvt_irq_ops gen8_irq_ops = {
> .init_irq = gen8_init_irq,
> .check_pending_irq = gen8_check_pending_irq,
> };
> @@ -626,7 +626,7 @@ void intel_vgpu_trigger_virtual_event(struct intel_vgpu
> *vgpu,
> struct intel_gvt *gvt = vgpu->gvt;
> struct intel_gvt_irq *irq = &gvt->irq;
> gvt_event_virt_handler_t handler;
> - struct intel_gvt_irq_ops *ops = gvt->irq.ops;
> + const struct intel_gvt_irq_ops *ops = gvt->irq.ops;
>
> handler = get_event_virt_handler(irq, event);
> drm_WARN_ON(&i915->drm, !handler);
> diff --git a/drivers/gpu/drm/i915/gvt/interrupt.h
> b/drivers/gpu/drm/i915/gvt/interrupt.h
> index 6c47d3e33161..0989e180ed54 100644
> --- a/drivers/gpu/drm/i915/gvt/interrupt.h
> +++ b/drivers/gpu/drm/i915/gvt/interrupt.h
> @@ -203,7 +203,7 @@ struct intel_gvt_irq_map {
>
> /* structure containing device specific IRQ state */
> struct intel_gvt_irq {
> - struct intel_gvt_irq_ops *ops;
> + const struct intel_gvt_irq_ops *ops;
> struct intel_gvt_irq_info *info[INTEL_GVT_IRQ_INFO_MAX];
> DECLARE_BITMAP(irq_info_bitmap, INTEL_GVT_IRQ_INFO_MAX);
> struct intel_gvt_event_info events[INTEL_GVT_EVENT_MAX];
Reviewed-by: Zhi Wang
Re: [PATCH 4/9] drm/i915/gvt: Constify intel_gvt_sched_policy_ops
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/sched_policy.c | 2 +-
> drivers/gpu/drm/i915/gvt/scheduler.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/sched_policy.c
> b/drivers/gpu/drm/i915/gvt/sched_policy.c
> index 036b74fe9298..c077fb4674f0 100644
> --- a/drivers/gpu/drm/i915/gvt/sched_policy.c
> +++ b/drivers/gpu/drm/i915/gvt/sched_policy.c
> @@ -368,7 +368,7 @@ static void tbs_sched_stop_schedule(struct intel_vgpu
> *vgpu)
> vgpu_data->active = false;
> }
>
> -static struct intel_gvt_sched_policy_ops tbs_schedule_ops = {
> +static const struct intel_gvt_sched_policy_ops tbs_schedule_ops = {
> .init = tbs_sched_init,
> .clean = tbs_sched_clean,
> .init_vgpu = tbs_sched_init_vgpu,
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.h
> b/drivers/gpu/drm/i915/gvt/scheduler.h
> index 7c86984a842f..1f391b3da2cc 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.h
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.h
> @@ -56,7 +56,7 @@ struct intel_gvt_workload_scheduler {
> wait_queue_head_t waitq[I915_NUM_ENGINES];
>
> void *sched_data;
> - struct intel_gvt_sched_policy_ops *sched_ops;
> + const struct intel_gvt_sched_policy_ops *sched_ops;
> };
>
> #define INDIRECT_CTX_ADDR_MASK 0xffc0
Reviewed-by: Zhi Wang
Re: [PATCH 5/9] drm/i915/gvt: Constify gvt_mmio_block
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put it in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 2 +-
> drivers/gpu/drm/i915/gvt/handlers.c | 12 ++--
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 0c0615602343..0ebffc327528 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -272,7 +272,7 @@ struct intel_gvt_mmio {
> /* Value of command write of this reg needs to be patched */
> #define F_CMD_WRITE_PATCH (1 << 8)
>
> - struct gvt_mmio_block *mmio_block;
> + const struct gvt_mmio_block *mmio_block;
> unsigned int num_mmio_block;
>
> DECLARE_HASHTABLE(mmio_info_table, INTEL_GVT_MMIO_HASH_BITS);
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index cde0a477fb49..5e85a77da257 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -3627,11 +3627,11 @@ static int init_bxt_mmio_info(struct intel_gvt *gvt)
> return 0;
> }
>
> -static struct gvt_mmio_block *find_mmio_block(struct intel_gvt *gvt,
> - unsigned int offset)
> +static const struct gvt_mmio_block *find_mmio_block(struct intel_gvt *gvt,
> + unsigned int offset)
> {
> unsigned long device = intel_gvt_get_device_type(gvt);
> - struct gvt_mmio_block *block = gvt->mmio.mmio_block;
> + const struct gvt_mmio_block *block = gvt->mmio.mmio_block;
> int num = gvt->mmio.num_mmio_block;
> int i;
>
> @@ -3670,7 +3670,7 @@ void intel_gvt_clean_mmio_info(struct intel_gvt *gvt)
>* accessible (should have no F_CMD_ACCESS flag).
>* otherwise, need to update cmd_reg_handler in cmd_parser.c
>*/
> -static struct gvt_mmio_block mmio_blocks[] = {
> +static const struct gvt_mmio_block mmio_blocks[] = {
> {D_SKL_PLUS, _MMIO(DMC_MMIO_START_RANGE), 0x3000, NULL, NULL},
> {D_ALL, _MMIO(MCHBAR_MIRROR_BASE_SNB), 0x4, NULL, NULL},
> {D_ALL, _MMIO(VGT_PVINFO_PAGE), VGT_PVINFO_SIZE,
> @@ -3753,7 +3753,7 @@ int intel_gvt_for_each_tracked_mmio(struct intel_gvt
> *gvt,
> int (*handler)(struct intel_gvt *gvt, u32 offset, void *data),
> void *data)
> {
> - struct gvt_mmio_block *block = gvt->mmio.mmio_block;
> + const struct gvt_mmio_block *block = gvt->mmio.mmio_block;
> struct intel_gvt_mmio_info *e;
> int i, j, ret;
>
> @@ -3871,7 +3871,7 @@ int intel_vgpu_mmio_reg_rw(struct intel_vgpu *vgpu,
> unsigned int offset,
> struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
> struct intel_gvt *gvt = vgpu->gvt;
> struct intel_gvt_mmio_info *mmio_info;
> - struct gvt_mmio_block *mmio_block;
> + const struct gvt_mmio_block *mmio_block;
> gvt_mmio_func func;
> int ret;
>
Reviewed-by: Zhi Wang
Re: [PATCH 6/9] drm/i915/gvt: Constify cmd_interrupt_events
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index c4118b808268..ce9307546e7f 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -1144,7 +1144,7 @@ struct cmd_interrupt_event {
> int mi_user_interrupt;
> };
>
> -static struct cmd_interrupt_event cmd_interrupt_events[] = {
> +static const struct cmd_interrupt_event cmd_interrupt_events[] = {
> [RCS0] = {
> .pipe_control_notify = RCS_PIPE_CONTROL,
> .mi_flush_dw = INTEL_GVT_EVENT_RESERVED,
Reviewed-by: Zhi Wang
Re: [PATCH 7/9] drm/i915/gvt: Constify formats
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory. WHile at it, make the description const
> char* since it is never modified.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/fb_decoder.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
> b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> index 11a8baba6822..3c8736ae8fed 100644
> --- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
> +++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> @@ -40,12 +40,12 @@
>
> #define PRIMARY_FORMAT_NUM 16
> struct pixel_format {
> - int drm_format; /* Pixel format in DRM definition */
> - int bpp;/* Bits per pixel, 0 indicates invalid */
> - char*desc; /* The description */
> + int drm_format; /* Pixel format in DRM definition */
> + int bpp;/* Bits per pixel, 0 indicates invalid
> */
> + const char *desc; /* The description */
> };
Thanks so much for this. According to the code of i915, we prefer using
one space as seperator.
>
> -static struct pixel_format bdw_pixel_formats[] = {
> +static const struct pixel_format bdw_pixel_formats[] = {
> {DRM_FORMAT_C8, 8, "8-bit Indexed"},
> {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
> {DRM_FORMAT_XRGB, 32, "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
> @@ -58,7 +58,7 @@ static struct pixel_format bdw_pixel_formats[] = {
> {0, 0, NULL},
> };
>
> -static struct pixel_format skl_pixel_formats[] = {
> +static const struct pixel_format skl_pixel_formats[] = {
> {DRM_FORMAT_YUYV, 16, "16-bit packed YUYV (8:8:8:8 MSB-V:Y2:U:Y1)"},
> {DRM_FORMAT_UYVY, 16, "16-bit packed UYVY (8:8:8:8 MSB-Y2:V:Y1:U)"},
> {DRM_FORMAT_YVYU, 16, "16-bit packed YVYU (8:8:8:8 MSB-U:Y2:V:Y1)"},
> @@ -278,14 +278,14 @@ int intel_vgpu_decode_primary_plane(struct intel_vgpu
> *vgpu,
>
> #define CURSOR_FORMAT_NUM (1 << 6)
> struct cursor_mode_format {
> - int drm_format; /* Pixel format in DRM definition */
> - u8 bpp;/* Bits per pixel; 0 indicates invalid */
> - u32 width; /* In pixel */
> - u32 height; /* In lines */
> - char*desc; /* The description */
> + int drm_format; /* Pixel format in DRM definition */
> + u8 bpp;/* Bits per pixel; 0 indicates invalid
> */
> + u32 width; /* In pixel */
> + u32 height; /* In lines */
> + const char *desc; /* The description */
> };
The same comment as above.
> -static struct cursor_mode_format cursor_pixel_formats[] = {
> +static const struct cursor_mode_format cursor_pixel_formats[] = {
> {DRM_FORMAT_ARGB, 32, 128, 128, "128x128 32bpp ARGB"},
> {DRM_FORMAT_ARGB, 32, 256, 256, "256x256 32bpp ARGB"},
> {DRM_FORMAT_ARGB, 32, 64, 64, "64x64 32bpp ARGB"},
> @@ -391,7 +391,7 @@ int intel_vgpu_decode_cursor_plane(struct intel_vgpu
> *vgpu,
>
> #define SPRITE_FORMAT_NUM (1 << 3)
>
> -static struct pixel_format sprite_pixel_formats[SPRITE_FORMAT_NUM] = {
> +static const struct pixel_format sprite_pixel_formats[SPRITE_FORMAT_NUM] = {
> [0x0] = {DRM_FORMAT_YUV422, 16, "YUV 16-bit 4:2:2 packed"},
> [0x1] = {DRM_FORMAT_XRGB2101010, 32, "RGB 32-bit 2:10:10:10"},
> [0x2] = {DRM_FORMAT_XRGB, 32, "RGB 32-bit 8:8:8:8"},
The rest of the patch looks good to me.
Re: [PATCH 8/9] drm/i915/gvt: Constify gtt_type_table_entry
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index c8cd6bf28ea8..614156856f16 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -185,7 +185,7 @@ struct gtt_type_table_entry {
> .pse_entry_type = pse_type, \
> }
>
> -static struct gtt_type_table_entry gtt_type_table[] = {
> +static const struct gtt_type_table_entry gtt_type_table[] = {
> GTT_TYPE_TABLE_ENTRY(GTT_TYPE_PPGTT_ROOT_L4_ENTRY,
> GTT_TYPE_PPGTT_ROOT_L4_ENTRY,
> GTT_TYPE_INVALID,
Reviewed-by: Zhi Wang
Re: [PATCH 9/9] drm/i915/gvt: Constify vgpu_types
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory. While at it, make name a const char*.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/vgpu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index fa6b92615799..80a940a1 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -77,7 +77,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
> #define VGPU_WEIGHT(vgpu_num) \
> (VGPU_MAX_WEIGHT / (vgpu_num))
>
> -static struct {
> +static const struct {
> unsigned int low_mm;
> unsigned int high_mm;
> unsigned int fence;
> @@ -88,7 +88,7 @@ static struct {
>*/
> unsigned int weight;
> enum intel_vgpu_edid edid;
> - char *name;
> + const char *name;
> } vgpu_types[] = {
> /* Fixed vGPU type table */
> { MB_TO_BYTES(64), MB_TO_BYTES(384), 4, VGPU_WEIGHT(8),
> GVT_EDID_1024_768, "8" },
Reviewed-by: Zhi Wang
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Hi Am 09.12.21 um 19:17 schrieb Guilherme G. Piccoli: Thanks again Alex! Some comments inlined below: On 09/12/2021 15:06, Alex Deucher wrote: Not really in a generic way. It's asic and platform specific. In addition most modern displays require link training to bring up the display, so you can't just save and restore registers. Oh sure, I understand that. My question is more like: is there a way, inside amdgpu driver, to save this state before taking over/overwriting/reprogramming the device? So we could (again, from inside the amdgpu driver) dump this pre-saved state in the shutdown handler, for example, having the device in a "pre-OS" state when the new kexec'ed kernel starts. We have have been talking about reading out and storing state of active devices within DRM. So far nothing usable has emerged. In a distant future, kexec might be able to store information about the active framebuffer and the new kernel's simpledrm (or some other driver) could use it as output. But don't hold your breath for it. It won't happen anytime soon. Best regards Thomas The drivers are asic and platform specific. E.g., the driver for vangogh is different from renoir is different from skylake, etc. The display programming interfaces are asic specific. Cool, that makes sense! But if you (or anybody here) know some of these GOP drivers, e.g. for the qemu/qxl device, I'm just curious to see/understand how complex is the FW driver to just put the device/screen in a usable state. Cheers, Guilherme -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[PATCH] drm/i915/selftests: Fix inconsistent object in IS_ERR and PTR_ERR
Fix inconsistent object in IS_ERR and PTR_ERR in
igt_dmabuf_import_same_driver and igt_dmabuf_import_same_driver_lmem.
As obj is the return value of __i915_gem_object_create_user,
the proper object to be passed as argument to PTR_ERR is obj.
Signed-off-by: Miaoqian Lin
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 4a6bb64c3a35..3cc74b0fed06 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -102,7 +102,7 @@ static int igt_dmabuf_import_same_driver_lmem(void *arg)
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, &lmem, 1);
if (IS_ERR(obj)) {
pr_err("__i915_gem_object_create_user failed with err=%ld\n",
- PTR_ERR(dmabuf));
+ PTR_ERR(obj));
err = PTR_ERR(obj);
goto out_ret;
}
@@ -158,7 +158,7 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
regions, num_regions);
if (IS_ERR(obj)) {
pr_err("__i915_gem_object_create_user failed with err=%ld\n",
- PTR_ERR(dmabuf));
+ PTR_ERR(obj));
err = PTR_ERR(obj);
goto out_ret;
}
--
2.17.1
[PATCH] drm: i915: display: intel_dmc: Fixes an unsigned subtraction which can never be negative.
smatch warning:
drivers/gpu/drm/i915/display/intel_dmc.c:601 parse_dmc_fw() warn:
unsigned 'fw->size - offset' is never less than zero
Firmware size is size_t and offset is u32. So the subtraction is
unsigned which can never be less than zero.
Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging")
Signed-off-by: Harshit Mogalapalli
---
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 0cab18f972d1..2f477c298b00 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -598,7 +598,7 @@ static void parse_dmc_fw(struct drm_i915_private *dev_priv,
continue;
offset = readcount + dmc->dmc_info[id].dmc_offset * 4;
- if (fw->size - offset < 0) {
+ if (offset > fw->size) {
drm_err(&dev_priv->drm, "Reading beyond the fw_size\n");
continue;
}
--
2.27.0
Re: [Intel-gfx] [PATCH] drm/i915/guc: Use correct context lock when callig clr_context_registered
On 09/12/2021 19:14, Daniele Ceraolo Spurio wrote:
On 12/9/2021 10:48 AM, Matthew Brost wrote:
s/ce/cn/ when grabbing guc_state.lock before calling
clr_context_registered.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: Matthew Brost
Cc:
I think Cc: stable is not needed here:
$ git tag --contains 0f7976506de61
drm-intel-fixes-2021-11-18
drm-intel-gt-next-2021-10-08
drm-intel-gt-next-2021-10-21
drm-intel-gt-next-2021-11-22
drm-intel-next-2021-10-15
drm-intel-next-fixes-2021-11-09
v5.16-rc1
v5.16-rc2
v5.16-rc3
v5.16-rc4
So still can hit 5.16 via fixes. Rodrigo, did I get this right and you
will be able to pick it up next week or so?
Reviewed-by: Daniele Ceraolo Spurio
I'm assuming we didn't see any splat from the lockdep assert in
clr_context_registered in our CI runs because we never hit this case as
it requires 64k+ contexts. Maybe we can add a selftest to purposely
exercise this path? Not a blocker for merging this fix.
Was the bug found by inspection or reported?
Given the buggy function is called steal_guc_id, so if the implication
is there is no testing for guc id stealing, then it indeed please add
some coverage ASAP.
Regards,
Tvrtko
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 1f9d4fde421f..9b7b4f4e0d91 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1937,9 +1937,9 @@ static int steal_guc_id(struct intel_guc *guc,
struct intel_context *ce)
list_del_init(&cn->guc_id.link);
ce->guc_id = cn->guc_id;
- spin_lock(&ce->guc_state.lock);
+ spin_lock(&cn->guc_state.lock);
clr_context_registered(cn);
- spin_unlock(&ce->guc_state.lock);
+ spin_unlock(&cn->guc_state.lock);
set_context_guc_id_invalid(cn);
Re: [PATCH 18/18] [HACK, RFC] clk: rk3568: do not divide dclk_vop0
On Wed, Dec 08, 2021 at 05:51:43PM +0100, Heiko Stübner wrote: > Hi Sascha, > > Am Mittwoch, 8. Dezember 2021, 16:12:30 CET schrieb Sascha Hauer: > > On the rk3568 we have this (simplified) situation: > > > > .. .-..-. > > -| hpll |--.--| /n ||dclk_vop0|- > > `´ | `-´`-´ > > | .-..-. > > `--| /m ||dclk_vop1|- > > | `-´`-´ > > | .-. > > `-|hdmi_ref |- > >`-´ > > > > hpll is the PLL that drives the HDMI reference clock and the pixel > > clocks for the different CRTCs (dclk_vop0/1). Between the pixel clocks > > and the hpll there are programmable dividers whereas the HDMI reference > > clock is directly connected to the hpll. > > > > For the HDMI output to work the pixel clock must be the same as the HDMI > > reference clock, hence the dividers must be programmed to 1. Normally a > > rate change on dclk_vop0/1 propagates through to the hpll and the clock > > framework picks a suitable combination of hpll and divider settings. by > > accident it picks a divider setting of 1 for the standard 1080p case, > > but other divider settings for most other resolutions leaving the HDMI > > port non working. > > > > This patch is not a solution, it merely puts the finger in the wound. We > > leave out the divider for the composite clock for dclk_vop0 which then > > leaves the divider at the bootloader default setting of 1. I assume > > the divider is disturbing only for the HDMI case, but needed for other > > outputs. Any thoughts how this can be handled? > > I'm not even sure if/how the common clock framework keeps track of > diverging wishes to parent-rates :-) . I don't think the common clock framework tries to keep track of that. > > But I do see two direct issues in the _existing_ code. > > dclk_vop0/1 uses CLK_SET_RATE_PARENT so is allowed to change > the rates of its parent clock(s). > > Its parent clocks are not only hpll but can also be vpll, gpll and cpll. > So this can cause even more mayhem, if the ccf for example decides > to select the gpll and then change its rate,which may result in a lot > of peripherals getting their rates changed under them ;-) . Right, we can only allow the CLK_SET_RATE_PARENT parent flag on the dclk clocks when the parent is HPLL. Since we can't be sure that HPLL is the parent we have to remove the flag. > > On the other hand I see in the clock driver that hdmi-ref is not allowed > to change its parent rate, so can only select between hpll and hpll_ph0 > (1/2 the rate?). > > So I guess, one way could be: > - add CLK_SET_RATE_PARENT to the hdmi-ref clock > - drop CLK_SET_RATE_PARENT from the dclks > - make sure hdmi-clock is set before the dclk That solves it for the HDMI case. I can imagine that for a LVDS user the CLK_SET_RATE_PARENT flag on the dclks is quite handy to get a PLL frequency suitable for the display. Otherwise he would have to set a suitable PLL frequency using assigned-clock-rates in the device tree. That's still possible so this might be a good compromise. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 17/18] drm: rockchip: Add VOP2 driver
Hi Johan,
On Wed, Dec 08, 2021 at 05:59:16PM +0100, Johan Jonker wrote:
> Hi,
>
> On 12/8/21 4:12 PM, Sascha Hauer wrote:
> > From: Andy Yan
> >
> > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> > It replaces the VOP unit found in the older Rockchip SoCs.
> >
> > This driver has been derived from the downstream Rockchip Kernel and
> > heavily modified:
> >
> > - All nonstandard DRM properties have been removed
> > - dropped struct vop2_plane_state and pass around less data between
> > functions
> > - Dropped all DRM_FORMAT_* not known on upstream
> > - rework register access to get rid of excessively used macros
> > - Drop all waiting for framesyncs
> >
> > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
> > board. Overlay support is tested with the modetest utility. AFBC support
> > on the cluster windows is tested with weston-simple-dmabuf-egl on
> > weston using the (yet to be upstreamed) panfrost driver support.
> >
> > Signed-off-by: Sascha Hauer
> > ---
>
> [..]
>
> > +
> > +static const struct of_device_id vop2_dt_match[] = {
> > + {
> > + .compatible = "rockchip,rk3568-vop",
> > + .data = &rk3568_vop
> > + }, {
>
> > + .compatible = "rockchip,rk3568-vop",
>
> Maybe use:
> .compatible = "rockchip,rk3566-vop",
Copy/Paste bug. Will fix.
>
> > + .data = &rk3566_vop
> > + }, {
> > + },
>
> Maybe sort this list alphabetical based on compatible in case later more
> SoCs are added.
>
> rk3566
> rk3568
Ok.
>
> ===
>
> The structure layout size above could be reduced for if we get more
> compatible strings additions.
>
> Example vop1:
>
> static const struct of_device_id vop_driver_dt_match[] = {
> { .compatible = "rockchip,rk3036-vop",
> .data = &rk3036_vop },
> { .compatible = "rockchip,rk3126-vop",
> .data = &rk3126_vop },
> { .compatible = "rockchip,px30-vop-big",
> .data = &px30_vop_big },
> { .compatible = "rockchip,px30-vop-lit",
> .data = &px30_vop_lit },
> { .compatible = "rockchip,rk3066-vop",
> .data = &rk3066_vop },
> { .compatible = "rockchip,rk3188-vop",
> .data = &rk3188_vop },
> { .compatible = "rockchip,rk3288-vop",
> .data = &rk3288_vop },
> { .compatible = "rockchip,rk3368-vop",
> .data = &rk3368_vop },
> { .compatible = "rockchip,rk3366-vop",
> .data = &rk3366_vop },
> { .compatible = "rockchip,rk3399-vop-big",
> .data = &rk3399_vop_big },
> { .compatible = "rockchip,rk3399-vop-lit",
> .data = &rk3399_vop_lit },
> { .compatible = "rockchip,rk3228-vop",
> .data = &rk3228_vop },
> { .compatible = "rockchip,rk3328-vop",
> .data = &rk3328_vop },
> {},
It's shorter, but ugly ;)
That's only my personal taste though, I don't care much.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 0/2] Add SMBus features to Tegra I2C
On Thu, Dec 09, 2021 at 07:04:30PM +0300, Dmitry Osipenko wrote: > 09.12.2021 18:05, Akhil R пишет: > > Add support for SMBus Alert and SMBus block read functions to > > i2c-tegra driver > > > > Akhil R (2): > > dt-bindings: i2c: tegra: Add SMBus feature properties > > i2c: tegra: Add SMBus block read and SMBus alert functions > > > > .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 4 ++ > > drivers/i2c/busses/i2c-tegra.c | 54 > > +- > > 2 files changed, 57 insertions(+), 1 deletion(-) > > > > How this was tested? This series must include the DT patch. If there is > no real user in upstream for this feature, then I don't think that we > should bother at all about it. This is primarily used by a device that uses ACPI and the driver uses the firmware-agnostic APIs to get at this. However, it also means that the driver effectively provides this same support for DT via those APIs and therefore it makes sense to document that part even if there are no current users of the DT bits. One big advantage of this is that it helps keep the ACPI and DT bindings in sync, and document this on the DT side also allows us to document the ACPI side of things where no formal documentation exists, as far as I know. Thierry signature.asc Description: PGP signature
Re: [PATCH 1/9] drm/i915/gvt: Constify intel_gvt_gtt_pte_ops
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
> drivers/gpu/drm/i915/gvt/gtt.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 53d0cb327539..6efa48727052 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -516,7 +516,7 @@ static struct intel_gvt_gtt_pte_ops gen8_gtt_pte_ops = {
> .set_pfn = gen8_gtt_set_pfn,
> };
>
> -static struct intel_gvt_gtt_gma_ops gen8_gtt_gma_ops = {
> +static const struct intel_gvt_gtt_gma_ops gen8_gtt_gma_ops = {
> .gma_to_ggtt_pte_index = gma_to_ggtt_pte_index,
> .gma_to_pte_index = gen8_gma_to_pte_index,
> .gma_to_pde_index = gen8_gma_to_pde_index,
> @@ -2097,7 +2097,7 @@ unsigned long intel_vgpu_gma_to_gpa(struct
> intel_vgpu_mm *mm, unsigned long gma)
> struct intel_vgpu *vgpu = mm->vgpu;
> struct intel_gvt *gvt = vgpu->gvt;
> struct intel_gvt_gtt_pte_ops *pte_ops = gvt->gtt.pte_ops;
> - struct intel_gvt_gtt_gma_ops *gma_ops = gvt->gtt.gma_ops;
> + const struct intel_gvt_gtt_gma_ops *gma_ops = gvt->gtt.gma_ops;
> unsigned long gpa = INTEL_GVT_INVALID_ADDR;
> unsigned long gma_index[4];
> struct intel_gvt_gtt_entry e;
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.h b/drivers/gpu/drm/i915/gvt/gtt.h
> index 3bf45672ef98..d0d598322404 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.h
> +++ b/drivers/gpu/drm/i915/gvt/gtt.h
> @@ -92,7 +92,7 @@ struct intel_gvt_gtt_gma_ops {
>
> struct intel_gvt_gtt {
> struct intel_gvt_gtt_pte_ops *pte_ops;
> - struct intel_gvt_gtt_gma_ops *gma_ops;
> + const struct intel_gvt_gtt_gma_ops *gma_ops;
> int (*mm_alloc_page_table)(struct intel_vgpu_mm *mm);
> void (*mm_free_page_table)(struct intel_vgpu_mm *mm);
> struct list_head oos_page_use_list_head;
It seems like the tittle doesn't match with the modification. I guess it
should be Constify intel_gvt_gtt_gma_ops. I can fix that for you when
applied.
Reviewed-by: Zhi Wang
Re: [PATCH 0/9] drm/i915/gvt: Constify static structs
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote: > Constify a number of static structs that are never modified to allow the > compiler to put them in read-only memory. In order to do this, constify a > number of local variables and pointers in structs. > > This is most important for structs that contain function pointers, and > the patches for those structs are placed first in the series. > > Rikard Falkeborn (9): >drm/i915/gvt: Constify intel_gvt_gtt_pte_ops >drm/i915/gvt: Constify intel_gvt_gtt_pte_ops >drm/i915/gvt: Constify intel_gvt_irq_ops >drm/i915/gvt: Constify intel_gvt_sched_policy_ops >drm/i915/gvt: Constify gvt_mmio_block >drm/i915/gvt: Constify cmd_interrupt_events >drm/i915/gvt: Constify formats >drm/i915/gvt: Constify gtt_type_table_entry >drm/i915/gvt: Constify vgpu_types > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +- > drivers/gpu/drm/i915/gvt/fb_decoder.c | 24 - > drivers/gpu/drm/i915/gvt/gtt.c | 68 - > drivers/gpu/drm/i915/gvt/gtt.h | 4 +- > drivers/gpu/drm/i915/gvt/gvt.h | 2 +- > drivers/gpu/drm/i915/gvt/handlers.c | 12 ++--- > drivers/gpu/drm/i915/gvt/interrupt.c| 10 ++-- > drivers/gpu/drm/i915/gvt/interrupt.h| 2 +- > drivers/gpu/drm/i915/gvt/sched_policy.c | 2 +- > drivers/gpu/drm/i915/gvt/scheduler.h| 2 +- > drivers/gpu/drm/i915/gvt/vgpu.c | 4 +- > 11 files changed, 66 insertions(+), 66 deletions(-) > Thanks so much for the contribuition. You only need to refine the PATCH 2 a little bit and re-send it.
Re: [PATCH] drm/panel: ilitek-ili9881c: Avoid unbalance prepare/unprepare
Hi Dave
some questions below
On Thu, Dec 9, 2021 at 7:10 PM Michael Nazzareno Trimarchi
wrote:
>
> Hi Dave
>
> On Thu, Dec 9, 2021 at 6:58 PM Dave Stevenson
> wrote:
> >
> > Hi Michael
> >
> > On Thu, 9 Dec 2021 at 16:58, Michael Nazzareno Trimarchi
> > wrote:
> > >
> > > Hi all
> > >
> > > On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
> > > wrote:
> > > >
> > > > All the panel driver check the fact that their prepare/unprepare
> > > > call was already called. It's not an ideal solution but fix
> > > > for now the problem on ili9881c
> > > >
> > > > [ 9862.283296] [ cut here ]
> > > > [ 9862.288490] unbalanced disables for vcc3v3_lcd
> > > > [ 9862.293555] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2851
> > > > _regulator_disable+0xd4/0x190
> > > >
> > > > from:
> > > >
> > > > [ 9862.038619] drm_panel_unprepare+0x2c/0x4c
> > > > [ 9862.043212] panel_bridge_post_disable+0x18/0x24
> > > > [ 9862.048390] dw_mipi_dsi_bridge_post_disable+0x3c/0xf0
> > > > [ 9862.054153] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > > >
> > > > and:
> > > >
> > > > [ 9862.183103] drm_panel_unprepare+0x2c/0x4c
> > > > [ 9862.187695] panel_bridge_post_disable+0x18/0x24
> > > > [ 9862.192872] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > > > [ 9862.199117] disable_outputs+0x120/0x31c
> >
> > This is down to the dw-mipi-dsi driver calling the post_disable hook
> > explicitly at [1], but then also allowing the framework to call it.
> > The explicit call is down to limitations in the DSI support, so we
> > can't control the DSI host state to a fine enough degree (an ongoing
> > discussion [2] [3]). There shouldn't be a need to handle mismatched
> > calling in individual panel drivers.
> >
> > Dave
> >
> > [1]
> > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L894
> > [2]
> > https://lists.freedesktop.org/archives/dri-devel/2021-November/332060.html
> > [3]
> > https://lists.freedesktop.org/archives/dri-devel/2021-December/334007.html
>
> I'm in the second case. I need to enable HS mode after the panel is
> initialized. Time to time I have timeout
> on dsi command or I have wrong panel initialization. So I explicit call from
> the bridge but I understand that is not correct in the design point of view.
>
> So this patch can not be queued because it's a known problem that
> people are discussing
>
Author: Michael Trimarchi
Date: Thu Dec 9 15:45:48 2021 +0100
drm: bridge: samsung-dsim: Enable panel/bridge before exist from standby
We need to exist from standby as last operation to have a proper video
working. This code implement the same code was before the bridge
migration
Signed-off-by: Michael Trimarchi
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 654851edbd9b..21265ae80022 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1838,6 +1838,7 @@ static void samsung_dsim_atomic_enable(struct
drm_bridge *bridge,
struct drm_bridge_state
*old_bridge_state)
{
struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+ struct drm_atomic_state old_state;
int ret;
if (dsi->state & DSIM_STATE_ENABLED)
@@ -1859,6 +1860,9 @@ static void samsung_dsim_atomic_enable(struct
drm_bridge *bridge,
}
samsung_dsim_set_display_mode(dsi);
+
+ drm_atomic_bridge_chain_enable(dsi->out_bridge, &old_state);
+
samsung_dsim_set_display_enable(dsi, true);
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
Right now I'm doing this to enable the change. I must change the panel
to avoid double enabled
I have some questions:
- the chain is an element (bridge/panel) linked together via some
connector (I hope I understand) when I enable
a bridge chain, all the elements should move from some status to
another. If we mark them already this should
not avoid that one element can be enabled two times? An element that
sources two other elements should for instance
receive the enable from two times before switching on.
Michael
> Michael
>
> >
> >
> > > > Signed-off-by: Michael Trimarchi
> > > > ---
> > > > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++
> > > > 1 file changed, 14 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > > b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > > index 103a16018975..f75eecb0e65c 100644
> > > > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> > > > @@ -52,6 +52,8 @@ struct ili9881c {
> > > >
> > > > struct regulator*power;
> > > > struct gpio_desc*reset;
> > > > +
> > > > + boolprepared;
> > > > };
> > > >
> > >
> > > I found that this can be a general problem. Should not mandatory to
> > > track panel status
> > >
> > > D
Re: [Nouveau] [PATCH] drm/nouveau: wait for the exclusive fence after the shared ones v2
Hi, this is your Linux kernel regression tracker speaking.
On 09.12.21 11:23, Christian König wrote:
> Always waiting for the exclusive fence resulted on some performance
> regressions. So try to wait for the shared fences first, then the
> exclusive fence should always be signaled already.
>
> v2: fix incorrectly placed "(", add some comment why we do this.
>
> Signed-off-by: Christian König
FWIW: In case you need to send an improved patch, could you please add
this (see (¹) below for the reasoning):
Link:
https://lore.kernel.org/dri-devel/da142fb9-07d7-24fe-4533-0247b8d16...@sfritsch.de/
And if the patch is already good to go: could the subsystem maintainer
please add it when applying? See (¹) for the reasoning.
BTW, these two lines afaics are missing as well:
Fixes: 3e1ad79bf661 ("drm/nouveau: always wait for the exclusive fence")
Reported-by: Stefan Fritsch
Ciao, Thorsten
(¹) Long story: The commit message would benefit from a link to the
regression report, for reasons explained in
Documentation/process/submitting-patches.rst. To quote:
```
If related discussions or any other background information behind the
change can be found on the web, add 'Link:' tags pointing to it. In case
your patch fixes a bug, for example, add a tag with a URL referencing
the report in the mailing list archives or a bug tracker;
```
This concept is old, but the text was reworked recently to make this use
case for the Link: tag clearer. For details see:
https://git.kernel.org/linus/1f57bd42b77c
Yes, that "Link:" is not really crucial; but it's good to have if
someone needs to look into the backstory of this change sometime in the
future. But I care for a different reason. I'm tracking this regression
(and others) with regzbot, my Linux kernel regression tracking bot. This
bot will notice if a patch with a Link: tag to a tracked regression gets
posted and record that, which allowed anyone looking into the regression
to quickly gasp the current status from regzbot's webui
(https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The
bot will also notice if a commit with a Link: tag to a regression report
is applied by Linus and then automatically mark the regression as
resolved then.
IOW: this tag makes my life a regression tracker a lot easier, as I
otherwise have to tell regzbot manually when the fix lands. :-/
#regzbot ^backmonitor:
https://lore.kernel.org/dri-devel/da142fb9-07d7-24fe-4533-0247b8d16...@sfritsch.de/
Re: [PATCH v2 3/3] drm/vc4: Notify the firmware when DRM is in charge
Hi Maxime,
On Fri, 2021-12-03 at 14:51 +0100, Maxime Ripard wrote:
> Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
> been made, simplefb has been unregistered and the KMS driver is entirely
> in charge of the display.
>
> Thus, we can notify the firmware it can free whatever resource it was
> using to maintain simplefb functional.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 19 +++
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 8ab89f805826..38d55a47c831 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -37,6 +37,8 @@
> #include
> #include
>
> +#include
> +
> #include "uapi/drm/vc4_drm.h"
>
> #include "vc4_drv.h"
> @@ -251,10 +253,27 @@ static int vc4_drm_bind(struct device *dev)
> if (ret)
> return ret;
>
> + node = of_find_compatible_node(NULL, NULL,
> "raspberrypi,bcm2835-firmware");
> + if (node) {
> + vc4->firmware = devm_rpi_firmware_get(dev, node);
I'm really sorry for contradicting myself, but I think it makes more sense to
do rpi_firmware_get() here...
> + of_node_put(node);
> +
> + if (!vc4->firmware)
> + return -EPROBE_DEFER;
> + }
> +
> ret = drm_aperture_remove_framebuffers(false, &vc4_drm_driver);
> if (ret)
> return ret;
>
> + if (vc4->firmware) {
> + ret = rpi_firmware_property(vc4->firmware,
> + RPI_FIRMWARE_NOTIFY_DISPLAY_DONE,
> + NULL, 0);
> + if (ret)
> + drm_warn(drm, "Couldn't stop firmware display driver:
> %d\n", ret);
> + }
> +
...and rpi_firmware_put() here. IIUC after this the fw handle isn't needed
anymore.
Other than that, the series looks fine to me.
Regards,
Nicolas
Re: [PATCH] drm/dp: Actually read Adjust Request Post Cursor2 register
On Thu, 09 Dec 2021, Kees Cook wrote:
> On Thu, Dec 09, 2021 at 05:20:45PM -0500, Harry Wentland wrote:
>>
>>
>> On 2021-12-09 01:23, Kees Cook wrote:
>> > On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
>> >> On Fri, 03 Dec 2021, Kees Cook wrote:
>> >>> The link_status array was not large enough to read the Adjust Request
>> >>> Post Cursor2 register. Adjust the size to include it. Found with a
>> >>> -Warray-bounds build:
>> >>>
>> >>> drivers/gpu/drm/drm_dp_helper.c: In function
>> >>> 'drm_dp_get_adjust_request_post_cursor':
>> >>> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is
>> >>> outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
>> >>> [-Werror=array-bounds]
>> >>>59 | return link_status[r - DP_LANE0_1_STATUS];
>> >>> |~~~^~~
>> >>> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
>> >>> 'link_status'
>> >>> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
>> >>> link_status[DP_LINK_STATUS_SIZE],
>> >>> |
>> >>> ~^~~~
>> >>>
>> >>> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
>> >>> Signed-off-by: Kees Cook
>> >>
>> >> Using DP_ADJUST_REQUEST_POST_CURSOR2 has been deprecated since DP 1.3
>> >> published in 2014, and Tegra is the only user of
>> >> drm_dp_get_adjust_request_post_cursor().
>> >
>> > I see POST_CURSOR2 is used here too:
>> >
>> > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> >
>>
>> Looks like we read and parse that in the admgpu driver without
>> using drm_dp_get_adjust_request_post_cursor.
>
> Right, and probably that could be switched to use it, but I'm not sure
> what the impact of the larger link_status read is.
>
>>
>> I don't have a strong feeling but I liked your original
>> patch a bit better. I'm not sure what it means when part
>> of a spec is deprecated. Once a spec is written display
>> vendors might implement it. We should make sure that
>> displays like that are always handled in a sane manner.
>
> Jani, Dave, any guidance here? I'm fine with whatever, but the current
> code is for sure broken. ;)
Post Cursor2 was completely optional for the transmitter even before it
was deprecated.
And now we'd be adding 5 bytes extra to all link status reads. To fix
the only user of drm_dp_get_adjust_request_post_cursor() that apparently
has never worked as intended. I'm just not convinced.
I was trying to look through the implications of DP_LINK_STATUS_SIZE
increase, and at least drm_dp_dpcd_read_phy_link_status() comes across
as something probably needing attention.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH 1/2] drm/i915: Introduce new Tile 4 format
On Thu, Dec 09, 2021 at 05:14:56PM +0200, Chery, Nanley G wrote:
>
>
> > -Original Message-
> > From: Lisovskiy, Stanislav
> > Sent: Thursday, December 9, 2021 5:47 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Lisovskiy, Stanislav
> > ; Saarinen, Jani ;
> > C,
> > Ramalingam ; ville.syrj...@linux.intel.com; Deak,
> > Imre ; Chery, Nanley G
> > Subject: [PATCH 1/2] drm/i915: Introduce new Tile 4 format
> >
>
> We want this patch to be 2/2, right? That way, we expose public kernel
> support for the format after the kernel gains internal support for it.
Previously modifiers have been added in a separate patch CC'd to
dri-devel (and that patch needs to be before the one starting to use
it) and then merged via the i915 tree only after getting an ACK for this
from Jani or Danvet.
The modifier will be exposed to userspace only after the second
one, so I don't see a problem with that approach.
Either way the patchset looks ok to me:
Reviewed-by: Imre Deak
> With that fixed, this patch is:
>
> Acked-by: Nanley Chery
>
> Alternatively, you could apply the ack to the prior combined patch if you'd
> like.
>
> -Nanley
>
>
>
> > This tiling layout uses 4KB tiles in a row-major layout. It has the same
> > shape as
> > Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It only
> > differs from
> > Tile Y at the 256B granularity in between. At this granularity, Tile Y has
> > a shape
> > of 16B x 32 rows, but this tiling has a shape of 64B x 8 rows.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > include/uapi/drm/drm_fourcc.h | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 7f652c96845b..a146c6df1066 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -565,6 +565,17 @@ extern "C" {
> > */
> > #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC
> > fourcc_mod_code(INTEL, 8)
> >
> > +/*
> > + * Intel Tile 4 layout
> > + *
> > + * This is a tiled layout using 4KB tiles in a row-major layout. It has
> > +the same
> > + * shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x
> > +4). It
> > + * only differs from Tile Y at the 256B granularity in between. At this
> > + * granularity, Tile Y has a shape of 16B x 32 rows, but this tiling
> > +has a shape
> > + * of 64B x 8 rows.
> > + */
> > +#define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
> > +
> > /*
> > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> > *
> > --
> > 2.24.1.485.gad05a3d8e5
>
Re: [PATCH 02/10] drm: Add privacy-screen class (v4)
Hi, this is your Linux kernel regression tracker speaking. Top-posting for once, to make this easy accessible to everyone. Hans, I stumbled upon your blog post about something that afaics is related to below patch: https://hansdegoede.livejournal.com/25948.html To quote: > To avoid any regressions distors should modify their initrd > generation tools to include privacy screen provider drivers in the > initrd (at least on systems with a privacy screen), before 5.17 > kernels start showing up in their repos. > > If this change is not made, then users using a graphical bootsplash > (plymouth) will get an extra boot-delay of up to 8 seconds > (DeviceTimeout in plymouthd.defaults) before plymouth will show and > when using disk-encryption where the LUKS password is requested from > the initrd, the system will fallback to text-mode after these 8 > seconds. Sorry for intruding, but to me as the kernel's regression tracker that blog post sounds a whole lot like "by kernel development standards this is not allowed due to the 'no regression rule', as users should never be required to update something in userspace when updating the kernel". But I'm not totally sure that's the case here. Could you please clarify what happens when a user doesn't update the initramfs. E.g. what happens besides the mentioned delay and the text mode (which are bad already, but might be a accetable compormise here -- but that's up for Linus to decide)? Does everything start to work normally shortly after the kernel mounted the rootfs and finally can load the missing module? tia! Ciao, Thorsten On 05.10.21 22:23, Hans de Goede wrote: > On some new laptops the LCD panel has a builtin electronic privacy-screen. > We want to export this functionality as a property on the drm connector > object. But often this functionality is not exposed on the GPU but on some > other (ACPI) device. > > This commit adds a privacy-screen class allowing the driver for these > other devices to register themselves as a privacy-screen provider; and > allowing the drm/kms code to get a privacy-screen provider associated > with a specific GPU/connector combo. > > Changes in v2: > - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy > code gets built as part of the main drm module rather then making it > a tristate which builds its own module. > - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to > drm_privacy_screen_consumer.h and define stubs when the check fails. > Together these 2 changes fix several dependency issues. > - Remove module related code now that this is part of the main drm.ko > - Use drm_class as class for the privacy-screen devices instead of > adding a separate class for this > > Changes in v3: > - Make the static inline drm_privacy_screen_get_state() stub set sw_state > and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized > variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set > > Changes in v4: > - Make drm_privacy_screen_set_sw_state() skip calling out to the hw if > hw_state == new_sw_state > > Reviewed-by: Emil Velikov > Reviewed-by: Lyude Paul > Signed-off-by: Hans de Goede > --- > Documentation/gpu/drm-kms-helpers.rst | 15 + > MAINTAINERS | 8 + > drivers/gpu/drm/Kconfig | 4 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_drv.c | 4 + > drivers/gpu/drm/drm_privacy_screen.c | 403 ++ > include/drm/drm_privacy_screen_consumer.h | 50 +++ > include/drm/drm_privacy_screen_driver.h | 80 + > include/drm/drm_privacy_screen_machine.h | 41 +++ > 9 files changed, 606 insertions(+) > create mode 100644 drivers/gpu/drm/drm_privacy_screen.c > create mode 100644 include/drm/drm_privacy_screen_consumer.h > create mode 100644 include/drm/drm_privacy_screen_driver.h > create mode 100644 include/drm/drm_privacy_screen_machine.h > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index ec2f65b31930..5bb55ec1b9b5 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -435,3 +435,18 @@ Legacy CRTC/Modeset Helper Functions Reference > > .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c > :export: > + > +Privacy-screen class > + > + > +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c > + :doc: overview > + > +.. kernel-doc:: include/drm/drm_privacy_screen_driver.h > + :internal: > + > +.. kernel-doc:: include/drm/drm_privacy_screen_machine.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c > + :export: > diff --git a/MAINTAINERS b/MAINTAINERS > index 28e5f0ae1009..cb94bb3b8724 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6423,6 +6423,14 @@ F: drivers/gpu/drm/drm_panel.c > F: drivers/gpu/drm/panel/ > F: include/drm/drm_panel.h > > +DRM PRIVACY-SCREEN CLASS >
Re: [PATCH v6 7/7] drm/mediatek: Add mt8195 DisplayPort driver
Il 10/11/21 14:06, Guillaume Ranquet ha scritto: From: Markus Schneider-Pargmann This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a according phy driver mediatek-dp-phy. It supports both functional units on the mt8195, the embedded DisplayPort as well as the external DisplayPort units. It offers hot-plug-detection, audio up to 8 channels, and DisplayPort 1.4 with up to 4 lanes. The driver creates a child device for the phy. The child device will never exist without the parent being active. As they are sharing a register range, the parent passes a regmap pointer to the child so that both can work with the same register range. The phy driver sets device data that is read by the parent to get the phy device that can be used to control the phy properties. This driver is based on an initial version by Jason-JH.Lin . Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Guillaume Ranquet Reported-by: kernel test robot Hello Markus, Guillaume, there is a critical issue with this patch. Please check below. --- drivers/gpu/drm/drm_edid.c |2 +- drivers/gpu/drm/mediatek/Kconfig|7 + drivers/gpu/drm/mediatek/Makefile |2 + drivers/gpu/drm/mediatek/mtk_dp.c | 3094 +++ drivers/gpu/drm/mediatek/mtk_dp_reg.h | 568 + drivers/gpu/drm/mediatek/mtk_dpi.c | 111 +- drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 26 + drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 + drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 + 9 files changed, 3799 insertions(+), 13 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c index 384074f69111b..e6e88e3cd811d 100644 --- a/drivers/gpu/drm/mediatek/mtk_dpi.c +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c @@ -979,6 +1051,16 @@ static int mtk_dpi_probe(struct platform_device *pdev) return ret; } + dpi->dpi_ck_cg = devm_clk_get(dev, "ck_cg"); mtk_dpi is used on MT2701, MT7183, MT8183, MT8192, but these platforms haven't got any "ck_cg" clock defined in their device-trees (regardless of whether these can support adding this clock or not, any code change shall be retro-compatible hence not breaking compatibility/functionality with older device-trees). Reminding that: - mediatek-drm uses the component framework - mtk_drm_drv is the component master - mtk_drm_drv bind() won't be called unless all of the components added with match aren't calling component_add() ... this change not only breaks DisplayPort support for *all* of the aforementioned SoCs, but also makes the entire mediatek-drm to not finish probing, producing a global breakage that also includes DSI and the entire stack of components of that master (so, no display on all of them). To avoid breaking any SoC that's not MT8195, please use devm_clk_get_optional() here in the next version. Thanks, - Angelo
Re: [Intel-gfx] [PATCH] drm/i915/guc: Use correct context lock when callig clr_context_registered
On Fri, 10 Dec 2021, Tvrtko Ursulin wrote:
> On 09/12/2021 19:14, Daniele Ceraolo Spurio wrote:
>>
>>
>> On 12/9/2021 10:48 AM, Matthew Brost wrote:
>>> s/ce/cn/ when grabbing guc_state.lock before calling
>>> clr_context_registered.
>>>
>>> Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
>>> Signed-off-by: Matthew Brost
>>> Cc:
>
> I think Cc: stable is not needed here:
>
> $ git tag --contains 0f7976506de61
> drm-intel-fixes-2021-11-18
> drm-intel-gt-next-2021-10-08
> drm-intel-gt-next-2021-10-21
> drm-intel-gt-next-2021-11-22
> drm-intel-next-2021-10-15
> drm-intel-next-fixes-2021-11-09
> v5.16-rc1
> v5.16-rc2
> v5.16-rc3
> v5.16-rc4
'dim fixes 0f7976506de61' concurs.
BR,
Jani.
>
> So still can hit 5.16 via fixes. Rodrigo, did I get this right and you
> will be able to pick it up next week or so?
>
>> Reviewed-by: Daniele Ceraolo Spurio
>>
>> I'm assuming we didn't see any splat from the lockdep assert in
>> clr_context_registered in our CI runs because we never hit this case as
>> it requires 64k+ contexts. Maybe we can add a selftest to purposely
>> exercise this path? Not a blocker for merging this fix.
>
> Was the bug found by inspection or reported?
>
> Given the buggy function is called steal_guc_id, so if the implication
> is there is no testing for guc id stealing, then it indeed please add
> some coverage ASAP.
>
> Regards,
>
> Tvrtko
>
>>
>> Daniele
>>
>>> ---
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> 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 1f9d4fde421f..9b7b4f4e0d91 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> @@ -1937,9 +1937,9 @@ static int steal_guc_id(struct intel_guc *guc,
>>> struct intel_context *ce)
>>> list_del_init(&cn->guc_id.link);
>>> ce->guc_id = cn->guc_id;
>>> - spin_lock(&ce->guc_state.lock);
>>> + spin_lock(&cn->guc_state.lock);
>>> clr_context_registered(cn);
>>> - spin_unlock(&ce->guc_state.lock);
>>> + spin_unlock(&cn->guc_state.lock);
>>> set_context_guc_id_invalid(cn);
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v4 11/16] drm/i915/dg2: Add DG2 unified compression
On Thu, Dec 09, 2021 at 09:15:28PM +0530, Ramalingam C wrote:
> From: Matt Roper
>
> DG2 unifies render compression and media compression into a single
> format for the first time. The programming and buffer layout is
> supposed to match compression on older gen12 platforms, but the actual
> compression algorithm is different from any previous platform; as such,
> we need a new framebuffer modifier to represent buffers in this format,
> but otherwise we can re-use the existing gen12 compression driver logic.
>
> Signed-off-by: Matt Roper
> cc: Radhakrishna Sripada
> Signed-off-by: Mika Kahola (v2)
> cc: Anshuman Gupta
> Signed-off-by: Juha-Pekka Heikkilä
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 13
> .../drm/i915/display/skl_universal_plane.c| 33 +++
> include/uapi/drm/drm_fourcc.h | 22 +
> 3 files changed, 61 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 46505c69fe72..e15216f1cb82 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -141,6 +141,14 @@ struct intel_modifier_desc {
>
> static const struct intel_modifier_desc intel_modifiers[] = {
> {
> + .modifier = I915_FORMAT_MOD_4_TILED_DG2_MC_CCS,
> + .display_ver = { 13, 14 },
13 is the latest display version.
> + .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_MC,
> + }, {
> + .modifier = I915_FORMAT_MOD_4_TILED_DG2_RC_CCS,
> + .display_ver = { 13, 14 },
> + .plane_caps = INTEL_PLANE_CAP_TILING_4 | INTEL_PLANE_CAP_CCS_RC,
> + }, {
> .modifier = I915_FORMAT_MOD_4_TILED,
> .display_ver = { 13, 14 },
> .plane_caps = INTEL_PLANE_CAP_TILING_4,
> @@ -550,6 +558,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
> int color_plane)
> return 128;
> else
> return 512;
> + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> + case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> case I915_FORMAT_MOD_4_TILED:
> /*
>* Each 4K tile consists of 64B(8*8) subtiles, with
> @@ -752,6 +762,9 @@ unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> case I915_FORMAT_MOD_4_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> return 1 * 1024 * 1024;
> + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> + case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> + return 16 * 1024;
> default:
> MISSING_CASE(fb->modifier);
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index f62ba027fcf9..d80424194c75 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -764,6 +764,14 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier)
> return PLANE_CTL_TILED_Y;
> case I915_FORMAT_MOD_4_TILED:
> return PLANE_CTL_TILED_4;
> + case I915_FORMAT_MOD_4_TILED_DG2_RC_CCS:
> + return PLANE_CTL_TILED_4 |
> + PLANE_CTL_RENDER_DECOMPRESSION_ENABLE |
> + PLANE_CTL_CLEAR_COLOR_DISABLE;
> + case I915_FORMAT_MOD_4_TILED_DG2_MC_CCS:
> + return PLANE_CTL_TILED_4 |
> + PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE |
> + PLANE_CTL_CLEAR_COLOR_DISABLE;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> return PLANE_CTL_TILED_Y |
> PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
> @@ -2073,6 +2081,10 @@ static bool gen12_plane_has_mc_ccs(struct
> drm_i915_private *i915,
> if (IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0))
> return false;
>
> + /* Wa_14013215631 */
> + if (IS_DG2_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> + return false;
> +
> return plane_id < PLANE_SPRITE4;
> }
>
> @@ -2312,18 +2324,25 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
> break;
> case PLANE_CTL_TILED_Y:
> plane_config->tiling = I915_TILING_Y;
> - if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
> - fb->modifier = DISPLAY_VER(dev_priv) >= 12 ?
> - I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS :
> - I915_FORMAT_MOD_Y_TILED_CCS;
> - else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
> + if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) {
> + if (DISPLAY_VER(dev_priv) >= 12)
> + fb->modifier =
> I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS;
> + else
> +
Re: [PATCH 02/10] drm: Add privacy-screen class (v4)
Hi Thorsten, On 12/10/21 11:12, Thorsten Leemhuis wrote: > Hi, this is your Linux kernel regression tracker speaking. > > Top-posting for once, to make this easy accessible to everyone. > > Hans, I stumbled upon your blog post about something that afaics is > related to below patch: > https://hansdegoede.livejournal.com/25948.html > > To quote: > >> To avoid any regressions distors should modify their initrd >> generation tools to include privacy screen provider drivers in the >> initrd (at least on systems with a privacy screen), before 5.17 >> kernels start showing up in their repos. >> >> If this change is not made, then users using a graphical bootsplash >> (plymouth) will get an extra boot-delay of up to 8 seconds >> (DeviceTimeout in plymouthd.defaults) before plymouth will show and >> when using disk-encryption where the LUKS password is requested from >> the initrd, the system will fallback to text-mode after these 8 >> seconds. > > Sorry for intruding, but to me as the kernel's regression tracker that > blog post sounds a whole lot like "by kernel development standards this > is not allowed due to the 'no regression rule', as users should never be > required to update something in userspace when updating the kernel". I completely understand where you are coming from here, but AFAIK the initrd generation has always been a bit of an exception here. For example (IIRC) over time we have seen the radeon module growing a runtime dependency on the amdkfd module which also required updated initrd generation tools. Another example (which I'm sure of) is the i915 driver gaining a softdep on kvmgt (which is now gone again) which required new enough kmod tools to understand this as well as initrd generation tools updates to also take softdeps into account: https://github.com/dracutdevs/dracut/commit/4cdee66c8ed5f82bbd0638e30d867318343b0e6c More in general if you look at e.g. dracut's git history, there are various other cases where dracut needed to be updated to adjust to kernel changes. For example dracut decides if a module is a block driver and thus may be necessary to have in the initrd based on a list of kernel-symbols the module links to and sometimes those symbols change due to refactoring of kernel internals, see e.g. : https://github.com/dracutdevs/dracut/commit/b292ce7295f18192124e64e5ec31161d09492160 TL;DR: initrd-generators and the kernel are simply tied together so much that users cannot expect to be able to jump to the latest kernel without either updating the initrd-generator, or adding some modules as modules which must always be added to the initrd in the initrd-generator config file (as a workaround). Declaring kernel changes which break initrd-generation in some way as being regressions, would mean that e.g. we cannot introduce any kernel changes which causes some drm/block/whatever drivers to use some new register helper functions which are not yet on the list of symbols which dracut uses to identify drm/block/whatever drivers. The only difference between previous initrd-generator breaking changes and this one, is that I decided that it would be good for everyone to be aware of this before hand; and now I get the feeling that I'm being punished for warning people about this instead of just letting things break silently. I know you don't intend your email this way in any way, but still. Also AFAIK drivers may also at some point drop support for (much) older firmware versions requiring installing a recent linux-firmware together with a new kernel. In my reading of the rules the 'users should never be required to update something in userspace when updating the kernel' rule is about keeping people's normal programs working, IOW not breaking userspace ABI and that is not happening here. > But I'm not totally sure that's the case here. Could you please clarify > what happens when a user doesn't update the initramfs. E.g. what happens > besides the mentioned delay and the text mode (which are bad already, > but might be a accetable compormise here -- but that's up for Linus to > decide)? Does everything start to work normally shortly after the kernel > mounted the rootfs and finally can load the missing module? Yes everything will work normally once the rootfs gets mounted and the missing module gets loaded. Regards, Hans > On 05.10.21 22:23, Hans de Goede wrote: >> On some new laptops the LCD panel has a builtin electronic privacy-screen. >> We want to export this functionality as a property on the drm connector >> object. But often this functionality is not exposed on the GPU but on some >> other (ACPI) device. >> >> This commit adds a privacy-screen class allowing the driver for these >> other devices to register themselves as a privacy-screen provider; and >> allowing the drm/kms code to get a privacy-screen provider associated >> with a specific GPU/connector combo. >> >> Changes in v2: >> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy >> co
[PATCH] drm/i915: Stop doing writeback from the shrinker
From: Tvrtko Ursulin
This effectively removes writeback which was added in 2d6692e642e7
("drm/i915: Start writeback from the shrinker").
Digging through the history it seems we went back and forth on the topic
of whether it would be safe a couple of times. See for instance
5537252b6b6d ("drm/i915: Invalidate our pages under memory pressure")
where Hugh Dickins has advised against it. I do not have enough expertise
in the memory management area so am hoping for expert input here.
Reason for proposing removal is that there are reports from the field
which indicate a sysetm wide deadlock (of a sort) implicating i915 doing
writeback at shrinking time.
Signature is a hung task notifier kicking in and task traces such as:
[ 247.030274] minijail-init D0 1773 1770 0x80004082
[ 247.036419] Call Trace:
[ 247.039167] __schedule+0x57e/0x10d2
[ 247.043175] ? __schedule+0x586/0x10d2
[ 247.047381] ? _raw_spin_unlock+0xe/0x20
[ 247.051779] ? __queue_work+0x316/0x371
[ 247.056079] schedule+0x7c/0x9f
[ 247.059602] rwsem_down_write_slowpath+0x2ae/0x494
[ 247.064971] unregister_shrinker+0x20/0x65
[ 247.069562] deactivate_locked_super+0x38/0x88
[ 247.074538] cleanup_mnt+0xcc/0x10e
[ 247.078447] task_work_run+0x7d/0xa6
[ 247.082459] do_exit+0x23d/0x831
[ 247.086079] ? syscall_trace_enter+0x207/0x20e
[ 247.091055] do_group_exit+0x8d/0x9d
[ 247.095062] __x64_sys_exit_group+0x17/0x17
[ 247.099750] do_syscall_64+0x54/0x7e
[ 247.103758] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 246.876816] chrome D0 1791 1785 0x4080
[ 246.882965] Call Trace:
[ 246.885713] __schedule+0x57e/0x10d2
[ 246.889724] ? pcpu_alloc_area+0x25d/0x273
[ 246.894314] schedule+0x7c/0x9f
[ 246.897836] rwsem_down_write_slowpath+0x2ae/0x494
[ 246.903207] register_shrinker_prepared+0x19/0x48
[ 246.908479] ? test_single_super+0x10/0x10
[ 246.913071] sget_fc+0x1fc/0x20e
[ 246.916691] ? kill_litter_super+0x40/0x40
[ 246.921334] ? proc_apply_options+0x42/0x42
[ 246.926044] vfs_get_super+0x3a/0xdf
[ 246.930053] vfs_get_tree+0x2b/0xc3
[ 246.933965] fc_mount+0x12/0x39
[ 246.937492] pid_ns_prepare_proc+0x9d/0xc5
[ 246.942085] alloc_pid+0x275/0x289
[ 246.945900] copy_process+0x5e5/0xeea
[ 246.950006] _do_fork+0x95/0x303
[ 246.953628] __se_sys_clone+0x65/0x7f
[ 246.957735] do_syscall_64+0x54/0x7e
[ 246.961743] entry_SYSCALL_64_after_hwframe+0x44/0xa9
And finally the smoking gun in:
[ 247.383338] CPU: 3 PID: 88 Comm: kswapd0 Tainted: G U
5.4.154 #36
[ 247.383338] Hardware name: Google Delbin/Delbin, BIOS
Google_Delbin.13672.57.0 02/09/2021
[ 247.383339] RIP: 0010:__rcu_read_lock+0x0/0x1a
[ 247.383339] Code: ff ff 0f 0b e9 61 fe ff ff 0f 0b e9 76 fe ff ff 0f 0b 49
8b 44 24 20 e9 59 ff ff ff 0f 0b e9 67 ff ff ff 0f 0b e9 1b ff ff ff <0f> 1f 44
00 00 55 48 89 e5 65 48 8b 04 25 80 5d 01 00 ff 80 f8 03
[ 247.383340] RSP: 0018:b0aa0031b978 EFLAGS: 0286
[ 247.383340] RAX: RBX: f6b944ca8040 RCX:
f6b944ca8001
[ 247.383341] RDX: 0028 RSI: 0001 RDI:
8b52bc618c18
[ 247.383341] RBP: b0aa0031b9d0 R08: R09:
8b52fb5f00d8
[ 247.383341] R10: R11: R12:
[ 247.383342] R13: 61c8864680b583eb R14: 0001 R15:
b0aa0031b980
[ 247.383342] FS: () GS:8b52fbf8()
knlGS:
[ 247.383343] CS: 0010 DS: ES: CR0: 80050033
[ 247.383343] CR2: 7c78a400d680 CR3: 000120f46006 CR4:
00762ee0
[ 247.383344] PKRU: 5554
[ 247.383344] Call Trace:
[ 247.383345] find_get_entry+0x4c/0x116
[ 247.383345] find_lock_entry+0xc8/0xec
[ 247.383346] shmem_writeback+0x7b/0x163
[ 247.383346] i915_gem_shrink+0x302/0x40b
[ 247.383347] ? __intel_runtime_pm_get+0x22/0x82
[ 247.383347] i915_gem_shrinker_scan+0x86/0xa8
[ 247.383348] shrink_slab+0x272/0x48b
[ 247.383348] shrink_node+0x784/0xbea
[ 247.383348] ? rcu_read_unlock_special+0x66/0x15f
[ 247.383349] ? update_batch_size+0x78/0x78
[ 247.383349] kswapd+0x75c/0xa56
[ 247.383350] kthread+0x147/0x156
[ 247.383350] ? kswapd_run+0xb6/0xb6
[ 247.383351] ? kthread_blkcg+0x2e/0x2e
[ 247.383351] ret_from_fork+0x1f/0x40
You will notice the trace is from an older kernel, the problem being
reproducing the issue on latest upstream base is proving to be tricky due
other (unrelated) issues.
It is even tricky to repro on an older kernel, with it seemingly needing a
very specific game, transparent huge pages enabled and a specific memory
configuration.
However given the history on the topic I could find, assuming what I found
is not incomplete, suspicion on writeback being not the right thing to do
in general is still there. I would therefore like to have input from the
experts here.
Signed-off-by: Tvrtko Ursulin
Fixes: 2
[PATCH v6 0/6] drm: sun4i: dsi: Bridge support
This series add bridge support for Allwinner DSI controller. In addition to previous version, this series add bridge support only not doing any bridge conversion at the moment. Previous version changes [1]. Patch 1: Drop the DRM bind race while attaching bridges Patch 2: Move component_add into sun6i_dsi_attach Patch 3: Add Bridge driver Patch 4: Add mode_set API Patch 5: Enable DSI Panel Patch 6: Enable DSI Bridge Patch 7: Enable DSI Bridge (I2C) [1] https://patchwork.kernel.org/project/dri-devel/cover/20211122065223.88059-1-ja...@amarulasolutions.com/ Any inputs? Jagan. Jagan Teki (6): drm: sun4i: dsi: Drop DRM bind race with bridge attach drm: sun4i: dsi: Add component only once DSI device attached drm: sun4i: dsi: Add bridge support [DO NOT MERGE] ARM: dts: sun8i: bananapi-m2m: Enable iS070WV20-CT16 DSI Panel [DO NOT MERGE] ARM: dts: sun8i: bananapi-m2m: Enable ICN6211 DSI Bridge [DO NOT MERGE] ARM: dts: sun8i: bananapi-m2m: Enable DLPC3433 Bridge (I2C) .../boot/dts/sun8i-r16-bananapi-m2m-i2c.dts | 69 +++ .../boot/dts/sun8i-r16-bananapi-m2m-panel.dts | 41 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 64 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 187 -- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h| 10 +- 5 files changed, 256 insertions(+), 115 deletions(-) -- 2.25.1
[PATCH v6 1/6] drm: sun4i: dsi: Drop DRM bind race with bridge attach
Existing host driver will keep looking for DRM pointer in
sun6i_dsi_attach and defers even if the particular DSI device
is found for the first time. Meanwhile it triggers the bind
callback and gets the DRM pointer and then continues the
sun6i_dsi_attach.
This makes a deadlock situation if sun6i_dsi_attach is trying
to find the bridge.
If interface bridge is trying to call host attach, then host
sun6i_dsi_attach is trying to find bridge and defers the
interface bridge even if it found the bridge as bind callback
does not complete at the movement. So, this sun6i_dsi_attach
defers interface bridge and triggers the bind callback and
tries to attach the bridge with a bridge pointer which is not
available at the moment.
Eventually these callbacks are triggered recursively, as
sun6i_dsi_attach defers interface bridge and bind callback
defers sun6i_dsi_attach due to invalid bridge ponter.
This patch prevents this situation by probing all DSI devices
on the pipeline first and then triggers the bind callback by
dropping exing DRM binding logic.
Signed-off-by: Jagan Teki
---
Changes for v6:
- none
Changes for v5:
- new patch
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +-
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 527c7b2474da..4bdcce8f1d84 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -967,14 +967,10 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
if (IS_ERR(panel))
return PTR_ERR(panel);
- if (!dsi->drm || !dsi->drm->registered)
- return -EPROBE_DEFER;
dsi->panel = panel;
dsi->device = device;
- drm_kms_helper_hotplug_event(dsi->drm);
-
dev_info(host->dev, "Attached device %s\n", device->name);
return 0;
@@ -988,8 +984,6 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
dsi->panel = NULL;
dsi->device = NULL;
- drm_kms_helper_hotplug_event(dsi->drm);
-
return 0;
}
@@ -1077,8 +1071,6 @@ static int sun6i_dsi_bind(struct device *dev, struct
device *master,
drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
- dsi->drm = drm;
-
return 0;
err_cleanup_connector:
@@ -1091,7 +1083,7 @@ static void sun6i_dsi_unbind(struct device *dev, struct
device *master,
{
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
- dsi->drm = NULL;
+ drm_encoder_cleanup(&dsi->encoder);
}
static const struct component_ops sun6i_dsi_ops = {
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index c863900ae3b4..61e88ea6044d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -29,7 +29,6 @@ struct sun6i_dsi {
struct device *dev;
struct mipi_dsi_device *device;
- struct drm_device *drm;
struct drm_panel*panel;
};
--
2.25.1
[PATCH v6 2/6] drm: sun4i: dsi: Add component only once DSI device attached
Having component_add for running all drm bind callbacks returns
error or unbound due to chain of DSI devices connected across
bridge topology on a display pipeline.
In a typical bridge oriented display pipeline where the host is
connected to the bridge converter and that indeed connected to
a panel.
DRM => SUN6I DSI Host => Chipone ICN6211 => BananaPi Panel
The bridge converter is looking for a panel to probe first and
then attach the host. The host attach is looking for a bridge
converter to probe and preserve bridge pointer, at this movement
the host is trying to bind the all callbacks and one of the bind
callback in the DSI host is trying to find the bridge using the
bridge pointer in sun6i_dsi_attach call.
chipone_probe().start
drm_of_find_panel_or_bridge
mipi_dsi_attach
sun6i_dsi_attach
drm_of_find_panel_or_bridge
chipone_probe().done
sun6i_dsi_probe().start
mipi_dsi_host_register
component_add
sun6i_dsi_probe().done
However, the movement when panel defers the probe, will make the
bridge converter defer the host attach call which eventually found
a NULL bridge pointer during DSI component bind callback.
So, in order to prevent this scenario of binding invalid bridge,
wait for DSI devices on the pipeline to probe first and start the
binding process by moving component_add in host probe to attach call.
chipone_probe().start
drm_of_find_panel_or_bridge
mipi_dsi_attach
sun6i_dsi_attach
drm_of_find_panel_or_bridge
component_add
chipone_probe().done
sun6i_dsi_probe().start
mipi_dsi_host_register
sun6i_dsi_probe().done
Signed-off-by: Jagan Teki
---
Changes for v6:
- none
Changes for v5:
- new patch
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 120 +
1 file changed, 61 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 4bdcce8f1d84..9cf91dcac3f2 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -959,11 +959,63 @@ static int sun6i_dsi_dcs_read(struct sun6i_dsi *dsi,
return 1;
}
+static int sun6i_dsi_bind(struct device *dev, struct device *master,
+void *data)
+{
+ struct drm_device *drm = data;
+ struct sun6i_dsi *dsi = dev_get_drvdata(dev);
+ int ret;
+
+ drm_encoder_helper_add(&dsi->encoder,
+ &sun6i_dsi_enc_helper_funcs);
+ ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
+ if (ret) {
+ dev_err(dsi->dev, "Couldn't initialise the DSI encoder\n");
+ return ret;
+ }
+ dsi->encoder.possible_crtcs = BIT(0);
+
+ drm_connector_helper_add(&dsi->connector,
+&sun6i_dsi_connector_helper_funcs);
+ ret = drm_connector_init(drm, &dsi->connector,
+&sun6i_dsi_connector_funcs,
+DRM_MODE_CONNECTOR_DSI);
+ if (ret) {
+ dev_err(dsi->dev,
+ "Couldn't initialise the DSI connector\n");
+ goto err_cleanup_connector;
+ }
+
+ drm_connector_attach_encoder(&dsi->connector, &dsi->encoder);
+
+ return 0;
+
+err_cleanup_connector:
+ drm_encoder_cleanup(&dsi->encoder);
+ return ret;
+}
+
+static void sun6i_dsi_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct sun6i_dsi *dsi = dev_get_drvdata(dev);
+
+ drm_encoder_cleanup(&dsi->encoder);
+}
+
+static const struct component_ops sun6i_dsi_ops = {
+ .bind = sun6i_dsi_bind,
+ .unbind = sun6i_dsi_unbind,
+};
+
static int sun6i_dsi_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);
+ struct device *dev = dsi->dev;
+ int ret;
if (IS_ERR(panel))
return PTR_ERR(panel);
@@ -973,6 +1025,13 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
dev_info(host->dev, "Attached device %s\n", device->name);
+ ret = component_add(dev, &sun6i_dsi_ops);
+ if (ret) {
+ dev_err(dev, "Couldn't register our component\n");
+ mipi_dsi_host_unregister(&dsi->host);
+ return ret;
+ }
+
return 0;
}
@@ -984,6 +1043,8 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
dsi->panel = NULL;
dsi->device = NULL;
+ component_del(dsi->dev, &sun6i_dsi_ops);
+
return 0;
}
@@ -1041,56 +1102,6 @@ static const struct regmap_config
sun6i_dsi_regmap_config = {
.name = "mipi-dsi",
};
-static int sun6i_dsi_bind(struct device *dev,
[PATCH v6 3/6] drm: sun4i: dsi: Add bridge support
Some display panels would come up with a non-DSI output, those
can have an option to connect the DSI host by means of interface
bridge converter.
This DSI to non-DSI interface bridge converter would require
DSI Host to handle drm bridge functionalities in order to
communicate interface bridge.
This patch adds support for bridge functionalities in Allwinner
DSI controller.
Supporting down-stream bridge makes few changes in the driver.
- It drops drm_connector and related operations as drm_bridge_attach
creates connector during attachment.
- It drop panel pointer and iterate the bridge, so-that it can operate
the normal bridge and panel_bridge in constitutive callbacks.
- It uses devm_drm_of_get_bridge for panel or bridge lookup. It uses
port 0 and endpoint 0 to support I2C-based bridges eventhough the
usual Allwinner DSI OF graph doesn't require this for panel and
non-I2C based downstream bridges.
Signed-off-by: Jagan Teki
---
Changes for v6:
- support donwstream bridge
- drop bridge conversion
- devm_drm_of_get_bridge() require child lookup
https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-ja...@amarulasolutions.com/
Changes for v5:
- add atomic APIs
- find host and device variant DSI devices.
Changes for v4, v3:
- none
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 83 ++
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 9 +--
2 files changed, 33 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 9cf91dcac3f2..f1d612bf1a0b 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
@@ -720,6 +721,7 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
struct mipi_dsi_device *device = dsi->device;
union phy_configure_opts opts = { };
struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
+ struct drm_bridge *iter;
u16 delay;
int err;
@@ -769,8 +771,10 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
phy_configure(dsi->dphy, &opts);
phy_power_on(dsi->dphy);
- if (dsi->panel)
- drm_panel_prepare(dsi->panel);
+ list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
+ if (iter->funcs->pre_enable)
+ iter->funcs->pre_enable(iter);
+ }
/*
* FIXME: This should be moved after the switch to HS mode.
@@ -784,8 +788,10 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
* ordering on the panels I've tested it with, so I guess this
* will do for now, until that IP is better understood.
*/
- if (dsi->panel)
- drm_panel_enable(dsi->panel);
+ list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
+ if (iter->funcs->enable)
+ iter->funcs->enable(iter);
+ }
sun6i_dsi_start(dsi, DSI_START_HSC);
@@ -797,12 +803,16 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder
*encoder)
static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
{
struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
+ struct drm_bridge *iter;
DRM_DEBUG_DRIVER("Disabling DSI output\n");
- if (dsi->panel) {
- drm_panel_disable(dsi->panel);
- drm_panel_unprepare(dsi->panel);
+ list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
+ if (iter->funcs->disable)
+ iter->funcs->disable(iter);
+
+ if (iter->funcs->post_disable)
+ iter->funcs->post_disable(iter);
}
phy_power_off(dsi->dphy);
@@ -813,35 +823,6 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder
*encoder)
regulator_disable(dsi->regulator);
}
-static int sun6i_dsi_get_modes(struct drm_connector *connector)
-{
- struct sun6i_dsi *dsi = connector_to_sun6i_dsi(connector);
-
- return drm_panel_get_modes(dsi->panel, connector);
-}
-
-static const struct drm_connector_helper_funcs
sun6i_dsi_connector_helper_funcs = {
- .get_modes = sun6i_dsi_get_modes,
-};
-
-static enum drm_connector_status
-sun6i_dsi_connector_detect(struct drm_connector *connector, bool force)
-{
- struct sun6i_dsi *dsi = connector_to_sun6i_dsi(connector);
-
- return dsi->panel ? connector_status_connected :
- connector_status_disconnected;
-}
-
-static const struct drm_connector_funcs sun6i_dsi_connector_funcs = {
- .detect = sun6i_dsi_connector_detect,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy= drm_connector_cleanup,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_s
[DO NOT MERGE] [PATCH v6 4/6] ARM: dts: sun8i: bananapi-m2m: Enable iS070WV20-CT16 DSI Panel
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211
DSI/RGB convertor bridge.
Enable support for it.
Signed-off-by: Jagan Teki
---
.../boot/dts/sun8i-r16-bananapi-m2m-panel.dts | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-panel.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-panel.dts
index bf5b5e2f6168..04392358b492 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-panel.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-panel.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -55,12 +56,21 @@ aliases {
i2c2 = &i2c2;
serial0 = &uart0;
serial1 = &uart1;
+ mmc0 = &mmc0;
};
chosen {
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PL4
*/
+ };
+
leds {
compatible = "gpio-leds";
@@ -122,6 +132,27 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "bananapi,s070wv20-ct16-icn6211";
+ reg = <0>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ backlight = <&backlight>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -157,6 +188,12 @@ &ohci0 {
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -269,6 +306,10 @@ &sound {
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.25.1
[DO NOT MERGE] [PATCH v6 5/6] ARM: dts: sun8i: bananapi-m2m: Enable ICN6211 DSI Bridge
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211
DSI/RGB convertor bridge.
Enable bridge along with associated panel.
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 64
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index bf5b5e2f6168..501666dfb5ee 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -55,12 +56,21 @@ aliases {
i2c2 = &i2c2;
serial0 = &uart0;
serial1 = &uart1;
+ mmc0 = &mmc0;
};
chosen {
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PL4
*/
+ };
+
leds {
compatible = "gpio-leds";
@@ -81,6 +91,18 @@ led-2 {
};
};
+ panel {
+ compatible = "bananapi,s070wv20-ct16";
+ enable-gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PB7
*/
+ backlight = <&backlight>;
+
+ port {
+ panel_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_panel>;
+ };
+ };
+ };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -122,6 +144,38 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ bridge@0 {
+ compatible = "chipone,icn6211";
+ reg = <0>;
+ enable-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge_out: port@1 {
+ reg = <1>;
+
+ bridge_out_panel: endpoint {
+ remote-endpoint = <&panel_out_bridge>;
+ };
+ };
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -157,6 +211,12 @@ &ohci0 {
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -269,6 +329,10 @@ &sound {
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.25.1
[DO NOT MERGE] [PATCH v6 6/6] ARM: dts: sun8i: bananapi-m2m: Enable DLPC3433 Bridge (I2C)
R16 board has DLCP3433 DSI bridge for connecting TI DMD Projectors.
Enable support for it.
Note: This is for testing purpose, DLPC3433 not available in BPI-M2M.
Signed-off-by: Jagan Teki
---
.../boot/dts/sun8i-r16-bananapi-m2m-i2c.dts | 69 +++
1 file changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-i2c.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-i2c.dts
index 7713cdaf6211..a96fbfd743f7 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-i2c.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m-i2c.dts
@@ -86,6 +86,16 @@ vol-down {
};
};
+ panel {
+ compatible = "panel-simple";
+
+ port {
+ panel_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_panel>;
+ };
+ };
+ };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -125,6 +135,32 @@ &dai {
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_out_bridge: endpoint {
+ remote-endpoint = <&bridge_out_dsi>;
+ };
+ };
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -132,6 +168,35 @@ &ehci0 {
&i2c1 {
clock-frequency = <10>;
status = "okay";
+
+ bridge@1d {
+ compatible = "ti,dlpc3433";
+ reg = <0x1d>;
+ enable-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>;
+ vcc_intf-supply = <®_dldo1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge_in: port@0 {
+ reg = <0>;
+
+ bridge_out_dsi: endpoint {
+ remote-endpoint = <&dsi_out_bridge>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+
+ bridge_out: port@1 {
+ reg = <1>;
+
+ bridge_out_panel: endpoint {
+ remote-endpoint = <&panel_out_bridge>;
+ };
+ };
+ };
+ };
};
&i2c2 {
@@ -289,6 +354,10 @@ &sound {
"Right DAC", "AIF1 Slot 0 Right";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.25.1
Re: [PATCH 02/10] drm: Add privacy-screen class (v4)
On 10.12.21 11:46, Hans de Goede wrote: > On 12/10/21 11:12, Thorsten Leemhuis wrote: >> Hi, this is your Linux kernel regression tracker speaking. >> >> Top-posting for once, to make this easy accessible to everyone. >> >> Hans, I stumbled upon your blog post about something that afaics is >> related to below patch: >> https://hansdegoede.livejournal.com/25948.html >> >> To quote: >> >>> To avoid any regressions distors should modify their initrd >>> generation tools to include privacy screen provider drivers in the >>> initrd (at least on systems with a privacy screen), before 5.17 >>> kernels start showing up in their repos. >>> >>> If this change is not made, then users using a graphical bootsplash >>> (plymouth) will get an extra boot-delay of up to 8 seconds >>> (DeviceTimeout in plymouthd.defaults) before plymouth will show and >>> when using disk-encryption where the LUKS password is requested from >>> the initrd, the system will fallback to text-mode after these 8 >>> seconds. >> >> Sorry for intruding, but to me as the kernel's regression tracker that >> blog post sounds a whole lot like "by kernel development standards this >> is not allowed due to the 'no regression rule', as users should never be >> required to update something in userspace when updating the kernel". > > I completely understand where you are coming from here, but AFAIK > the initrd generation has always been a bit of an exception here. Many thx for the clarification. Yeah, kinda, but it afaics also partly depends on what kind of breakage users have to endure -- which according to the description is not that bad in this case, so I guess in this case everything is fine as it is. Again, thx for your answer. Ciao, Thorsten > For example (IIRC) over time we have seen the radeon module growing > a runtime dependency on the amdkfd module which also required updated > initrd generation tools. > > Another example (which I'm sure of) is the i915 driver gaining a softdep > on kvmgt (which is now gone again) which required new enough kmod tools > to understand this as well as initrd generation tools updates to also > take softdeps into account: > https://github.com/dracutdevs/dracut/commit/4cdee66c8ed5f82bbd0638e30d867318343b0e6c > > More in general if you look at e.g. dracut's git history, there are > various other cases where dracut needed to be updated to adjust > to kernel changes. For example dracut decides if a module is a block > driver and thus may be necessary to have in the initrd based on a > list of kernel-symbols the module links to and sometimes those > symbols change due to refactoring of kernel internals, see e.g. : > https://github.com/dracutdevs/dracut/commit/b292ce7295f18192124e64e5ec31161d09492160 > > TL;DR: initrd-generators and the kernel are simply tied together so much > that users cannot expect to be able to jump to the latest kernel without > either updating the initrd-generator, or adding some modules as modules > which must always be added to the initrd in the initrd-generator config > file (as a workaround). > > Declaring kernel changes which break initrd-generation in some way as > being regressions, would mean that e.g. we cannot introduce any > kernel changes which causes some drm/block/whatever drivers to use > some new register helper functions which are not yet on the list of > symbols which dracut uses to identify drm/block/whatever drivers. > > The only difference between previous initrd-generator breaking changes > and this one, is that I decided that it would be good for everyone > to be aware of this before hand; and now I get the feeling that I'm > being punished for warning people about this instead of just letting > things break silently. I know you don't intend your email this way in > any way, but still. > > Also AFAIK drivers may also at some point drop support for (much) older > firmware versions requiring installing a recent linux-firmware together > with a new kernel. > > In my reading of the rules the 'users should never be required to update > something in userspace when updating the kernel' rule is about keeping > people's normal programs working, IOW not breaking userspace ABI and that > is not happening here. > >> But I'm not totally sure that's the case here. Could you please clarify >> what happens when a user doesn't update the initramfs. E.g. what happens >> besides the mentioned delay and the text mode (which are bad already, >> but might be a accetable compormise here -- but that's up for Linus to >> decide)? Does everything start to work normally shortly after the kernel >> mounted the rootfs and finally can load the missing module? > > Yes everything will work normally once the rootfs gets mounted and the > missing module gets loaded. > > Regards, > > Hans > > > >> On 05.10.21 22:23, Hans de Goede wrote: >>> On some new laptops the LCD panel has a builtin electronic privacy-screen. >>> We want to export this functionality as a property on the drm connector >>
Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
Hi Jason, Thank you for replying. 2021年12月8日(水) 2:14 Jason Gunthorpe : > > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > > Hi maintainers, > > > > Could you please review this patch series? > > Why is it RFC? > > I'm confused why this is useful? > > This can't do copy from MMIO memory, so it shouldn't be compatible > with things like Gaudi - does something prevent this? I think if an export of the dma-buf supports vmap, CPU is able to access the mmio memory. Is it wrong? If this is wrong, there is no advantages this changes.. > > Jason Regards, Shunsuke
[PATCH] video: ocfb: add const to of_device_id
struct of_device_id should normally be const.
Signed-off-by: Chunyang Zhong
---
drivers/video/fbdev/ocfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
index bfa4ed421148..da7e1457e58f 100644
--- a/drivers/video/fbdev/ocfb.c
+++ b/drivers/video/fbdev/ocfb.c
@@ -387,7 +387,7 @@ static int ocfb_remove(struct platform_device *pdev)
return 0;
}
-static struct of_device_id ocfb_match[] = {
+static const struct of_device_id ocfb_match[] = {
{ .compatible = "opencores,ocfb", },
{},
};
--
2.34.1
[PATCH] drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with external bridge
DRM bridge drivers are now attaching their DSI device at probe time,
which requires us to register our DSI host in order to let the bridge
to probe: this recently started producing an endless -EPROBE_DEFER
loop on some machines that are using external bridges, like the
parade-ps8640, found on the ACER Chromebook R13.
Now that the DSI hosts/devices probe sequence is documented, we can
do adjustments to the mtk_dsi driver as to both fix now and make sure
to avoid this situation in the future: for this, following what is
documented in drm_bridge.c, move the mtk_dsi component_add() to the
mtk_dsi_ops.attach callback and delete it in the detach callback;
keeping in mind that we are registering a drm_bridge for our DSI,
which is only used/attached if the DSI Host is bound, it wouldn't
make sense to keep adding our bridge at probe time (as it would
be useless to have it if mtk_dsi_ops.attach() fails!), so also move
that one to the dsi host attach function (and remove it in detach).
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 167 +++--
1 file changed, 84 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb0019..2ff347da35c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -786,18 +786,101 @@ void mtk_dsi_ddp_stop(struct device *dev)
mtk_dsi_poweroff(dsi);
}
+static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
+{
+ int ret;
+
+ ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
+ if (ret) {
+ DRM_ERROR("Failed to encoder init to drm\n");
+ return ret;
+ }
+
+ dsi->encoder.possible_crtcs = mtk_drm_find_possible_crtc_by_comp(drm,
dsi->host.dev);
+
+ ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+ if (ret)
+ goto err_cleanup_encoder;
+
+ dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
+ if (IS_ERR(dsi->connector)) {
+ DRM_ERROR("Unable to create bridge connector\n");
+ ret = PTR_ERR(dsi->connector);
+ goto err_cleanup_encoder;
+ }
+ drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+
+ return 0;
+
+err_cleanup_encoder:
+ drm_encoder_cleanup(&dsi->encoder);
+ return ret;
+}
+
+static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
+{
+ int ret;
+ struct drm_device *drm = data;
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+
+ ret = mtk_dsi_encoder_init(drm, dsi);
+ if (ret)
+ return ret;
+
+ return device_reset_optional(dev);
+}
+
+static void mtk_dsi_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct mtk_dsi *dsi = dev_get_drvdata(dev);
+
+ drm_encoder_cleanup(&dsi->encoder);
+}
+
+static const struct component_ops mtk_dsi_component_ops = {
+ .bind = mtk_dsi_bind,
+ .unbind = mtk_dsi_unbind,
+};
+
static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct mtk_dsi *dsi = host_to_dsi(host);
+ struct device *dev = host->dev;
+ int ret;
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
+ if (IS_ERR(dsi->next_bridge))
+ return PTR_ERR(dsi->next_bridge);
+
+ drm_bridge_add(&dsi->bridge);
+
+ ret = component_add(host->dev, &mtk_dsi_component_ops);
+ if (ret) {
+ DRM_ERROR("failed to add dsi_host component: %d\n", ret);
+ drm_bridge_remove(&dsi->bridge);
+ return ret;
+ }
return 0;
}
+static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
+ struct mipi_dsi_device *device)
+{
+ struct mtk_dsi *dsi = host_to_dsi(host);
+
+ drm_bridge_remove(&dsi->bridge);
+ component_del(host->dev, &mtk_dsi_component_ops);
+ return 0;
+}
+
static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
{
int ret;
@@ -938,73 +1021,14 @@ static ssize_t mtk_dsi_host_transfer(struct
mipi_dsi_host *host,
static const struct mipi_dsi_host_ops mtk_dsi_ops = {
.attach = mtk_dsi_host_attach,
+ .detach = mtk_dsi_host_detach,
.transfer = mtk_dsi_host_transfer,
};
-static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
-{
- int ret;
-
- ret = drm_simple_encoder_init(drm, &dsi->encoder,
- DRM_MODE_ENCODER_DSI);
- if (ret) {
- DRM_ERROR("Failed to encode
Re: [PATCH v8 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
On 07-12-2021 15:27, Kevin Tang wrote:
> Adds dsi host controller support for the Unisoc's display subsystem.
> Adds dsi phy support for the Unisoc's display subsystem.
> Only MIPI DSI Displays supported, DP/TV/HMDI will be support
> in the feature.
>
> v1:
> - Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
>
> v2:
> - Use drm_xxx to replace all DRM_XXX.
> - Use kzalloc to replace devm_kzalloc for sprd_dsi structure init.
>
> v4:
> - Use drmm_helpers to allocate encoder.
> - Move allocate encoder and connector to bind function.
>
> v5:
> - Drop the dsi ip file prefix.
> - Fix the checkpatch warnings.
> - Add Signed-off-by for dsi&dphy patch.
> - Use the mode_flags of mipi_dsi_device to setup crtc DPI and EDPI mode.
>
> v6:
> - Redesign the way to access the dsi register.
> - Reduce the dsi_context member variables.
>
> v7:
> - Fix codeing style issue by checkpatch.
> - Drop the pll registers structure define.
> - Use bridge API instead of drm panel API.
> - Register mipi_dsi_host on probe phase;
> - Remove some unused function.
>
> v8:
> - Fix missing signed-off-by.
> - Move component_add to dsi_host.attach callback.
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> ---
> drivers/gpu/drm/sprd/Kconfig |1 +
> drivers/gpu/drm/sprd/Makefile|8 +-
> drivers/gpu/drm/sprd/megacores_pll.c | 305
> drivers/gpu/drm/sprd/sprd_dpu.c | 13 +
> drivers/gpu/drm/sprd/sprd_drm.c |1 +
> drivers/gpu/drm/sprd/sprd_drm.h |1 +
> drivers/gpu/drm/sprd/sprd_dsi.c | 1073 ++
> drivers/gpu/drm/sprd/sprd_dsi.h | 126 +++
> 8 files changed, 1526 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
> create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
> create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
>
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> index 37762c333..3edeaeca0 100644
> --- a/drivers/gpu/drm/sprd/Kconfig
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -5,6 +5,7 @@ config DRM_SPRD
> select DRM_GEM_CMA_HELPER
> select DRM_KMS_CMA_HELPER
> select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
> help
> Choose this option if you have a Unisoc chipset.
> diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> index ab12b95e6..e82e6a6f8 100644
> --- a/drivers/gpu/drm/sprd/Makefile
> +++ b/drivers/gpu/drm/sprd/Makefile
> @@ -1,4 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -obj-y := sprd_drm.o \
> - sprd_dpu.o
> +sprd-drm-y := sprd_drm.o \
> + sprd_dpu.o \
> + sprd_dsi.o \
> + megacores_pll.o
> +
> +obj-$(CONFIG_DRM_SPRD) += sprd-drm.o
> \ No newline at end of file
> diff --git a/drivers/gpu/drm/sprd/megacores_pll.c
> b/drivers/gpu/drm/sprd/megacores_pll.c
> new file mode 100644
> index 0..3091dfdc1
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/megacores_pll.c
> @@ -0,0 +1,305 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Unisoc Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sprd_dsi.h"
> +
> +#define L0
> +#define H1
> +#define CLK 0
> +#define DATA 1
> +#define INFINITY 0x
> +#define MIN_OUTPUT_FREQ (100)
> +
> +#define AVERAGE(a, b) (min(a, b) + abs((b) - (a)) / 2)
> +
> +/* sharkle */
> +#define VCO_BAND_LOW 750
> +#define VCO_BAND_MID 1100
> +#define VCO_BAND_HIGH1500
> +#define PHY_REF_CLK 26000
> +
> +static int dphy_calc_pll_param(struct dphy_pll *pll)
> +{
> + const u32 khz = 1000;
> + const u32 mhz = 100;
> + const unsigned long long factor = 100;
> + unsigned long long tmp;
> + int i;
> +
> + pll->potential_fvco = pll->freq / khz;
> + pll->ref_clk = PHY_REF_CLK / khz;
> +
> + for (i = 0; i < 4; ++i) {
> + if (pll->potential_fvco >= VCO_BAND_LOW &&
> + pll->potential_fvco <= VCO_BAND_HIGH) {
> + pll->fvco = pll->potential_fvco;
> + pll->out_sel = BIT(i);
> + break;
> + }
> + pll->potential_fvco <<= 1;
> + }
> + if (pll->fvco == 0)
> + return -EINVAL;
> +
> + if (pll->fvco >= VCO_BAND_LOW && pll->fvco <= VCO_BAND_MID) {
> + /* vco band control */
> + pll->vco_band = 0x0;
> + /* low pass filter control */
> + pll->lpf_sel = 1;
> + } else if (pll->fvco > VCO_BAND_MID && pll->fvco <= VCO_BAND_HIGH) {
> + pll->vco_band = 0x1;
> + pll->lpf_sel = 0;
> + } else {
> + return -EINVAL;
> + }
> +
> + pl
Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: > Hi Jason, > Thank you for replying. > > 2021年12月8日(水) 2:14 Jason Gunthorpe : > > > > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > > > Hi maintainers, > > > > > > Could you please review this patch series? > > > > Why is it RFC? > > > > I'm confused why this is useful? > > > > This can't do copy from MMIO memory, so it shouldn't be compatible > > with things like Gaudi - does something prevent this? > I think if an export of the dma-buf supports vmap, CPU is able to access the > mmio memory. > > Is it wrong? If this is wrong, there is no advantages this changes.. I don't know what the dmabuf folks did, but yes, it is wrong. IOMEM must be touched using only special accessors, some platforms crash if you don't do this. Even x86 will crash if you touch it with something like an XMM optimized memcpy. Christian? If the vmap succeeds what rules must the caller use to access the memory? Jason
Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: Hi Jason, Thank you for replying. 2021年12月8日(水) 2:14 Jason Gunthorpe : On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: Hi maintainers, Could you please review this patch series? Why is it RFC? I'm confused why this is useful? This can't do copy from MMIO memory, so it shouldn't be compatible with things like Gaudi - does something prevent this? I think if an export of the dma-buf supports vmap, CPU is able to access the mmio memory. Is it wrong? If this is wrong, there is no advantages this changes.. I don't know what the dmabuf folks did, but yes, it is wrong. IOMEM must be touched using only special accessors, some platforms crash if you don't do this. Even x86 will crash if you touch it with something like an XMM optimized memcpy. Christian? If the vmap succeeds what rules must the caller use to access the memory? See dma-buf-map.h and especially struct dma_buf_map. MMIO memory is perfectly supported here and actually the most common case. Christian. Jason
Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote: > Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: > > On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: > > > Hi Jason, > > > Thank you for replying. > > > > > > 2021年12月8日(水) 2:14 Jason Gunthorpe : > > > > On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: > > > > > Hi maintainers, > > > > > > > > > > Could you please review this patch series? > > > > Why is it RFC? > > > > > > > > I'm confused why this is useful? > > > > > > > > This can't do copy from MMIO memory, so it shouldn't be compatible > > > > with things like Gaudi - does something prevent this? > > > I think if an export of the dma-buf supports vmap, CPU is able to access > > > the > > > mmio memory. > > > > > > Is it wrong? If this is wrong, there is no advantages this changes.. > > I don't know what the dmabuf folks did, but yes, it is wrong. > > > > IOMEM must be touched using only special accessors, some platforms > > crash if you don't do this. Even x86 will crash if you touch it with > > something like an XMM optimized memcpy. > > > > Christian? If the vmap succeeds what rules must the caller use to > > access the memory? > > See dma-buf-map.h and especially struct dma_buf_map. > > MMIO memory is perfectly supported here and actually the most common case. Okay that looks sane, but this rxe RFC seems to ignore this completely. It stuffs the vaddr directly into a umem which goes to all manner of places in the driver. ?? Jason
Re: [RFC PATCH v4 0/2] RDMA/rxe: Add dma-buf support
Am 10.12.21 um 14:26 schrieb Jason Gunthorpe: On Fri, Dec 10, 2021 at 01:47:37PM +0100, Christian König wrote: Am 10.12.21 um 13:42 schrieb Jason Gunthorpe: On Fri, Dec 10, 2021 at 08:29:24PM +0900, Shunsuke Mie wrote: Hi Jason, Thank you for replying. 2021年12月8日(水) 2:14 Jason Gunthorpe : On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote: Hi maintainers, Could you please review this patch series? Why is it RFC? I'm confused why this is useful? This can't do copy from MMIO memory, so it shouldn't be compatible with things like Gaudi - does something prevent this? I think if an export of the dma-buf supports vmap, CPU is able to access the mmio memory. Is it wrong? If this is wrong, there is no advantages this changes.. I don't know what the dmabuf folks did, but yes, it is wrong. IOMEM must be touched using only special accessors, some platforms crash if you don't do this. Even x86 will crash if you touch it with something like an XMM optimized memcpy. Christian? If the vmap succeeds what rules must the caller use to access the memory? See dma-buf-map.h and especially struct dma_buf_map. MMIO memory is perfectly supported here and actually the most common case. Okay that looks sane, but this rxe RFC seems to ignore this completely. It stuffs the vaddr directly into a umem which goes to all manner of places in the driver. ?? Well, yes that can go boom pretty quickly. Not sure what they want to use this for. Christian. Jason
Re: Habanalabs, Ask for the linux firmware code which loads by coprocesseor
On 09 12月 21 14:23:45, Oded Gabbay wrote: > On Tue, Dec 7, 2021 at 9:19 AM Cai Huoqing wrote: > > > > Hi Oded Gabbay and habanalabs folks. > > > > I'm insterested in this kind of AI acceralator. > > > > After scanning the driver code. > > It seems that there are a linux firmware which is loaded by > > coprocessor(an slave cpu ?). > > shows in the code. > > > > ./goya/goya.c:74:#define GOYA_LINUX_FW_FILE > > "habanalabs/goya/goya-fit.itb" > > ./goya/goya.c:2436: return hl_fw_load_fw_to_device(hdev, > > GOYA_LINUX_FW_FILE, dst, 0, 0); > > ./goya/goya.c:2507: fw_loader->linux_img.image_name = > > GOYA_LINUX_FW_FILE; > > ./gaudi/gaudi.c:63:#define GAUDI_LINUX_FW_FILE > > "habanalabs/gaudi/gaudi-fit.itb" > > ./gaudi/gaudi.c:3945: return hl_fw_load_fw_to_device(hdev, > > GAUDI_LINUX_FW_FILE, dst, 0, 0); > > ./gaudi/gaudi.c:4011: fw_loader->linux_img.image_name = > > GAUDI_LINUX_FW_FILE; > > > > And the host driver(/driver/misc/habanalabs) communicate with the slave > > firmware > > by MMIO or share memory, right? > > > > If that, would you mind provide the source code of linux firmware > > to avoid the confusion from code reading. > Hi Cai, > > You can download the source code from: > https://vault.habana.ai/artifactory/misc/hl-linux.bz2 Thanks, that's what I need, pretty nice code! And I will be glad to see you taking it into the linux mailine soon. Thanks, Cai > > > > > BTW, where can I find the register description datasheet > We don't supply this information. > Thanks, > Oded
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad there are projects to collect/save the data and reuse after a kdump, this is very useful. I'll continue my study on the atombios thing of AMD and QXL, maybe at least we can make it work in qemu, that'd be great (like a small initdriver to reprogram de paravirtual device on kexec boot). Cheers, Guilherme
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On Fri, Dec 10, 2021 at 9:09 AM Guilherme G. Piccoli wrote: > > Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad > there are projects to collect/save the data and reuse after a kdump, > this is very useful. > > I'll continue my study on the atombios thing of AMD and QXL, maybe at > least we can make it work in qemu, that'd be great (like a small > initdriver to reprogram de paravirtual device on kexec boot). Why not just reload the driver after kexec? Alex > > Cheers, > > > Guilherme
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On 10/12/2021 11:16, Alex Deucher wrote:> [...] > Why not just reload the driver after kexec? > > Alex Because the original issue is the kdump case, and we want a very very tiny kernel - also, the crash originally could have been caused by amdgpu itself, so if it's a GPU issue, we don't want to mess with that in kdump. And I confess I tried modprobe amdgpu after a kdump, no success - kdump won't call shutdown handlers, so GPU will be in a "rogue" state... My question was about regular kexec because it's much simpler usually, we can do whatever we want there. My line of thought was: if I make it work in regular kexec with a simple framebuffer, I might be able to get it working on kdump heheh
RE: [PATCH v3 1/3] dt-bindings: gpu: mali-bifrost: Document RZ/G2L support
Hi All,
Gentle ping.
Cheers,
Biju
> Subject: [PATCH v3 1/3] dt-bindings: gpu: mali-bifrost: Document RZ/G2L
> support
>
> The Renesas RZ/G2{L, LC} SoC (a.k.a R9A07G044) has a Bifrost Mali-G31 GPU,
> add a compatible string for it.
>
> Signed-off-by: Biju Das
> Reviewed-by: Lad Prabhakar
> ---
> v2->v3:
> * Moved optional clock-names and reset-names to SoC-specific conditional
> schemas.
> * minimum number of reset for the generic GPU is set to 1.
> * Documented number of clocks, resets, interrupts and interrupt-names in
> RZ/G2L
>SoC-specific conditional schemas.
> v1->v2:
> * Updated minItems for resets as 2
> * Documented optional property reset-names
> * Documented reset-names as required property for RZ/G2L SoC.
> ---
> .../bindings/gpu/arm,mali-bifrost.yaml| 45 ++-
> 1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> index 6f98dd55fb4c..63a08f3f321d 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> @@ -19,6 +19,7 @@ properties:
>- amlogic,meson-g12a-mali
>- mediatek,mt8183-mali
>- realtek,rtd1619-mali
> + - renesas,r9a07g044-mali
>- rockchip,px30-mali
>- rockchip,rk3568-mali
>- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is
> fully discoverable @@ -27,19 +28,26 @@ properties:
> maxItems: 1
>
>interrupts:
> +minItems: 3
> items:
>- description: Job interrupt
>- description: MMU interrupt
>- description: GPU interrupt
> + - description: Event interrupt
>
>interrupt-names:
> +minItems: 3
> items:
>- const: job
>- const: mmu
>- const: gpu
> + - const: event
>
>clocks:
> -maxItems: 1
> +minItems: 1
> +maxItems: 3
> +
> + clock-names: true
>
>mali-supply: true
>
> @@ -52,7 +60,10 @@ properties:
> maxItems: 3
>
>resets:
> -maxItems: 2
> +minItems: 1
> +maxItems: 3
> +
> + reset-names: true
>
>"#cooling-cells":
> const: 2
> @@ -94,6 +105,36 @@ allOf:
> then:
>required:
> - resets
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: renesas,r9a07g044-mali
> +then:
> + properties:
> +interrupts:
> + minItems: 4
> +interrupt-names:
> + minItems: 4
> +clocks:
> + minItems: 3
> +clock-names:
> + items:
> +- const: gpu
> +- const: bus
> +- const: bus_ace
> +resets:
> + minItems: 3
> +reset-names:
> + items:
> +- const: rst
> +- const: axi_rst
> +- const: ace_rst
> + required:
> +- clock-names
> +- power-domains
> +- resets
> +- reset-names
>- if:
>properties:
> compatible:
> --
> 2.17.1
Re: [PATCH] drm/i915: Stop doing writeback from the shrinker
On Fri, 2021-12-10 at 11:05 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This effectively removes writeback which was added in 2d6692e642e7
> ("drm/i915: Start writeback from the shrinker").
>
> Digging through the history it seems we went back and forth on the
> topic
> of whether it would be safe a couple of times. See for instance
> 5537252b6b6d ("drm/i915: Invalidate our pages under memory pressure")
> where Hugh Dickins has advised against it. I do not have enough
> expertise
> in the memory management area so am hoping for expert input here.
>
> Reason for proposing removal is that there are reports from the field
> which indicate a sysetm wide deadlock (of a sort) implicating i915
> doing
> writeback at shrinking time.
>
> Signature is a hung task notifier kicking in and task traces such as:
It would be interesting to see what exactly the find_get_entry is
blocked on. The other two tasks are blocked on the shrinker_rwsem which
is held by i915. If it's indeed a deadlock with either of those two,
then the fix Chris is working on for an unrelated issue we discovered
with shrinking would move out the writeback call from the
shrinker_rwsem and resolve this, but if i915 is in turn deadlocking
with another process and these two are just hanging waiting for the
shrinker_rwsem, we would still have other issues.
Do you by any chance have the list of the locks held by the system at
this point?
/Thomas
>
> [ 247.030274] minijail-init D 0 1773 1770 0x80004082
> [ 247.036419] Call Trace:
> [ 247.039167] __schedule+0x57e/0x10d2
> [ 247.043175] ? __schedule+0x586/0x10d2
> [ 247.047381] ? _raw_spin_unlock+0xe/0x20
> [ 247.051779] ? __queue_work+0x316/0x371
> [ 247.056079] schedule+0x7c/0x9f
> [ 247.059602] rwsem_down_write_slowpath+0x2ae/0x494
> [ 247.064971] unregister_shrinker+0x20/0x65
> [ 247.069562] deactivate_locked_super+0x38/0x88
> [ 247.074538] cleanup_mnt+0xcc/0x10e
> [ 247.078447] task_work_run+0x7d/0xa6
> [ 247.082459] do_exit+0x23d/0x831
> [ 247.086079] ? syscall_trace_enter+0x207/0x20e
> [ 247.091055] do_group_exit+0x8d/0x9d
> [ 247.095062] __x64_sys_exit_group+0x17/0x17
> [ 247.099750] do_syscall_64+0x54/0x7e
> [ 247.103758] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> [ 246.876816] chrome D 0 1791 1785 0x4080
> [ 246.882965] Call Trace:
> [ 246.885713] __schedule+0x57e/0x10d2
> [ 246.889724] ? pcpu_alloc_area+0x25d/0x273
> [ 246.894314] schedule+0x7c/0x9f
> [ 246.897836] rwsem_down_write_slowpath+0x2ae/0x494
> [ 246.903207] register_shrinker_prepared+0x19/0x48
> [ 246.908479] ? test_single_super+0x10/0x10
> [ 246.913071] sget_fc+0x1fc/0x20e
> [ 246.916691] ? kill_litter_super+0x40/0x40
> [ 246.921334] ? proc_apply_options+0x42/0x42
> [ 246.926044] vfs_get_super+0x3a/0xdf
> [ 246.930053] vfs_get_tree+0x2b/0xc3
> [ 246.933965] fc_mount+0x12/0x39
> [ 246.937492] pid_ns_prepare_proc+0x9d/0xc5
> [ 246.942085] alloc_pid+0x275/0x289
> [ 246.945900] copy_process+0x5e5/0xeea
> [ 246.950006] _do_fork+0x95/0x303
> [ 246.953628] __se_sys_clone+0x65/0x7f
> [ 246.957735] do_syscall_64+0x54/0x7e
> [ 246.961743] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> And finally the smoking gun in:
>
> [ 247.383338] CPU: 3 PID: 88 Comm: kswapd0 Tainted: G
> U 5.4.154 #36
> [ 247.383338] Hardware name: Google Delbin/Delbin, BIOS
> Google_Delbin.13672.57.0 02/09/2021
> [ 247.383339] RIP: 0010:__rcu_read_lock+0x0/0x1a
> [ 247.383339] Code: ff ff 0f 0b e9 61 fe ff ff 0f 0b e9 76 fe ff ff
> 0f 0b 49 8b 44 24 20 e9 59 ff ff ff 0f 0b e9 67 ff ff ff 0f 0b e9 1b
> ff ff ff <0f> 1f 44 00 00 55 48 89 e5 65 48 8b 04 25 80 5d 01 00 ff
> 80 f8 03
> [ 247.383340] RSP: 0018:b0aa0031b978 EFLAGS: 0286
> [ 247.383340] RAX: RBX: f6b944ca8040 RCX:
> f6b944ca8001
> [ 247.383341] RDX: 0028 RSI: 0001 RDI:
> 8b52bc618c18
> [ 247.383341] RBP: b0aa0031b9d0 R08: R09:
> 8b52fb5f00d8
> [ 247.383341] R10: R11: R12:
>
> [ 247.383342] R13: 61c8864680b583eb R14: 0001 R15:
> b0aa0031b980
> [ 247.383342] FS: () GS:8b52fbf8()
> knlGS:
> [ 247.383343] CS: 0010 DS: ES: CR0: 80050033
> [ 247.383343] CR2: 7c78a400d680 CR3: 000120f46006 CR4:
> 00762ee0
> [ 247.383344] PKRU: 5554
> [ 247.383344] Call Trace:
> [ 247.383345] find_get_entry+0x4c/0x116
> [ 247.383345] find_lock_entry+0xc8/0xec
> [ 247.383346] shmem_writeback+0x7b/0x163
> [ 247.383346] i915_gem_shrink+0x302/0x40b
> [ 247.383347] ? __intel_runtime_pm_get+0x22/0x82
> [ 247.383347] i915_gem_shrinker_scan+0x86/0xa8
> [ 247.383348] shrink_slab+0x272/0x48b
> [ 247.383348] shrink_node+0x784/0xbea
> [ 247.383348] ? rcu_read_unlock_special+0x66/0
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Am 10.12.21 um 15:25 schrieb Guilherme G. Piccoli: On 10/12/2021 11:16, Alex Deucher wrote:> [...] Why not just reload the driver after kexec? Alex Because the original issue is the kdump case, and we want a very very tiny kernel - also, the crash originally could have been caused by amdgpu itself, so if it's a GPU issue, we don't want to mess with that in kdump. And I confess I tried modprobe amdgpu after a kdump, no success - kdump won't call shutdown handlers, so GPU will be in a "rogue" state... My question was about regular kexec because it's much simpler usually, we can do whatever we want there. My line of thought was: if I make it work in regular kexec with a simple framebuffer, I might be able to get it working on kdump heheh How about issuing a PCIe reset and re-initializing the ASIC with just the VBIOS? That should be pretty straightforward I think. Christian.
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On 10/12/2021 12:13, Christian König wrote: > [...] > How about issuing a PCIe reset and re-initializing the ASIC with just > the VBIOS? > > That should be pretty straightforward I think. > > Christian. Thanks Christian, that'd be perfect! Is it feasible? Per Alex comment, we'd need to run atombios commands to reprogram the timings, display info, etc...like a small driver would do, a full init. Also, what kind of PCIe reset is recommended for this adapter? Like a hot reset, powering-off/re-power, FLR or that MODE2 reset present in amdgpu code? Remembering this is an APU device. Thanks a lot!
Re: [PATCH v7 08/11] drm/i915/pxp: Use to_gt() helper
On Fri, Dec 10, 2021 at 03:07:56AM +0200, Andi Shyti wrote:
> Use to_gt() helper consistently throughout the codebase.
> Pure mechanical s/i915->gt/to_gt(i915). No functional changes.
>
> Signed-off-by: Andi Shyti
Reviewed-by: Matt Roper
> ---
> Hi,
>
> the inline of i915_dev_to_pxp() was accidentally removed in v6.
> Thanks Matt.
>
> Andi
>
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> index 5d169624ad60..195b2323ec00 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> @@ -16,7 +16,9 @@
>
> static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
> {
> - return &kdev_to_i915(i915_kdev)->gt.pxp;
> + struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
> +
> + return &to_gt(i915)->pxp;
> }
>
> static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Am 10.12.21 um 16:24 schrieb Guilherme G. Piccoli: On 10/12/2021 12:13, Christian König wrote: [...] How about issuing a PCIe reset and re-initializing the ASIC with just the VBIOS? That should be pretty straightforward I think. Christian. Thanks Christian, that'd be perfect! Is it feasible? Per Alex comment, we'd need to run atombios commands to reprogram the timings, display info, etc...like a small driver would do, a full init. Also, what kind of PCIe reset is recommended for this adapter? Like a hot reset, powering-off/re-power, FLR or that MODE2 reset present in amdgpu code? Remembering this is an APU device. Well, Alex is the expert on that. APU makes the whole thing pretty tricky since the VBIOS is part of the system BIOS there and I'm not sure you can only re-initialize the GPU without a complete reset. On dGPUs just making sure the ROM is mapped and calling the VESA modeset BIOS functions might already do the trick. Christian. Thanks a lot!
Re: [PATCH] drm/i915: Stop doing writeback from the shrinker
On 10/12/2021 14:46, Thomas Hellström wrote:
On Fri, 2021-12-10 at 11:05 +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
This effectively removes writeback which was added in 2d6692e642e7
("drm/i915: Start writeback from the shrinker").
Digging through the history it seems we went back and forth on the
topic
of whether it would be safe a couple of times. See for instance
5537252b6b6d ("drm/i915: Invalidate our pages under memory pressure")
where Hugh Dickins has advised against it. I do not have enough
expertise
in the memory management area so am hoping for expert input here.
Reason for proposing removal is that there are reports from the field
which indicate a sysetm wide deadlock (of a sort) implicating i915
doing
writeback at shrinking time.
Signature is a hung task notifier kicking in and task traces such as:
It would be interesting to see what exactly the find_get_entry is
blocked on. The other two tasks are blocked on the shrinker_rwsem which
is held by i915. If it's indeed a deadlock with either of those two,
It may indeed be a livelock instead of a deadlock. I have received a
newer trace and it indeed shows kswapd in running state. But no progress
in 120s and dead machine sounded like too suspicious it could happen
with just a gaming workload so I assumed a more serious issue than just
severe memory pressure.
then the fix Chris is working on for an unrelated issue we discovered
with shrinking would move out the writeback call from the
shrinker_rwsem and resolve this, but if i915 is in turn deadlocking
with another process and these two are just hanging waiting for the
shrinker_rwsem, we would still have other issues.
Presumably this would involve an extra worker and tracking on a list or
something?
Otherwise my main hope really was to get a verdict from memory
management experts on pros & cons of doing writeback from the driver in
any flavour.
Do you by any chance have the list of the locks held by the system at
this point?
No, but maybe Renato you could also collect "echo d" and "echo m" to
sysrq-trigger when things go bad?
Regards,
Tvrtko
Re: [PATCH] drm/panel: ilitek-ili9881c: Avoid unbalance prepare/unprepare
Hi Michael
On Fri, 10 Dec 2021 at 09:05, Michael Nazzareno Trimarchi
wrote:
>
> Hi Dave
>
> some questions below
>
> On Thu, Dec 9, 2021 at 7:10 PM Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi Dave
> >
> > On Thu, Dec 9, 2021 at 6:58 PM Dave Stevenson
> > wrote:
> > >
> > > Hi Michael
> > >
> > > On Thu, 9 Dec 2021 at 16:58, Michael Nazzareno Trimarchi
> > > wrote:
> > > >
> > > > Hi all
> > > >
> > > > On Sat, Oct 16, 2021 at 4:58 PM Michael Trimarchi
> > > > wrote:
> > > > >
> > > > > All the panel driver check the fact that their prepare/unprepare
> > > > > call was already called. It's not an ideal solution but fix
> > > > > for now the problem on ili9881c
> > > > >
> > > > > [ 9862.283296] [ cut here ]
> > > > > [ 9862.288490] unbalanced disables for vcc3v3_lcd
> > > > > [ 9862.293555] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2851
> > > > > _regulator_disable+0xd4/0x190
> > > > >
> > > > > from:
> > > > >
> > > > > [ 9862.038619] drm_panel_unprepare+0x2c/0x4c
> > > > > [ 9862.043212] panel_bridge_post_disable+0x18/0x24
> > > > > [ 9862.048390] dw_mipi_dsi_bridge_post_disable+0x3c/0xf0
> > > > > [ 9862.054153] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > > > >
> > > > > and:
> > > > >
> > > > > [ 9862.183103] drm_panel_unprepare+0x2c/0x4c
> > > > > [ 9862.187695] panel_bridge_post_disable+0x18/0x24
> > > > > [ 9862.192872] drm_atomic_bridge_chain_post_disable+0x8c/0xd0
> > > > > [ 9862.199117] disable_outputs+0x120/0x31c
> > >
> > > This is down to the dw-mipi-dsi driver calling the post_disable hook
> > > explicitly at [1], but then also allowing the framework to call it.
> > > The explicit call is down to limitations in the DSI support, so we
> > > can't control the DSI host state to a fine enough degree (an ongoing
> > > discussion [2] [3]). There shouldn't be a need to handle mismatched
> > > calling in individual panel drivers.
> > >
> > > Dave
> > >
> > > [1]
> > > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L894
> > > [2]
> > > https://lists.freedesktop.org/archives/dri-devel/2021-November/332060.html
> > > [3]
> > > https://lists.freedesktop.org/archives/dri-devel/2021-December/334007.html
> >
> > I'm in the second case. I need to enable HS mode after the panel is
> > initialized. Time to time I have timeout
> > on dsi command or I have wrong panel initialization. So I explicit call from
> > the bridge but I understand that is not correct in the design point of view.
> >
> > So this patch can not be queued because it's a known problem that
> > people are discussing
> >
> Author: Michael Trimarchi
> Date: Thu Dec 9 15:45:48 2021 +0100
>
> drm: bridge: samsung-dsim: Enable panel/bridge before exist from standby
>
> We need to exist from standby as last operation to have a proper video
> working. This code implement the same code was before the bridge
> migration
>
> Signed-off-by: Michael Trimarchi
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 654851edbd9b..21265ae80022 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1838,6 +1838,7 @@ static void samsung_dsim_atomic_enable(struct
> drm_bridge *bridge,
>struct drm_bridge_state
> *old_bridge_state)
> {
> struct samsung_dsim *dsi = bridge_to_dsi(bridge);
> + struct drm_atomic_state old_state;
> int ret;
>
> if (dsi->state & DSIM_STATE_ENABLED)
> @@ -1859,6 +1860,9 @@ static void samsung_dsim_atomic_enable(struct
> drm_bridge *bridge,
> }
>
> samsung_dsim_set_display_mode(dsi);
> +
> + drm_atomic_bridge_chain_enable(dsi->out_bridge, &old_state);
Calling this is contrary to the documentation [1]
"Note: the bridge passed should be the one closest to the encoder"
You're passing in a bridge that is half way down the chain, from a
bridge atomic_enable that is already being called by
drm_atomic_bridge_chain_enable
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_bridge.c#L695
> +
> samsung_dsim_set_display_enable(dsi, true);
>
> dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
>
> Right now I'm doing this to enable the change. I must change the panel
> to avoid double enabled
>
> I have some questions:
>
> - the chain is an element (bridge/panel) linked together via some
> connector (I hope I understand) when I enable
> a bridge chain, all the elements should move from some status to
> another. If we mark them already this should
> not avoid that one element can be enabled two times? An element that
> sources two other elements should for instance
> receive the enable from two times before switching on.
I don't claim to be an expert, just that I've been trying to get DSI
working on a number of devices.
The bridge chain is meant to be managed by the framework via
drm_atomic_helper_
Re: [PATCH v7 1/3] drm/dsi: transer dsi hs packet aligned
Hi, Dave & Daniel:
This patch looks good to me, how do you think about it?
Regards,
Chun-Kuang.
Jitao Shi 於 2021年11月4日 週四 上午11:36寫道：
>
> Hi sirs
>
> Pls help to review this change.
>
> Best Regards
> Jitao.
>
> On Tue, 2021-10-05 at 07:53 +0800, Chun-Kuang Hu wrote:
> > Hi, Jitao:
> >
> > Jitao Shi 於 2021年9月16日 週四 上午6:31寫道：
> > >
> > > Some DSI devices reqire the hs packet starting and ending
> > > at same time on all dsi lanes. So use a flag to those devices.
> > >
> >
> > Reviewed-by: Chun-Kuang Hu
> >
> > > Signed-off-by: Jitao Shi
> > > ---
> > > include/drm/drm_mipi_dsi.h | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/include/drm/drm_mipi_dsi.h
> > > b/include/drm/drm_mipi_dsi.h
> > > index af7ba8071eb0..8e8563792682 100644
> > > --- a/include/drm/drm_mipi_dsi.h
> > > +++ b/include/drm/drm_mipi_dsi.h
> > > @@ -177,6 +177,7 @@ struct mipi_dsi_device_info {
> > > * @lp_rate: maximum lane frequency for low power mode in hertz,
> > > this should
> > > * be set to the real limits of the hardware, zero is only
> > > accepted for
> > > * legacy drivers
> > > + * @hs_packet_end_aligned: transfer dsi hs packet ending aligned
> > > */
> > > struct mipi_dsi_device {
> > > struct mipi_dsi_host *host;
> > > @@ -189,6 +190,7 @@ struct mipi_dsi_device {
> > > unsigned long mode_flags;
> > > unsigned long hs_rate;
> > > unsigned long lp_rate;
> > > + bool hs_packet_end_aligned;
> > > };
> > >
> > > #define MIPI_DSI_MODULE_PREFIX "mipi-dsi:"
> > > --
> > > 2.25.1
Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system
On 2021-12-09 8:31 p.m., Alistair Popple wrote:
On Friday, 10 December 2021 3:54:31 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
On 12/9/2021 10:29 AM, Felix Kuehling wrote:
Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
On 12/8/2021 11:30 AM, Felix Kuehling wrote:
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote:
Avoid long term pinning for Coherent device type pages. This could
interfere with their own device memory manager.
If caller tries to get user device coherent pages with PIN_LONGTERM flag
set, those pages will be migrated back to system memory.
Signed-off-by: Alex Sierra
---
mm/gup.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 886d6148d3d0..1572eacf07f4 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1689,17 +1689,37 @@ struct page *get_dump_page(unsigned long addr)
#endif /* CONFIG_ELF_CORE */
#ifdef CONFIG_MIGRATION
+static int migrate_device_page(unsigned long address,
+ struct page *page)
+{
+ struct vm_area_struct *vma = find_vma(current->mm, address);
+ struct vm_fault vmf = {
+ .vma = vma,
+ .address = address & PAGE_MASK,
+ .flags = FAULT_FLAG_USER,
+ .pgoff = linear_page_index(vma, address),
+ .gfp_mask = GFP_KERNEL,
+ .page = page,
+ };
+ if (page->pgmap && page->pgmap->ops->migrate_to_ram)
+ return page->pgmap->ops->migrate_to_ram(&vmf);
How does this synchronise against pgmap being released? As I understand things
at this point we're not holding a reference on either the page or pgmap, so
the page and therefore the pgmap may have been freed.
I think a similar problem exists for device private fault handling as well and
it has been on my list of things to fix for a while. I think the solution is to
call try_get_page(), except it doesn't work with device pages due to the whole
refcount thing. That issue is blocking a fair bit of work now so I've started
looking into it.
At least the page should have been pinned by the __get_user_pages_locked
call in __gup_longterm_locked. That refcount is dropped in
check_and_migrate_movable_pages when it returns 0 or an error.
Never mind. We unpin the pages first. Alex, would the migration work if
we unpinned them afterwards? Also, the normal CPU page fault code path
seems to make sure the page is locked (check in pfn_swap_entry_to_page)
before calling migrate_to_ram.
I don't think that's true. The check in pfn_swap_entry_to_page() is only for
migration entries:
BUG_ON(is_migration_entry(entry) && !PageLocked(p));
As this is coherent memory though why do we have to call into a device driver
to do the migration? Couldn't this all be done in the kernel?
I think you're right. I hadn't thought of that mainly because I'm even
less familiar with the non-device migration code. Alex, can you give
that a try? As long as the driver still gets a page-free callback when
the device page is freed, it should work.
Yes, you should still get the page-free callback when the migration code drops
the last page reference.
ACK.Will do
There is currently not really any support for migrating device pages based on
pfn. What I think is needed is something like migrate_pages(), but that API
won't work for a couple of reasons - main one being that it relies on pages
being LRU pages.
I've been working on a series to implement an equivalent of migrate_pages() for
device-private (and by extension device-coherent) pages. It might also be useful
here so I will try and get it posted as an RFC next week.
If we want to make progress on this patch series in the shorter term, we
could just fail get_user_pages with FOLL_LONGTERM for DEVICE_COHERENT
pages. Then add the migration support when your patch series is ready.
Regards,
Felix
- Alistair
Alex Sierra
Regards,
Felix
No, you can not unpinned after migration. Due to the expected_count VS
page_count condition at migrate_page_move_mapping, during migrate_page call.
Regards,
Alex Sierra
Regards,
Felix
[PATCH 1/2] drm/panel: panel-simple: add bus_format and connector_type to cdtech_s043wq26h_ct7 panel
Add bus_format and connector_type to cdtech_s043wq26h_ct7 panel.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index eb475a3a774b..c8ad713865cb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1215,7 +1215,9 @@ static const struct panel_desc cdtech_s043wq26h_ct7 = {
.width = 95,
.height = 54,
},
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
/* S070PWS19HP-FC21 2017/04/22 */
--
2.25.1
[PATCH 2/2] drm/panel: panel-simple: add bus_format and connector_type to cdtech_s070wv95_ct16 panel
Add bus_format and connector_type to cdtech_s070wv95_ct16 panel.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index c8ad713865cb..dc300ace4d68 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1295,6 +1295,8 @@ static const struct panel_desc cdtech_s070wv95_ct16 = {
.width = 154,
.height = 85,
},
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct display_timing chefree_ch101olhlwh_002_timing = {
--
2.25.1
Re: [PATCH v12, 15/19] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192
On Thu, Dec 02, 2021 at 11:45:40AM +0800, Yunfei Dong wrote: > Adds decoder dt-bindings for mt8192. > > Signed-off-by: Yunfei Dong > --- > .../media/mediatek,vcodec-subdev-decoder.yaml | 266 ++ > 1 file changed, 266 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > > diff --git > a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > new file mode 100644 > index ..67cbcf8b3373 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > @@ -0,0 +1,266 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > + > +%YAML 1.2 > +--- > +$id: > "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#"; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > + > +title: Mediatek Video Decode Accelerator With Multi Hardware > + > +maintainers: > + - Yunfei Dong > + > +description: | > + Mediatek Video Decode is the video decode hardware present in Mediatek > + SoCs which supports high resolution decoding functionalities. Required > + parent and child device node. > + > + About the Decoder Hardware Block Diagram, please check below: > + > ++-++ > +| || > +| input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | > +||| | || | > ++||---+-||-+ > + lat workqueue | core workqueue > > + > -||-||-- > + || || > > + \/\/ > + +--+ > + |enable/disable| > + | clk powerirqiommu | > + | (lat/lat soc/core0/core1)| > + +--+ > + > + As above, there are parent and child devices, child mean each hardware. > The child device > + controls the information of each hardware independent which include > clk/power/irq. > + > + There are two workqueues in parent device: lat workqueue and core > workqueue. They are used > + to lat and core hardware deocder. Lat workqueue need to get input > bitstream and lat buffer, > + then enable lat to decode, writing the result to lat buffer, dislabe > hardware when lat decode > + done. Core workqueue need to get lat buffer and output buffer, then enable > core to decode, > + writing the result to output buffer, disable hardware when core decode > done. These two > + hardwares will decode each frame cyclically. > + > + For the smi common may not the same for each hardware, can't combine all > hardware in one node, > + or leading to iommu fault when access dram data. > + > +properties: > + compatible: > +const: mediatek,mt8192-vcodec-dec > + > + reg: > +maxItems: 1 > + > + iommus: > +minItems: 1 > +maxItems: 32 > +description: | > + List of the hardware port in respective IOMMU block for current Socs. > + Refer to bindings/iommu/mediatek,iommu.yaml. > + > + mediatek,scp: > +$ref: /schemas/types.yaml#/definitions/phandle > +maxItems: 1 > +description: | > + The node of system control processor (SCP), using > + the remoteproc & rpmsg framework. > + $ref: /schemas/remoteproc/mtk,scp.yaml '$ref' is not valid here. Just 'See remoteproc/mtk,scp.yaml' > + > + dma-ranges: > +maxItems: 1 > +description: | > + Describes the physical address space of IOMMU maps to memory. > + > + "#address-cells": > +const: 1 > + > + "#size-cells": > +const: 1 > + > + ranges: true > + > +# Required child node: > +patternProperties: > + vcodec-lat: '^vcodec-lat@[0-9a-f]+$': > +type: object > + > +properties: > + compatible: > +const: mediatek,mtk-vcodec-lat > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + iommus: > +minItems: 1 > +maxItems: 32 > +description: | > + List of the hardware port in respective IOMMU block for current > Socs. > + Refer to bindings/iommu/mediatek,iommu.yaml. > + > + clocks: > +maxItems: 5 > + > + clock-names: > +items: > + - const: sel > + - const: soc-vdec > + - const: soc-lat > + - const: vdec > + - const: top > + > + assigned-clocks: > +maxItem
Re: [PATCH v11 3/8] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
On Thu, Dec 02, 2021 at 07:39:48PM +0100, H. Nikolaus Schaller wrote:
> From: Sam Ravnborg
>
> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
> Based on .txt binding from Zubair Lutfullah Kakakhel
>
> We also add generic ddc-i2c-bus to synopsys,dw-hdmi.yaml
>
> Signed-off-by: Sam Ravnborg
> Signed-off-by: H. Nikolaus Schaller
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> ---
> .../display/bridge/ingenic,jz4780-hdmi.yaml | 78 +++
> .../display/bridge/synopsys,dw-hdmi.yaml | 3 +
> 2 files changed, 81 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
> b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
> new file mode 100644
> index 0..49ae1130efded
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
> @@ -0,0 +1,78 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bindings for Ingenic JZ4780 HDMI Transmitter
> +
> +maintainers:
> + - H. Nikolaus Schaller
> +
> +description: |
> + The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI
> 1.4
> + TX controller IP with accompanying PHY IP.
> +
> +allOf:
> + - $ref: synopsys,dw-hdmi.yaml#
> +
> +properties:
> + compatible:
> +const: ingenic,jz4780-dw-hdmi
> +
> + reg-io-width:
> +const: 4
> +
> + clocks:
> +maxItems: 2
> +
> + hdmi-5v-supply:
> +description: regulator to provide +5V at the connector
Being part of the connector, that belongs in a connector node.
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
You need to define what each 'port' node is.
> +
> +required:
> + - compatible
> + - clocks
> + - clock-names
> + - hdmi-5v-supply
> + - ports
> + - reg-io-width
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +hdmi: hdmi@1018 {
> +compatible = "ingenic,jz4780-dw-hdmi";
> +reg = <0x1018 0x8000>;
> +reg-io-width = <4>;
> +ddc-i2c-bus = <&i2c4>;
> +interrupt-parent = <&intc>;
> +interrupts = <3>;
> +clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>;
> +clock-names = "iahb", "isfr";
> +hdmi-5v-supply = <&hdmi_power>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +hdmi_in: port@0 {
> +reg = <0>;
> +dw_hdmi_in: endpoint {
> +remote-endpoint = <&jz4780_lcd_out>;
> +};
> +};
> +hdmi_out: port@1 {
> +reg = <1>;
> +dw_hdmi_out: endpoint {
> +remote-endpoint = <&hdmi_con>;
> +};
> +};
> +};
> +};
> +
> +...
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> index 9be44a682e67a..9cbeabaee0968 100644
> --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
> @@ -50,6 +50,9 @@ properties:
>interrupts:
> maxItems: 1
>
> + ddc-i2c-bus:
> +description: An I2C interface if the internal DDC I2C driver is not to
> be used
That too is already defined to be part of the connector node.
> +
> additionalProperties: true
>
> ...
> --
> 2.33.0
>
>
Re: [PATCH] drm/dp: Actually read Adjust Request Post Cursor2 register
On Fri, Dec 10, 2021 at 12:06:20PM +0200, Jani Nikula wrote:
> On Thu, 09 Dec 2021, Kees Cook wrote:
> > On Thu, Dec 09, 2021 at 05:20:45PM -0500, Harry Wentland wrote:
> >>
> >>
> >> On 2021-12-09 01:23, Kees Cook wrote:
> >> > On Wed, Dec 08, 2021 at 01:19:28PM +0200, Jani Nikula wrote:
> >> >> On Fri, 03 Dec 2021, Kees Cook wrote:
> >> >>> The link_status array was not large enough to read the Adjust Request
> >> >>> Post Cursor2 register. Adjust the size to include it. Found with a
> >> >>> -Warray-bounds build:
> >> >>>
> >> >>> drivers/gpu/drm/drm_dp_helper.c: In function
> >> >>> 'drm_dp_get_adjust_request_post_cursor':
> >> >>> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is
> >> >>> outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'}
> >> >>> [-Werror=array-bounds]
> >> >>>59 | return link_status[r - DP_LANE0_1_STATUS];
> >> >>> |~~~^~~
> >> >>> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing
> >> >>> 'link_status'
> >> >>> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
> >> >>> link_status[DP_LINK_STATUS_SIZE],
> >> >>> |
> >> >>> ~^~~~
> >> >>>
> >> >>> Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor
> >> >>> adjustments")
> >> >>> Signed-off-by: Kees Cook
> >> >>
> >> >> Using DP_ADJUST_REQUEST_POST_CURSOR2 has been deprecated since DP 1.3
> >> >> published in 2014, and Tegra is the only user of
> >> >> drm_dp_get_adjust_request_post_cursor().
> >> >
> >> > I see POST_CURSOR2 is used here too:
> >> >
> >> > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> >> >
> >>
> >> Looks like we read and parse that in the admgpu driver without
> >> using drm_dp_get_adjust_request_post_cursor.
> >
> > Right, and probably that could be switched to use it, but I'm not sure
> > what the impact of the larger link_status read is.
> >
> >>
> >> I don't have a strong feeling but I liked your original
> >> patch a bit better. I'm not sure what it means when part
> >> of a spec is deprecated. Once a spec is written display
> >> vendors might implement it. We should make sure that
> >> displays like that are always handled in a sane manner.
> >
> > Jani, Dave, any guidance here? I'm fine with whatever, but the current
> > code is for sure broken. ;)
>
> Post Cursor2 was completely optional for the transmitter even before it
> was deprecated.
>
> And now we'd be adding 5 bytes extra to all link status reads. To fix
> the only user of drm_dp_get_adjust_request_post_cursor() that apparently
> has never worked as intended. I'm just not convinced.
>
> I was trying to look through the implications of DP_LINK_STATUS_SIZE
> increase, and at least drm_dp_dpcd_read_phy_link_status() comes across
> as something probably needing attention.
Okay, it sounds like you'd prefer the "make it tegra-specific" patch I
proposed. I will work that up as a proper patch and send it.
Thanks!
--
Kees Cook
Re: [PATCH] drm: i915: display: intel_dmc: Fixes an unsigned subtraction which can never be negative.
On Thu, Dec 09, 2021 at 08:41:24PM -0800, Harshit Mogalapalli wrote:
smatch warning:
drivers/gpu/drm/i915/display/intel_dmc.c:601 parse_dmc_fw() warn:
unsigned 'fw->size - offset' is never less than zero
Firmware size is size_t and offset is u32. So the subtraction is
unsigned which can never be less than zero.
Fixes: 3d5928a168a9 ("drm/i915/xelpd: Pipe A DMC plugging")
Signed-off-by: Harshit Mogalapalli
Reviewed-by: Lucas De Marchi
"s|drm: i915: display: Fixes|drm/i915/display: Fix|" in the subject,
that I will do when applying after we have the CI results.
thanks
Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 0cab18f972d1..2f477c298b00 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -598,7 +598,7 @@ static void parse_dmc_fw(struct drm_i915_private *dev_priv,
continue;
offset = readcount + dmc->dmc_info[id].dmc_offset * 4;
- if (fw->size - offset < 0) {
+ if (offset > fw->size) {
drm_err(&dev_priv->drm, "Reading beyond the fw_size\n");
continue;
}
--
2.27.0
[PATCH 00/17] MediaTek MT8192 APU
The MediaTek AI Processing Unit (APU) is a proprietary hardware in the SoC to support AI functions. The patches support the MT8192 APU runs on internal microprocessor. Software packages contins mailbox, iommu, APU remote processor, power control, middleware and debug looger. This series is based on drivers implemented in MT8192 apu power domain[1], apu SMC[2] and IOMMU[2] patches. [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=593809 [2] https://patchwork.kernel.org/patch/12670253 [3] https://patchwork.kernel.org/project/linux-mediatek/list/?series=551641 The device tree depends on [4][5][6] which haven't yet been accepted. [4] https://patchwork.kernel.org/patch/12456165 [5] https://patchwork.kernel.org/patch/12134935 [6] https://patchwork.kernel.org/patch/12140237 Change notes: Initial RFC: https://patchwork.kernel.org/project/linux-mediatek/list/?series=568939 Flora Fu (17): dt-bindings: mailbox: mediatek: Add APU mailbox compatible dt-bindings: memory: mediatek: Add MT8192 apu iommu bindings dt-bindings: remoteproc: mediatek: Add APU rproc compatible dt-bindings: soc: mediatek: apu: Add APU power compatible dt-bindings: soc: mediatek: apu: Add apu logger compatible mailbox: mediatek: add mtk-apu-mailbox driver iommu/mediatek: Support APU iommu and config data for mt8192 remoteproc: mediatek: Add APU remoteproc driver soc: mediatek: apu: Add Apu power driver soc: mediatek: apu: Add APU software logger dirver soc: mediatek: apu: Add middleware driver arm64: dts: mt8192: Add APU mtk-apu-mailbox node arm64: dts: mt8192: Add APU-IOMMU nodes arm64: dts: mt8192: Add apu tinysys node arm64: dts: mt8192: Add APU power nodes arm64: dts: mt8192: Add apu-sw-logger node arm64: dts: mt8192: Set up regulators for APU subsys .../bindings/iommu/mediatek,iommu.yaml|7 +- .../mailbox/mediatek,apu-mailbox.yaml | 47 + .../bindings/remoteproc/mediatek,apu-rv.yaml | 106 ++ .../soc/mediatek/mediatek,apu-logger.yaml | 42 + .../soc/mediatek/mediatek,apu-pwr.yaml| 80 ++ arch/arm64/boot/dts/mediatek/mt8192-evb.dts |5 + arch/arm64/boot/dts/mediatek/mt8192.dtsi | 118 ++ drivers/iommu/mtk_iommu.c | 45 +- drivers/mailbox/Kconfig |9 + drivers/mailbox/Makefile |2 + drivers/mailbox/mtk-apu-mailbox.c | 162 +++ drivers/remoteproc/Kconfig| 12 + drivers/remoteproc/Makefile |2 + drivers/remoteproc/mtk-apu-ipi.c | 474 drivers/remoteproc/mtk-apu-rproc.c| 1054 + drivers/soc/mediatek/apusys/Kconfig | 23 + drivers/soc/mediatek/apusys/Makefile | 17 + drivers/soc/mediatek/apusys/apu-device.h | 39 + drivers/soc/mediatek/apusys/apu-pwr-dbg.c | 167 +++ drivers/soc/mediatek/apusys/apu-pwr-ipi.c | 377 ++ drivers/soc/mediatek/apusys/apu-pwr.c | 613 ++ drivers/soc/mediatek/apusys/apu-pwr.h | 260 drivers/soc/mediatek/apusys/apu-sw-logger.c | 540 + drivers/soc/mediatek/apusys/mdw-cmd.c | 618 ++ drivers/soc/mediatek/apusys/mdw-drv.c | 226 drivers/soc/mediatek/apusys/mdw-ioctl.c | 331 ++ drivers/soc/mediatek/apusys/mdw-ioctl.h | 256 drivers/soc/mediatek/apusys/mdw-mem.c | 938 +++ drivers/soc/mediatek/apusys/mdw-mem.h | 23 + drivers/soc/mediatek/apusys/mdw-rv-cmd.c | 158 +++ drivers/soc/mediatek/apusys/mdw-rv-dev.c | 386 ++ drivers/soc/mediatek/apusys/mdw-rv-msg.h | 90 ++ drivers/soc/mediatek/apusys/mdw-rv.c | 131 ++ drivers/soc/mediatek/apusys/mdw-rv.h | 98 ++ drivers/soc/mediatek/apusys/mdw-sysfs.c | 200 drivers/soc/mediatek/apusys/mdw.h | 207 include/dt-bindings/memory/mt8192-larb-port.h |4 + include/linux/remoteproc/mtk-apu-config.h | 100 ++ include/linux/remoteproc/mtk-apu.h| 217 39 files changed, 8181 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/mediatek,apu-mailbox.yaml create mode 100644 Documentation/devicetree/bindings/remoteproc/mediatek,apu-rv.yaml create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-logger.yaml create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pwr.yaml create mode 100644 drivers/mailbox/mtk-apu-mailbox.c create mode 100644 drivers/remoteproc/mtk-apu-ipi.c create mode 100644 drivers/remoteproc/mtk-apu-rproc.c create mode 100644 drivers/soc/mediatek/apusys/apu-device.h create mode 100644 drivers/soc/mediatek/apusys/apu-pwr-dbg.c create mode 100644 drivers/soc/mediatek/apusys/apu-pwr-ipi.c create mode 100644 drivers/soc/mediatek/apusys/apu-pwr.c create mode 100644 drivers/soc/mediatek/apusys/apu-pwr.h create mode 100644 drive
[PATCH 01/17] dt-bindings: mailbox: mediatek: Add APU mailbox compatible
Add the mailbox compatible for the MediaTek APU.
The MT8192 and MT8195 SOC will use it.
Signed-off-by: Pi-Cheng Chen
Signed-off-by: Flora Fu
---
.../mailbox/mediatek,apu-mailbox.yaml | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/mediatek,apu-mailbox.yaml
diff --git
a/Documentation/devicetree/bindings/mailbox/mediatek,apu-mailbox.yaml
b/Documentation/devicetree/bindings/mailbox/mediatek,apu-mailbox.yaml
new file mode 100644
index ..ffd0e1623955
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,apu-mailbox.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2021 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/mediatek,apu-mailbox.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek AI Processing Unit mailbox controller bindings
+
+description:
+ The APU mailbox controller provides access from the
+ application processor to the MediaTek AI Processing Unit.
+
+maintainers:
+ - Pi-Cheng Chen
+
+properties:
+ compatible:
+enum:
+ - mediatek,mtk-apu-mailbox
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ "#mbox-cells":
+const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+apu_mailbox: apu_mailbox@1900 {
+ compatible = "mediatek,mtk-apu-mailbox";
+ reg = <0x1900 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+};
--
2.18.0
[PATCH 02/17] dt-bindings: memory: mediatek: Add MT8192 apu iommu bindings
MT8192 has one APU iommu hardware and add apu iommu bindings. Signed-off-by: Flora Fu --- .../devicetree/bindings/iommu/mediatek,iommu.yaml | 7 +-- include/dt-bindings/memory/mt8192-larb-port.h | 4 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index c528a299afa9..14fae9642ec9 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -77,6 +77,7 @@ properties: - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two - mediatek,mt8192-m4u # generation two + - mediatek,mt8192-iommu-apu# generation two - mediatek,mt8195-iommu-vdo# generation two - mediatek,mt8195-iommu-vpp# generation two - mediatek,mt8195-iommu-infra # generation two @@ -154,6 +155,7 @@ allOf: compatible: enum: - mediatek,mt8192-m4u +- mediatek,mt8192-iommu-apu - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp @@ -165,8 +167,9 @@ allOf: not: properties: compatible: -contains: - const: mediatek,mt8195-iommu-infra +enum: + - mediatek,mt8192-iommu-apu + - mediatek,mt8195-iommu-infra then: required: diff --git a/include/dt-bindings/memory/mt8192-larb-port.h b/include/dt-bindings/memory/mt8192-larb-port.h index 23035a52c675..908d6831bf99 100644 --- a/include/dt-bindings/memory/mt8192-larb-port.h +++ b/include/dt-bindings/memory/mt8192-larb-port.h @@ -240,4 +240,8 @@ #define M4U_PORT_L20_IPE_RSC_RDMA0 MTK_M4U_ID(20, 4) #define M4U_PORT_L20_IPE_RSC_WDMA MTK_M4U_ID(20, 5) +#define IOMMU_PORT_APU_DATAMTK_M4U_ID(0, 0) +#define IOMMU_PORT_APU_VLM MTK_M4U_ID(0, 1) +#define IOMMU_PORT_APU_VPU MTK_M4U_ID(0, 2) + #endif -- 2.18.0
[PATCH 04/17] dt-bindings: soc: mediatek: apu: Add APU power compatible
Add new document for APU power compatible.
Signed-off-by: Flora Fu
---
.../soc/mediatek/mediatek,apu-pwr.yaml| 80 +++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pwr.yaml
diff --git
a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pwr.yaml
b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pwr.yaml
new file mode 100644
index ..00f67dddb162
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pwr.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 (C) MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,apu-pwr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek APU Power driver bindings
+
+description: |
+ MediaTek AI Process Unit (APU) power driver supports for subsys clock and
+ regulator controller.
+
+maintainers:
+ - Flora Fu
+
+properties:
+ compatible:
+items:
+ - enum:
+ - mediatek,mt8192-apu-power
+ reg:
+minItems: 1
+
+ reg-names:
+minItems: 1
+
+ power-domains:
+maxItems: 1
+
+ vvpu-supply:
+description: apu vpu regulator supply.
+
+ vmdla-supply:
+description: apu mdla regulator supply.
+
+ clocks:
+description: Contains module clock source and clock names
+
+ clock-names:
+description: Names of the clocks list in clocks property
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - vvpu-supply
+ - vmdla-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+apusys_power: apusys_power@190f1000 {
+ compatible = "mediatek,mt8192-apu-power";
+ reg = <0x190f1000 0x1000>;
+ reg-names = "apu_pcu";
+ power-domains = <&apuspm 0>;
+ vvpu-supply = <&mt6359_vproc1_buck_reg>;
+ vmdla-supply = <&mt6359_vproc2_buck_reg>;
+ clocks = <&topckgen CLK_TOP_DSP_SEL>,
+ <&topckgen CLK_TOP_DSP1_SEL>,
+ <&topckgen CLK_TOP_DSP1_NPUPLL_SEL>,
+ <&topckgen CLK_TOP_DSP2_SEL>,
+ <&topckgen CLK_TOP_DSP2_NPUPLL_SEL>,
+ <&topckgen CLK_TOP_DSP5_SEL>,
+ <&topckgen CLK_TOP_DSP5_APUPLL_SEL>,
+ <&topckgen CLK_TOP_IPU_IF_SEL>,
+ <&clk26m>;
+ clock-names = "clk_top_dsp_sel",
+"clk_top_dsp1_sel",
+"clk_top_dsp1_npupll_sel",
+"clk_top_dsp2_sel",
+"clk_top_dsp2_npupll_sel",
+"clk_top_dsp5_sel",
+"clk_top_dsp5_apupll_sel",
+"clk_top_ipu_if_sel",
+"clk_top_clk26m";
+};
--
2.18.0
[PATCH 05/17] dt-bindings: soc: mediatek: apu: Add apu logger compatible
Add new document for apu logger compatible.
Signed-off-by: Flora Fu
---
.../soc/mediatek/mediatek,apu-logger.yaml | 42 +++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-logger.yaml
diff --git
a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-logger.yaml
b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-logger.yaml
new file mode 100644
index ..9e56fb3b8080
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-logger.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 (C) MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/mediatek,apu-logger.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: MediaTek APU Logger for debug into microprocessor
+
+description: |
+ The APU logger is for debug usage. The APU remote microprocessor's logs
+ will be output to the mapped memory and application processor can read
+ logs from the dedicated reserved registers.
+
+maintainers:
+ - Flora Fu
+
+properties:
+ compatible:
+items:
+ - enum:
+ - mediatek,apu-sw-logger
+ reg:
+maxItems: 1
+
+ iommus:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+apusys_sw_logger@1940 {
+ compatible = "mediatek,apu-sw-logger";
+ reg = <0x1940 0x10>;
+ iommus = <&iommu_apu IOMMU_PORT_APU_DATA>;
+};
--
2.18.0
[PATCH 03/17] dt-bindings: remoteproc: mediatek: Add APU rproc compatible
Add new binding document for the APU remote processor.
The initial version is used for MT8192 SOC.
Signed-off-by: Pi-Cheng Chen
Signed-off-by: Flora Fu
---
.../bindings/remoteproc/mediatek,apu-rv.yaml | 106 ++
1 file changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/mediatek,apu-rv.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/mediatek,apu-rv.yaml
b/Documentation/devicetree/bindings/remoteproc/mediatek,apu-rv.yaml
new file mode 100644
index ..c390b85040eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mediatek,apu-rv.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 (C) MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/mediatek,apu-rv.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek APU remote processor controller bindings
+
+description: |
+ APU integrated subsystem having MD32RV33 (MD32) that runs tinysys.
+ The tinysys runs on a microprocessor in APU.
+ Its firmware is loaded and booted from Kernel side.
+ Kernel and tinysys uses IPI to send and receive messages.
+
+maintainers:
+ - Flora Fu
+ - Pi-Cheng Chen
+
+properties:
+ compatible:
+items:
+ - enum:
+ - mediatek,mt8192-apusys-rv
+ - const: simple-mfd
+
+ reg:
+minItems: 1
+
+ reg-names:
+minItems: 1
+
+ power-domains:
+maxItems: 1
+
+ iommus:
+maxItems: 1
+
+ interrupts:
+description: List of interrupts.
+
+ interrupt-names:
+description: Name list of interrupts.
+
+ mboxes:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - power-domains
+ - interrupts
+ - mboxes
+
+additionalProperties:
+ type: object
+ description:
+Represent subnodes that will register as rpmsg devices.
+ properties:
+compatible:
+ enum:
+- mediatek,apu-ctrl-rpmsg
+- mediatek,apupwr-tx-rpmsg
+- mediatek,apupwr-rx-rpmsg
+- mediatek,apu-mdw-rpmsg
+mediatek,rpmsg-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ description:
+Contains the name for the rpmsg device. Used to match
+the subnode to rpmsg device announced by APU.
+ required:
+- compatible
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+
+apusys_rv@19001000 {
+ compatible = "mediatek,mt8192-apusys-rv", "simple-mfd";
+ reg = <0x19001000 0x1000>;
+ reg-names = "md32_sysctrl";
+ power-domains = <&apuspm 0>;
+ iommus = <&iommu_apu IOMMU_PORT_APU_DATA>;
+ interrupts = ;
+ interrupt-names = "apu_wdt";
+ mboxes = <&apu_mailbox 0>;
+ apu_ctrl {
+compatible = "mediatek,apu-ctrl-rpmsg";
+mediatek,rpmsg-name = "apu-ctrl-rpmsg";
+ };
+ apu_pwr_tx {
+compatible = "mediatek,apupwr-tx-rpmsg";
+mediatek,rpmsg-name = "apupwr-tx-rpmsg";
+ };
+ apu_pwr_rx {
+compatible = "mediatek,apupwr-rx-rpmsg";
+mediatek,rpmsg-name = "apupwr-rx-rpmsg";
+ };
+ apu_mdw_rpmsg {
+compatible = "mediatek,apu-mdw-rpmsg";
+mediatek,rpmsg-name = "apu-mdw-rpmsg";
+ };
+};
--
2.18.0
[PATCH 06/17] mailbox: mediatek: add mtk-apu-mailbox driver
Add mtk-apu-mailbox driver to support communication with
APU remote microprocessor.
Signed-off-by: Pi-Cheng Chen
Signed-off-by: Flora Fu
---
drivers/mailbox/Kconfig | 9 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/mtk-apu-mailbox.c | 162 ++
3 files changed, 173 insertions(+)
create mode 100644 drivers/mailbox/mtk-apu-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index d9cd3606040e..aeaaadd4cb8d 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -238,6 +238,15 @@ config STM32_IPCC
with hardware for Inter-Processor Communication Controller (IPCC)
between processors. Say Y here if you want to have this support.
+config MTK_APU_MBOX
+ tristate "MediaTek APU Mailbox Support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ help
+ Say yes here to add support for the MediaTek APU Mailbox
+ driver. The mailbox implementation provides access from the
+ application processor to the MediaTek AI Processing Unit.
+ If unsure say N.
+
config MTK_CMDQ_MBOX
tristate "MediaTek CMDQ Mailbox Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 338cc05e5431..e24ad25c3378 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -49,6 +49,8 @@ obj-$(CONFIG_TEGRA_HSP_MBOX) += tegra-hsp.o
obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
+obj-$(CONFIG_MTK_APU_MBOX) += mtk-apu-mailbox.o
+
obj-$(CONFIG_MTK_CMDQ_MBOX)+= mtk-cmdq-mailbox.o
obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o
diff --git a/drivers/mailbox/mtk-apu-mailbox.c
b/drivers/mailbox/mtk-apu-mailbox.c
new file mode 100644
index ..860db0504907
--- /dev/null
+++ b/drivers/mailbox/mtk-apu-mailbox.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INBOX (0x0)
+#define OUTBOX (0x20)
+#define INBOX_IRQ (0xc0)
+#define OUTBOX_IRQ (0xc4)
+#define INBOX_IRQ_MASK (0xd0)
+
+#define MSG_MBOX_SLOTS (4)
+
+struct mtk_apu_mailbox {
+ struct device *dev;
+ void __iomem *regs;
+ spinlock_t lock; /* register access lock */
+ struct mbox_controller controller;
+ u32 msgs[MSG_MBOX_SLOTS];
+};
+
+static irqreturn_t mtk_apu_mailbox_threaded_irq(int irq, void *dev_id)
+{
+ struct mtk_apu_mailbox *mbox = dev_id;
+ struct mbox_chan *link = &mbox->controller.chans[0];
+ int i;
+
+ for (i = 0; i < MSG_MBOX_SLOTS; i++)
+ mbox->msgs[i] = readl(mbox->regs + OUTBOX + i * sizeof(u32));
+
+ mbox_chan_received_data(link, &mbox->msgs);
+ writel(readl(mbox->regs + OUTBOX_IRQ), mbox->regs + OUTBOX_IRQ);
+
+ return IRQ_HANDLED;
+}
+
+static int mtk_apu_mailbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct mtk_apu_mailbox *mbox = container_of(chan->mbox,
+ struct mtk_apu_mailbox,
+ controller);
+ int i;
+
+ spin_lock(&mbox->lock);
+ writel(~BIT(MSG_MBOX_SLOTS - 1), mbox->regs + INBOX_IRQ_MASK);
+ for (i = 0; i < MSG_MBOX_SLOTS; i++)
+ writel(((u32 *)data)[i], mbox->regs + INBOX + i * sizeof(u32));
+ spin_unlock(&mbox->lock);
+
+ return 0;
+}
+
+static bool mtk_apu_mailbox_last_tx_done(struct mbox_chan *chan)
+{
+ struct mtk_apu_mailbox *mbox = container_of(chan->mbox,
+ struct mtk_apu_mailbox,
+ controller);
+
+ return readl(mbox->regs + INBOX_IRQ) == 0;
+}
+
+static const struct mbox_chan_ops mtk_apu_mailbox_ops = {
+ .send_data = mtk_apu_mailbox_send_data,
+ .last_tx_done = mtk_apu_mailbox_last_tx_done,
+};
+
+static int mtk_apu_mailbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct mtk_apu_mailbox *mbox;
+ int ret = 0;
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ mbox->dev = dev;
+ platform_set_drvdata(pdev, mbox);
+ spin_lock_init(&mbox->lock);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ mbox->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mbox->regs))
+ return PTR_ERR(mbox->regs);
+
+ ret = devm_request_threaded_irq(dev,
+ irq_of_parse_and_map(dev->of_node, 0),
+ NULL, mtk_apu_mailbox_threaded_irq,
+ IRQF_ONESHOT, dev_name(dev), mbox);
+ if (ret)
[PATCH 07/17] iommu/mediatek: Support APU iommu and config data for mt8192
APU IOMMU is a new iommu HW. it uses a new pagetable.
Add support for mt8192 apu iommu.
Signed-off-by: Yong Wu
Signed-off-by: Flora Fu
---
drivers/iommu/mtk_iommu.c | 45 ++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8377f3c37283..4bc7c76062e6 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -133,6 +133,7 @@
/* 2 bits: iommu type */
#define MTK_IOMMU_TYPE_MM (0x0 << 13)
#define MTK_IOMMU_TYPE_INFRA (0x1 << 13)
+#define MTK_IOMMU_TYPE_APU (0x2 << 13)
#define MTK_IOMMU_TYPE_MASK(0x3 << 13)
#define IFA_IOMMU_PCIe_SUPPORT BIT(15)
@@ -185,6 +186,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data, unsigned int ban
#define MTK_IOMMU_4GB_MODE_REMAP_BASE 0x14000UL
static LIST_HEAD(m4ulist); /* List all the M4U HWs */
+static LIST_HEAD(apulist); /* List the apu iommu HWs */
#define for_each_m4u(data, head) list_for_each_entry(data, head, list)
@@ -209,6 +211,13 @@ static const struct mtk_iommu_iova_region
mt8192_multi_dom[] = {
#endif
};
+static const struct mtk_iommu_iova_region mt8192_multi_dom_apu[] = {
+ { .iova_base = 0x0, .size = SZ_4G}, /* APU DATA */
+ { .iova_base = 0x400ULL,.size = 0x400}, /* APU VLM */
+ { .iova_base = 0x1000ULL, .size = 0x1000}, /* APU VPU */
+ { .iova_base = 0x7000ULL, .size = 0x1260}, /* APU REG */
+};
+
/* If 2 M4U share a domain(use the same hwlist), Put the corresponding info in
first data.*/
static struct mtk_iommu_data *mtk_iommu_get_frst_data(struct list_head *hwlist)
{
@@ -638,24 +647,45 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
iommu_domain *domain,
static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
{
+ unsigned int flag = DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- struct mtk_iommu_data *data;
+ struct mtk_iommu_data *data, *curdata;
+ struct device_link *link;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return ERR_PTR(-ENODEV); /* Not a iommu client device */
data = dev_iommu_priv_get(dev);
+ if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_APU)) {
+ /*
+* The APU IOMMU HWs must work together. The consumer device
+* must connect with all the apu iommu HWs at the same time.
+*/
+ for_each_m4u(curdata, data->hw_list) {
+ link = device_link_add(dev, curdata->dev, flag);
+ if (!link)
+ dev_err(dev, "Unable to link %s\n",
dev_name(curdata->dev));
+ }
+ }
return &data->iommu;
}
static void mtk_iommu_release_device(struct device *dev)
{
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct mtk_iommu_data *data;
if (!fwspec || fwspec->ops != &mtk_iommu_ops)
return;
+ data = dev_iommu_priv_get(dev);
+ if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_APU)) {
+ struct list_head *head = data->hw_list;
+
+ for_each_m4u(data, head)
+ device_link_remove(dev, data->dev);
+ }
iommu_fwspec_free(dev);
}
@@ -1270,6 +1300,18 @@ static const struct mtk_iommu_plat_data mt8192_data = {
{0, 14, 16}, {0, 13, 18, 17}},
};
+static const struct mtk_iommu_plat_data mt8192_data_apu = {
+ .m4u_plat = M4U_MT8192,
+ .flags = DCM_DISABLE | MTK_IOMMU_TYPE_APU |
+ SHARE_PGTABLE,
+ .inv_sel_reg= REG_MMU_INV_SEL_GEN2,
+ .hw_list= &apulist,
+ .bank_nr= 1,
+ .bank_enable= {true},
+ .iova_region= mt8192_multi_dom_apu,
+ .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom_apu),
+};
+
static const struct mtk_iommu_plat_data mt8195_data_infra = {
.m4u_plat = M4U_MT8195,
.flags= WR_THROT_EN | DCM_DISABLE |
@@ -1325,6 +1367,7 @@ static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
{ .compatible = "mediatek,mt8192-m4u", .data = &mt8192_data},
+ { .compatible = "mediatek,mt8192-iommu-apu", .data =
&mt8192_data_apu},
{ .compatible = "mediatek,mt8195-iommu-infra", .data =
&mt8195_data_infra},
{ .compatible = "mediatek,mt8195-iommu-vdo", .data =
&mt8195_data_vdo},
{ .compatible = "mediatek,mt8195-iommu-vpp", .data =
&mt8195_data_vpp},
--
2.18.0
[PATCH 11/17] soc: mediatek: apu: Add middleware driver
The APU middleware is responsible to receive all user's requests
and control command and device related flow.
In Kernel side, the middleware use the IPI to send command
to remote tinysys to dispatch commands to AI engines in APU.
Signed-off-by: JB Tsai
Signed-off-by: Flora Fu
---
drivers/soc/mediatek/apusys/Makefile | 10 +
drivers/soc/mediatek/apusys/apu-device.h | 39 +
drivers/soc/mediatek/apusys/mdw-cmd.c| 618 +++
drivers/soc/mediatek/apusys/mdw-drv.c| 226 ++
drivers/soc/mediatek/apusys/mdw-ioctl.c | 331
drivers/soc/mediatek/apusys/mdw-ioctl.h | 256 +++
drivers/soc/mediatek/apusys/mdw-mem.c| 938 +++
drivers/soc/mediatek/apusys/mdw-mem.h| 23 +
drivers/soc/mediatek/apusys/mdw-rv-cmd.c | 158
drivers/soc/mediatek/apusys/mdw-rv-dev.c | 386 ++
drivers/soc/mediatek/apusys/mdw-rv-msg.h | 90 +++
drivers/soc/mediatek/apusys/mdw-rv.c | 131
drivers/soc/mediatek/apusys/mdw-rv.h | 98 +++
drivers/soc/mediatek/apusys/mdw-sysfs.c | 200 +
drivers/soc/mediatek/apusys/mdw.h| 207 +
15 files changed, 3711 insertions(+)
create mode 100644 drivers/soc/mediatek/apusys/apu-device.h
create mode 100644 drivers/soc/mediatek/apusys/mdw-cmd.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-drv.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-ioctl.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-ioctl.h
create mode 100644 drivers/soc/mediatek/apusys/mdw-mem.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-mem.h
create mode 100644 drivers/soc/mediatek/apusys/mdw-rv-cmd.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-rv-dev.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-rv-msg.h
create mode 100644 drivers/soc/mediatek/apusys/mdw-rv.c
create mode 100644 drivers/soc/mediatek/apusys/mdw-rv.h
create mode 100644 drivers/soc/mediatek/apusys/mdw-sysfs.c
create mode 100644 drivers/soc/mediatek/apusys/mdw.h
diff --git a/drivers/soc/mediatek/apusys/Makefile
b/drivers/soc/mediatek/apusys/Makefile
index 6fb69abcf3b9..9104c2979b85 100644
--- a/drivers/soc/mediatek/apusys/Makefile
+++ b/drivers/soc/mediatek/apusys/Makefile
@@ -7,3 +7,13 @@ mtk_apu_pwr-objs += apu-pwr-ipi.o
mtk_apu_pwr-$(CONFIG_MTK_APU_DEBUG) += apu-pwr-dbg.o
obj-$(CONFIG_MTK_APU_DEBUG) += apu-sw-logger.o
+
+obj-$(CONFIG_MTK_APU) += mtk_apu_mdw.o
+mtk_apu_mdw-objs += mdw-drv.o
+mtk_apu_mdw-objs += mdw-ioctl.o
+mtk_apu_mdw-objs += mdw-mem.o
+mtk_apu_mdw-objs += mdw-cmd.o
+mtk_apu_mdw-objs += mdw-rv.o
+mtk_apu_mdw-objs += mdw-rv-cmd.o
+mtk_apu_mdw-objs += mdw-rv-dev.o
+mtk_apu_mdw-$(CONFIG_DEBUG_FS) += mdw-sysfs.o
diff --git a/drivers/soc/mediatek/apusys/apu-device.h
b/drivers/soc/mediatek/apusys/apu-device.h
new file mode 100644
index ..8a3ddf8d
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/apu-device.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#ifndef APUSYS_DEVICE_H
+#define APUSYS_DEVICE_H
+
+#include
+
+/* device type */
+enum {
+ APUSYS_DEVICE_NONE,
+
+ APUSYS_DEVICE_SAMPLE,
+ APUSYS_DEVICE_MDLA,
+ APUSYS_DEVICE_VPU,
+ APUSYS_DEVICE_EDMA,
+ APUSYS_DEVICE_RT = 32,
+ APUSYS_DEVICE_SAMPLE_RT,
+ APUSYS_DEVICE_MDLA_RT,
+ APUSYS_DEVICE_VPU_RT,
+
+ APUSYS_DEVICE_MAX = 64,
+};
+
+/* device definition */
+#define APUSYS_DEVICE_META_SIZE (32)
+
+struct apusys_device {
+ int dev_type;
+ int idx;
+ int preempt_type;
+ u8 preempt_level;
+ char meta_data[APUSYS_DEVICE_META_SIZE];
+ void *private;
+ int (*send_cmd)(int type, void *hnd, struct apusys_device *dev);
+};
+#endif
diff --git a/drivers/soc/mediatek/apusys/mdw-cmd.c
b/drivers/soc/mediatek/apusys/mdw-cmd.c
new file mode 100644
index ..231a82b4ba0e
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/mdw-cmd.c
@@ -0,0 +1,618 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+
+#include "mdw.h"
+#include "mdw-mem.h"
+
+static struct mdw_mem *mdw_cmd_get_mem(u64 handle)
+{
+ struct mdw_mem *m = NULL;
+
+ m = mdw_mem_get(handle);
+ if (!m)
+ return NULL;
+
+ mdw_mem_dma_map(m);
+
+ return m;
+}
+
+static int mdw_cmd_put_mem(struct mdw_mem *m)
+{
+ return mdw_mem_dma_unmap(m);
+}
+
+static void mdw_cmd_put_cmdbufs(struct mdw_fpriv *mpriv, struct mdw_cmd *c)
+{
+ struct mdw_subcmd_kinfo *ksubcmd = NULL;
+ unsigned int i = 0, j = 0;
+
+ if (!c->cmdbufs)
+ return;
+
+ /* flush cmdbufs and execinfos */
+ apusys_mem_invalidate_kva(c->cmdbufs->vaddr, c->cmdbufs->size);
+
+ for (i = 0; i < c->num_subcmds; i++) {
+ ksubcmd = &c->ksubcmds[i];
+ for (j = 0; j < ksubcmd->info->num_cmdbufs; j++) {
+ if (!ksubcmd->ori_cbs[j])
+ continue;
[PATCH 09/17] soc: mediatek: apu: Add Apu power driver
Add APU power driver to support for subsys clock
and regulator controller.
Add MT8192 platform APU power driver's platform data.
Signed-off-by: Flora Fu
---
drivers/soc/mediatek/apusys/Kconfig | 23 +
drivers/soc/mediatek/apusys/Makefile | 5 +
drivers/soc/mediatek/apusys/apu-pwr-dbg.c | 167 ++
drivers/soc/mediatek/apusys/apu-pwr-ipi.c | 377 +
drivers/soc/mediatek/apusys/apu-pwr.c | 613 ++
drivers/soc/mediatek/apusys/apu-pwr.h | 260 +
6 files changed, 1445 insertions(+)
create mode 100644 drivers/soc/mediatek/apusys/apu-pwr-dbg.c
create mode 100644 drivers/soc/mediatek/apusys/apu-pwr-ipi.c
create mode 100644 drivers/soc/mediatek/apusys/apu-pwr.c
create mode 100644 drivers/soc/mediatek/apusys/apu-pwr.h
diff --git a/drivers/soc/mediatek/apusys/Kconfig
b/drivers/soc/mediatek/apusys/Kconfig
index 332e323e02ae..1daf73c74c17 100644
--- a/drivers/soc/mediatek/apusys/Kconfig
+++ b/drivers/soc/mediatek/apusys/Kconfig
@@ -11,4 +11,27 @@ config MTK_APU_PM
APU power domain shall be enabled before accessing the
internal sub modules.
+config MTK_APU
+ tristate "MediaTek APUSYS Support"
+ select REGMAP
+ select MAILBOX
+ select MTK_APU_MBOX
+ select MTK_APU_RPROC
+ select MTK_SCP
+ help
+ Say yes here to add support for the APU tinysys and enable
+ sub modules include apu power and middleware.
+ The tinysys firmware is loaded and booted from Kernel side through
+ rproc framework. The related sub modules in application processor
+ use IPI to communicate with APU tinysys.
+
+config MTK_APU_DEBUG
+ tristate "MediaTek APUSYS debug functions"
+ depends on MTK_APU
+ help
+ Say yes here to enable debug features in APU.
+ The debug configuration will enable kernel driver debug and register a
+ logger for retrieving debug logs from remote processor.
+ Disable it if you don't need them.
+
endif # MTK_APUSYS
diff --git a/drivers/soc/mediatek/apusys/Makefile
b/drivers/soc/mediatek/apusys/Makefile
index 8821c0f0b7b7..8fff18d63dc1 100644
--- a/drivers/soc/mediatek/apusys/Makefile
+++ b/drivers/soc/mediatek/apusys/Makefile
@@ -1,2 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_MTK_APU_PM) += mtk-apu-pm.o
+
+obj-$(CONFIG_MTK_APU) += mtk_apu_pwr.o
+mtk_apu_pwr-objs += apu-pwr.o
+mtk_apu_pwr-objs += apu-pwr-ipi.o
+mtk_apu_pwr-$(CONFIG_MTK_APU_DEBUG) += apu-pwr-dbg.o
diff --git a/drivers/soc/mediatek/apusys/apu-pwr-dbg.c
b/drivers/soc/mediatek/apusys/apu-pwr-dbg.c
new file mode 100644
index ..ee81271cbb2c
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/apu-pwr-dbg.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "apu-pwr.h"
+
+#define DEBUG_MAX_ARGS_NUM (5)
+
+struct dentry *apu_power_debugfs;
+
+static int apu_power_set_parameter(struct apu_power *apupwr,
+ enum APU_POWER_PARAM param,
+ u32 argc, u32 *args)
+{
+ struct device *dev = apupwr->dev;
+ int ret = 0;
+
+ switch (param) {
+ case POWER_PARAM_FIX_OPP:
+ if (args[0] == 0) {
+ apu_update_fixed_opp_by_reg(dev, 0x);
+ apu_power_notify_uP_opp_limit(apupwr,
+ OPP_LIMIT_FIX_OPP);
+ }
+ break;
+ case POWER_PARAM_DVFS_DEBUG:
+ if (args[0] >= 0 && args[0] <= 0x) {
+ apu_update_fixed_opp_by_reg(dev, args[0]);
+ apu_power_notify_uP_opp_limit(apupwr,
+ OPP_LIMIT_DVFS_DEBUG);
+ }
+ break;
+ case POWER_PARAM_ULOG_LEVEL:
+ ret = (argc == 1) ? 0 : -EINVAL;
+ if (ret) {
+ dev_err(dev,
+ "invalid argument, expected:1, received:%d\n",
+ argc);
+ goto out;
+ }
+ apupwr->dbg_option = POWER_PARAM_ULOG_LEVEL;
+ apupwr->ulog_level = args[0];
+ apu_power_set_ulog_level(apupwr, args[0]);
+ break;
+
+ default:
+ dev_err(dev, "unsupport the power parameter:%d\n", param);
+ break;
+ }
+
+out:
+ return ret;
+}
+
+static int apu_power_dbg_show(struct seq_file *s, void *unused)
+{
+ struct apu_power *apupwr = (struct apu_power *)s->private;
+ u32 ulog_level = apupwr->ulog_level;
+ u32 dbg_option = apupwr->dbg_option;
+
+ switch (dbg_option) {
+ case POWER_PARAM_ULOG_LEVEL:
+ seq_printf(s, "ulog_level = %d\n", ulog_level);
+ break;
[PATCH 15/17] arm64: dts: mt8192: Add APU power nodes
Add APU power node for MT8192.
Signed-off-by: Flora Fu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 61
1 file changed, 61 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index de73fbf0cb90..f95d381ff1cc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -996,6 +996,67 @@
};
};
+ apusys_power: apusys_power@190f1000 {
+ compatible = "mediatek,mt8192-apu-power";
+ reg = <0 0x190f1000 0 0x1000>,
+ <0 0x19000600 0 0x100>;
+ reg-names = "apu_pcu",
+ "apu_spare";
+ power-domains = <&apuspm 0>;
+ clocks = <&topckgen CLK_TOP_DSP_SEL>,
+ <&topckgen CLK_TOP_DSP1_SEL>,
+ <&topckgen CLK_TOP_DSP1_NPUPLL_SEL>,
+ <&topckgen CLK_TOP_DSP2_SEL>,
+ <&topckgen CLK_TOP_DSP2_NPUPLL_SEL>,
+ <&topckgen CLK_TOP_DSP5_SEL>,
+ <&topckgen CLK_TOP_DSP5_APUPLL_SEL>,
+ <&topckgen CLK_TOP_IPU_IF_SEL>,
+ <&clk26m>,
+ <&topckgen CLK_TOP_MAINPLL_D4_D2>,
+ <&topckgen CLK_TOP_UNIVPLL_D4_D2>,
+ <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
+ <&topckgen CLK_TOP_MMPLL_D6>,
+ <&topckgen CLK_TOP_MMPLL_D5>,
+ <&topckgen CLK_TOP_MMPLL_D4>,
+ <&topckgen CLK_TOP_UNIVPLL_D5>,
+ <&topckgen CLK_TOP_UNIVPLL_D4>,
+ <&topckgen CLK_TOP_UNIVPLL_D3>,
+ <&topckgen CLK_TOP_MAINPLL_D6>,
+ <&topckgen CLK_TOP_MAINPLL_D4>,
+ <&topckgen CLK_TOP_MAINPLL_D3>,
+ <&topckgen CLK_TOP_TVDPLL>,
+ <&topckgen CLK_TOP_APUPLL>,
+ <&topckgen CLK_TOP_NPUPLL>,
+ <&apmixedsys CLK_APMIXED_APUPLL>,
+ <&apmixedsys CLK_APMIXED_NPUPLL>;
+ clock-names = "clk_top_dsp_sel",
+ "clk_top_dsp1_sel",
+ "clk_top_dsp1_npupll_sel",
+ "clk_top_dsp2_sel",
+ "clk_top_dsp2_npupll_sel",
+ "clk_top_dsp5_sel",
+ "clk_top_dsp5_apupll_sel",
+ "clk_top_ipu_if_sel",
+ "clk_top_clk26m",
+ "clk_top_mainpll_d4_d2",
+ "clk_top_univpll_d4_d2",
+ "clk_top_univpll_d6_d2",
+ "clk_top_mmpll_d6",
+ "clk_top_mmpll_d5",
+ "clk_top_mmpll_d4",
+ "clk_top_univpll_d5",
+ "clk_top_univpll_d4",
+ "clk_top_univpll_d3",
+ "clk_top_mainpll_d6",
+ "clk_top_mainpll_d4",
+ "clk_top_mainpll_d3",
+ "clk_top_tvdpll_ck",
+ "clk_top_apupll_ck",
+ "clk_top_npupll_ck",
+ "clk_apmixed_apupll_rate",
+ "clk_apmixed_npupll_rate";
+ };
+
camsys: clock-controller@1a00 {
compatible = "mediatek,mt8192-camsys";
reg = <0 0x1a00 0 0x1000>;
--
2.18.0
[PATCH 13/17] arm64: dts: mt8192: Add APU-IOMMU nodes
Add APU-IOMMI nodes
Signed-off-by: Yong Wu
Signed-off-by: Flora Fu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 5c97dc7985b4..62acaba7b033 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -913,6 +914,14 @@
#mbox-cells = <1>;
};
+ iommu_apu: iommu@1901 {
+ compatible = "mediatek,mt8192-iommu-apu";
+ reg = <0 0x1901 0 0x1000>;
+ interrupts = ;
+ power-domains = <&apuspm 0>;
+ #iommu-cells = <1>;
+ };
+
apu_conn: apu_conn@1902 {
compatible = "mediatek,mt8192-apu-conn", "syscon";
reg = <0 0x1902 0 0x1000>;
--
2.18.0
[PATCH 16/17] arm64: dts: mt8192: Add apu-sw-logger node
Add apu-sw-logger node to enable debug into tinysys.
Signed-off-by: Flora Fu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index f95d381ff1cc..c8cc58e74f3c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -914,6 +914,12 @@
#mbox-cells = <1>;
};
+ apusys_sw_logger@1940 {
+ compatible = "mediatek,apu-sw-logger";
+ reg = <0 0x1940 0 0x10>;
+ iommus = <&iommu_apu IOMMU_PORT_APU_DATA>;
+ };
+
apusys_rv@19001000 {
compatible = "mediatek,mt8192-apusys-rv", "simple-mfd";
reg = <0 0x1900 0 0x1000>,
--
2.18.0
[PATCH 12/17] arm64: dts: mt8192: Add APU mtk-apu-mailbox node
Add mtk-apu-mailbox for mt8192 SOC.
Signed-off-by: Flora Fu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index cb2b171e0080..5c97dc7985b4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -906,6 +906,13 @@
#clock-cells = <1>;
};
+ apu_mailbox: apu_mailbox@1900 {
+ compatible = "mediatek,mtk-apu-mailbox";
+ reg = <0 0x1900 0 0x100>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
apu_conn: apu_conn@1902 {
compatible = "mediatek,mt8192-apu-conn", "syscon";
reg = <0 0x1902 0 0x1000>;
--
2.18.0
[PATCH 17/17] arm64: dts: mt8192: Set up regulators for APU subsys
Set up APU regulators for mdla and vvpu.
Signed-off-by: Flora Fu
---
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 5d9e108e41f5..431008466d77 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -35,3 +35,8 @@
domain-supply = <&mt6359_vproc1_buck_reg>;
};
};
+
+&apusys_power {
+ vvpu-supply = <&mt6359_vproc1_buck_reg>;
+ vmdla-supply = <&mt6359_vproc2_buck_reg>;
+};
--
2.18.0
[PATCH 10/17] soc: mediatek: apu: Add APU software logger dirver
The APU software logger is for debug for remote processor.
The remote microprocessor's logs will be output to the mapped
memory and application processor can read logs from the
dedicated reserved registers
Signed-off-by: Flora Fu
---
drivers/soc/mediatek/apusys/Makefile| 2 +
drivers/soc/mediatek/apusys/apu-sw-logger.c | 540
2 files changed, 542 insertions(+)
create mode 100644 drivers/soc/mediatek/apusys/apu-sw-logger.c
diff --git a/drivers/soc/mediatek/apusys/Makefile
b/drivers/soc/mediatek/apusys/Makefile
index 8fff18d63dc1..6fb69abcf3b9 100644
--- a/drivers/soc/mediatek/apusys/Makefile
+++ b/drivers/soc/mediatek/apusys/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_MTK_APU) += mtk_apu_pwr.o
mtk_apu_pwr-objs += apu-pwr.o
mtk_apu_pwr-objs += apu-pwr-ipi.o
mtk_apu_pwr-$(CONFIG_MTK_APU_DEBUG) += apu-pwr-dbg.o
+
+obj-$(CONFIG_MTK_APU_DEBUG) += apu-sw-logger.o
diff --git a/drivers/soc/mediatek/apusys/apu-sw-logger.c
b/drivers/soc/mediatek/apusys/apu-sw-logger.c
new file mode 100644
index ..98a9748e92a7
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/apu-sw-logger.c
@@ -0,0 +1,540 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define APUSYS_LOGGER_DIR "apu_logger"
+
+#define LOG_LINE_MAX_LENS SZ_128
+#define APU_LOG_SIZE SZ_1M
+#define APU_LOG_BUF_SIZE SZ_1M
+
+#define LOG_W_PTR 0x0
+#define LOG_R_PTR 0x4
+#define LOG_OV_FLG 0xC
+
+struct sw_logger_seq_data {
+ u32 w_ptr;
+ u32 r_ptr;
+ u32 overflow_flg;
+ int i;
+ int is_finished;
+ char *data;
+ bool startl_first;
+};
+
+struct apu_sw_logger {
+ struct device *dev;
+ struct dentry *dbg_root;
+ dma_addr_t handle;
+ char *sw_log_buf;
+ void __iomem *apu_slog;
+ spinlock_t logger_spinlock; /* logger status update lock */
+ struct sw_logger_seq_data pseqdata_lock;
+ struct sw_logger_seq_data *pseqdata;
+};
+
+static struct dentry *log_root;
+static struct dentry *log_seqlog;
+static struct dentry *log_seqlogl;
+static struct device *sw_logger_dev;
+
+static void sw_logger_buf_invalidate(struct apu_sw_logger *logger)
+{
+ dma_sync_single_for_cpu(logger->dev, logger->handle, APU_LOG_SIZE,
+ DMA_FROM_DEVICE);
+}
+
+static int sw_logger_buf_alloc(struct device *dev)
+{
+ struct apu_sw_logger *logger = dev_get_drvdata(dev);
+ int ret;
+
+ ret = dma_set_coherent_mask(logger->dev, DMA_BIT_MASK(64));
+ if (ret)
+ return ret;
+
+ logger->sw_log_buf = kzalloc(APU_LOG_SIZE, GFP_KERNEL);
+ if (!logger->sw_log_buf)
+ return -ENOMEM;
+
+ logger->handle = dma_map_single(logger->dev, logger->sw_log_buf,
+ APU_LOG_SIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(logger->dev, logger->handle) != 0) {
+ kfree(logger->sw_log_buf);
+ logger->sw_log_buf = NULL;
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+int sw_logger_config_init(struct config_v1 *conf)
+{
+ int ret;
+ unsigned long flags;
+ struct logger_init_info *st_logger_init_info;
+ struct apu_sw_logger *logger;
+
+ if (!conf)
+ return -EINVAL;
+
+ if (!sw_logger_dev) {
+ pr_debug("%s: logger NA and skip logger\n",
+__func__);
+ return 0;
+ }
+
+ logger = dev_get_drvdata(sw_logger_dev);
+ if (!logger->sw_log_buf) {
+ ret = sw_logger_buf_alloc(logger->dev);
+ if (ret) {
+ dev_err(logger->dev, "%s: sw_logger_buf_alloc fail\n",
+ __func__);
+ return ret;
+ }
+ }
+
+ spin_lock_irqsave(&logger->logger_spinlock, flags);
+ iowrite32(0, logger->apu_slog + LOG_W_PTR);
+ iowrite32(0, logger->apu_slog + LOG_R_PTR);
+ iowrite32(0, logger->apu_slog + LOG_OV_FLG);
+ spin_unlock_irqrestore(&logger->logger_spinlock, flags);
+
+ st_logger_init_info = (struct logger_init_info *)
+ get_apu_config_user_ptr(conf, LOGGER_INIT_INFO);
+
+ st_logger_init_info->iova = logger->handle;
+
+ return 0;
+}
+EXPORT_SYMBOL(sw_logger_config_init);
+
+void sw_logger_config_remove(void)
+{
+ struct apu_sw_logger *logger = dev_get_drvdata(sw_logger_dev);
+
+ if (logger->handle)
+ dma_unmap_single(logger->dev, logger->handle,
+APU_LOG_SIZE, DMA_FROM_DEVICE);
+ kfree(logger->sw_log_buf);
+ logger->sw_log_buf = NULL;
+}
+EXPORT_SYMBOL(sw_logger_config_remove);
+
+/*
+ * seq_start() takes a position as an argument and returns an iterator which
+ * will start reading at that position.
+ *
[PATCH 14/17] arm64: dts: mt8192: Add apu tinysys node
Add node for APU tinysys.
Signed-off-by: Flora Fu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 35
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 62acaba7b033..de73fbf0cb90 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -914,6 +914,41 @@
#mbox-cells = <1>;
};
+ apusys_rv@19001000 {
+ compatible = "mediatek,mt8192-apusys-rv", "simple-mfd";
+ reg = <0 0x1900 0 0x1000>,
+ <0 0x19001000 0 0x1000>,
+ <0 0x19002000 0 0x10>;
+ reg-names = "apu_mbox",
+ "md32_sysctrl",
+ "apu_wdt";
+ power-domains = <&apuspm 0>;
+ iommus = <&iommu_apu IOMMU_PORT_APU_DATA>;
+ interrupts = ;
+ interrupt-names = "apu_wdt";
+ mboxes = <&apu_mailbox 0>;
+
+ apu_ctrl {
+ compatible = "mediatek,apu-ctrl-rpmsg";
+ mtk,rpmsg-name = "apu-ctrl-rpmsg";
+ };
+
+ apu_pwr_tx {
+ compatible = "mediatek,apupwr-tx-rpmsg";
+ mtk,rpmsg-name = "apupwr-tx-rpmsg";
+ };
+
+ apu_pwr_rx {
+ compatible = "mediatek,apupwr-rx-rpmsg";
+ mtk,rpmsg-name = "apupwr-rx-rpmsg";
+ };
+
+ apu_mdw_rpmsg {
+ compatible = "mediatek,apu-mdw-rpmsg";
+ mtk,rpmsg-name = "apu-mdw-rpmsg";
+ };
+ };
+
iommu_apu: iommu@1901 {
compatible = "mediatek,mt8192-iommu-apu";
reg = <0 0x1901 0 0x1000>;
--
2.18.0
[PATCH 08/17] remoteproc: mediatek: Add APU remoteproc driver
APU integrated subsystem having MD32RV33 (MD32) that runs tinysys
The tinysys is runs on a microprocessor in APU. Its firmware
is loaded and booted from Kernel side. Kernel and tinysys use IPI
to send and receive messages.
Signed-off-by: Pi-Cheng Chen
Signed-off-by: Flora Fu
---
drivers/remoteproc/Kconfig| 12 +
drivers/remoteproc/Makefile |2 +
drivers/remoteproc/mtk-apu-ipi.c | 474 +
drivers/remoteproc/mtk-apu-rproc.c| 1054 +
include/linux/remoteproc/mtk-apu-config.h | 100 ++
include/linux/remoteproc/mtk-apu.h| 217 +
6 files changed, 1859 insertions(+)
create mode 100644 drivers/remoteproc/mtk-apu-ipi.c
create mode 100644 drivers/remoteproc/mtk-apu-rproc.c
create mode 100644 include/linux/remoteproc/mtk-apu-config.h
create mode 100644 include/linux/remoteproc/mtk-apu.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f2e961f998ca..72fc5fe7f4b5 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -54,6 +54,18 @@ config INGENIC_VPU_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config MTK_APU_RPROC
+ tristate "MediaTek APU remoteproc support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ select MAILBOX
+ select MTK_APU_MBOX
+ select MTK_SCP
+ help
+ Say y here to support MediaTek AI Processing Unit Subsystem
+ via the remote processor framework.
+
+ It's safe to say N here.
+
config MTK_SCP
tristate "Mediatek SCP support"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 0ac256b6c977..1c1f1e443c56 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,6 +15,8 @@ obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
obj-$(CONFIG_IMX_DSP_REMOTEPROC) += imx_dsp_rproc.o
obj-$(CONFIG_INGENIC_VPU_RPROC)+= ingenic_rproc.o
obj-$(CONFIG_MTK_SCP) += mtk_scp.o mtk_scp_ipi.o
+obj-$(CONFIG_MTK_APU_RPROC)+= apu.o
+apu-objs += mtk-apu-rproc.o mtk-apu-ipi.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk-apu-ipi.c b/drivers/remoteproc/mtk-apu-ipi.c
new file mode 100644
index ..62197441eb0b
--- /dev/null
+++ b/drivers/remoteproc/mtk-apu-ipi.c
@@ -0,0 +1,474 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct apu_mbox_hdr {
+ unsigned int id;
+ unsigned int len;
+ unsigned int serial_no;
+ unsigned int csum;
+};
+
+#define IPI_BUF_SIZE (round_up(sizeof(struct mtk_share_obj) * 2, PAGE_SIZE))
+
+static struct lock_class_key ipi_lock_key[APU_IPI_MAX];
+static unsigned int tx_serial_no;
+static unsigned int rx_serial_no;
+
+#if IS_ENABLED(CONFIG_MTK_APU_DEBUG)
+static inline void dump_msg_buf(struct mtk_apu *apu, void *data, u32 len)
+{
+ struct device *dev = apu->dev;
+ u32 i;
+ int size = 64, num;
+ u8 buf[64], *ptr = buf;
+ int ret;
+
+ dev_info(dev, "= dump message =\n");
+ for (i = 0; i < len; i++) {
+ num = snprintf(ptr, size, "%02x ", ((u8 *)data)[i]);
+ if (num <= 0) {
+ dev_info(dev, "%s: snprintf return error(num = %d)\n",
+__func__, num);
+ return;
+ }
+ size -= num;
+ ptr += num;
+
+ if ((i + 1) % 4 == 0) {
+ ret = snprintf(ptr++, size--, " ");
+ if (ret <= 0) {
+ dev_info(dev, "%s: snprintf return error(ret =
%d)\n",
+__func__, ret);
+ return;
+ }
+ }
+
+ if ((i + 1) % 16 == 0 || (i + 1) >= len) {
+ dev_info(dev, "%s\n", buf);
+ size = 64;
+ ptr = buf;
+ }
+ }
+ dev_info(dev, "\n");
+}
+#endif
+
+static u32 calculate_csum(void *data, u32 len)
+{
+ u32 csum = 0, res = 0, i;
+ u8 *ptr;
+
+ for (i = 0; i < (len / sizeof(csum)); i++)
+ csum += *(((u32 *)data) + i);
+
+ ptr = (u8 *)data + len / sizeof(csum) * sizeof(csum);
+ for (i = 0; i < (len % sizeof(csum)); i++)
+ res |= *(ptr + i) << i * 8;
+
+ csum += res;
+
+ return csum;
+}
+
+static inline bool bypass_check(u32 id)
+{
+ /* whitelist IPI used in power off flow */
+ return id == APU_IPI_DEEP_IDLE;
+}
+
+static void
[PATCH 1/3] drm: bridge: nwl-dsi: Drop panel_bridge from nwl_dsi
panel_bridge pointer never used anywhere except the one it
looked up at nwl_dsi_bridge_attach.
Drop it from the nwl_dsi structure.
Cc: Guido Günther
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/nwl-dsi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index a7389a0facfb..6becdcdc99fe 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -65,7 +65,6 @@ struct nwl_dsi_transfer {
struct nwl_dsi {
struct drm_bridge bridge;
struct mipi_dsi_host dsi_host;
- struct drm_bridge *panel_bridge;
struct device *dev;
struct phy *phy;
union phy_configure_opts phy_cfg;
@@ -924,13 +923,11 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
*bridge,
if (IS_ERR(panel_bridge))
return PTR_ERR(panel_bridge);
}
- dsi->panel_bridge = panel_bridge;
- if (!dsi->panel_bridge)
+ if (!panel_bridge)
return -EPROBE_DEFER;
- return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge,
-flags);
+ return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags);
}
static void nwl_dsi_bridge_detach(struct drm_bridge *bridge)
--
2.25.1
[PATCH 2/3] Revert "drm/bridge: dw-mipi-dsi: Find the possible DSI devices"
This reverts commit c206c7faeb3263a7cc7b4de443a3877cd7a5e74b.
In order to avoid any probe ordering issues, the I2C based downstream
bridge drivers now register and attach the DSI devices at the probe
instead of doing it on drm_bridge_function.attach().
Examples of those commits are:
commit <6ef7ee48765f> ("drm/bridge: sn65dsi83: Register and attach our
DSI device at probe")
commit ("drm/bridge: lt8912b: Register and attach our DSI
device at probe")
commit <864c49a31d6b> ("drm/bridge: adv7511: Register and attach our DSI
device at probe")
dw-mipi-dsi has panel or bridge finding code based on previous downstream
bridges, so revert the same and make the panel or bridge funding in host
attach as before.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 58 +--
1 file changed, 15 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index e44e18a0112a..7900da1d4325 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -246,7 +246,6 @@ struct dw_mipi_dsi {
struct clk *pclk;
- bool device_found;
unsigned int lane_mbps; /* per lane */
u32 channel;
u32 lanes;
@@ -310,37 +309,13 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32
reg)
return readl(dsi->base + reg);
}
-static int dw_mipi_dsi_panel_or_bridge(struct dw_mipi_dsi *dsi,
- struct device_node *node)
-{
- struct drm_bridge *bridge;
- struct drm_panel *panel;
- int ret;
-
- ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
- if (ret)
- return ret;
-
- if (panel) {
- bridge = drm_panel_bridge_add_typed(panel,
- DRM_MODE_CONNECTOR_DSI);
- if (IS_ERR(bridge))
- return PTR_ERR(bridge);
- }
-
- dsi->panel_bridge = bridge;
-
- if (!dsi->panel_bridge)
- return -EPROBE_DEFER;
-
- return 0;
-}
-
static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
int ret;
if (device->lanes > dsi->plat_data->max_data_lanes) {
@@ -354,14 +329,22 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- if (!dsi->device_found) {
- ret = dw_mipi_dsi_panel_or_bridge(dsi, host->dev->of_node);
- if (ret)
- return ret;
+ ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
+ &panel, &bridge);
+ if (ret)
+ return ret;
- dsi->device_found = true;
+ if (panel) {
+ bridge = drm_panel_bridge_add_typed(panel,
+ DRM_MODE_CONNECTOR_DSI);
+ if (IS_ERR(bridge))
+ return PTR_ERR(bridge);
}
+ dsi->panel_bridge = bridge;
+
+ drm_bridge_add(&dsi->bridge);
+
if (pdata->host_ops && pdata->host_ops->attach) {
ret = pdata->host_ops->attach(pdata->priv_data, device);
if (ret < 0)
@@ -1016,16 +999,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge,
/* Set the encoder type as caller does not know it */
bridge->encoder->encoder_type = DRM_MODE_ENCODER_DSI;
- if (!dsi->device_found) {
- int ret;
-
- ret = dw_mipi_dsi_panel_or_bridge(dsi, dsi->dev->of_node);
- if (ret)
- return ret;
-
- dsi->device_found = true;
- }
-
/* Attach the panel-bridge to the dsi bridge */
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge,
flags);
@@ -1208,7 +1181,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
#ifdef CONFIG_OF
dsi->bridge.of_node = pdev->dev.of_node;
#endif
- drm_bridge_add(&dsi->bridge);
return dsi;
}
--
2.25.1
[PATCH 3/3] drm: bridge: Switch to devm_drm_of_get_bridge
devm_drm_of_get_bridge is capable of looking up the downstream
bridge and panel and trying to add a panel bridge if the panel
is found.
Replace explicit finding calls with devm_drm_of_get_bridge.
Cc: Philipp Zabel
Cc: Chun-Kuang Hu
Cc: Linus Walleij
Signed-off-by: Jagan Teki
---
Note: for mcde_dsi child lookups has dependecy with
https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-ja...@amarulasolutions.com/
drivers/gpu/drm/bridge/analogix/anx7625.c | 13 +--
drivers/gpu/drm/bridge/chipone-icn6211.c | 7 +---
drivers/gpu/drm/bridge/nwl-dsi.c | 18 ++---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 7 +---
drivers/gpu/drm/bridge/parade-ps8622.c| 7 +---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 15 ++-
drivers/gpu/drm/mcde/mcde_dsi.c | 39 +++
drivers/gpu/drm/mediatek/mtk_dsi.c| 14 ++-
8 files changed, 18 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 001fb39d9919..065cc3b041dd 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1333,8 +1333,6 @@ static int anx7625_parse_dt(struct device *dev,
struct anx7625_platform_data *pdata)
{
struct device_node *np = dev->of_node, *ep0;
- struct drm_panel *panel;
- int ret;
int bus_type, mipi_lanes;
anx7625_get_swing_setting(dev, pdata);
@@ -1371,16 +1369,7 @@ static int anx7625_parse_dt(struct device *dev,
if (of_property_read_bool(np, "analogix,audio-enable"))
pdata->audio_en = 1;
- ret = drm_of_find_panel_or_bridge(np, 1, 0, &panel, NULL);
- if (ret < 0) {
- if (ret == -ENODEV)
- return 0;
- return ret;
- }
- if (!panel)
- return -ENODEV;
-
- pdata->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
+ pdata->panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
if (IS_ERR(pdata->panel_bridge))
return PTR_ERR(pdata->panel_bridge);
DRM_DEV_DEBUG_DRIVER(dev, "get panel node.\n");
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index a6151db95586..23c34039ac48 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -178,7 +178,6 @@ static const struct drm_bridge_funcs chipone_bridge_funcs =
{
static int chipone_parse_dt(struct chipone *icn)
{
struct device *dev = icn->dev;
- struct drm_panel *panel;
int ret;
icn->vdd1 = devm_regulator_get_optional(dev, "vdd1");
@@ -214,11 +213,7 @@ static int chipone_parse_dt(struct chipone *icn)
return PTR_ERR(icn->enable_gpio);
}
- ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, &panel, NULL);
- if (ret)
- return ret;
-
- icn->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
+ icn->panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
if (IS_ERR(icn->panel_bridge))
return PTR_ERR(icn->panel_bridge);
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 6becdcdc99fe..f6859dfa6d36 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -910,22 +910,10 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
*bridge,
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
struct drm_bridge *panel_bridge;
- struct drm_panel *panel;
- int ret;
-
- ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, &panel,
- &panel_bridge);
- if (ret)
- return ret;
-
- if (panel) {
- panel_bridge = drm_panel_bridge_add(panel);
- if (IS_ERR(panel_bridge))
- return PTR_ERR(panel_bridge);
- }
- if (!panel_bridge)
- return -EPROBE_DEFER;
+ panel_bridge = devm_drm_of_get_bridge(dsi->dev, dsi->dev->of_node, 1,
0);
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags);
}
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index e941c1132598..1ab91f4e057b 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -263,7 +263,6 @@ static int ptn3460_probe(struct i2c_client *client,
struct device *dev = &client->dev;
struct ptn3460_bridge *ptn_bridge;
struct drm_bridge *panel_bridge;
- struct drm_panel *panel;
int ret;
ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
@@ -271,11 +270,7 @@ static int ptn3460_probe(struct i2c_client *c
[PATCH v2 02/11] gpu: host1x: Add missing DMA API include
Host1x seems to be relying on picking up dma-mapping.h transitively from iova.h, which has no reason to include it in the first place. Fix the former issue before we totally break things by fixing the latter one. CC: Thierry Reding CC: Mikko Perttunen CC: dri-devel@lists.freedesktop.org Signed-off-by: Robin Murphy --- v2: No change drivers/gpu/host1x/bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c index 218e3718fd68..881fad5c3307 100644 --- a/drivers/gpu/host1x/bus.c +++ b/drivers/gpu/host1x/bus.c @@ -5,6 +5,7 @@ */ #include +#include #include #include #include -- 2.28.0.dirty
[PATCH v2 03/11] drm/tegra: vic: Fix DMA API misuse
Upon failure, dma_alloc_coherent() returns NULL. If that does happen,
passing some uninitialised stack contents to dma_mapping_error() - which
belongs to a different API in the first place - has precious little
chance of detecting it.
Also include the correct header, because the fragile transitive
inclusion currently providing it is going to break soon.
Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding
CC: Mikko Perttunen
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy
---
It also doesn't appear to handle failure of the tegra_drm_alloc() path
either, but that's a loose thread I have no desire to pull on... ;)
v2: Resend as part of the series, originally posted separately here:
https://lore.kernel.org/dri-devel/2703882439344010e33bf21ecd63cf9e5e6dc00d.1637781007.git.robin.mur...@arm.com/
drivers/gpu/drm/tegra/vic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index c02010ff2b7f..da4af5371991 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -232,10 +233,8 @@ static int vic_load_firmware(struct vic *vic)
if (!client->group) {
virt = dma_alloc_coherent(vic->dev, size, &iova, GFP_KERNEL);
-
- err = dma_mapping_error(vic->dev, iova);
- if (err < 0)
- return err;
+ if (!virt)
+ return -ENOMEM;
} else {
virt = tegra_drm_alloc(tegra, size, &iova);
}
--
2.28.0.dirty
Re: [Intel-gfx] [PATCH] drm/i915/guc: Use correct context lock when callig clr_context_registered
On Fri, Dec 10, 2021 at 08:41:22AM +, Tvrtko Ursulin wrote:
>
> On 09/12/2021 19:14, Daniele Ceraolo Spurio wrote:
> >
> >
> > On 12/9/2021 10:48 AM, Matthew Brost wrote:
> > > s/ce/cn/ when grabbing guc_state.lock before calling
> > > clr_context_registered.
> > >
> > > Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
> > > Signed-off-by: Matthew Brost
> > > Cc:
>
> I think Cc: stable is not needed here:
>
> $ git tag --contains 0f7976506de61
> drm-intel-fixes-2021-11-18
> drm-intel-gt-next-2021-10-08
> drm-intel-gt-next-2021-10-21
> drm-intel-gt-next-2021-11-22
> drm-intel-next-2021-10-15
> drm-intel-next-fixes-2021-11-09
> v5.16-rc1
> v5.16-rc2
> v5.16-rc3
> v5.16-rc4
>
> So still can hit 5.16 via fixes. Rodrigo, did I get this right and you will
> be able to pick it up next week or so?
>
Will remove.
> > Reviewed-by: Daniele Ceraolo Spurio
> >
> > I'm assuming we didn't see any splat from the lockdep assert in
> > clr_context_registered in our CI runs because we never hit this case as
> > it requires 64k+ contexts. Maybe we can add a selftest to purposely
> > exercise this path? Not a blocker for merging this fix.
>
> Was the bug found by inspection or reported?
>
Internal testing.
> Given the buggy function is called steal_guc_id, so if the implication is
> there is no testing for guc id stealing, then it indeed please add some
> coverage ASAP.
>
Will do. I'll aim to get something out next week.
Matt
> Regards,
>
> Tvrtko
>
> >
> > Daniele
> >
> > > ---
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > 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 1f9d4fde421f..9b7b4f4e0d91 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -1937,9 +1937,9 @@ static int steal_guc_id(struct intel_guc *guc,
> > > struct intel_context *ce)
> > > list_del_init(&cn->guc_id.link);
> > > ce->guc_id = cn->guc_id;
> > > - spin_lock(&ce->guc_state.lock);
> > > + spin_lock(&cn->guc_state.lock);
> > > clr_context_registered(cn);
> > > - spin_unlock(&ce->guc_state.lock);
> > > + spin_unlock(&cn->guc_state.lock);
> > > set_context_guc_id_invalid(cn);
> >
Re: RPI 7" display touch controller
On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey wrote:
>
> On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> wrote:
> >
> > On Thu, 18 Nov 2021 at 17:36, Tim Harvey wrote:
> > >
> > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > wrote:
> > > >
> > > > Hi Tim
> > > >
> > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey wrote:
> > > > >
> > > > > Greetings,
> > > > >
> > > > > I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
> > > > > board and while I've been able to get the MIPI DSI display and
> > > > > backlight working I still can't seem to figure out the touch
> > > > > controller.
> > > > >
> > > > > It's supposed to have an FT5406 controller on it without an interrupt
> > > > > so I added polling support drivers/input/touchscreen/edt-ft5x06.c
> > > > > which I was able to verify using another touchscreen with that
> > > > > controller but when reading data from the FT5406 on the RPI controller
> > > > > the data does not make sense.
> > > > >
> > > > > These panels appear to route the I2C from the FT5406 to a STM32F103
> > > > > MPU that then provides a different I2C slave interface to the 15pin
> > > > > connector that I'm connected to. On that I2C interface I see an i2c
> > > > > slave at 0x45 which is managed by the regulator driver Marek wrote
> > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and there is also an
> > > > > i2c slave at 0x38 which I assumed was the FT5406 but I believe the MPU
> > > > > is perhaps obfuscating that touch data.
> > > > >
> > > > > Anyone have any ideas on how to make that touch controller useful?
> > > >
> > > > There should be nothing unusual. 0x38 is the EDT touch controller.
> > > > Starting with the Raspberry Pi OS Bullseye release, we're now using
> > > > the panel directly from DRM rather than through the firmware. That's
> > > > based on the branch at
> > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > >
> > >
> > > Dave,
> > >
> > > That sounds like the driver that made it into mainline with Eric's
> > > commit 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
> > > Touchscreen."). I looked there but that driver just deals with the DSI
> > > and not with touch.
> >
> > No, we've reverted away from that driver as it exposes no regulator
> > framework either, so again the touch element loses power.
> >
> > > > I also added polling support to edt-ft5x04.c.
> > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all of which are
> > > > in /arch/arm/boot/dts/overlays
> > >
> > > It doesn't look like you ever submitted your edt-ft5x04 polling mode
> > > support upstream. I saw another series to add polling support
> > > submitted by Nicolas back in 2019 but was never followed up on
> > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187&archive=both).
> >
> > No I haven't as it's been crazy trying to get this lot to work under
> > KMS at all over the last couple of months.
> >
> > > I have updated Nicolas' patch with the changes requested and am happy
> > > to submit it upstream. The benefit of his patch is that it uses a dt
> > > binding for the polling interval. I'm happy to submit this upstream.
> >
> > I hadn't seen Nicolas' patches, hence implementing it myself.
> >
> > If you've implemented the requested changes, could you check that the
> > polling rate is as expected? We were seeing that the input framework
> > wasn't delivering the requested poll rate when CONFIG_HZ=100 is
> > defined in the config. I must confess that I haven't checked it on my
> > current patch, but it was on my list of things to do.
> > There was a report that "bd88ce25335d Input: raspberrypi-ts - switch
> > to using polled mode of input devices" dropped the polling rate from
> > the desired 60Hz in switching to that framework.
>
> Ok, I'll make a note to test that and submit it.
>
> >
> > > >
> > > > The main issue I had was configuring the regulator framework
> > > > appropriately to allow the touch controller power to be separate from
> > > > the bridge power. Without that if DRM powered down the panel it killed
> > > > the touch controller too, and the touch driver never reinitialised
> > > > itself.
> > >
> > > I'm using the same drivers/regulator/rpi-panel-attiny-regulator.c
> > > regulator driver from mainline that Marek added as the power-supply
> > > for the panel as well as the backlight controller. It looks like the
> > > version in the rpi-5.10.y has several patches on top of it so I'll
> > > take a look at those differences to see if it may be affecting the
> > > touchscreen controller. It's really strange to me that the touch
> > > controller's I2C goes through the STM32F103 MPU (as in the MPU's I2C
> > > master connects to the touchscreen controller and a different MPU I2C
> > > bus presents the touch controller like they are translating
> > > something?).
> >
> > The touchscreen I2C does NOT go through the STM.
> > Th
Re: [PATCH 1/3] drm: bridge: nwl-dsi: Drop panel_bridge from nwl_dsi
Hi,
On Fri, Dec 10, 2021 at 11:18:17PM +0530, Jagan Teki wrote:
> panel_bridge pointer never used anywhere except the one it
> looked up at nwl_dsi_bridge_attach.
>
> Drop it from the nwl_dsi structure.
>
> Cc: Guido Günther
> Signed-off-by: Jagan Teki
Reviewed-by: Guido Günther
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index a7389a0facfb..6becdcdc99fe 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -65,7 +65,6 @@ struct nwl_dsi_transfer {
> struct nwl_dsi {
> struct drm_bridge bridge;
> struct mipi_dsi_host dsi_host;
> - struct drm_bridge *panel_bridge;
> struct device *dev;
> struct phy *phy;
> union phy_configure_opts phy_cfg;
> @@ -924,13 +923,11 @@ static int nwl_dsi_bridge_attach(struct drm_bridge
> *bridge,
> if (IS_ERR(panel_bridge))
> return PTR_ERR(panel_bridge);
> }
> - dsi->panel_bridge = panel_bridge;
>
> - if (!dsi->panel_bridge)
> + if (!panel_bridge)
> return -EPROBE_DEFER;
>
> - return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge,
> - flags);
> + return drm_bridge_attach(bridge->encoder, panel_bridge, bridge, flags);
> }
>
> static void nwl_dsi_bridge_detach(struct drm_bridge *bridge)
> --
> 2.25.1
>
Re: RPI 7" display touch controller
On Fri, 10 Dec 2021 at 18:20, Tim Harvey wrote:
>
> On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey wrote:
> >
> > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> > wrote:
> > >
> > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey wrote:
> > > >
> > > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > > wrote:
> > > > >
> > > > > Hi Tim
> > > > >
> > > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey
> > > > > wrote:
> > > > > >
> > > > > > Greetings,
> > > > > >
> > > > > > I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
> > > > > > board and while I've been able to get the MIPI DSI display and
> > > > > > backlight working I still can't seem to figure out the touch
> > > > > > controller.
> > > > > >
> > > > > > It's supposed to have an FT5406 controller on it without an
> > > > > > interrupt
> > > > > > so I added polling support drivers/input/touchscreen/edt-ft5x06.c
> > > > > > which I was able to verify using another touchscreen with that
> > > > > > controller but when reading data from the FT5406 on the RPI
> > > > > > controller
> > > > > > the data does not make sense.
> > > > > >
> > > > > > These panels appear to route the I2C from the FT5406 to a STM32F103
> > > > > > MPU that then provides a different I2C slave interface to the 15pin
> > > > > > connector that I'm connected to. On that I2C interface I see an i2c
> > > > > > slave at 0x45 which is managed by the regulator driver Marek wrote
> > > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and there is also
> > > > > > an
> > > > > > i2c slave at 0x38 which I assumed was the FT5406 but I believe the
> > > > > > MPU
> > > > > > is perhaps obfuscating that touch data.
> > > > > >
> > > > > > Anyone have any ideas on how to make that touch controller useful?
> > > > >
> > > > > There should be nothing unusual. 0x38 is the EDT touch controller.
> > > > > Starting with the Raspberry Pi OS Bullseye release, we're now using
> > > > > the panel directly from DRM rather than through the firmware. That's
> > > > > based on the branch at
> > > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > > >
> > > >
> > > > Dave,
> > > >
> > > > That sounds like the driver that made it into mainline with Eric's
> > > > commit 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
> > > > Touchscreen."). I looked there but that driver just deals with the DSI
> > > > and not with touch.
> > >
> > > No, we've reverted away from that driver as it exposes no regulator
> > > framework either, so again the touch element loses power.
> > >
> > > > > I also added polling support to edt-ft5x04.c.
> > > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all of which are
> > > > > in /arch/arm/boot/dts/overlays
> > > >
> > > > It doesn't look like you ever submitted your edt-ft5x04 polling mode
> > > > support upstream. I saw another series to add polling support
> > > > submitted by Nicolas back in 2019 but was never followed up on
> > > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187&archive=both).
> > >
> > > No I haven't as it's been crazy trying to get this lot to work under
> > > KMS at all over the last couple of months.
> > >
> > > > I have updated Nicolas' patch with the changes requested and am happy
> > > > to submit it upstream. The benefit of his patch is that it uses a dt
> > > > binding for the polling interval. I'm happy to submit this upstream.
> > >
> > > I hadn't seen Nicolas' patches, hence implementing it myself.
> > >
> > > If you've implemented the requested changes, could you check that the
> > > polling rate is as expected? We were seeing that the input framework
> > > wasn't delivering the requested poll rate when CONFIG_HZ=100 is
> > > defined in the config. I must confess that I haven't checked it on my
> > > current patch, but it was on my list of things to do.
> > > There was a report that "bd88ce25335d Input: raspberrypi-ts - switch
> > > to using polled mode of input devices" dropped the polling rate from
> > > the desired 60Hz in switching to that framework.
> >
> > Ok, I'll make a note to test that and submit it.
> >
> > >
> > > > >
> > > > > The main issue I had was configuring the regulator framework
> > > > > appropriately to allow the touch controller power to be separate from
> > > > > the bridge power. Without that if DRM powered down the panel it killed
> > > > > the touch controller too, and the touch driver never reinitialised
> > > > > itself.
> > > >
> > > > I'm using the same drivers/regulator/rpi-panel-attiny-regulator.c
> > > > regulator driver from mainline that Marek added as the power-supply
> > > > for the panel as well as the backlight controller. It looks like the
> > > > version in the rpi-5.10.y has several patches on top of it so I'll
> > > > take a look at those differences to see if it may be affecting the
> > > > touchscreen controller. It's really strange to me that
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On Fri, Dec 10, 2021 at 9:25 AM Guilherme G. Piccoli wrote: > > On 10/12/2021 11:16, Alex Deucher wrote:> [...] > > Why not just reload the driver after kexec? > > > > Alex > > Because the original issue is the kdump case, and we want a very very > tiny kernel - also, the crash originally could have been caused by > amdgpu itself, so if it's a GPU issue, we don't want to mess with that > in kdump. And I confess I tried modprobe amdgpu after a kdump, no > success - kdump won't call shutdown handlers, so GPU will be in a > "rogue" state... > > My question was about regular kexec because it's much simpler usually, > we can do whatever we want there. My line of thought was: if I make it > work in regular kexec with a simple framebuffer, I might be able to get > it working on kdump heheh > Well if the GPU is hung, I'm not sure if you'll be able to get back the display environment without a GPU reset and once you do that, you've lost any state you might have been trying to preserve. Alex
Re: Reuse framebuffer after a kexec (amdgpu / efifb)
On Fri, Dec 10, 2021 at 10:24 AM Guilherme G. Piccoli wrote: > > On 10/12/2021 12:13, Christian König wrote: > > [...] > > How about issuing a PCIe reset and re-initializing the ASIC with just > > the VBIOS? > > > > That should be pretty straightforward I think. > > > > Christian. > > > Thanks Christian, that'd be perfect! Is it feasible? Per Alex comment, > we'd need to run atombios commands to reprogram the timings, display > info, etc...like a small driver would do, a full init. > You need the equivalent of a GOP driver or a full GPU driver. I think it would be less effort to just fix up any problems amdgpu has when trying to load after the crash than to write a new mini driver. By the time you add everything you'd need, you'd be pretty close to a full GPU driver. > Also, what kind of PCIe reset is recommended for this adapter? Like a > hot reset, powering-off/re-power, FLR or that MODE2 reset present in > amdgpu code? Remembering this is an APU device. You'd need to issue the relevant device specific reset sequence. It would be a mode2 reset on vangogh, but varies on other asics. It would probably be easiest to just fix up the logic in amdgpu to detect bad GPU state on driver load and do a GPU reset before driver init. We already have the logic in place for some dGPUs, but APUs only recently got full GPU reset support due to architectural limitations and hardware bugs. Alex
[PATCH v2 0/4] drm: exynos: dsi: Convert drm bridge
Updated series about drm bridge conversion of exynos dsi. Patch 1: panel checker Patch 2: panel_bridge API Patch 3: Bridge conversion Patch 4: Atomic functions [1] https://patchwork.kernel.org/project/dri-devel/cover/20211122070633.89219-1-ja...@amarulasolutions.com/ Any inputs? Jagan. Jagan Teki (4): drm: exynos: dsi: Check panel for panel helpers drm: exynos: dsi: Use drm panel_bridge API drm: exynos: dsi: Convert to bridge driver drm: exynos: dsi: Switch to atomic funcs drivers/gpu/drm/exynos/exynos_drm_dsi.c | 208 ++-- 1 file changed, 51 insertions(+), 157 deletions(-) -- 2.25.1
[PATCH v2 1/4] drm: exynos: dsi: Check panel for panel helpers
Trigger the panel operation helpers only if host found the panel.
Add check.
Signed-off-by: Jagan Teki
---
Changes for v2:
- new patch
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8d137857818c..0bb44e476633 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1439,7 +1439,8 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
- drm_panel_disable(dsi->panel);
+ if (dsi->panel)
+ drm_panel_disable(dsi->panel);
list_for_each_entry_reverse(iter, &dsi->bridge_chain, chain_node) {
if (iter->funcs->disable)
@@ -1447,7 +1448,8 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
}
exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
+ if (dsi->panel)
+ drm_panel_unprepare(dsi->panel);
list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
if (iter->funcs->post_disable)
--
2.25.1
[PATCH v2 2/4] drm: exynos: dsi: Use drm panel_bridge API
Replace the manual panel handling code by a drm panel_bridge via
devm_drm_of_get_bridge().
Adding panel_bridge handling,
- Drops drm_connector and related operations as drm_bridge_attach
creates connector during attachment.
- Drops panel pointer and iterate the bridge, so-that it can operate
the normal bridge and panel_bridge in constitutive callbacks.
This simplifies the driver and allows all components in the display
pipeline to be treated as bridges.
Signed-off-by: Jagan Teki
---
Changes for v2:
- new patch
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 147 +++-
1 file changed, 14 insertions(+), 133 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 0bb44e476633..8c6f7ac82822 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,8 +254,6 @@ struct exynos_dsi_driver_data {
struct exynos_dsi {
struct drm_encoder encoder;
struct mipi_dsi_host dsi_host;
- struct drm_connector connector;
- struct drm_panel *panel;
struct list_head bridge_chain;
struct drm_bridge *out_bridge;
struct device *dev;
@@ -285,7 +283,6 @@ struct exynos_dsi {
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
-#define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
{
@@ -1391,42 +1388,21 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
dsi->state |= DSIM_STATE_ENABLED;
- if (dsi->panel) {
- ret = drm_panel_prepare(dsi->panel);
- if (ret < 0)
- goto err_put_sync;
- } else {
- list_for_each_entry_reverse(iter, &dsi->bridge_chain,
- chain_node) {
- if (iter->funcs->pre_enable)
- iter->funcs->pre_enable(iter);
- }
+ list_for_each_entry_reverse(iter, &dsi->bridge_chain, chain_node) {
+ if (iter->funcs->pre_enable)
+ iter->funcs->pre_enable(iter);
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
- if (dsi->panel) {
- ret = drm_panel_enable(dsi->panel);
- if (ret < 0)
- goto err_display_disable;
- } else {
- list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
- if (iter->funcs->enable)
- iter->funcs->enable(iter);
- }
+ list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
+ if (iter->funcs->enable)
+ iter->funcs->enable(iter);
}
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
return;
-
-err_display_disable:
- exynos_dsi_set_display_enable(dsi, false);
- drm_panel_unprepare(dsi->panel);
-
-err_put_sync:
- dsi->state &= ~DSIM_STATE_ENABLED;
- pm_runtime_put(dsi->dev);
}
static void exynos_dsi_disable(struct drm_encoder *encoder)
@@ -1439,17 +1415,12 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
- if (dsi->panel)
- drm_panel_disable(dsi->panel);
-
list_for_each_entry_reverse(iter, &dsi->bridge_chain, chain_node) {
if (iter->funcs->disable)
iter->funcs->disable(iter);
}
exynos_dsi_set_display_enable(dsi, false);
- if (dsi->panel)
- drm_panel_unprepare(dsi->panel);
list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
if (iter->funcs->post_disable)
@@ -1460,70 +1431,6 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
pm_runtime_put_sync(dsi->dev);
}
-static enum drm_connector_status
-exynos_dsi_detect(struct drm_connector *connector, bool force)
-{
- return connector->status;
-}
-
-static void exynos_dsi_connector_destroy(struct drm_connector *connector)
-{
- drm_connector_unregister(connector);
- drm_connector_cleanup(connector);
- connector->dev = NULL;
-}
-
-static const struct drm_connector_funcs exynos_dsi_connector_funcs = {
- .detect = exynos_dsi_detect,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = exynos_dsi_connector_destroy,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static int exynos_dsi_get_modes(struct drm_connector *connector)
-{
- struct exynos_dsi *dsi = connector_to_dsi(connector);
-
- if (dsi->panel)
- return drm_panel_get_modes(dsi->panel, connector);
-
- return 0;
-}
[PATCH v2 3/4] drm: exynos: dsi: Convert to bridge driver
Convert the encoders to bridge drivers in order to standardize on
a single API with built-in dumb encoder support for compatibility
with existing component drivers.
Driver bridge conversion will help to reuse the same bridge on
different platforms as exynos dsi driver can be used as a Samsung
DSIM and use it for i.MX8MM platform.
Bridge conversion,
- Drops drm_encoder_helper_funcs, bridge_chain.
- Adds drm_bridge_funcs and register a drm bridge.
Convert it.
Signed-off-by: Jagan Teki
---
Changes for v2:
- drop bridge_chain
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 84 +
1 file changed, 45 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8c6f7ac82822..37ad94b563c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,7 +254,7 @@ struct exynos_dsi_driver_data {
struct exynos_dsi {
struct drm_encoder encoder;
struct mipi_dsi_host dsi_host;
- struct list_head bridge_chain;
+ struct drm_bridge bridge;
struct drm_bridge *out_bridge;
struct device *dev;
@@ -284,9 +284,9 @@ struct exynos_dsi {
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
-static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct exynos_dsi *bridge_to_dsi(struct drm_bridge *b)
{
- return container_of(e, struct exynos_dsi, encoder);
+ return container_of(b, struct exynos_dsi, bridge);
}
enum reg_idx {
@@ -877,9 +877,10 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
return 0;
}
-static void exynos_dsi_set_display_mode(struct exynos_dsi *dsi)
+static void exynos_dsi_set_display_mode(struct drm_bridge *bridge)
{
- struct drm_display_mode *m = &dsi->encoder.crtc->state->adjusted_mode;
+ struct exynos_dsi *dsi = bridge_to_dsi(bridge);
+ struct drm_display_mode *m =
&bridge->encoder->crtc->state->adjusted_mode;
unsigned int num_bits_resol = dsi->driver_data->num_bits_resol;
u32 reg;
@@ -1371,10 +1372,10 @@ static void exynos_dsi_unregister_te_irq(struct
exynos_dsi *dsi)
}
}
-static void exynos_dsi_enable(struct drm_encoder *encoder)
+static void exynos_dsi_enable(struct drm_bridge *bridge)
{
- struct exynos_dsi *dsi = encoder_to_dsi(encoder);
- struct drm_bridge *iter;
+ struct exynos_dsi *dsi = bridge_to_dsi(bridge);
+ const struct drm_bridge_funcs *funcs = dsi->out_bridge->funcs;
int ret;
if (dsi->state & DSIM_STATE_ENABLED)
@@ -1388,52 +1389,53 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
dsi->state |= DSIM_STATE_ENABLED;
- list_for_each_entry_reverse(iter, &dsi->bridge_chain, chain_node) {
- if (iter->funcs->pre_enable)
- iter->funcs->pre_enable(iter);
- }
+ if (dsi->out_bridge)
+ funcs->pre_enable(dsi->out_bridge);
- exynos_dsi_set_display_mode(dsi);
+ exynos_dsi_set_display_mode(bridge);
exynos_dsi_set_display_enable(dsi, true);
- list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
- if (iter->funcs->enable)
- iter->funcs->enable(iter);
- }
+ if (dsi->out_bridge)
+ funcs->enable(dsi->out_bridge);
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
return;
}
-static void exynos_dsi_disable(struct drm_encoder *encoder)
+static void exynos_dsi_disable(struct drm_bridge *bridge)
{
- struct exynos_dsi *dsi = encoder_to_dsi(encoder);
- struct drm_bridge *iter;
+ struct exynos_dsi *dsi = bridge_to_dsi(bridge);
+ const struct drm_bridge_funcs *funcs = dsi->out_bridge->funcs;
if (!(dsi->state & DSIM_STATE_ENABLED))
return;
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
- list_for_each_entry_reverse(iter, &dsi->bridge_chain, chain_node) {
- if (iter->funcs->disable)
- iter->funcs->disable(iter);
- }
+ if (dsi->out_bridge)
+ funcs->disable(dsi->out_bridge);
exynos_dsi_set_display_enable(dsi, false);
- list_for_each_entry(iter, &dsi->bridge_chain, chain_node) {
- if (iter->funcs->post_disable)
- iter->funcs->post_disable(iter);
- }
+ if (dsi->out_bridge)
+ funcs->post_disable(dsi->out_bridge);
dsi->state &= ~DSIM_STATE_ENABLED;
pm_runtime_put_sync(dsi->dev);
}
-static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs =
{
- .enable = exynos_dsi_enable,
- .disable = exynos_dsi_disable,
+static int exynos_dsi_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct exynos_dsi *dsi = bridge_to_dsi(bridge);
+
+ return drm_bridg
[PATCH v2 4/4] drm: exynos: dsi: Switch to atomic funcs
The new support drm bridges are moving towards atomic functions.
Replace atomic version of functions to continue the transition
to the atomic API.
Signed-off-by: Jagan Teki
---
Changes for v2:
- new patch
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 37ad94b563c4..f2c12a356952 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1372,7 +1372,8 @@ static void exynos_dsi_unregister_te_irq(struct
exynos_dsi *dsi)
}
}
-static void exynos_dsi_enable(struct drm_bridge *bridge)
+static void exynos_dsi_atomic_enable(struct drm_bridge *bridge,
+struct drm_bridge_state *old_bridge_state)
{
struct exynos_dsi *dsi = bridge_to_dsi(bridge);
const struct drm_bridge_funcs *funcs = dsi->out_bridge->funcs;
@@ -1390,19 +1391,20 @@ static void exynos_dsi_enable(struct drm_bridge *bridge)
dsi->state |= DSIM_STATE_ENABLED;
if (dsi->out_bridge)
- funcs->pre_enable(dsi->out_bridge);
+ funcs->atomic_pre_enable(dsi->out_bridge, old_bridge_state);
exynos_dsi_set_display_mode(bridge);
exynos_dsi_set_display_enable(dsi, true);
if (dsi->out_bridge)
- funcs->enable(dsi->out_bridge);
+ funcs->atomic_enable(dsi->out_bridge, old_bridge_state);
dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
return;
}
-static void exynos_dsi_disable(struct drm_bridge *bridge)
+static void exynos_dsi_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct exynos_dsi *dsi = bridge_to_dsi(bridge);
const struct drm_bridge_funcs *funcs = dsi->out_bridge->funcs;
@@ -1413,12 +1415,12 @@ static void exynos_dsi_disable(struct drm_bridge
*bridge)
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
if (dsi->out_bridge)
- funcs->disable(dsi->out_bridge);
+ funcs->atomic_disable(dsi->out_bridge, old_bridge_state);
exynos_dsi_set_display_enable(dsi, false);
if (dsi->out_bridge)
- funcs->post_disable(dsi->out_bridge);
+ funcs->atomic_post_disable(dsi->out_bridge, old_bridge_state);
dsi->state &= ~DSIM_STATE_ENABLED;
pm_runtime_put_sync(dsi->dev);
@@ -1433,8 +1435,11 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
}
static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
- .enable = exynos_dsi_enable,
- .disable= exynos_dsi_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_enable = exynos_dsi_atomic_enable,
+ .atomic_disable = exynos_dsi_atomic_disable,
.attach = exynos_dsi_attach,
};
@@ -1605,7 +1610,7 @@ static void exynos_dsi_unbind(struct device *dev, struct
device *master,
{
struct exynos_dsi *dsi = dev_get_drvdata(dev);
- exynos_dsi_disable(&dsi->bridge);
+ exynos_dsi_atomic_disable(&dsi->bridge, NULL);
mipi_dsi_host_unregister(&dsi->dsi_host);
}
--
2.25.1
Re: RPI 7" display touch controller
On Fri, Dec 10, 2021 at 10:41 AM Dave Stevenson
wrote:
>
> On Fri, 10 Dec 2021 at 18:20, Tim Harvey wrote:
> >
> > On Thu, Nov 18, 2021 at 12:52 PM Tim Harvey wrote:
> > >
> > > On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
> > > wrote:
> > > >
> > > > On Thu, 18 Nov 2021 at 17:36, Tim Harvey wrote:
> > > > >
> > > > > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > > > > wrote:
> > > > > >
> > > > > > Hi Tim
> > > > > >
> > > > > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey
> > > > > > wrote:
> > > > > > >
> > > > > > > Greetings,
> > > > > > >
> > > > > > > I'm trying to get a RPI 7" touchscreen display working on an
> > > > > > > IMX8MM
> > > > > > > board and while I've been able to get the MIPI DSI display and
> > > > > > > backlight working I still can't seem to figure out the touch
> > > > > > > controller.
> > > > > > >
> > > > > > > It's supposed to have an FT5406 controller on it without an
> > > > > > > interrupt
> > > > > > > so I added polling support drivers/input/touchscreen/edt-ft5x06.c
> > > > > > > which I was able to verify using another touchscreen with that
> > > > > > > controller but when reading data from the FT5406 on the RPI
> > > > > > > controller
> > > > > > > the data does not make sense.
> > > > > > >
> > > > > > > These panels appear to route the I2C from the FT5406 to a
> > > > > > > STM32F103
> > > > > > > MPU that then provides a different I2C slave interface to the
> > > > > > > 15pin
> > > > > > > connector that I'm connected to. On that I2C interface I see an
> > > > > > > i2c
> > > > > > > slave at 0x45 which is managed by the regulator driver Marek wrote
> > > > > > > (drivers/regulator/rpi-panel-attiny-regulator.c) and there is
> > > > > > > also an
> > > > > > > i2c slave at 0x38 which I assumed was the FT5406 but I believe
> > > > > > > the MPU
> > > > > > > is perhaps obfuscating that touch data.
> > > > > > >
> > > > > > > Anyone have any ideas on how to make that touch controller useful?
> > > > > >
> > > > > > There should be nothing unusual. 0x38 is the EDT touch controller.
> > > > > > Starting with the Raspberry Pi OS Bullseye release, we're now using
> > > > > > the panel directly from DRM rather than through the firmware. That's
> > > > > > based on the branch at
> > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/
> > > > > >
> > > > >
> > > > > Dave,
> > > > >
> > > > > That sounds like the driver that made it into mainline with Eric's
> > > > > commit 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
> > > > > Touchscreen."). I looked there but that driver just deals with the DSI
> > > > > and not with touch.
> > > >
> > > > No, we've reverted away from that driver as it exposes no regulator
> > > > framework either, so again the touch element loses power.
> > > >
> > > > > > I also added polling support to edt-ft5x04.c.
> > > > > > For DT, it uses a combination of the overlays vc4-kms-v3d,
> > > > > > vc4-kms-dsi-7inch, and that includes edt-ft5406.dtsi, all of which
> > > > > > are
> > > > > > in /arch/arm/boot/dts/overlays
> > > > >
> > > > > It doesn't look like you ever submitted your edt-ft5x04 polling mode
> > > > > support upstream. I saw another series to add polling support
> > > > > submitted by Nicolas back in 2019 but was never followed up on
> > > > > (https://patchwork.kernel.org/project/linux-input/list/?series=112187&archive=both).
> > > >
> > > > No I haven't as it's been crazy trying to get this lot to work under
> > > > KMS at all over the last couple of months.
> > > >
> > > > > I have updated Nicolas' patch with the changes requested and am happy
> > > > > to submit it upstream. The benefit of his patch is that it uses a dt
> > > > > binding for the polling interval. I'm happy to submit this upstream.
> > > >
> > > > I hadn't seen Nicolas' patches, hence implementing it myself.
> > > >
> > > > If you've implemented the requested changes, could you check that the
> > > > polling rate is as expected? We were seeing that the input framework
> > > > wasn't delivering the requested poll rate when CONFIG_HZ=100 is
> > > > defined in the config. I must confess that I haven't checked it on my
> > > > current patch, but it was on my list of things to do.
> > > > There was a report that "bd88ce25335d Input: raspberrypi-ts - switch
> > > > to using polled mode of input devices" dropped the polling rate from
> > > > the desired 60Hz in switching to that framework.
> > >
> > > Ok, I'll make a note to test that and submit it.
> > >
> > > >
> > > > > >
> > > > > > The main issue I had was configuring the regulator framework
> > > > > > appropriately to allow the touch controller power to be separate
> > > > > > from
> > > > > > the bridge power. Without that if DRM powered down the panel it
> > > > > > killed
> > > > > > the touch controller too, and the touch driver never reinitialised
> > > > > > itself.
> > > > >
> > > > > I'm using the same drivers/regulator/rpi-panel-attiny-regulator.c
> > > >
