Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature
[PATCH] drm/radeon: Call mmiowb() at the end of radeon_ring_commit()
Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of
mmiowb()") remove all mmiowb() in drivers, but it says:
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
spin_unlock(). However, pairing each mmiowb() removal in this patch with
the corresponding call to spin_unlock() is not at all trivial, so there
is a small chance that this change may regress any drivers incorrectly
relying on mmiowb() to order MMIO writes between CPUs using lock-free
synchronisation."
The mmio in radeon_ring_commit() is protected by a mutex rather than a
spinlock, but in the mutex fastpath it behaves similar to spinlock and
need a mmiowb() to make sure the wptr is up-to-date for hardware.
Without this, we get such an error when run 'glxgears' on weak ordering
architectures such as LoongArch:
radeon :04:00.0: ring 0 stalled for more than 10324msec
radeon :04:00.0: ring 3 stalled for more than 10240msec
radeon :04:00.0: GPU lockup (current fence id 0x0001f412 last fence
id 0x0001f414 on ring 3)
radeon :04:00.0: GPU lockup (current fence id 0xf940 last fence
id 0xf941 on ring 0)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon :04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
Cc: sta...@vger.kernel.org
Signed-off-by: Tianyang Zhang
Signed-off-by: Huacai Chen
---
drivers/gpu/drm/radeon/radeon_ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 38048593bb4a..d461dc85d820 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -183,6 +183,7 @@ void radeon_ring_commit(struct radeon_device *rdev, struct
radeon_ring *ring,
if (hdp_flush && rdev->asic->mmio_hdp_flush)
rdev->asic->mmio_hdp_flush(rdev);
radeon_ring_set_wptr(rdev, ring);
+ mmiowb(); /* Make sure wptr is up-to-date for hw */
}
/**
--
2.43.0
Re: [PATCH 1/6] drm/bridge: aux-hpd: fix OF node leaks
On Mon, Feb 19, 2024 at 06:48:30PM +0100, Markus Elfring wrote:
> > The two device node references taken during allocation need to be
> > dropped when the auxiliary device is freed.
> …
> > +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> …
> > @@ -74,6 +75,8 @@ struct device *drm_dp_hpd_bridge_register(struct device
> > *parent,
> >
> > ret = auxiliary_device_init(adev);
> > if (ret) {
> > + of_node_put(adev->dev.platform_data);
> > + of_node_put(adev->dev.of_node);
> > ida_free(&drm_aux_hpd_bridge_ida, adev->id);
> > kfree(adev);
> > return ERR_PTR(ret);
>
> The last two statements are also used in a previous if branch.
> https://elixir.bootlin.com/linux/v6.8-rc5/source/drivers/gpu/drm/bridge/aux-hpd-bridge.c#L63
>
> How do you think about to avoid such a bit of duplicate source code
> by adding a label here?
No, the current code is fine and what you are suggesting is in any case
unrelated to this fix.
If this function ever grows a third error path like that, I too would
consider it however.
Johan
Re: [PATCH 3/6] drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
- Correct code indent. [Jani]
--v3:
- Update definition names for AS SDP which are starting from
HSW, as these defines are applicable for ADLP+.(Ankit)
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_dp.c | 95 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 12 ++-
drivers/gpu/drm/i915/i915_reg.h | 8 ++
include/drm/display/drm_dp.h | 2 +-
include/drm/display/drm_dp_helper.h | 2 +
5 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50..d68fb9d45054 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -95,7 +95,6 @@
#define INTEL_DP_RESOLUTION_STANDARD (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
#define INTEL_DP_RESOLUTION_FAILSAFE (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
-
/* Constants for DP DSC configurations */
static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
@@ -4089,6 +4088,34 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
return false;
}
+static ssize_t intel_dp_as_sdp_pack(const struct drm_dp_as_sdp *as_sdp,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /* Prepare AS (Adaptive Sync) SDP Header */
+ sdp->sdp_header.HB0 = 0;
+ sdp->sdp_header.HB1 = as_sdp->sdp_type;
+ sdp->sdp_header.HB2 = 0x02;
+ sdp->sdp_header.HB3 = as_sdp->length;
+
+ /* Fill AS (Adaptive Sync) SDP Payload */
+ sdp->db[1] = 0x0;
+ sdp->db[1] = as_sdp->vtotal & 0xFF;
+ sdp->db[2] = (as_sdp->vtotal >> 8) & 0xF;
+ sdp->db[3] = 0x0;
+ sdp->db[4] = 0x0;
+ sdp->db[7] = 0x0;
+ sdp->db[8] = 0x0;
+
+ return length;
+}
+
static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
struct dp_sdp *sdp, size_t size)
{
@@ -4256,6 +4283,10 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
&crtc_state->infoframes.drm.drm,
&sdp,
sizeof(sdp));
break;
+ case DP_SDP_ADAPTIVE_SYNC:
+ len = intel_dp_as_sdp_pack(&crtc_state->infoframes.as_sdp, &sdp,
+ sizeof(sdp));
+ break;
default:
MISSING_CASE(type);
return;
@@ -4276,7 +4307,8 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 dip_enable = VIDEO_DIP_ENABLE_AVI_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW |
-VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK;
+VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK |
+VIDEO_DIP_ENABLE_ADAPTIVE_SYNC;
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
@@ -4298,6 +4330,40 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static
+int intel_dp_as_sdp_unpack(struct drm_dp_as_sdp *as_sdp,
+ const void *buffer, size_t size)
+{
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ memset(as_sdp, 0, sizeof(*as_sdp));
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != DP_SDP_ADAPTIVE_SYNC)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB2 != 0x02)
+ return -EINVAL;
+
+ if ((sdp->sdp_header.HB3 & 0x3F) != 9)
+ return -EINVAL;
+
+ if ((sdp->db[0] & AS_SDP_OP_MODE) != 0x0)
+ return -EINVAL;
+
+ as_sdp->vtotal = ((u64)sdp->db[2] << 32) | (u64)sdp->db[1];
+ as_sdp->target_rr = 0;
+ as_sdp->duration_incr_ms = 0;
+ as_sdp->duration_decr_ms = 0;
+
+ return 0;
+}
+
static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp *vsc,
const void *buffer, size_t size)
{
@@ -4368,6 +4434,27 @@ static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp
*vsc,
return 0;
}
Re: [PATCH 6/6] drm/i915/display: Read/Write AS sdp only when sink/source has enabled
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Write/Read Adaptive sync SDP only when Sink and Source is enabled
for the same. Also along with write TRANS_VRR_VSYNC values.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4
.../gpu/drm/i915/display/intel_display_device.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 15 +++
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
drivers/gpu/drm/i915/display/intel_vrr.c | 7 +++
5 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bea441590204..68cd49193d03 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3926,6 +3926,7 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
/* XXX: DSI transcoder paranoia */
if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
@@ -3972,6 +3973,9 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
intel_read_dp_sdp(encoder, pipe_config,
HDMI_PACKET_TYPE_GAMUT_METADATA);
intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
+ if (HAS_AS_SDP(dev_priv) && intel_dp_sink_as_sdp_supported(intel_dp))
+ intel_read_dp_sdp(encoder, pipe_config, DP_SDP_ADAPTIVE_SYNC);
+
intel_audio_codec_get_config(encoder, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h b/drivers/gpu/drm/i915/display/intel_display_device.h
index fe4268813786..6399fbc6c738 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -68,6 +68,7 @@ struct drm_printer;
#define HAS_TRANSCODER(i915, trans)
((DISPLAY_RUNTIME_INFO(i915)->cpu_transcoder_mask & \
BIT(trans)) != 0)
#define HAS_VRR(i915) (DISPLAY_VER(i915) >= 11)
+#define HAS_AS_SDP(i915) (DISPLAY_VER(i915) >= 13)
#define INTEL_NUM_PIPES(i915)
(hweight8(DISPLAY_RUNTIME_INFO(i915)->pipe_mask))
#define I915_HAS_HOTPLUG(i915)
(DISPLAY_INFO(i915)->has_hotplug)
#define OVERLAY_NEEDS_PHYSICAL(i915)
(DISPLAY_INFO(i915)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0759266e7bfb..5bd99fa8f200 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -119,6 +119,17 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
return dig_port->base.type == INTEL_OUTPUT_EDP;
}
+bool
+intel_dp_sink_as_sdp_supported(struct intel_dp *intel_dp)
+{
+ u8 dpcd[DP_RECEIVER_CAP_SIZE];
+
+ if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd))
+ return -EIO;
+
This is already read in intel_dp->dpcd, we can use that.
+ return drm_dp_as_sdp_supported(&intel_dp->aux, dpcd);
+}
+
static void intel_dp_unset_edid(struct intel_dp *intel_dp);
/* Is link rate UHBR and thus 128b/132b? */
@@ -4330,6 +4341,7 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK |
VIDEO_DIP_ENABLE_ADAPTIVE_SYNC;
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
if (!enable && HAS_DSC(dev_priv))
@@ -4347,6 +4359,9 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state, DP_SDP_VSC);
+ if (HAS_AS_SDP(dev_priv) && intel_dp_sink_as_sdp_supported(intel_dp))
+ intel_write_dp_sdp(encoder, crtc_state, DP_SDP_ADAPTIVE_SYNC);
+
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
index 530cc97bc42f..09ab313af896 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -180,5 +180,6 @@ intel_dp_compute_config_link_bpp_limits(struct intel_dp
*intel_dp,
struct link_config_limits *limits);
void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_connector *connector);
+bool intel_dp_sink_as_sdp_supported(struct intel_dp *intel_dp);
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 2fa0004d00c7..86729e145991 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -192,6 +192,9 @@
Re: [PATCH] drm/v3d: Enable V3D to use different PAGE_SIZE
El lun, 19-02-2024 a las 10:00 -0300, Maíra Canal escribió: > Hi Iago, > > On 2/19/24 09:56, Iago Toral wrote: > > Hi Maíra, > > > > El mié, 14-02-2024 a las 16:34 -0300, Maíra Canal escribió: > > > Currently, the V3D driver uses PAGE_SHIFT over the assumption > > > that > > > PAGE_SHIFT = 12, as the PAGE_SIZE = 4KB. But, the RPi 5 is using > > > PAGE_SIZE = 16KB, so the MMU PAGE_SHIFT is different than the > > > system's > > > PAGE_SHIFT. > > > > > > Enable V3D to be used in system's with any PAGE_SIZE by making > > > sure > > > that > > > everything MMU-related uses the MMU page shift. > > > > > > Signed-off-by: Maíra Canal > > > --- > > > drivers/gpu/drm/v3d/v3d_bo.c | 12 ++-- > > > drivers/gpu/drm/v3d/v3d_debugfs.c | 2 +- > > > drivers/gpu/drm/v3d/v3d_drv.h | 2 ++ > > > drivers/gpu/drm/v3d/v3d_irq.c | 2 +- > > > drivers/gpu/drm/v3d/v3d_mmu.c | 2 -- > > > 5 files changed, 10 insertions(+), 10 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/v3d/v3d_bo.c > > > b/drivers/gpu/drm/v3d/v3d_bo.c > > > index 1bdfac8beafd..a07ede668cc1 100644 > > > --- a/drivers/gpu/drm/v3d/v3d_bo.c > > > +++ b/drivers/gpu/drm/v3d/v3d_bo.c > > > > I think we need the same change in v3d_get_bo_vaddr, no? > > No, that one uses the PAGE_SHIFT of the CPU, because > is in > the CPU. Ah, makes sense, thanks! Reviewed-by: Iago Toral Quiroga > > Best Regards, > - Maíra > > > > > Iago > > > > > @@ -40,7 +40,7 @@ void v3d_free_object(struct drm_gem_object > > > *obj) > > > > > > mutex_lock(&v3d->bo_lock); > > > v3d->bo_stats.num_allocated--; > > > - v3d->bo_stats.pages_allocated -= obj->size >> > > > PAGE_SHIFT; > > > + v3d->bo_stats.pages_allocated -= obj->size >> > > > V3D_MMU_PAGE_SHIFT; > > > mutex_unlock(&v3d->bo_lock); > > > > > > spin_lock(&v3d->mm_lock); > > > @@ -109,8 +109,8 @@ v3d_bo_create_finish(struct drm_gem_object > > > *obj) > > > * lifetime of the BO. > > > */ > > > ret = drm_mm_insert_node_generic(&v3d->mm, &bo->node, > > > - obj->size >> > > > PAGE_SHIFT, > > > - GMP_GRANULARITY >> > > > PAGE_SHIFT, 0, 0); > > > + obj->size >> > > > V3D_MMU_PAGE_SHIFT, > > > + GMP_GRANULARITY >> > > > V3D_MMU_PAGE_SHIFT, 0, 0); > > > spin_unlock(&v3d->mm_lock); > > > if (ret) > > > return ret; > > > @@ -118,7 +118,7 @@ v3d_bo_create_finish(struct drm_gem_object > > > *obj) > > > /* Track stats for /debug/dri/n/bo_stats. */ > > > mutex_lock(&v3d->bo_lock); > > > v3d->bo_stats.num_allocated++; > > > - v3d->bo_stats.pages_allocated += obj->size >> > > > PAGE_SHIFT; > > > + v3d->bo_stats.pages_allocated += obj->size >> > > > V3D_MMU_PAGE_SHIFT; > > > mutex_unlock(&v3d->bo_lock); > > > > > > v3d_mmu_insert_ptes(bo); > > > @@ -201,7 +201,7 @@ int v3d_create_bo_ioctl(struct drm_device > > > *dev, > > > void *data, > > > if (IS_ERR(bo)) > > > return PTR_ERR(bo); > > > > > > - args->offset = bo->node.start << PAGE_SHIFT; > > > + args->offset = bo->node.start << V3D_MMU_PAGE_SHIFT; > > > > > > ret = drm_gem_handle_create(file_priv, &bo->base.base, > > > &args->handle); > > > drm_gem_object_put(&bo->base.base); > > > @@ -246,7 +246,7 @@ int v3d_get_bo_offset_ioctl(struct drm_device > > > *dev, void *data, > > > } > > > bo = to_v3d_bo(gem_obj); > > > > > > - args->offset = bo->node.start << PAGE_SHIFT; > > > + args->offset = bo->node.start << V3D_MMU_PAGE_SHIFT; > > > > > > drm_gem_object_put(gem_obj); > > > return 0; > > > diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c > > > b/drivers/gpu/drm/v3d/v3d_debugfs.c > > > index dc3cf708d02e..19e3ee7ac897 100644 > > > --- a/drivers/gpu/drm/v3d/v3d_debugfs.c > > > +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c > > > @@ -219,7 +219,7 @@ static int v3d_debugfs_bo_stats(struct > > > seq_file > > > *m, void *unused) > > > seq_printf(m, "allocated bos: %d\n", > > > v3d->bo_stats.num_allocated); > > > seq_printf(m, "allocated bo size (kb): %ld\n", > > > - (long)v3d->bo_stats.pages_allocated << > > > (PAGE_SHIFT - 10)); > > > + (long)v3d->bo_stats.pages_allocated << > > > (V3D_MMU_PAGE_SHIFT - 10)); > > > mutex_unlock(&v3d->bo_lock); > > > > > > return 0; > > > diff --git a/drivers/gpu/drm/v3d/v3d_drv.h > > > b/drivers/gpu/drm/v3d/v3d_drv.h > > > index 3c7d58866570..1950c723dde1 100644 > > > --- a/drivers/gpu/drm/v3d/v3d_drv.h > > > +++ b/drivers/gpu/drm/v3d/v3d_drv.h > > > @@ -19,6 +19,8 @@ struct reset_control; > > > > > > #define GMP_GRANULARITY (128 * 1024) > > > > > > +#define V3D_MMU_PAGE_SHIFT 12 > > > + > > > #define V3D_MAX_QUEUES (V3D_CPU + 1) > > > > > > static in
Re: [PATCH 5/6] drm/i915/display: Compute vrr_vsync params
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Compute vrr_vsync_start/end which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.
--v2:
- Update, VSYNC_START/END macros to VRR_VSYNC_START/END.(Ankit)
- Update bit fields of VRR_VSYNC_START/END.(Ankit)
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_vrr.c | 7 +++
drivers/gpu/drm/i915/i915_reg.h| 11 +++
3 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index a6991bc3f07b..015ed846b896 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1414,6 +1414,7 @@ struct intel_crtc_state {
bool enable, in_range;
u8 pipeline_full;
u16 flipline, vmin, vmax, guardband;
+ u32 vsync_end, vsync_start;
} vrr;
/* Stream Splitter for eDP MSO */
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 5d905f932cb4..2fa0004d00c7 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -149,6 +149,13 @@ intel_vrr_compute_config(struct intel_crtc_state
*crtc_state,
crtc_state->vrr.flipline = crtc_state->vrr.vmin + 1;
+ crtc_state->vrr.vsync_start =
+ (crtc_state->hw.adjusted_mode.crtc_vtotal -
+
VRR_VSYNC_START(crtc_state->hw.adjusted_mode.vsync_start));
+ crtc_state->vrr.vsync_end =
+ (crtc_state->hw.adjusted_mode.crtc_vtotal -
+ (VRR_VSYNC_END(crtc_state->hw.adjusted_mode.vsync_end)
>> 16));
+
/*
* For XE_LPD+, we use guardband and pipeline override
* is deprecated.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c02ea07af4c2..f73e95b18819 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1955,6 +1955,10 @@
#define VSYNC_END(vsync_end)REG_FIELD_PREP(VSYNC_END_MASK,
(vsync_end))
#define VSYNC_START_MASKREG_GENMASK(15, 0)
#define VSYNC_START(vsync_start)REG_FIELD_PREP(VSYNC_START_MASK,
(vsync_start))
+#define VSYNC_END_MASK REG_GENMASK(31, 16)
+#define VSYNC_END(vsync_end) REG_FIELD_PREP(VSYNC_END_MASK,
(vsync_end))
+#define VSYNC_START_MASK REG_GENMASK(15, 0)
+#define VSYNC_START(vsync_start) REG_FIELD_PREP(VSYNC_START_MASK,
(vsync_start))
I think this is typo, we really dont need to touch these.
#define _TRANS_EXITLINE_A 0x60018
#define _PIPEASRC 0x6001c
#define PIPESRC_WIDTH_MASK REG_GENMASK(31, 16)
@@ -2007,7 +2011,9 @@
#define _TRANS_VRR_CTL_B 0x61420
#define _TRANS_VRR_CTL_C 0x62420
#define _TRANS_VRR_CTL_D 0x63420
+#define _TRANS_VRR_VSYNC_A 0x60078
#define TRANS_VRR_CTL(trans) _MMIO_TRANS2(trans,
_TRANS_VRR_CTL_A)
+#define TRANS_VRR_VSYNC(trans) _MMIO_TRANS2(trans,
_TRANS_VRR_VSYNC_A)
#define VRR_CTL_VRR_ENABLE REG_BIT(31)
#define VRR_CTL_IGN_MAX_SHIFT REG_BIT(30)
#define VRR_CTL_FLIP_LINE_ENREG_BIT(29)
@@ -2087,6 +2093,11 @@
#define TRANS_VRR_STATUS2(trans) _MMIO_TRANS2(trans,
_TRANS_VRR_STATUS2_A)
#define VRR_STATUS2_VERT_LN_CNT_MASKREG_GENMASK(19, 0)
+#define VRR_VSYNC_END_MASK REG_GENMASK(28, 16)
+#define VRR_VSYNC_END(vsync_end) REG_FIELD_PREP(VSYNC_END_MASK,
(vsync_end))
+#define VRR_VSYNC_START_MASK REG_GENMASK(12, 0)
+#define VRR_VSYNC_START(vsync_start) REG_FIELD_PREP(VSYNC_START_MASK,
(vsync_start))
Here too, we need to use the correct VRR_VSYNC_STAR/END_MASK
Regards,
Ankit
+
#define _TRANS_PUSH_A 0x60A70
#define _TRANS_PUSH_B 0x61A70
#define _TRANS_PUSH_C 0x62A70
Re: [PATCH 4/6] drm/i915/display: Compute and Enable AS SDP
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add necessary functions definitions to enable
and compute AS SDP data. The new `intel_dp_compute_as_sdp`
function computes AS SDP values based on the display
configuration, ensuring proper handling of Variable Refresh
Rate (VRR).
--v2:
- Add DP_SDP_ADAPTIVE_SYNC to infoframe_type_to_idx().[Ankit]
- separate patch for intel_read/write_dp_sdp [Ankit].
- _HSW_VIDEO_DIP_ASYNC_DATA_A should be from ADL onward [Ankit]
- To fix indentation [Ankit]
--v3:
- Add VIDEO_DIP_ENABLE_AS_HSW flag to intel_dp_set_infoframes.
--v4:
- Add HAS_VRR check before write as sdp.
--v5:
- Add missed HAS_VRR check before read as sdp.
--v6:
Use Adaptive Sync sink status, which can be
used as a check for read/write sdp. (Ankit)
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_dp.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d68fb9d45054..0759266e7bfb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2617,6 +2617,25 @@ static void intel_dp_compute_vsc_colorimetry(const
struct intel_crtc_state *crtc
vsc->content_type = DP_CONTENT_TYPE_NOT_DEFINED;
}
+static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
+ struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct drm_dp_as_sdp *as_sdp = &crtc_state->infoframes.as_sdp;
+ struct intel_connector *connector = intel_dp->attached_connector;
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->hw.adjusted_mode;
+ int vrefresh = drm_mode_vrefresh(adjusted_mode);
+
+ if (!intel_vrr_is_in_range(connector, vrefresh))
+ return;
I think there should be 2 variables in crtc_state->vrras_sdp_enable and
as_sdp_mode.
as_sdp_enable to track, if we really need to send the as_sdp and the
as_sdp_mode to track which mode we want (AVT/FAVT)
We fill these in vrr_compute_config, along with other members like trans
vrr_sync_start/end.
Here we can check if as_sdp_enable is set, if not we return early.
+
+ crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC);
+ as_sdp->sdp_type = DP_SDP_ADAPTIVE_SYNC;
+ as_sdp->length = 0x9;
+ as_sdp->vtotal = adjusted_mode->vtotal;
Here the as_sdp->operation_mode should be set which is computed in
vrr_compute_config, as mentioned above.
Other fields will depend on mode that is selected.
Regards,
Ankit
+}
+
static void intel_dp_compute_vsc_sdp(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -2942,6 +2961,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
g4x_dp_set_clock(encoder, pipe_config);
intel_vrr_compute_config(pipe_config, conn_state);
+ intel_dp_compute_as_sdp(intel_dp, pipe_config, conn_state);
intel_psr_compute_config(intel_dp, pipe_config, conn_state);
intel_dp_drrs_compute_config(connector, pipe_config, link_bpp_x16);
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
Re: [PATCH 3/6] drm/i915/dp: Add Read/Write support for Adaptive Sync SDP
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
- Correct code indent. [Jani]
--v3:
- Update definition names for AS SDP which are starting from
HSW, as these defines are applicable for ADLP+.(Ankit)
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_dp.c | 95 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 12 ++-
drivers/gpu/drm/i915/i915_reg.h | 8 ++
include/drm/display/drm_dp.h | 2 +-
include/drm/display/drm_dp_helper.h | 2 +
5 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50..d68fb9d45054 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -95,7 +95,6 @@
#define INTEL_DP_RESOLUTION_STANDARD (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
#define INTEL_DP_RESOLUTION_FAILSAFE (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
-
/* Constants for DP DSC configurations */
static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
@@ -4089,6 +4088,34 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
return false;
}
+static ssize_t intel_dp_as_sdp_pack(const struct drm_dp_as_sdp *as_sdp,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /* Prepare AS (Adaptive Sync) SDP Header */
+ sdp->sdp_header.HB0 = 0;
+ sdp->sdp_header.HB1 = as_sdp->sdp_type;
+ sdp->sdp_header.HB2 = 0x02;
+ sdp->sdp_header.HB3 = as_sdp->length;
+
+ /* Fill AS (Adaptive Sync) SDP Payload */
+ sdp->db[1] = 0x0;
Operation_mode, target_rr etc should be filled from as_sdp struct.
+ sdp->db[1] = as_sdp->vtotal & 0xFF;
+ sdp->db[2] = (as_sdp->vtotal >> 8) & 0xF;
+ sdp->db[3] = 0x0;
+ sdp->db[4] = 0x0;
+ sdp->db[7] = 0x0;
+ sdp->db[8] = 0x0;
+
+ return length;
+}
+
static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
struct dp_sdp *sdp, size_t size)
{
@@ -4256,6 +4283,10 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
&crtc_state->infoframes.drm.drm,
&sdp,
sizeof(sdp));
break;
+ case DP_SDP_ADAPTIVE_SYNC:
+ len = intel_dp_as_sdp_pack(&crtc_state->infoframes.as_sdp, &sdp,
+ sizeof(sdp));
+ break;
default:
MISSING_CASE(type);
return;
@@ -4276,7 +4307,8 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 dip_enable = VIDEO_DIP_ENABLE_AVI_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW |
-VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK;
+VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK |
+VIDEO_DIP_ENABLE_ADAPTIVE_SYNC;
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
@@ -4298,6 +4330,40 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static
+int intel_dp_as_sdp_unpack(struct drm_dp_as_sdp *as_sdp,
+ const void *buffer, size_t size)
+{
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ memset(as_sdp, 0, sizeof(*as_sdp));
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != DP_SDP_ADAPTIVE_SYNC)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB2 != 0x02)
+ return -EINVAL;
+
+ if ((sdp->sdp_header.HB3 & 0x3F) != 9)
+ return -EINVAL;
+
+ if ((sdp->db[0] & AS_SDP_OP_MODE) != 0x0)
+ return -EINVAL;
lets not check this thing here, but fill as_sdp->operation_mode, read
from the sdp.
Checking should be done in intel_pipe_config_compare, perhaps need to
add a new PIPE_CONF_CHECK_ for adaptive sync SDP.
+
+ as_sdp->vtotal = ((u64)sdp->db[2] << 32) | (u64)sdp->db[1];
+ as_sdp->target_rr = 0;
+ as_sdp->duration_incr_ms = 0;
+ as_sdp->duration_
Re: [PATCH v4 0/2] drm: Check polling initialized before
Gentle reminder to consume this patchset. On Tue, Feb 06, 2024 at 03:07:47PM +0100, Daniel Vetter wrote: > On Thu, Feb 01, 2024 at 10:42:56PM -0800, Shradha Gupta wrote: > > This patchset consists of sanity checks before enabling/disabling > > output polling to make sure we do not call polling enable and disable > > functions when polling for the device is not initialized or is now > > uninitialized(by drm_kms_helper_poll_fini() function) > > > > The first patch consists of these checks in > > drm_kms_helper_poll_disable() and drm_kms_helper_poll_enable() calls. > > It further flags a warning if a caller violates this. It also adds > > these checks in drm_mode_config_helper_resume() and > > drm_mode_config_helper_suspend() calls to avoid this warning. > > > > The second patch adds a similar missing check in > > drm_helper_probe_single_connector_modes() function that is exposed by > > the new warning introduced in the first patch. > > > > Shradha Gupta (2): > > drm: Check output polling initialized before disabling > > drm: Check polling initialized before enabling in > > drm_helper_probe_single_connector_modes > > On the series: > > Reviewed-by: Daniel Vetter > > > > > drivers/gpu/drm/drm_modeset_helper.c | 19 --- > > drivers/gpu/drm/drm_probe_helper.c | 21 + > > 2 files changed, 33 insertions(+), 7 deletions(-) > > > > -- > > 2.34.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH 2/6] drm: Add Adaptive Sync SDP logging
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add structure representing Adaptive Sync Secondary Data
Packet (AS SDP). Also, add Adaptive Sync SDP logging in
drm_dp_helper.c to facilitate debugging.
--v2:
- Update logging. [Jani, Ankit]
- use as_sdp instead of async [Ankit]
- Correct define placeholders to where it is being actually used. [Jani]
- Update members in as_sdp structure and make it uniform. [Jani]
--v3:
- Add changes dri-devel mail list. No code changes.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/display/drm_dp_helper.c | 12
.../drm/i915/display/intel_crtc_state_dump.c | 12
.../drm/i915/display/intel_display_types.h| 1 +
include/drm/display/drm_dp.h | 2 ++
include/drm/display/drm_dp_helper.h | 30 +++
5 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 81c5507928f5..5911b20de2ea 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,18 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+void drm_dp_as_sdp_log(struct drm_printer *p, const struct drm_dp_as_sdp *as_sdp)
+{
+ drm_printf(p, "DP SDP: AS_SDP, revision %u, length %u\n",
+ as_sdp->revision, as_sdp->length);
+ drm_printf(p, "vtotal: %d\n", as_sdp->vtotal);
+ drm_printf(p, "target_rr: %d\n", as_sdp->target_rr);
+ drm_printf(p, "duration_incr_ms: %d\n", as_sdp->duration_incr_ms);
+ drm_printf(p, "duration_decr_ms: %d\n", as_sdp->duration_decr_ms);
+ drm_printf(p, "operation_mode: %d\n", as_sdp->operation_mode);
+}
+EXPORT_SYMBOL(drm_dp_as_sdp_log);
+
/**
* drm_dp_as_sdp_supported() - check if adaptive sync sdp is supported
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 4bcf446c75f4..26d77c2934e8 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -60,6 +60,15 @@ intel_dump_dp_vsc_sdp(struct drm_i915_private *i915,
drm_dp_vsc_sdp_log(&p, vsc);
}
+static void
+intel_dump_dp_as_sdp(struct drm_i915_private *i915,
+const struct drm_dp_as_sdp *as_sdp)
+{
+ struct drm_printer p = drm_dbg_printer(&i915->drm, DRM_UT_KMS,
"AS_SDP");
+
+ drm_dp_as_sdp_log(&p, as_sdp);
+}
+
static void
intel_dump_buffer(struct drm_i915_private *i915,
const char *prefix, const u8 *buf, size_t len)
@@ -299,6 +308,9 @@ void intel_crtc_state_dump(const struct intel_crtc_state
*pipe_config,
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA))
intel_dump_infoframe(i915, &pipe_config->infoframes.drm);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC))
+ intel_dump_dp_as_sdp(i915, &pipe_config->infoframes.as_sdp);
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(DP_SDP_VSC))
intel_dump_dp_vsc_sdp(i915, &pipe_config->infoframes.vsc);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0d4012097db1..a6991bc3f07b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1332,6 +1332,7 @@ struct intel_crtc_state {
union hdmi_infoframe hdmi;
union hdmi_infoframe drm;
struct drm_dp_vsc_sdp vsc;
+ struct drm_dp_as_sdp as_sdp;
} infoframes;
u8 eld[MAX_ELD_BYTES];
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 281afff6ee4e..af6790fb4791 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1578,10 +1578,12 @@ enum drm_dp_phy {
#define DP_SDP_AUDIO_COPYMANAGEMENT 0x05 /* DP 1.2 */
#define DP_SDP_ISRC 0x06 /* DP 1.2 */
#define DP_SDP_VSC0x07 /* DP 1.2 */
+#define DP_SDP_ADAPTIVE_SYNC0x22 /* DP 1.4 */
#define DP_SDP_CAMERA_GENERIC(i) (0x08 + (i)) /* 0-7, DP 1.3 */
#define DP_SDP_PPS0x10 /* DP 1.4 */
#define DP_SDP_VSC_EXT_VESA 0x20 /* DP 1.4 */
#define DP_SDP_VSC_EXT_CEA0x21 /* DP 1.4 */
+
/* 0x80+ CEA-861 infoframe types */
#define DP_SDP_AUDIO_INFOFRAME_HB2 0x1b
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index a0356721de0f..8a692a86d8d6 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -98,6 +98,36 @@ struct drm_dp_vsc_sdp {
enum dp_content_type content_type;
}
Re: Re: [PATCH v3 2/3] bits: Introduce fixed-type BIT
On Fri, Feb 09, 2024 at 08:53:25AM -0800, Yury Norov wrote: On Wed, Feb 07, 2024 at 11:45:20PM -0800, Lucas De Marchi wrote: Implement fixed-type BIT() to help drivers add stricter checks, like was done for GENMASK. Signed-off-by: Lucas De Marchi Acked-by: Jani Nikula So I get v1 from Jan.23 in my mailbox, and this one is v3. Did I miss a v2? Anyways, please bear my reviewed-by from v1 for this patch. Jan 23 was actually the v2 and I missed the subject prefix. My understanding was that you were going to apply this through some bitmap tree, but checking MAINTAINERS now it seems there's no git tree associated. So I will just add your r-b and merge this through drm-xe. thanks Lucas De Marchi Thanks, Yury --- include/linux/bits.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/linux/bits.h b/include/linux/bits.h index bd56f32de44e..811846ce110e 100644 --- a/include/linux/bits.h +++ b/include/linux/bits.h @@ -24,12 +24,16 @@ #define GENMASK_INPUT_CHECK(h, l) \ (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ __is_constexpr((l) > (h)), (l) > (h), 0))) +#define BIT_INPUT_CHECK(type, b) \ + ((BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ + __is_constexpr(b), (b) >= BITS_PER_TYPE(type), 0 #else /* * BUILD_BUG_ON_ZERO is not available in h files included from asm files, * disable the input check if that is the case. */ #define GENMASK_INPUT_CHECK(h, l) 0 +#define BIT_INPUT_CHECK(type, b) 0 #endif /* @@ -54,4 +58,17 @@ #define GENMASK_U32(h, l) __GENMASK(u32, h, l) #define GENMASK_U64(h, l) __GENMASK(u64, h, l) +/* + * Fixed-type variants of BIT(), with additional checks like __GENMASK(). The + * following examples generate compiler warnings due to shift-count-overflow: + * + * - BIT_U8(8) + * - BIT_U32(-1) + * - BIT_U32(40) + */ +#define BIT_U8(b) ((u8)(BIT_INPUT_CHECK(u8, b) + BIT(b))) +#define BIT_U16(b) ((u16)(BIT_INPUT_CHECK(u16, b) + BIT(b))) +#define BIT_U32(b) ((u32)(BIT_INPUT_CHECK(u32, b) + BIT(b))) +#define BIT_U64(b) ((u64)(BIT_INPUT_CHECK(u64, b) + BIT(b))) + #endif /* __LINUX_BITS_H */ -- 2.43.0
Re: [PATCH v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory
On Mon, Feb 19, 2024 at 06:59:02PM +0100, Christophe JAILLET wrote: > Le 19/02/2024 à 09:37, Dan Carpenter a écrit : > > On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote: > > > If 'list_limit' is set to a very high value, 'lsize' computation could > > > overflow if 'head.count' is big enough. > > > > > > > The "list_limit" is set via module parameter so if you set that high > > enough to lead to an integer overflow then you kind of deserve what > > you get. > > > > This patch is nice for kernel hardening and making the code easier to > > read/audit but the real world security impact is negligible. > > Agreed. > > That is what I meant by "and unlikely". > Maybe the commit message could be more explicit if needed. > > Let me know if ok as-is or if I should try to re-word the description. No, it's fine. But in the future if there is an integer overflow then lets mention in the commit message who it affects or what the impact is. regards, dan carpenter
Re: (subset) [linux][PATCH v6 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
Hi Krzysztof, On 12/02/24 3:53 pm, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 08/02/2024 11:43, Lee Jones wrote: >> On Fri, 02 Feb 2024 05:47:33 +0530, Dharma Balasubiramani wrote: >>> Convert the atmel,hlcdc binding to DT schema format. >>> >>> Align clocks and clock-names properties to clearly indicate that the LCD >>> controller expects lvds_pll_clk when interfaced with the lvds display. This >>> alignment with the specific hardware requirements ensures accurate device >>> tree >>> configuration for systems utilizing the HLCDC IP. >>> >>> [...] >> >> Applied, thanks! >> >> [3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format >>commit: cb946db1335b599ece363d33966bf653ed0fa58a >> > > Next is still failing. > > Dharma, > You must explain and clearly mark dependencies between patches. I sincerely apologize for any confusion caused by the oversight. I have organized the patches according to their dependencies in the patch series, but unfortunately, I neglected to explicitly mention these dependencies. I understand the importance of clear communication in our collaborative efforts. Please feel free to provide guidance on how I can assist you further in resolving this matter. > > Lee, > Can you pick up two previous patches as well? > > Best regards, > Krzysztof > -- With Best Regards, Dharma B.
[PATCH v14 7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ
Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ. Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base on the configuration chosen. HDMI PHY mode is configurated in the driver. Signed-off-by: Sandor Yu Tested-by: Alexander Stein --- v13->v14: *No change. v12->v13: - Fix build warning v11->v12: - Adjust clk disable order. - Return error code to replace -1 for function wait_for_ack(). - Use bool for variable pclk_in. - Add year 2024 to copyright. drivers/phy/freescale/Kconfig | 10 + drivers/phy/freescale/Makefile | 1 + drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 960 3 files changed, 971 insertions(+) create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig index c39709fd700ac..14f47b7cc77ab 100644 --- a/drivers/phy/freescale/Kconfig +++ b/drivers/phy/freescale/Kconfig @@ -45,6 +45,16 @@ config PHY_FSL_IMX8MQ_DP Enable this to support the Cadence HDPTX DP PHY driver on i.MX8MQ SOC. +config PHY_FSL_IMX8MQ_HDMI + tristate "Freescale i.MX8MQ HDMI PHY support" + depends on OF && HAS_IOMEM + depends on COMMON_CLK + select GENERIC_PHY + select CDNS_MHDP_HELPER + help + Enable this to support the Cadence HDPTX HDMI PHY driver + on i.MX8MQ SOC. + endif config PHY_FSL_LYNX_28G diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile index 47e5285209fa8..1380ac31c2ead 100644 --- a/drivers/phy/freescale/Makefile +++ b/drivers/phy/freescale/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o +obj-$(CONFIG_PHY_FSL_IMX8MQ_HDMI) += phy-fsl-imx8mq-hdmi.o obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c new file mode 100644 index 0..537b1f45c91cc --- /dev/null +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c @@ -0,0 +1,960 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Cadence High-Definition Multimedia Interface (HDMI) PHY driver + * + * Copyright (C) 2022-2024 NXP Semiconductor, Inc. + */ +#include +#include +#include +#include +#include +#include +#include + +#define ADDR_PHY_AFE 0x8 + +/* PHY registers */ +#define CMN_SSM_BIAS_TMR 0x0022 +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f +#define CMN_PSM_CLK_CTRL 0x0061 +#define CMN_CDIAG_REFCLK_CTRL 0x0062 +#define CMN_PLL0_VCOCAL_START 0x0081 +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084 +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085 +#define CMN_TXPUCAL_CTRL 0x00e0 +#define CMN_TXPDCAL_CTRL 0x00f0 +#define CMN_TXPU_ADJ_CTRL 0x0108 +#define CMN_TXPD_ADJ_CTRL 0x010c +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 +#define CMN_DIAG_PLL0_OVRD 0x01c2 +#define CMN_DIAG_PLL0_TEST_MODE0x01c4 +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 +#define CMN_DIAG_PLL0_CP_TUNE 0x01c6 +#define CMN_DIAG_PLL0_LF_PROG 0x01c7 +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8 +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9 +#define CMN_DIAG_PLL0_INCLK_CTRL 0x01ca +#define CMN_DIAG_PLL0_PXL_DIVH 0x01cb +#define CMN_DIAG_PLL0_PXL_DIVL 0x01cc +#define CMN_DIAG_HSCLK_SEL 0x01e0 +#define XCVR_PSM_RCTRL 0x4001 +#define TX_TXCC_CAL_SCLR_MULT_00x4047 +#define TX_TXCC_CPOST_MULT_00_00x404c +#define XCVR_DIAG_PLLDRC_CTRL 0x40e0 +#define XCVR_DIAG_PLLDRC_CTRL 0x40e0 +#define XCVR_DIAG_HSCLK_SEL0x40e1 +#define XCVR_DIAG_BIDI_CTRL0x40e8 +#define TX_PSC_A0 0x4100 +#define TX_PSC_A1 0x4101 +#define TX_PSC_A2 0x4102 +#define TX_PSC_A3 0x4103 +#define TX_DIAG_TX_CTRL0x41e0 +#define TX_DIAG_TX_DRV 0x41e1 +#define TX_DIAG_BGREF_PREDRV_DELAY 0x41e7 +#define TX_DIAG_ACYA_0 0x41ff +#define TX_DIAG_ACYA_1 0x43ff +#define TX_DIAG_ACYA_2 0x45ff +#define TX_DIAG_ACYA_3 0x47ff +#define TX_ANA_CTRL_REG_1 0x5020 +#define TX_ANA_CTRL_REG_2
[PATCH v14 6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base on the configuration chosen. DisplayPort PHY mode is configurated in the driver. Signed-off-by: Sandor Yu --- v12->v14: *No change. v11->v12: - Return error code to replace -1 for function wait_for_ack(). - Set cdns_phy->power_up = false in phy_power_down function. - Remove "RATE_8_1 = 81", it is not used in driver. - Add year 2024 to copyright. drivers/phy/freescale/Kconfig | 10 + drivers/phy/freescale/Makefile| 1 + drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 726 ++ 3 files changed, 737 insertions(+) create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig index 853958fb2c063..c39709fd700ac 100644 --- a/drivers/phy/freescale/Kconfig +++ b/drivers/phy/freescale/Kconfig @@ -35,6 +35,16 @@ config PHY_FSL_IMX8M_PCIE Enable this to add support for the PCIE PHY as found on i.MX8M family of SOCs. +config PHY_FSL_IMX8MQ_DP + tristate "Freescale i.MX8MQ DP PHY support" + depends on OF && HAS_IOMEM + depends on COMMON_CLK + select GENERIC_PHY + select CDNS_MHDP_HELPER + help + Enable this to support the Cadence HDPTX DP PHY driver + on i.MX8MQ SOC. + endif config PHY_FSL_LYNX_28G diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile index cedb328bc4d28..47e5285209fa8 100644 --- a/drivers/phy/freescale/Makefile +++ b/drivers/phy/freescale/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c new file mode 100644 index 0..2e24ca04c5980 --- /dev/null +++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c @@ -0,0 +1,726 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Cadence HDP-TX Display Port Interface (DP) PHY driver + * + * Copyright (C) 2022-2024 NXP Semiconductor, Inc. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#define ADDR_PHY_AFE 0x8 + +/* PHY registers */ +#define CMN_SSM_BIAS_TMR 0x0022 +#define CMN_PLLSM0_PLLEN_TMR 0x0029 +#define CMN_PLLSM0_PLLPRE_TMR 0x002a +#define CMN_PLLSM0_PLLVREF_TMR 0x002b +#define CMN_PLLSM0_PLLLOCK_TMR 0x002c +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f +#define CMN_PSM_CLK_CTRL 0x0061 +#define CMN_PLL0_VCOCAL_START 0x0081 +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084 +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085 +#define CMN_PLL0_INTDIV0x0094 +#define CMN_PLL0_FRACDIV 0x0095 +#define CMN_PLL0_HIGH_THR 0x0096 +#define CMN_PLL0_DSM_DIAG 0x0097 +#define CMN_PLL0_SS_CTRL2 0x0099 +#define CMN_ICAL_INIT_TMR 0x00c4 +#define CMN_ICAL_ITER_TMR 0x00c5 +#define CMN_RXCAL_INIT_TMR 0x00d4 +#define CMN_RXCAL_ITER_TMR 0x00d5 +#define CMN_TXPUCAL_INIT_TMR 0x00e4 +#define CMN_TXPUCAL_ITER_TMR 0x00e5 +#define CMN_TXPDCAL_INIT_TMR 0x00f4 +#define CMN_TXPDCAL_ITER_TMR 0x00f5 +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 +#define CMN_RX_ADJ_INIT_TMR0x0106 +#define CMN_RX_ADJ_ITER_TMR0x0107 +#define CMN_TXPU_ADJ_INIT_TMR 0x010a +#define CMN_TXPU_ADJ_ITER_TMR 0x010b +#define CMN_TXPD_ADJ_INIT_TMR 0x010e +#define CMN_TXPD_ADJ_ITER_TMR 0x010f +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 +#define CMN_DIAG_PLL0_OVRD 0x01c2 +#define CMN_DIAG_PLL0_TEST_MODE0x01c4 +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 +#define CMN_DIAG_PLL0_CP_TUNE 0x01c6 +#define CMN_DIAG_PLL0_LF_PROG 0x01c7 +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8 +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9 +#define CMN_DIAG_HSCLK_SEL 0x01e0 +#define CMN_DIAG_PER_CAL_ADJ 0x01ec +#define CMN_DIAG_CAL_CTRL 0x01ed +#define CMN_DIAG_ACYA 0x01ff +#define XCVR_PSM_RCTRL 0x4001 +#define X
[PATCH v14 5/7] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
Add bindings for Freescale iMX8MQ DP and HDMI PHY.
Signed-off-by: Sandor Yu
Reviewed-by: Rob Herring
---
v9->v14:
*No change.
.../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
new file mode 100644
index 0..917f113503dca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mq-dp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
+
+maintainers:
+ - Sandor Yu
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mq-dp-phy
+ - fsl,imx8mq-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PHY reference clock.
+ - description: APB clock.
+
+ clock-names:
+items:
+ - const: ref
+ - const: apb
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dp_phy: phy@32c0 {
+compatible = "fsl,imx8mq-dp-phy";
+reg = <0x32c0 0x10>;
+#phy-cells = <0>;
+clocks = <&hdmi_phy_27m>, <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+clock-names = "ref", "apb";
+};
--
2.34.1
[PATCH v14 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
standards according embedded Firmware running in the uCPU.
For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
SOC's ROM code. Bootload binary included respective specific firmware
is required.
Driver will check display connector type and
then load the corresponding driver.
Signed-off-by: Sandor Yu
Tested-by: Alexander Stein
---
v13->v14:
- Rebase to next-20240219, replace get_edid function by edid_read
function.
v12->v13:
- Explicitly include linux/platform_device.h for cdns-mhdp8501-core.c
- Fix build warning
- Order bit bpc and color_space in descending shit.
v11->v12:
- Replace DRM_INFO with dev_info or dev_warn.
- Replace DRM_ERROR with dev_err.
- Return ret when cdns_mhdp_dpcd_read failed in function
cdns_dp_aux_transferi().
- Remove unused parmeter in function cdns_dp_get_msa_misc
and use two separate variables for color space and bpc.
- Add year 2024 to copyright.
drivers/gpu/drm/bridge/cadence/Kconfig| 16 +
drivers/gpu/drm/bridge/cadence/Makefile | 2 +
.../drm/bridge/cadence/cdns-mhdp8501-core.c | 316
.../drm/bridge/cadence/cdns-mhdp8501-core.h | 365 +
.../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 700 ++
.../drm/bridge/cadence/cdns-mhdp8501-hdmi.c | 680 +
6 files changed, 2079 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index e0973339e9e33..45848e741f5f4 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -51,3 +51,19 @@ config DRM_CDNS_MHDP8546_J721E
initializes the J721E Display Port and sets up the
clock and data muxes.
endif
+
+config DRM_CDNS_MHDP8501
+ tristate "Cadence MHDP8501 DP/HDMI bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ select DRM_DISPLAY_DP_HELPER
+ select DRM_DISPLAY_HELPER
+ select CDNS_MHDP_HELPER
+ select DRM_CDNS_AUDIO
+ depends on OF
+ help
+ Support Cadence MHDP8501 DisplayPort/HDMI bridge.
+ Cadence MHDP8501 support one or more protocols,
+ including DisplayPort and HDMI.
+ To use the DP and HDMI drivers, their respective
+ specific firmware is required.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 087dc074820d7..02c1a9f3cf6fc 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
+obj-$(CONFIG_DRM_CDNS_MHDP8501) += cdns-mhdp8501.o
+cdns-mhdp8501-y := cdns-mhdp8501-core.o cdns-mhdp8501-dp.o cdns-mhdp8501-hdmi.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
new file mode 100644
index 0..bc36797b39fdb
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence Display Port Interface (DP) driver
+ *
+ * Copyright (C) 2023, 2024 NXP Semiconductor, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cdns-mhdp8501-core.h"
+
+static int cdns_mhdp8501_read_hpd(struct cdns_mhdp8501_device *mhdp)
+{
+ u8 status;
+ int ret;
+
+ mutex_lock(&mhdp->mbox_mutex);
+
+ ret = cdns_mhdp_mailbox_send(&mhdp->base, MB_MODULE_ID_GENERAL,
+GENERAL_GET_HPD_STATE, 0, NULL);
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdns_mhdp_mailbox_recv_header(&mhdp->base, MB_MODULE_ID_GENERAL,
+ GENERAL_GET_HPD_STATE,
+ sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdns_mhdp_mailbox_recv_data(&mhdp->base, &status, sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ mutex_unlock(&mhdp->mbox_mutex);
+
+ return status;
+
+err_get_hpd:
+ dev_err(mhdp->dev, "read hpd failed: %d\n", ret);
+ mutex_unlock(&mhdp->mbox_mutex);
+
+ return ret;
+}
+
+enum drm_connector_status cdns_mhdp8501_detect(struct cdns_mhdp8501_device
*mhdp
[PATCH v14 3/7] dt-bindings: display: bridge: Add Cadence MHDP8501
Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
Signed-off-by: Sandor Yu
Reviewed-by: Krzysztof Kozlowski
---
v9->v14:
*No change.
.../display/bridge/cdns,mhdp8501.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
new file mode 100644
index 0..3ae643845cfee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MHDP8501 DP/HDMI bridge
+
+maintainers:
+ - Sandor Yu
+
+description:
+ Cadence MHDP8501 DisplayPort/HDMI interface.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mq-mhdp8501
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: MHDP8501 DP/HDMI APB clock.
+
+ phys:
+maxItems: 1
+description:
+ phandle to the DisplayPort or HDMI PHY
+
+ interrupts:
+items:
+ - description: Hotplug cable plugin.
+ - description: Hotplug cable plugout.
+
+ interrupt-names:
+items:
+ - const: plug_in
+ - const: plug_out
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Input port from display controller output.
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Output port to DisplayPort or HDMI connector.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-names
+ - phys
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+mhdp: display-bridge@32c0 {
+compatible = "fsl,imx8mq-mhdp8501";
+reg = <0x32c0 0x10>;
+interrupts = ,
+ ;
+interrupt-names = "plug_in", "plug_out";
+clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+phys = <&dp_phy>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+mhdp_in: endpoint {
+remote-endpoint = <&dcss_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+mhdp_out: endpoint {
+remote-endpoint = <&dp_connector>;
+};
+};
+};
+};
--
2.34.1
[PATCH v14 2/7] phy: Add HDMI configuration options
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The parameters added here are based on HDMI PHY
implementation practices. The current set of parameters
should cover the potential users.
Signed-off-by: Sandor Yu
Reviewed-by: Dmitry Baryshkov
Acked-by: Vinod Koul
---
v9->v14:
*No change.
include/linux/phy/phy-hdmi.h | 24
include/linux/phy/phy.h | 7 ++-
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 include/linux/phy/phy-hdmi.h
diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
new file mode 100644
index 0..b7de88e9090f0
--- /dev/null
+++ b/include/linux/phy/phy-hdmi.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2022 NXP
+ */
+
+#ifndef __PHY_HDMI_H_
+#define __PHY_HDMI_H_
+
+#include
+/**
+ * struct phy_configure_opts_hdmi - HDMI configuration set
+ * @pixel_clk_rate: Pixel clock of video modes in KHz.
+ * @bpc: Maximum bits per color channel.
+ * @color_space: Colorspace in enum hdmi_colorspace.
+ *
+ * This structure is used to represent the configuration state of a HDMI phy.
+ */
+struct phy_configure_opts_hdmi {
+ unsigned int pixel_clk_rate;
+ unsigned int bpc;
+ enum hdmi_colorspace color_space;
+};
+
+#endif /* __PHY_HDMI_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index aa76609ba2580..0731b8b707f7c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -42,7 +43,8 @@ enum phy_mode {
PHY_MODE_MIPI_DPHY,
PHY_MODE_SATA,
PHY_MODE_LVDS,
- PHY_MODE_DP
+ PHY_MODE_DP,
+ PHY_MODE_HDMI,
};
enum phy_media {
@@ -60,11 +62,14 @@ enum phy_media {
* the DisplayPort protocol.
* @lvds: Configuration set applicable for phys supporting
* the LVDS phy mode.
+ * @hdmi: Configuration set applicable for phys supporting
+ * the HDMI phy mode.
*/
union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
struct phy_configure_opts_lvds lvds;
+ struct phy_configure_opts_hdmi hdmi;
};
/**
--
2.34.1
[PATCH v14 1/7] drm: bridge: Cadence: Create mhdp helper driver
MHDP8546 mailbox access functions will be share to other mhdp driver
and Cadence HDP-TX HDMI/DP PHY drivers.
Create a new mhdp helper driver and move all those functions into.
cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(),
because it use the DPTX command ID DPTX_WRITE_REGISTER.
New cdns_mhdp_reg_write() is created with the general command ID
GENERAL_REGISTER_WRITE.
rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
same as the other mailbox access functions.
Signed-off-by: Sandor Yu
---
v12->v14:
*No change.
V11->v12:
- Move status initialize out of mbox_mutex.
- Reorder API functions in alphabetical.
- Add notes for malibox access functions.
- Add year 2024 to copyright.
drivers/gpu/drm/bridge/cadence/Kconfig| 4 +
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 304 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 403 +++---
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 44 +-
include/drm/bridge/cdns-mhdp-helper.h | 97 +
6 files changed, 479 insertions(+), 374 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
create mode 100644 include/drm/bridge/cdns-mhdp-helper.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index cced81633ddcd..e0973339e9e33 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -21,6 +21,9 @@ config DRM_CDNS_DSI_J721E
the routing of the DSS DPI signal to the Cadence DSI.
endif
+config CDNS_MHDP_HELPER
+ tristate
+
config DRM_CDNS_MHDP8546
tristate "Cadence DPI/DP bridge"
select DRM_DISPLAY_DP_HELPER
@@ -28,6 +31,7 @@ config DRM_CDNS_MHDP8546
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
+ select CDNS_MHDP_HELPER
depends on OF
help
Support Cadence DPI to DP bridge. This is an internal
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d137..087dc074820d7 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
cdns-dsi-y := cdns-dsi-core.o
cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
new file mode 100644
index 0..ba31695b483ac
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
@@ -0,0 +1,304 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, 2024 NXP Semiconductor, Inc.
+ *
+ */
+#include
+#include
+#include
+
+/* Mailbox helper functions */
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_base *base)
+{
+ int ret, empty;
+
+ WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+ ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ return readl(base->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_base *base, u8 val)
+{
+ int ret, full;
+
+ WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+ ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_FULL,
+full, !full, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ writel(val, base->regs + CDNS_MAILBOX_TX_DATA);
+
+ return 0;
+}
+
+int cdns_mhdp_mailbox_recv_header(struct cdns_mhdp_base *base,
+ u8 module_id, u8 opcode,
+ u16 req_size)
+{
+ u32 mbox_size, i;
+ u8 header[4];
+ int ret;
+
+ /* read the header of the message */
+ for (i = 0; i < sizeof(header); i++) {
+ ret = cdns_mhdp_mailbox_read(base);
+ if (ret < 0)
+ return ret;
+
+ header[i] = ret;
+ }
+
+ mbox_size = get_unaligned_be16(header + 2);
+
+ if (opcode != header[0] || module_id != header[1] ||
+ req_size != mbox_size) {
+ /*
+* If the message in mailbox is not what we want, we need to
+* clear the mailbox by reading its contents.
+*/
+ for (i = 0; i < mbox_size; i++)
+ if (cdns_mhdp_
[PATCH v14 0/7] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
driver and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ.
The patch set compose of DRM bridge drivers and PHY drivers.
Both of them need by patch #1 and #2 to pass build.
DRM bridges driver patches:
#1: drm: bridge: Cadence: Creat mhdp helper driver
#2: phy: Add HDMI configuration options
#3: dt-bindings: display: bridge: Add Cadence MHDP8501
#4: drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
PHY driver patches:
#1: drm: bridge: Cadence: Creat mhdp helper driver
#2: phy: Add HDMI configuration options
#5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
#6: phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
#7: phy: freescale: Add HDMI PHY driver for i.MX8MQ
v13->v14:
Patch #4:
- Rebase to next-20240219, replace get_edid function by edid_read
function as commits d807ad80d811b ("drm/bridge: add ->edid_read
hook and drm_bridge_edid_read()") and 27b8f91c08d99 ("drm/bridge:
remove ->get_edid callback") had change the API.
v12->v13:
Patch #4:
- Explicitly include linux/platform_device.h for cdns-mhdp8501-core.c
- Fix build warning
- Order bit bpc and color_space in descending shit.
Patch #7:
- Fix build warning
v11->v12:
Patch #1:
- Move status initialize out of mbox_mutex.
- Reorder API functions in alphabetical.
- Add notes for malibox access functions.
- Add year 2024 to copyright.
Patch #4:
- Replace DRM_INFO with dev_info or dev_warn.
- Replace DRM_ERROR with dev_err.
- Return ret when cdns_mhdp_dpcd_read failed in function
cdns_dp_aux_transferi().
- Remove unused parmeter in function cdns_dp_get_msa_misc
and use two separate variables for color space and bpc.
- Add year 2024 to copyright.
Patch #6:
- Return error code to replace -1 for function wait_for_ack().
- Set cdns_phy->power_up = false in phy_power_down function.
- Remove "RATE_8_1 = 81", it is not used in driver.
- Add year 2024 to copyright.
Patch #7:
- Adjust clk disable order.
- Return error code to replace -1 for function wait_for_ack().
- Use bool for variable pclk_in.
- Add year 2024 to copyright.
v10->v11:
- rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
same as the other mailbox access functions.
- use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read()
and remove them from EXPORT_SYMBOL_GPL().
- remove MODULE_ALIAS() from mhdp8501 driver.
v9->v10:
- Create mhdp helper driver to replace macro functions,
move all mhdp mailbox access functions and common functions
into the helper driver.
Patch #1:drm: bridge: Cadence: Creat mhdp helper driver
it is totaly different with v9.
v8->v9:
- Remove compatible string "cdns,mhdp8501" that had removed
from dt-bindings file in v8.
- Add Dmitry's R-b tag to patch #2
- Add Krzysztof's R-b tag to patch #3
v7->v8:
MHDP8501 HDMI/DP:
- Correct DT node name to "display-bridge".
- Remove "cdns,mhdp8501" from mhdp8501 dt-binding doc.
HDMI/DP PHY:
- Introduced functions `wait_for_ack` and `wait_for_ack_clear` to handle
waiting with acknowledgment bits set and cleared respectively.
- Use FIELD_PRE() to set bitfields for both HDMI and DP PHY.
v6->v7:
MHDP8501 HDMI/DP:
- Combine HDMI and DP driver into one mhdp8501 driver.
Use the connector type to load the corresponding functions.
- Remove connector init functions.
- Add in phy_hdmi.h to reuse ‘enum hdmi_colorspace’.
HDMI/DP PHY:
- Lowercase hex values
- Fix parameters indent issue on some functions
- Replace ‘udelay’ with ‘usleep_range’
v5->v6:
HDMI/DP bridge driver
- 8501 is the part number of Cadence MHDP on i.MX8MQ.
Use MHDP8501 to name hdmi/dp drivers and files.
- Add compatible "fsl,imx8mq-mhdp8501-dp" for i.MX8MQ DP driver
- Add compatible "fsl,imx8mq-mhdp8501-hdmi" for i.MX8MQ HDMI driver
- Combine HDMI and DP dt-bindings into one file cdns,mhdp8501.yaml
- Fix HDMI scrambling is not enable issue when driver working in 4Kp60
mode.
- Add HDMI/DP PHY API mailbox protect.
HDMI/DP PHY driver:
- Rename DP and HDMI PHY files and move to folder phy/freescale/
- Remove properties num_lanes and link_rate from DP PHY driver.
- Combine HDMI and DP dt-bindings into one file fsl,imx8mq-dp-hdmi-phy.yaml
- Update compatible string to "fsl,imx8mq-dp-phy".
- Update compatible string to "fsl,imx8mq-hdmi-phy".
v4->v5:
- Drop "clk" suffix in clock name.
- Add output port property in the example of hdmi/dp.
v3->v4:
dt-bindings:
- Correct dt-bindings coding style and address review comments.
- Add apb_clk description.
- Add output port for HDMI/DP connector
PHY:
- Alphabetically sorted in Kconfig and Makefile for DP and HDMI PHY
- Remove unused registers define from HDMI and DP PHY drivers.
- More description in phy_hdmi.h.
- Add apb_clk to HDMI and DP phy driver.
HDMI
Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature
[PATCH v2 resend 4/4] video: fbdev: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +--
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++-
drivers/video/fbdev/pxafb.c | 2 +-
include/video/omapfb_dss.h| 3 ---
7 files changed, 10 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index b7eb17a16ec4..1f13bcf73da5 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -5079,7 +5080,7 @@ static int dsi_probe_of(struct platform_device *pdev)
struct device_node *ep;
struct omap_dsi_pin_config pin_cfg;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index 0282d4eef139..14965a3fd05b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -130,24 +130,6 @@ static struct device_node
*omapdss_of_get_remote_port(const struct device_node *
return np;
}
-struct device_node *
-omapdss_of_get_first_endpoint(const struct device_node *parent)
-{
- struct device_node *port, *ep;
-
- port = omapdss_of_get_next_port(parent, NULL);
-
- if (!port)
- return NULL;
-
- ep = omapdss_of_get_next_endpoint(port, NULL);
-
- of_node_put(port);
-
- return ep;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
-
struct omap_dss_device *
omapdss_of_find_source_for_first_ep(struct device_node *node)
{
@@ -155,7 +137,7 @@ omapdss_of_find_source_for_first_ep(struct device_node
*node)
struct device_node *src_port;
struct omap_dss_device *src;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return ERR_PTR(-EINVAL);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
index f05b4e35a842..8f407ec134dc 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -529,7 +530,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
struct device_node *ep;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
index 03292945b1d4..4ad219f522b9 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -561,7 +562,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
struct device_node *ep;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
index c9d40e28a06f..0bd80d3b8f1b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -764,7 +765,7 @@ static int venc_probe_of(struct platform_device *pdev)
u32 channels;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index fa943612c4e2..2ef56fa28aff 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2171,7 +2171,7 @@ static int of_get_pxafb_mode_info(struct device *dev,
u32 bus_width;
int ret, i;
- np = of_graph_get_next_endpoint(dev->of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(dev->of_node,
[PATCH v2 resend 3/4] media: platform: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/atmel/atmel-isi.c | 4 ++--
drivers/media/platform/intel/pxa_camera.c | 2 +-
drivers/media/platform/samsung/exynos4-is/fimc-is.c | 2 +-
drivers/media/platform/samsung/exynos4-is/mipi-csis.c | 3 ++-
drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++--
drivers/media/platform/ti/davinci/vpif.c | 3 +--
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isi.c
b/drivers/media/platform/atmel/atmel-isi.c
index f8450a8ccda6..c1108df72dd5 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -834,7 +834,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
isi->pdata.full_mode = 1;
isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(&pdev->dev, "Could not find the endpoint\n");
return -EINVAL;
@@ -1158,7 +1158,7 @@ static int isi_graph_init(struct atmel_isi *isi)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(isi->dev->of_node, NULL);
+ ep = of_graph_get_endpoint_by_regs(isi->dev->of_node, 0, -1);
if (!ep)
return -EINVAL;
diff --git a/drivers/media/platform/intel/pxa_camera.c
b/drivers/media/platform/intel/pxa_camera.c
index 59b89e421dc2..d904952bf00e 100644
--- a/drivers/media/platform/intel/pxa_camera.c
+++ b/drivers/media/platform/intel/pxa_camera.c
@@ -2207,7 +2207,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
pcdev->mclk = mclk_rate;
}
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(dev, "could not find endpoint\n");
return -EINVAL;
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-is.c
b/drivers/media/platform/samsung/exynos4-is/fimc-is.c
index a08c87ef6e2d..39aab667910d 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-is.c
@@ -175,7 +175,7 @@ static int fimc_is_parse_sensor_config(struct fimc_is *is,
unsigned int index,
return -EINVAL;
}
- ep = of_graph_get_next_endpoint(node, NULL);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return -ENXIO;
diff --git a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
index aae8a8b2c0f4..4b9b20ba3504 100644
--- a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
@@ -727,7 +727,8 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
&state->max_num_lanes))
return -EINVAL;
- node = of_graph_get_next_endpoint(node, NULL);
+ /* from port@3 or port@4 */
+ node = of_graph_get_endpoint_by_regs(node, -1, -1);
if (!node) {
dev_err(&pdev->dev, "No port node at %pOF\n",
pdev->dev.of_node);
diff --git a/drivers/media/platform/st/stm32/stm32-dcmi.c
b/drivers/media/platform/st/stm32/stm32-dcmi.c
index c4610e305546..ff3331af9406 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmi.c
@@ -1855,7 +1855,7 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(dcmi->dev->of_node, NULL);
+ ep = of_graph_get_endpoint_by_regs(dcmi->dev->of_node, 0, -1);
if (!ep) {
dev_err(dcmi->dev, "Failed to get next endpoint\n");
return -EINVAL;
@@ -1907,7 +1907,7 @@ static int dcmi_probe(struct platform_device *pdev)
"Could not get reset control\n");
/* Get bus characteristics from devicetree */
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(&pdev->dev, "Could not find the endpoint\n");
return -ENODEV;
diff --git a/drivers/media/platform/ti/davinci/vpif.c
b/drivers/media/platform/ti/davinci/vpif.c
index 63cdfed37bc9..f4e1fa76bf37 100644
--- a/drivers/media/platform/ti/davinci/vpif.c
+++ b/drivers/media/platform/ti/davinci/vpif.c
@@ -465,8 +465,7 @
[PATCH v2 resend 2/4] media: i2c: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Link: https://lore.kernel.org/r/9d1e99b0-892d-4a72-a9b3-886b8ed09...@xs4all.nl
Signed-off-by: Kuninori Morimoto
---
drivers/media/i2c/adv7343.c | 2 +-
drivers/media/i2c/adv7604.c | 4 ++--
drivers/media/i2c/mt9p031.c | 2 +-
drivers/media/i2c/mt9v032.c | 2 +-
drivers/media/i2c/ov2659.c | 2 +-
drivers/media/i2c/ov5645.c | 2 +-
drivers/media/i2c/ov5647.c | 2 +-
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
drivers/media/i2c/s5k5baf.c | 2 +-
drivers/media/i2c/tc358743.c | 2 +-
drivers/media/i2c/tda1997x.c | 2 +-
drivers/media/i2c/tvp514x.c | 2 +-
drivers/media/i2c/tvp7002.c | 2 +-
13 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index ff21cd4744d3..4fbe4e18570e 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -403,7 +403,7 @@ adv7343_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 810fa8826f30..319db3e847c4 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -3204,8 +3204,8 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
np = state->i2c_clients[ADV76XX_PAGE_IO]->dev.of_node;
- /* Parse the endpoint. */
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ /* FIXME: Parse the endpoint. */
+ endpoint = of_graph_get_endpoint_by_regs(np, -1, -1);
if (!endpoint)
return -EINVAL;
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 596200d0248c..f4b481212356 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -1078,7 +1078,7 @@ mt9p031_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 3ca76eeae7ff..e9f5c6647f97 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -1006,7 +1006,7 @@ mt9v032_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 1d0ef72a6403..d1653d7431d0 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1388,7 +1388,7 @@ ov2659_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!endpoint)
return NULL;
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
index a26ac11c989d..9daf06ffedf4 100644
--- a/drivers/media/i2c/ov5645.c
+++ b/drivers/media/i2c/ov5645.c
@@ -1056,7 +1056,7 @@ static int ov5645_probe(struct i2c_client *client)
ov5645->i2c_client = client;
ov5645->dev = dev;
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint) {
dev_err(dev, "endpoint node not found\n");
return -EINVAL;
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
index 96c0fd4ff5ab..7e1ecdf2485f 100644
--- a/drivers/media/i2c/ov5647.c
+++ b/drivers/media/i2c/ov5647.c
@@ -1363,7 +1363,7 @@ static int ov5647_parse_dt(struct ov5647 *sensor, struct
device_node *np)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(np, NULL);
+ ep = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!ep)
[PATCH v2 resend 1/4] gpu: drm: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/drm_of.c | 4 +++-
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 +-
drivers/gpu/drm/tiny/arcpgu.c | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 177b600895d3..b6b2cade69ae 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -504,6 +504,8 @@ EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_count_ep);
* Gets parent DSI bus for a DSI device controlled through a bus other
* than MIPI-DCS (SPI, I2C, etc.) using the Device Tree.
*
+ * This function assumes that the device's port@0 is the DSI input.
+ *
* Returns pointer to mipi_dsi_host if successful, -EINVAL if the
* request is unsupported, -EPROBE_DEFER if the DSI host is found but
* not available, or -ENODEV otherwise.
@@ -516,7 +518,7 @@ struct mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev)
/*
* Get first endpoint child from device.
*/
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint)
return ERR_PTR(-ENODEV);
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 4618c892cdd6..e10e469aa7a6 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -400,7 +400,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c)
rpi_touchscreen_i2c_write(ts, REG_POWERON, 0);
/* Look up the DSI host. It needs to probe before we do. */
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint)
return -ENODEV;
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index 4f8f3172379e..8c29b719ea62 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -288,7 +288,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
* There is only one output port inside each device. It is linked with
* encoder endpoint.
*/
- endpoint_node = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
+ endpoint_node = of_graph_get_endpoint_by_regs(pdev->dev.of_node, 0, -1);
if (endpoint_node) {
encoder_node = of_graph_get_remote_port_parent(endpoint_node);
of_node_put(endpoint_node);
--
2.25.1
[PATCH v2 resend 0/4] of: replace of_graph_get_next_endpoint()
Hi Rob This is resend v2 of replace of_graph_get_next_endpoint() We should get rid of or minimize of_graph_get_next_endpoint() in its current form. In general, drivers should be asking for a specific port number because their function is fixed in the binding. https://lore.kernel.org/r/20240131184347.ga1906672-r...@kernel.org This patch-set replace of_graph_get_next_endpoint() by of_graph_get_endpoint_by_regs(). There are still next_endpoint() after this patch-set, but it will be replaced by for_each_endpoint_of_node() in next patch-set (A) [*] this patch-set [o] done [o] tidyup of_graph_get_endpoint_count() [*] replace endpoint func - use endpoint_by_regs() (A) [ ] replace endpoint func - use for_each() [ ] rename endpoint func to device_endpoint [ ] add new port function [ ] add new endpont function [ ] remove of_graph_get_next_device_endpoint() v1 -> v2 - add Reviewed-by from Launrent - use by_regs(xx, -1, -1) for some devices - add extra explain for drm_of_get_dsi_bus() - add FIXME and Link on adv7604.c - based on latest of branch Kuninori Morimoto (4): gpu: drm: replace of_graph_get_next_endpoint() media: i2c: replace of_graph_get_next_endpoint() media: platform: replace of_graph_get_next_endpoint() video: fbdev: replace of_graph_get_next_endpoint() drivers/gpu/drm/drm_of.c | 4 +++- .../drm/panel/panel-raspberrypi-touchscreen.c | 2 +- drivers/gpu/drm/tiny/arcpgu.c | 2 +- drivers/media/i2c/adv7343.c | 2 +- drivers/media/i2c/adv7604.c | 4 ++-- drivers/media/i2c/mt9p031.c | 2 +- drivers/media/i2c/mt9v032.c | 2 +- drivers/media/i2c/ov2659.c| 2 +- drivers/media/i2c/ov5645.c| 2 +- drivers/media/i2c/ov5647.c| 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/i2c/s5k5baf.c | 2 +- drivers/media/i2c/tc358743.c | 2 +- drivers/media/i2c/tda1997x.c | 2 +- drivers/media/i2c/tvp514x.c | 2 +- drivers/media/i2c/tvp7002.c | 2 +- drivers/media/platform/atmel/atmel-isi.c | 4 ++-- drivers/media/platform/intel/pxa_camera.c | 2 +- .../platform/samsung/exynos4-is/fimc-is.c | 2 +- .../platform/samsung/exynos4-is/mipi-csis.c | 3 ++- drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++-- drivers/media/platform/ti/davinci/vpif.c | 3 +-- drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++- drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +-- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++- drivers/video/fbdev/pxafb.c | 2 +- include/video/omapfb_dss.h| 3 --- 29 files changed, 38 insertions(+), 53 deletions(-) -- 2.25.1
[PATCH 3/4] backlight: lm3630a: Use backlight_get_brightness helper in update_status
As per documentation "drivers are expected to use this function in their update_status() operation to get the brightness value.". With this we can also drop the manual backlight_is_blank() handling since backlight_get_brightness() is already handling this correctly. Signed-off-by: Luca Weiss --- drivers/video/backlight/lm3630a_bl.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c index 26ff4178cc16..e6c0916ec88b 100644 --- a/drivers/video/backlight/lm3630a_bl.c +++ b/drivers/video/backlight/lm3630a_bl.c @@ -189,10 +189,11 @@ static int lm3630a_bank_a_update_status(struct backlight_device *bl) int ret; struct lm3630a_chip *pchip = bl_get_data(bl); enum lm3630a_pwm_ctrl pwm_ctrl = pchip->pdata->pwm_ctrl; + int brightness = backlight_get_brightness(bl); /* pwm control */ if ((pwm_ctrl & LM3630A_PWM_BANK_A) != 0) - return lm3630a_pwm_ctrl(pchip, bl->props.brightness, + return lm3630a_pwm_ctrl(pchip, brightness, bl->props.max_brightness); /* disable sleep */ @@ -201,9 +202,9 @@ static int lm3630a_bank_a_update_status(struct backlight_device *bl) goto out_i2c_err; usleep_range(1000, 2000); /* minimum brightness is 0x04 */ - ret = lm3630a_write(pchip, REG_BRT_A, bl->props.brightness); + ret = lm3630a_write(pchip, REG_BRT_A, brightness); - if (backlight_is_blank(bl) || (backlight_get_brightness(bl) < 0x4)) + if (brightness < 0x4) /* turn the string off */ ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDA_ENABLE, 0); else @@ -263,10 +264,11 @@ static int lm3630a_bank_b_update_status(struct backlight_device *bl) int ret; struct lm3630a_chip *pchip = bl_get_data(bl); enum lm3630a_pwm_ctrl pwm_ctrl = pchip->pdata->pwm_ctrl; + int brightness = backlight_get_brightness(bl); /* pwm control */ if ((pwm_ctrl & LM3630A_PWM_BANK_B) != 0) - return lm3630a_pwm_ctrl(pchip, bl->props.brightness, + return lm3630a_pwm_ctrl(pchip, brightness, bl->props.max_brightness); /* disable sleep */ @@ -275,9 +277,9 @@ static int lm3630a_bank_b_update_status(struct backlight_device *bl) goto out_i2c_err; usleep_range(1000, 2000); /* minimum brightness is 0x04 */ - ret = lm3630a_write(pchip, REG_BRT_B, bl->props.brightness); + ret = lm3630a_write(pchip, REG_BRT_B, brightness); - if (backlight_is_blank(bl) || (backlight_get_brightness(bl) < 0x4)) + if (brightness < 0x4) /* turn the string off */ ret |= lm3630a_update(pchip, REG_CTRL, LM3630A_LEDB_ENABLE, 0); else -- 2.43.2
[PATCH 1/4] backlight: lm3630a: Initialize backlight_properties on init
The backlight_properties struct should be initialized to zero before
using, otherwise there will be some random values in the struct.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
Signed-off-by: Luca Weiss
---
drivers/video/backlight/lm3630a_bl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index a3412c936ca2..8e275275b808 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -343,6 +343,7 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
struct backlight_properties props;
const char *label;
+ memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
--
2.43.2
[PATCH 0/4] Various fixes for the lm3630a backlight driver
On the MSM8974 Nexus 5 and OnePlus One phones (latter doesn't have display upstream) the display backlight was turning off whenever you would write a brightness to sysfs since a recent commit to the driver (kernel v6.5). backlight: lm3630a: Turn off both led strings when display is blank Turns out, backlight_is_blank() thought the display was blanked because the props variable is was checking was never actually initialized so it was just reading some value that was left before. The first commit in this series fixes this, and the others are some cleanups / fixes I noticed while working on this. As last commit, we can finally hook up the panel and backlight on the Nexus 5 so blanking the screen actually turns off the backlight. Signed-off-by: Luca Weiss --- Luca Weiss (4): backlight: lm3630a: Initialize backlight_properties on init backlight: lm3630a: Don't set bl->props.brightness in get_brightness backlight: lm3630a: Use backlight_get_brightness helper in update_status ARM: dts: qcom: msm8974-hammerhead: Hook up backlight .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts| 4 ++- drivers/video/backlight/lm3630a_bl.c | 29 ++ 2 files changed, 16 insertions(+), 17 deletions(-) --- base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d change-id: 20240219-lm3630a-fixups-8a9359e5a8ce Best regards, -- Luca Weiss
[PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Hook up backlight
Connect the panel with the backlight nodes so that the backlight can be
turned off when the display is blanked.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
index 4aaae8537a3f..8eaa5b162815 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -182,7 +182,7 @@ &blsp2_i2c5 {
status = "okay";
clock-frequency = <355000>;
- led-controller@38 {
+ backlight: led-controller@38 {
compatible = "ti,lm3630a";
status = "okay";
reg = <0x38>;
@@ -272,6 +272,8 @@ panel: panel@0 {
reg = <0>;
compatible = "lg,acx467akm-7";
+ backlight = <&backlight>;
+
pinctrl-names = "default";
pinctrl-0 = <&panel_pin>;
--
2.43.2
[PATCH 2/4] backlight: lm3630a: Don't set bl->props.brightness in get_brightness
There's no need to set bl->props.brightness, the get_brightness function
is just supposed to return the current brightness and not touch the
struct.
With that done we can also remove the 'goto out' and just return the
value.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
Signed-off-by: Luca Weiss
---
drivers/video/backlight/lm3630a_bl.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 8e275275b808..26ff4178cc16 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -233,7 +233,7 @@ static int lm3630a_bank_a_get_brightness(struct
backlight_device *bl)
if (rval < 0)
goto out_i2c_err;
brightness |= rval;
- goto out;
+ return brightness;
}
/* disable sleep */
@@ -244,11 +244,8 @@ static int lm3630a_bank_a_get_brightness(struct
backlight_device *bl)
rval = lm3630a_read(pchip, REG_BRT_A);
if (rval < 0)
goto out_i2c_err;
- brightness = rval;
+ return rval;
-out:
- bl->props.brightness = brightness;
- return bl->props.brightness;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access register\n");
return 0;
@@ -310,7 +307,7 @@ static int lm3630a_bank_b_get_brightness(struct
backlight_device *bl)
if (rval < 0)
goto out_i2c_err;
brightness |= rval;
- goto out;
+ return brightness;
}
/* disable sleep */
@@ -321,11 +318,8 @@ static int lm3630a_bank_b_get_brightness(struct
backlight_device *bl)
rval = lm3630a_read(pchip, REG_BRT_B);
if (rval < 0)
goto out_i2c_err;
- brightness = rval;
+ return rval;
-out:
- bl->props.brightness = brightness;
- return bl->props.brightness;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access register\n");
return 0;
--
2.43.2
Re: [PATCH 8/8] arm64: dts: qcom: qrb2210-rb1: Enable the GPU
On Mon, 19 Feb 2024 at 23:37, Konrad Dybcio wrote: > > On 19.02.2024 15:49, Dmitry Baryshkov wrote: > > On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio > > wrote: > >> > >> Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol). > > > > Is it not? > > Sure, every electronic device is also a heater, I suppose.. I found > this wording extremely funny though 3D accelerator is a bit outdated term, but it's still valid. Well, unless using A702 makes 3D applications run slower than when using llvmpipe. > >> [1] > >> https://docs.qualcomm.com/bundle/publicresource/87-61720-1_REV_A_QUALCOMM_ROBOTICS_RB1_PLATFORM__QUALCOMM_QRB2210__PRODUCT_BRIEF.pdf > >> Signed-off-by: Konrad Dybcio > > > > With the exception of the commit message: > > :( > > Konrad > > > > > Reviewed-by: Dmitry Baryshkov > > > >> --- > >> arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 8 > >> 1 file changed, 8 insertions(+) > > > > -- With best wishes Dmitry
[pull] amdgpu, amdkfd, radeon drm-next-6.9
Hi Dave, Sima, More new stuff for 6.9. The following changes since commit d5597444032b2f5c8624918fb5b29be5bba78a3c: drm/amdgpu: Fix HDP flush for VFs on nbio v7.9 (2024-02-07 12:26:24 -0500) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.9-2024-02-19 for you to fetch changes up to 31e0a586f3385134bcad00d8194eb0728cb1a17d: drm/amdgpu: add MMHUB 3.3.1 support (2024-02-19 14:50:46 -0500) amd-drm-next-6.9-2024-02-19: amdgpu: - ATHUB 4.1 support - EEPROM support updates - RAS updates - LSDMA 7.0 support - JPEG DPG support - IH 7.0 support - HDP 7.0 support - VCN 5.0 support - Misc display fixes - Retimer fixes - DCN 3.5 fixes - VCN 4.x fixes - PSR fixes - PSP 14.0 support - VA_RESERVED cleanup - SMU 13.0.6 updates - NBIO 7.11 updates - SDMA 6.1 updates - MMHUB 3.3 updates - Suspend/resume fixes - DMUB updates amdkfd: - Trap handler enhancements - Fix cache size reporting - Relocate the trap handler radeon: - fix typo in print statement Alex Deucher (1): drm/amdgpu/psp: update define to better align with its meaning Aric Cyr (1): drm/amd/display: 3.2.272 Charlene Liu (2): drm/amd/display: enable fgcg by default drm/amd/display: allow psr-su/replay for z8 Dan Carpenter (1): drm/amd/display: Fix && vs || typos Felix Kuehling (2): drm/amdgpu: Reduce VA_RESERVED_BOTTOM to 64KB drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole Gabe Teeger (1): Revert "drm/amd/display: Send DTBCLK disable message on first commit" George Shen (1): Revert "drm/amd/display: Add left edge pixel for YCbCr422/420 + ODM pipe split" Hamza Mahfooz (2): drm/amdgpu: make damage clips support configurable drm/amdgpu: respect the abmlevel module parameter value if it is set Hawking Zhang (8): drm/amdgpu: Add athub v4_1_0 ip headers (v5) drm/amdgpu: Add athub v4_1_0 ip block support drm/amdgpu: Add lsdma v7_0_0 ip headers (v3) drm/amdgpu: Add osssys v7_0_0 ip headers (v4) drm/amdgpu: Add hdp v7_0_0 ip headers (v3) drm/amdgpu: Add vcn v5_0_0 ip headers (v5) drm/amdgpu: Add mp v14_0_2 ip headers (v5) drm/amdgpu: Add psp v14_0 ip block support Jonathan Kim (1): drm/amdkfd: fill in data for control stack header for gfx10 Kent Russell (1): drm/amdkfd: Fix L2 cache size reporting in GFX9.4.3 Laurent Morichetti (1): drm/amdkfd: pass debug exceptions to second-level trap handler Lijo Lazar (1): drm/amd/pm: Allow setting max UCLK on SMU v13.0.6 Likun Gao (16): drm/amd/swsmu: add judgement for vcn jpeg dpm set drm/amdgpu: skip ucode bo reserve for RLC AUTOLOAD drm/amdgpu: support rlc auotload type set drm/amdgpu: Add lsdma v7_0 ip block support drm/amdgpu/discovery: Add lsdma v7_0 ip block drm/amdgpu: Add ih v7_0 ip block support drm/amdgpu/discovery: Add ih v7_0 ip block drm/amdgpu: Add hdp v7_0 ip block support drm/amdgpu/discovery: Add hdp v7_0 ip block drm/amdgpu: use spirom update wait_for helper for psp v14 drm/amdgpu: support psp ip block for psp v14 drm/amdgpu/psp: set autoload support by default drm/amdgpu/psp: handle TMR type via flag drm/amdgpu/psp: set boot_time_tmr flag drm/amdgpu: add psp_timeout to limit PSP related operation drm/amdgpu: support psp ip block discovery for psp v14 Mario Limonciello (3): drm/amd: Stop evicting resources on APUs in suspend Revert "drm/amd: flush any delayed gfxoff on suspend entry" drm/amd: Change `jpeg_v4_0_5_start_dpg_mode()` to void Martin Tsai (1): drm/amd/display: should support dmub hw lock on Replay Michael Strauss (1): drm/amd/display: Update FIXED_VS Retimer HWSS Test Pattern Sequences Nicholas Kazlauskas (2): drm/amd/display: Add shared firmware state for DMUB IPS handshake drm/amd/display: Increase ips2_eval delay for DCN35 Nikita Zhandarovich (2): drm/radeon/ni: Fix wrong firmware size logging in ni_init_microcode() drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini() Rajneesh Bhardwaj (2): drm/amdkfd: update SIMD distribution algo for GFXIP 9.4.2 onwards drm/amdgpu: Fix implicit assumtion in gfx11 debug flags Rodrigo Siqueira (1): drm/amd/display: Remove break after return Roman Li (1): drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr Saleemkhan Jamadar (2): drm/amdgpu: add ucode id for jpeg DPG support drm/amdgpu/jpeg: add support for jpeg DPG mode Sohaib Nadeem (2): Revert "drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz" drm/amd/display: fixed integer types and null check locations Sonny Jiang (7): drm/amdgpu: add VCN_5_0_0 firmware support drm/amdgpu: add VCN_5_0_0 IP block supp
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Mon, 12 Feb 2024 15:15:54 +0200 Jani Nikula
wrote:
>
> On Tue, 06 Feb 2024, Stephen Rothwell wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (i386 defconfig)
> > failed like this:
> >
> > In function 'i915_ttm_placement_from_obj',
> > inlined from 'i915_ttm_get_pages' at
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c:847:2:
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c:165:18: error: 'places[0].flags' is
> > used uninitialized [-Werror=uninitialized]
> > 165 | places[0].flags |= TTM_PL_FLAG_DESIRED;
> > | ~^~
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'i915_ttm_get_pages':
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c:837:26: note: 'places' declared here
> > 837 | struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
> > | ^~
> >
> > Caused by commit
> >
> > a78a8da51b36 ("drm/ttm: replace busy placement with flags v6")
>
> Cc: more people.
>
> >
> > I applied the following hack for today:
> >
> > From: Stephen Rothwell
> > Date: Tue, 6 Feb 2024 15:17:54 +1100
> > Subject: [PATCH] drm/ttm: initialise places
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index 80c6cafc8887..34e699e67c25 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -834,7 +834,7 @@ static int __i915_ttm_get_pages(struct
> > drm_i915_gem_object *obj,
> >
> > static int i915_ttm_get_pages(struct drm_i915_gem_object *obj)
> > {
> > - struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1];
> > + struct ttm_place places[I915_TTM_MAX_PLACEMENTS + 1] = {};
> > struct ttm_placement placement;
> >
> > /* restricted by sg_alloc_table */
> > --
> > 2.43.0
I am still applying the above patch ...
--
Cheers,
Stephen Rothwell
pgp1OxeTlxTbl.pgp
Description: OpenPGP digital signature
Re: [PATCH 8/8] arm64: dts: qcom: qrb2210-rb1: Enable the GPU
On 19.02.2024 15:49, Dmitry Baryshkov wrote: > On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote: >> >> Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol). > > Is it not? Sure, every electronic device is also a heater, I suppose.. I found this wording extremely funny though > >> >> [1] >> https://docs.qualcomm.com/bundle/publicresource/87-61720-1_REV_A_QUALCOMM_ROBOTICS_RB1_PLATFORM__QUALCOMM_QRB2210__PRODUCT_BRIEF.pdf >> Signed-off-by: Konrad Dybcio > > With the exception of the commit message: :( Konrad > > Reviewed-by: Dmitry Baryshkov > >> --- >> arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 8 >> 1 file changed, 8 insertions(+) > >
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Mon, Feb 19, 2024 at 3:00 AM Matt Coster wrote: > > Hi Adam, > > On 18/02/2024 23:26, Adam Ford wrote: > > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > >> > >> On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > >>> Hi Maxime Ripard, > >>> > -Original Message- > From: Maxime Ripard > Sent: Friday, February 16, 2024 9:05 AM > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on > ARCH_K3 > > On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > > Hi Adam Ford, > > > >> -Original Message- > >> From: Adam Ford > >> Sent: Thursday, February 15, 2024 11:36 PM > >> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend > >> on > >> ARCH_K3 > >> > >> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford wrote: > >>> > >>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > wrote: > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > wrote: > > > > Hi Maxime, > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > > > >> wrote: > >> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven > >> wrote: > >>> Using the Imagination Technologies PowerVR Series 6 GPU > >>> requires a proprietary firmware image, which is currently > >>> only available for Texas Instruments K3 AM62x SoCs. Hence > >>> add a dependency on ARCH_K3, to prevent asking the user > >>> about this driver when configuring a kernel without Texas > >>> Instruments K3 > >> Multicore SoC support. > >> > >> This wasn't making sense the first time you sent it, and now > >> that commit log is just plain wrong. We have firmwares for > >> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, > >> which can be found on (at least) Renesas, Mediatek, > >> Rockchip, TI and StarFive, so across three > > > > I am so happy to be proven wrong! > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > > R-Car M3- > >> W. > > > >> architectures and 5 platforms. In two months. > > > > That sounds like great progress, thanks a lot! > > > Geert, > > > Where can I find these firmwares? Linux-firmware[1] seems to > > lack all but the original K3 AM62x one. > > I think PowerVR has a repo [1], but the last time I checked it, > the BVNC for the firmware didn't match what was necessary for > the GX6250 on the RZ/G2M. I can't remember what the > corresponding R-Car3 model is. I haven't tried recently because > I was told more documentation for firmware porting would be > delayed until everything was pushed into the kernel and Mesa. > Maybe there is a better repo and/or newer firmware somewhere else. > > >>> I should have doubled checked the repo contents before I sent my > >>> last e-mail , but it appears the firmware [2] for the RZ/G2M, > >>> might be present now. I don't know if there are driver updates > >>> necessary. I checked my e-mails, but I didn't see any > >>> notification, or I would have tried it earlier. Either way, thank > >>> you Frank for adding it. I'll try to test when I have some time. > >>> > >> > >> I don't have the proper version of Mesa setup yet, but for what it's > >> worth, the firmware loads without error, and it doesn't hang. > > > > Based on [1] and [2], > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost as > > earlier version of RZ/G2L which uses drm based on RCar-Du, later changed > to rzg2l-du. > > IIRC, the mesa support isn't there yet for kmscube to start. > >>> > >>> What about glmark2? I tested glmark2 as well. > >> > >> It's not really a matter of kmscube itself, but the interaction with the > >> compositor entirely. You can run a headless vulkan rendering, but an > >> application that renders to a window won't work. > > > > I have made a little progress. I have Ubuntu running on an RZ/G2M > > (Rogue GX6250) with a device tree configuring the GPU and the GPU > > loads with firmware. > > > > powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw > > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS) > > [drm] Initialized powervr 1.0.0 20230904 for fd00.gpu on minor 0 > > > > drmdevice lists card0 and renderD128 > > --- Checking the number of DRM device available --- > > --- Devices reported 2 --- > > --- Retrieving devices information (PCI device revision is ignored) --- > > device[0] > > +-> available_nodes 0x05 > > +-> nodes > > | +-> nodes[0] /dev/dri/card0 > > | +-> nodes[2] /dev/dri/renderD128 > > +-> bustype 0002 > > | +-> platform > > | +-> ful
Re: [PATCH 3/3] drm/ci: mark universal-plane-sanity as failing on SC7180
On 19/02/2024 17:25, Helen Koike wrote: On 18/02/2024 01:12, Dmitry Baryshkov wrote: The test kms_universal_plane@universal-plane-sanity fails on both SC7180 platforms. The drm/msm returns -ERANGE as it can not handle passet scaling range, however the test is not ready to handle that. Mark the test as failing until it is fixed. ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Test assertion failure function sanity_test_pipe, file ../tests/kms_universal_plane.c:438: ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Failed assertion: drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id, output->config.crtc->crtc_id, test.oversized_fb.fb_id, 0, 0, 0, mode->hdisplay + 100, mode->vdisplay + 100, IGT_FIXED(0,0), IGT_FIXED(0,0), IGT_FIXED(mode->hdisplay,0), IGT_FIXED(mode->vdisplay,0)) == expect ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Last errno: 34, Numerical result out of range Signed-off-by: Dmitry Baryshkov Acked-by: Helen Koike Applied to drm-misc/drm-misc-next Thanks Helen --- .../gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt | 1 + .../drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt index 7e4d8744fcc6..f0576aa629e8 100644 --- a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt @@ -15,3 +15,4 @@ kms_plane_alpha_blend@alpha-7efc,Fail kms_plane_alpha_blend@coverage-7efc,Fail kms_plane_alpha_blend@coverage-vs-premult-vs-constant,Fail kms_rmfb@close-fd,Fail +kms_universal_plane@universal-plane-sanity,Fail diff --git a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt index 7e4d8744fcc6..f0576aa629e8 100644 --- a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt @@ -15,3 +15,4 @@ kms_plane_alpha_blend@alpha-7efc,Fail kms_plane_alpha_blend@coverage-7efc,Fail kms_plane_alpha_blend@coverage-vs-premult-vs-constant,Fail kms_rmfb@close-fd,Fail +kms_universal_plane@universal-plane-sanity,Fail
Re: [PATCH 2/3] drm/ci: update msm-apq8096-fails list
On 19/02/2024 17:26, Helen Koike wrote: On 18/02/2024 01:12, Dmitry Baryshkov wrote: Mark two tests as passing on the APQ8096 / db820c platform. Signed-off-by: Dmitry Baryshkov Acked-by: Helen Koike Applied to drm-misc/drm-misc-next Thanks Helen --- drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt b/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt index 2cd49e8ee47f..88a1fc0a3b0d 100644 --- a/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt @@ -1,4 +1,2 @@ kms_3d,Fail kms_addfb_basic@addfb25-bad-modifier,Fail -kms_force_connector_basic@force-edid,Fail -kms_hdmi_inject@inject-4k,Fail
Re: [PATCH 1/3] drm/ci: update IGT test names
On 19/02/2024 17:25, Helen Koike wrote: On 19/02/2024 14:42, Dmitry Baryshkov wrote: On Mon, 19 Feb 2024 at 18:48, Helen Koike wrote: On 19/02/2024 11:33, Dmitry Baryshkov wrote: On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote: Hi Dmitry, On 18/02/2024 01:12, Dmitry Baryshkov wrote: Since the addition of testlist.txt the IGT has changed some of test names. Some test names were changed to use '-' instead of '_'. In other cases tests were just renamed. Follow those changes. Signed-off-by: Dmitry Baryshkov Thanks for the patchset Do you have a pipeline link with those patches I can check? https://gitlab.freedesktop.org/drm/msm/-/pipelines/1106149/ I see two jobs failing, both had a timeout on the serial. msm:apq8016 had: Pass: 26, Fail: 1, ExpectedFail: 2, Skip: 1044, Duration: 17:40, Remaining: 27:48 but it didn't generate the fails.csv due to the timeout. In any case, should it also be updated on xfails? I could not get apq8016 to finish. Once it works in a stable way, I'll update corresponding xfails. Fair enough. We had apq8016 running well before, I wonder what happened. For this patch: Acked-by: Helen Koike Thanks Helen Applied to drm-misc/drm-misc-next Thanks Helen Regards, Helen Thanks Helen --- drivers/gpu/drm/ci/testlist.txt | 1888 ++- 1 file changed, 844 insertions(+), 1044 deletions(-) diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt index eaeb751bb0ad..3377f002f8c5 100644 --- a/drivers/gpu/drm/ci/testlist.txt +++ b/drivers/gpu/drm/ci/testlist.txt @@ -100,7 +100,7 @@ kms_atomic@plane-invalid-params-fence kms_atomic@crtc-invalid-params kms_atomic@crtc-invalid-params-fence kms_atomic@atomic-invalid-params -kms_atomic@atomic_plane_damage +kms_atomic@atomic-plane-damage kms_atomic_interruptible@legacy-setmode kms_atomic_interruptible@atomic-setmode kms_atomic_interruptible@legacy-dpms @@ -321,726 +321,726 @@ kms_bw@linear-tiling-7-displays-3840x2160p kms_bw@linear-tiling-8-displays-1920x1080p kms_bw@linear-tiling-8-displays-2560x1440p kms_bw@linear-tiling-8-displays-3840x2160p -kms_ccs@pipe-A-bad-pixel-format-y_tiled_ccs -kms_ccs@pipe-A-bad-pixel-format-yf_tiled_ccs -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-y_tiled_ccs -kms_ccs@pipe-A-bad-rotation-90-yf_tiled_ccs -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-y_tiled_ccs -kms_ccs@pipe-A-crc-primary-basic-yf_tiled_ccs -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-yf_tiled_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-y_tiled_ccs -kms_ccs@pipe-A-random-ccs-data-yf_tiled_ccs -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-random-
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The above w/a is required for every platform that the i915 driver
> supports. It is fixed on the latest platforms but they are only
> supported by Xe instead of i915. So just remove the platform check
> completely and keep the code simple.
Well, I was going to say that I would prefer a GMD version greater-than
check to be future proof. However if this code gets used in some other
new platform a new specific guc support would likely need to be added
as well right?
Perhaps at least adding a comment in the code?
with that
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 2b450c43bbd7f..a3662edb42032 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>
> /* Wa_14018913170 */
> if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
> IS_PONTEVECCHIO(gt->i915))
> - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> }
>
> return flags;
> --
> 2.43.0
>
Re: [PATCH 2/3] drm/ci: update msm-apq8096-fails list
On 18/02/2024 01:12, Dmitry Baryshkov wrote: Mark two tests as passing on the APQ8096 / db820c platform. Signed-off-by: Dmitry Baryshkov Acked-by: Helen Koike --- drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt b/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt index 2cd49e8ee47f..88a1fc0a3b0d 100644 --- a/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt @@ -1,4 +1,2 @@ kms_3d,Fail kms_addfb_basic@addfb25-bad-modifier,Fail -kms_force_connector_basic@force-edid,Fail -kms_hdmi_inject@inject-4k,Fail
Re: [PATCH 3/3] drm/ci: mark universal-plane-sanity as failing on SC7180
On 18/02/2024 01:12, Dmitry Baryshkov wrote: The test kms_universal_plane@universal-plane-sanity fails on both SC7180 platforms. The drm/msm returns -ERANGE as it can not handle passet scaling range, however the test is not ready to handle that. Mark the test as failing until it is fixed. ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Test assertion failure function sanity_test_pipe, file ../tests/kms_universal_plane.c:438: ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Failed assertion: drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id, output->config.crtc->crtc_id, test.oversized_fb.fb_id, 0, 0, 0, mode->hdisplay + 100, mode->vdisplay + 100, IGT_FIXED(0,0), IGT_FIXED(0,0), IGT_FIXED(mode->hdisplay,0), IGT_FIXED(mode->vdisplay,0)) == expect ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Last errno: 34, Numerical result out of range Signed-off-by: Dmitry Baryshkov Acked-by: Helen Koike --- .../gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt| 1 + .../drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt| 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt index 7e4d8744fcc6..f0576aa629e8 100644 --- a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-fails.txt @@ -15,3 +15,4 @@ kms_plane_alpha_blend@alpha-7efc,Fail kms_plane_alpha_blend@coverage-7efc,Fail kms_plane_alpha_blend@coverage-vs-premult-vs-constant,Fail kms_rmfb@close-fd,Fail +kms_universal_plane@universal-plane-sanity,Fail diff --git a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt index 7e4d8744fcc6..f0576aa629e8 100644 --- a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-fails.txt @@ -15,3 +15,4 @@ kms_plane_alpha_blend@alpha-7efc,Fail kms_plane_alpha_blend@coverage-7efc,Fail kms_plane_alpha_blend@coverage-vs-premult-vs-constant,Fail kms_rmfb@close-fd,Fail +kms_universal_plane@universal-plane-sanity,Fail
Re: [PATCH 1/3] drm/ci: update IGT test names
On 19/02/2024 14:42, Dmitry Baryshkov wrote: On Mon, 19 Feb 2024 at 18:48, Helen Koike wrote: On 19/02/2024 11:33, Dmitry Baryshkov wrote: On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote: Hi Dmitry, On 18/02/2024 01:12, Dmitry Baryshkov wrote: Since the addition of testlist.txt the IGT has changed some of test names. Some test names were changed to use '-' instead of '_'. In other cases tests were just renamed. Follow those changes. Signed-off-by: Dmitry Baryshkov Thanks for the patchset Do you have a pipeline link with those patches I can check? https://gitlab.freedesktop.org/drm/msm/-/pipelines/1106149/ I see two jobs failing, both had a timeout on the serial. msm:apq8016 had: Pass: 26, Fail: 1, ExpectedFail: 2, Skip: 1044, Duration: 17:40, Remaining: 27:48 but it didn't generate the fails.csv due to the timeout. In any case, should it also be updated on xfails? I could not get apq8016 to finish. Once it works in a stable way, I'll update corresponding xfails. Fair enough. We had apq8016 running well before, I wonder what happened. For this patch: Acked-by: Helen Koike Thanks Helen Regards, Helen Thanks Helen --- drivers/gpu/drm/ci/testlist.txt | 1888 ++- 1 file changed, 844 insertions(+), 1044 deletions(-) diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt index eaeb751bb0ad..3377f002f8c5 100644 --- a/drivers/gpu/drm/ci/testlist.txt +++ b/drivers/gpu/drm/ci/testlist.txt @@ -100,7 +100,7 @@ kms_atomic@plane-invalid-params-fence kms_atomic@crtc-invalid-params kms_atomic@crtc-invalid-params-fence kms_atomic@atomic-invalid-params -kms_atomic@atomic_plane_damage +kms_atomic@atomic-plane-damage kms_atomic_interruptible@legacy-setmode kms_atomic_interruptible@atomic-setmode kms_atomic_interruptible@legacy-dpms @@ -321,726 +321,726 @@ kms_bw@linear-tiling-7-displays-3840x2160p kms_bw@linear-tiling-8-displays-1920x1080p kms_bw@linear-tiling-8-displays-2560x1440p kms_bw@linear-tiling-8-displays-3840x2160p -kms_ccs@pipe-A-bad-pixel-format-y_tiled_ccs -kms_ccs@pipe-A-bad-pixel-format-yf_tiled_ccs -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-y_tiled_ccs -kms_ccs@pipe-A-bad-rotation-90-yf_tiled_ccs -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-y_tiled_ccs -kms_ccs@pipe-A-crc-primary-basic-yf_tiled_ccs -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-yf_tiled_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-y_tiled_ccs -kms_ccs@pipe-A-random-ccs-data-yf_tiled_ccs -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-random
[PATCH v2] drm/bridge: adv7511: fix crash on irq during probe
From: Mads Bligaard Nielsen
Moved IRQ registration down to end of adv7511_probe().
If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:
Unable to handle kernel read from unreadable memory at virtual address
03d5
Internal error: Oops: 9604 [#1] PREEMPT_RT SMP
Call trace:
cec_received_msg_ts+0x48/0x990 [cec]
adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
adv7511_irq_process+0xd8/0x120 [adv7511]
adv7511_irq_handler+0x1c/0x30 [adv7511]
irq_thread_fn+0x30/0xa0
irq_thread+0x14c/0x238
kthread+0x190/0x1a8
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Mads Bligaard Nielsen
Signed-off-by: Alvin Šipraga
---
Changes in v2:
- rebase on latest drm-misc-fixes
- no other changes
- RESEND
- Link to v1:
https://lore.kernel.org/r/20231014-adv7511-cec-irq-crash-fix-v1-1-3389486c8...@bang-olufsen.dk
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8be235144f6d..6fc292393c67 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1277,17 +1277,6 @@ static int adv7511_probe(struct i2c_client *i2c)
INIT_WORK(&adv7511->hpd_work, adv7511_hpd_work);
- if (i2c->irq) {
- init_waitqueue_head(&adv7511->wq);
-
- ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
- adv7511_irq_handler,
- IRQF_ONESHOT, dev_name(dev),
- adv7511);
- if (ret)
- goto err_unregister_cec;
- }
-
adv7511_power_off(adv7511);
i2c_set_clientdata(i2c, adv7511);
@@ -1311,6 +1300,17 @@ static int adv7511_probe(struct i2c_client *i2c)
adv7511_audio_init(dev, adv7511);
+ if (i2c->irq) {
+ init_waitqueue_head(&adv7511->wq);
+
+ ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
+ adv7511_irq_handler,
+ IRQF_ONESHOT, dev_name(dev),
+ adv7511);
+ if (ret)
+ goto err_unregister_audio;
+ }
+
if (adv7511->info->has_dsi) {
ret = adv7533_attach_dsi(adv7511);
if (ret)
---
base-commit: 335126937753844d36036984e96a8f343538a778
change-id: 20231014-adv7511-cec-irq-crash-fix-6fdd9093dc7a
[PATCH v3 1/2] drm/bridge: adv7511: rearrange hotplug work code
From: Alvin Šipraga
In preparation for calling EDID helpers from the hotplug work, move the
hotplug work below the EDID helper section. No functional change.
Reviewed-by: Robert Foss
Signed-off-by: Alvin Šipraga
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 120 ++-
1 file changed, 62 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8be235144f6d..5ffc5904bd59 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -406,64 +406,6 @@ static void adv7511_power_off(struct adv7511 *adv7511)
* Interrupt and hotplug detection
*/
-static bool adv7511_hpd(struct adv7511 *adv7511)
-{
- unsigned int irq0;
- int ret;
-
- ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), &irq0);
- if (ret < 0)
- return false;
-
- if (irq0 & ADV7511_INT0_HPD) {
- regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-ADV7511_INT0_HPD);
- return true;
- }
-
- return false;
-}
-
-static void adv7511_hpd_work(struct work_struct *work)
-{
- struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
- enum drm_connector_status status;
- unsigned int val;
- int ret;
-
- ret = regmap_read(adv7511->regmap, ADV7511_REG_STATUS, &val);
- if (ret < 0)
- status = connector_status_disconnected;
- else if (val & ADV7511_STATUS_HPD)
- status = connector_status_connected;
- else
- status = connector_status_disconnected;
-
- /*
-* The bridge resets its registers on unplug. So when we get a plug
-* event and we're already supposed to be powered, cycle the bridge to
-* restore its state.
-*/
- if (status == connector_status_connected &&
- adv7511->connector.status == connector_status_disconnected &&
- adv7511->powered) {
- regcache_mark_dirty(adv7511->regmap);
- adv7511_power_on(adv7511);
- }
-
- if (adv7511->connector.status != status) {
- adv7511->connector.status = status;
-
- if (adv7511->connector.dev) {
- if (status == connector_status_disconnected)
- cec_phys_addr_invalidate(adv7511->cec_adap);
- drm_kms_helper_hotplug_event(adv7511->connector.dev);
- } else {
- drm_bridge_hpd_notify(&adv7511->bridge, status);
- }
- }
-}
-
static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
{
unsigned int irq0, irq1;
@@ -600,6 +542,68 @@ static int adv7511_get_edid_block(void *data, u8 *buf,
unsigned int block,
return 0;
}
+/*
-
+ * Hotplug handling
+ */
+
+static bool adv7511_hpd(struct adv7511 *adv7511)
+{
+ unsigned int irq0;
+ int ret;
+
+ ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), &irq0);
+ if (ret < 0)
+ return false;
+
+ if (irq0 & ADV7511_INT0_HPD) {
+ regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
+ADV7511_INT0_HPD);
+ return true;
+ }
+
+ return false;
+}
+
+static void adv7511_hpd_work(struct work_struct *work)
+{
+ struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
+ enum drm_connector_status status;
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(adv7511->regmap, ADV7511_REG_STATUS, &val);
+ if (ret < 0)
+ status = connector_status_disconnected;
+ else if (val & ADV7511_STATUS_HPD)
+ status = connector_status_connected;
+ else
+ status = connector_status_disconnected;
+
+ /*
+* The bridge resets its registers on unplug. So when we get a plug
+* event and we're already supposed to be powered, cycle the bridge to
+* restore its state.
+*/
+ if (status == connector_status_connected &&
+ adv7511->connector.status == connector_status_disconnected &&
+ adv7511->powered) {
+ regcache_mark_dirty(adv7511->regmap);
+ adv7511_power_on(adv7511);
+ }
+
+ if (adv7511->connector.status != status) {
+ adv7511->connector.status = status;
+
+ if (adv7511->connector.dev) {
+ if (status == connector_status_disconnected)
+ cec_phys_addr_invalidate(adv7511->cec_adap);
+ drm_kms_helper_hotplug_event(adv7511->connector.dev);
+ } else {
+ drm_bridge_hpd_notify(&adv7511->bridge, status);
+ }
+ }
+}
+
/*
--
[PATCH v3 2/2] drm/bridge: adv7511: get edid in hpd_work to update CEC phys address
From: Alvin Šipraga
The adv7511 driver is solely responsible for setting the physical
address of its CEC adapter. To do this, it must read the EDID. However,
EDID is only read when either the drm_bridge_funcs :: get_edid or
drm_connector_helper_funcs :: get_modes ops are called. Without loss of
generality, it cannot be assumed that these ops are called when a sink
gets attached. Therefore there exist scenarios in which the CEC physical
address will be invalid (f.f.f.f), rendering the CEC adapter inoperable.
Address this problem by always fetching the EDID in the HPD work when we
detect a connection. The CEC physical address is set in the process.
This is done by moving the EDID DRM helper into an internal helper
function so that it can be cleanly called from an earlier section of
the code. The EDID getter has not changed in practice.
Reviewed-by: Robert Foss
Signed-off-by: Alvin Šipraga
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 73 ++--
1 file changed, 47 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 5ffc5904bd59..d823b372ff43 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -542,6 +542,36 @@ static int adv7511_get_edid_block(void *data, u8 *buf,
unsigned int block,
return 0;
}
+static struct edid *__adv7511_get_edid(struct adv7511 *adv7511,
+ struct drm_connector *connector)
+{
+ struct edid *edid;
+
+ /* Reading the EDID only works if the device is powered */
+ if (!adv7511->powered) {
+ unsigned int edid_i2c_addr =
+ (adv7511->i2c_edid->addr << 1);
+
+ __adv7511_power_on(adv7511);
+
+ /* Reset the EDID_I2C_ADDR register as it might be cleared */
+ regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+edid_i2c_addr);
+ }
+
+ edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
+
+ if (!adv7511->powered)
+ __adv7511_power_off(adv7511);
+
+ adv7511_set_config_csc(adv7511, connector, adv7511->rgb,
+ drm_detect_hdmi_monitor(edid));
+
+ cec_s_phys_addr_from_edid(adv7511->cec_adap, edid);
+
+ return edid;
+}
+
/*
-
* Hotplug handling
*/
@@ -595,8 +625,23 @@ static void adv7511_hpd_work(struct work_struct *work)
adv7511->connector.status = status;
if (adv7511->connector.dev) {
- if (status == connector_status_disconnected)
+ if (status == connector_status_disconnected) {
cec_phys_addr_invalidate(adv7511->cec_adap);
+ } else {
+ struct edid *edid;
+
+ /*
+* Get the updated EDID so that the CEC
+* subsystem gets informed of any change in CEC
+* address. The helper returns a newly allocated
+* edid structure, so free it to prevent
+* leakage.
+*/
+ edid = __adv7511_get_edid(adv7511,
+ &adv7511->connector);
+ kfree(edid);
+ }
+
drm_kms_helper_hotplug_event(adv7511->connector.dev);
} else {
drm_bridge_hpd_notify(&adv7511->bridge, status);
@@ -611,31 +656,7 @@ static void adv7511_hpd_work(struct work_struct *work)
static struct edid *adv7511_get_edid(struct adv7511 *adv7511,
struct drm_connector *connector)
{
- struct edid *edid;
-
- /* Reading the EDID only works if the device is powered */
- if (!adv7511->powered) {
- unsigned int edid_i2c_addr =
- (adv7511->i2c_edid->addr << 1);
-
- __adv7511_power_on(adv7511);
-
- /* Reset the EDID_I2C_ADDR register as it might be cleared */
- regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
-edid_i2c_addr);
- }
-
- edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
-
- if (!adv7511->powered)
- __adv7511_power_off(adv7511);
-
- adv7511_set_config_csc(adv7511, connector, adv7511->rgb,
- drm_detect_hdmi_monitor(edid));
-
- cec_s_phys_addr_from_edid(adv7511->cec_adap, edid);
-
- return edid;
+ return __adv7511_get_edid(adv7511, connector);
}
static int adv7511_g
[PATCH v3 0/2] drm/bridge: adv7511: get edid in hpd_work to update CEC phys address
This series fixes a small bug where the CEC adapter could have an invalid CEC address even though we got a hotplug connect and could have read it. Signed-off-by: Alvin Šipraga --- Changes in v3: - rebase on latest drm-misc-fixes - remove redundant NULL check before kfree() - collect Robert's Reviewed-by - Link to v2: https://lore.kernel.org/r/20231124-adv7511-cec-edid-v2-0-f0e5eeafd...@bang-olufsen.dk Changes in v2: - Rearrange driver code to avoid the previous prototype of adv7511_get_edid(), per Laurent's feedback - Free the returned EDID to prevent a memory leak, per Jani's comment - Link to v1: https://lore.kernel.org/r/20231014-adv7511-cec-edid-v1-1-a58ceae0b...@bang-olufsen.dk --- Alvin Šipraga (2): drm/bridge: adv7511: rearrange hotplug work code drm/bridge: adv7511: get edid in hpd_work to update CEC phys address drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 153 --- 1 file changed, 89 insertions(+), 64 deletions(-) --- base-commit: 335126937753844d36036984e96a8f343538a778 change-id: 20231014-adv7511-cec-edid-ff75bd3ac929
Re: [PATCH] drm/i915: check before removing mm notifier
On Mon, Feb 19, 2024 at 01:50:47PM +0100, Nirmoy Das wrote:
> Error in mmu_interval_notifier_insert() can leave a NULL
> notifier.mm pointer. Catch that and return early.
>
> Cc: Andi Shyti
> Cc: Shawn Lee
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 0e21ce9d3e5a..61abfb505766 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -349,6 +349,9 @@ i915_gem_userptr_release(struct drm_i915_gem_object *obj)
> {
> GEM_WARN_ON(obj->userptr.page_ref);
>
> + if (!obj->userptr.notifier.mm)
> + return;
> +
hmmm... right, it looks that we need this protection. But...
I mean, feel free to use
Reviewed-by: Rodrigo Vivi
for this patch,
but I believe that if this mmu insert failed we might have other
deeper problems like when checking i915_gem_object_is_userptr() ?
No?!
> mmu_interval_notifier_remove(&obj->userptr.notifier);
> obj->userptr.notifier.mm = NULL;
> }
> --
> 2.42.0
>
Re: [PATCH] drm/i915: Fix possible null pointer dereference after drm_dbg_printer conversion
On Mon, Feb 19, 2024 at 01:14:23PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Request can be NULL if no guilty request was identified so simply use
> engine->i915 instead.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: d50892a9554c ("drm/i915: switch from drm_debug_printer() to device
> specific drm_dbg_printer()")
> Reported-by: Dan Carpenter
> Cc: Jani Nikula
> Cc: Luca Coelho
> Cc: Maxime Ripard
> Cc: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 5f8d86e25993..8d4bb95f8424 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -96,8 +96,8 @@ static void heartbeat_commit(struct i915_request *rq,
> static void show_heartbeat(const struct i915_request *rq,
> struct intel_engine_cs *engine)
> {
> - struct drm_printer p = drm_dbg_printer(&rq->i915->drm, DRM_UT_DRIVER,
> -"heartbeat");
> + struct drm_printer p =
> + drm_dbg_printer(&engine->i915->drm, DRM_UT_DRIVER, "heartbeat");
>
> if (!rq) {
> intel_engine_dump(engine, &p,
> --
> 2.40.1
>
[PATCH] accel: constify the struct device_type usage
Since commit aed65af1cc2f ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the
accel_sysfs_device_minor variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman
Signed-off-by: Ricardo B. Marliere
---
drivers/accel/drm_accel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
index 24cac4c0274b..16c3edb8c46e 100644
--- a/drivers/accel/drm_accel.c
+++ b/drivers/accel/drm_accel.c
@@ -23,7 +23,7 @@ static struct idr accel_minors_idr;
static struct dentry *accel_debugfs_root;
-static struct device_type accel_sysfs_device_minor = {
+static const struct device_type accel_sysfs_device_minor = {
.name = "accel_minor"
};
---
base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d
change-id: 20240219-device_cleanup-accel-a990dc3bfbc1
Best regards,
--
Ricardo B. Marliere
Re: [PATCH] drm: rockchip: Don't require MIPI DSI device when it's used for ISP
On Mon, Feb 19, 2024 at 11:02:01AM +0800, Andy Yan wrote:
> Hi Ondrej:
>
> On 2/18/24 23:17, Ondřej Jirman wrote:
> > Hi Andy,
> >
> > On Sun, Feb 18, 2024 at 07:14:56PM +0800, Andy Yan wrote:
> > > Hi,
> > >
> > > On 2/18/24 02:39, Ondřej Jirman wrote:
> > > > From: Ondrej Jirman
> > > >
> > > > On RK3399 one MIPI DSI device can be alternatively used with the ISP1,
> > > > to provide RX DPHY. When this is the case (ISP1 is enabled in device
> > > > tree), probe success of DRM is tied to probe success of ISP1 connected
> > > > camera sensor. This can fail if the user is able to killswitch the
> > > > camera
> > > > power, like on Pinephone Pro.
> > > >
> > > > Detect use of MIPI DSI controller by ISP, and don't include it in
> > > > component match list in that case.
> > > >
> > >
> > > Isn't this supposed to be taken care of within the dts?
> > > Since DPHY1 should exclusively used by MIPI DSI1 and ISP1, then if
> > > a device want to use ISP1, the DSI1 should be disabled in dts.
> >
> > DSI1 can't be disabled, because it provides PHY device for ISP1 in this
> > scenario.
> >
> > The problem is that in this scenario DRM keeps waiting for DSI1 device,
> > despite it just being used for PHY for ISP1 and not as a component for
> > rockchip DRM driver.
>
>
> Oh, get it.
> With a quick look, seems that Heiko has already take this scenario into
> consideration
> when add PHY function in the dsi drivers[0]
> Does this mean the current drivers does not work as expected?
It didn't work anymore since some fw devlink changes that were added some
time after 2021. But it might have got resolved since than.
So please ignore this patch for now.
kind regards,
o.
> [0]https://patchwork.freedesktop.org/patch/420386/
> >
> > See:
> >
> > isp1: isp1@ff92 {
> > compatible = "rockchip,rk3399-cif-isp";
> > reg = <0x0 0xff92 0x0 0x4000>;
> > interrupts = ;
> > clocks = <&cru SCLK_ISP1>,
> > <&cru ACLK_ISP1_WRAPPER>,
> > <&cru HCLK_ISP1_WRAPPER>;
> > clock-names = "isp", "aclk", "hclk";
> > iommus = <&isp1_mmu>;
> > phys = <&mipi_dsi1>; <-
> > phy-names = "dphy";
> > power-domains = <&power RK3399_PD_ISP1>;
> > status = "disabled";
> >
> > If mipi_dsi1 is disabled, isp1 will never probe.
> >
> > It's a consequence of this special dual use of mipi_dsi1.
> >
> > kind regards,
> > o.
> >
> > > > Signed-off-by: Ondrej Jirman
> > > > ---
> > > >drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 47
> > > > +
> > > >1 file changed, 47 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > > index ab55d7132550..f47de94ad576 100644
> > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > > @@ -354,6 +354,43 @@ static void rockchip_drm_match_remove(struct
> > > > device *dev)
> > > > device_link_del(link);
> > > >}
> > > > +/*
> > > > + * Check if ISP block linked to a mipi-dsi device via phys phandle is
> > > > + * enabled in device tree.
> > > > + */
> > > > +static bool rockchip_drm_is_mipi1_and_used_by_isp(struct device *dev)
> > > > +{
> > > > + struct device_node *np = NULL, *phy_np;
> > > > +
> > > > + if (!of_device_is_compatible(dev->of_node,
> > > > "rockchip,rk3399-mipi-dsi"))
> > > > + return false;
> > > > +
> > > > + while (true) {
> > > > + np = of_find_compatible_node(np, NULL,
> > > > "rockchip,rk3399-cif-isp");
> > > > + if (!np)
> > > > + break;
> > > > +
> > > > + if (!of_device_is_available(np)) {
> > > > + of_node_put(np);
> > > > + continue;
> > > > + }
> > > > +
> > > > + phy_np = of_parse_phandle(np, "phys", 0);
> > > > + if (!phy_np) {
> > > > + of_node_put(np);
> > > > + continue;
> > > > + }
> > > > +
> > > > + of_node_put(phy_np);
> > > > + of_node_put(np);
> > > > +
> > > > + if (phy_np == dev->of_node)
> > > > + return true;
> > > > + }
> > > > +
> > > > + return false;
> > > > +}
> > > > +
> > > >static struct component_match *rockchip_drm_match_add(struct device
> > > > *dev)
> > > >{
> > > > struct component_match *match = NULL;
> > > > @@ -371,6 +408,16 @@ static struct component_match
> > > > *rockchip_drm_match_add(struct device *dev)
> > > > if (!d)
> > > > break;
> > > > + /*
> > > > +* If mi
Re: [PATCH v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory
On 2/18/24 11:46, Christophe JAILLET wrote:
If 'list_limit' is set to a very high value, 'lsize' computation could
overflow if 'head.count' is big enough.
In such a case, udmabuf_create() would access to memory beyond 'list'.
Use memdup_array_user() which checks for overflow.
While at it, include .
Fixes: fbb0de795078 ("Add udmabuf misc device")'
I don't think this tag is needed in this case.
Also, please, CC linux-hardening next time.
Signed-off-by: Christophe JAILLET
In any case, LGTM:
Reviewed-by: Gustavo A. R. Silva
Thanks!
--
Gustavo
---
v2: - Use memdup_array_user() [Kees Cook]
- Use sizeof(*list) [Gustavo A. R. Silva]
- Add include
v1:
https://lore.kernel.org/all/3e37f05c7593f1016f0a46de188b3357cbbd0c0b.1695060389.git.christophe.jail...@wanadoo.fr/
Signed-off-by: Christophe JAILLET
---
drivers/dma-buf/udmabuf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c40645999648..5728948ea6f2 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -314,14 +315,13 @@ static long udmabuf_ioctl_create_list(struct file *filp,
unsigned long arg)
struct udmabuf_create_list head;
struct udmabuf_create_item *list;
int ret = -EINVAL;
- u32 lsize;
if (copy_from_user(&head, (void __user *)arg, sizeof(head)))
return -EFAULT;
if (head.count > list_limit)
return -EINVAL;
- lsize = sizeof(struct udmabuf_create_item) * head.count;
- list = memdup_user((void __user *)(arg + sizeof(head)), lsize);
+ list = memdup_array_user((void __user *)(arg + sizeof(head)),
+sizeof(*list), head.count);
if (IS_ERR(list))
return PTR_ERR(list);
Re: [PATCH] dma-buf: Add syntax highlighting to code listings in the document
Kindly ping :) On Fri, Jan 19, 2024 at 11:33 AM Tommy Chiang wrote: > > This patch tries to improve the display of the code listing > on The Linux Kernel documentation website for dma-buf [1] . > > Originally, it appears that it was attempting to escape > the '*' character, but looks like it's not necessary (now), > so we are seeing something like '\*' on the webite. > > This patch removes these unnecessary backslashes and adds syntax > highlighting to improve the readability of the code listing. > > [1] https://docs.kernel.org/driver-api/dma-buf.html > > Signed-off-by: Tommy Chiang > --- > drivers/dma-buf/dma-buf.c | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 8fe5aa67b167..e083a0ab06d7 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1282,10 +1282,12 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF); > * vmap interface is introduced. Note that on very old 32-bit architectures > * vmalloc space might be limited and result in vmap calls failing. > * > - * Interfaces:: > + * Interfaces: > * > - * void \*dma_buf_vmap(struct dma_buf \*dmabuf, struct iosys_map \*map) > - * void dma_buf_vunmap(struct dma_buf \*dmabuf, struct iosys_map \*map) > + * .. code-block:: c > + * > + * void *dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) > + * void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) > * > * The vmap call can fail if there is no vmap support in the exporter, or > if > * it runs out of vmalloc space. Note that the dma-buf layer keeps a > reference > @@ -1342,10 +1344,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF); > * enough, since adding interfaces to intercept pagefaults and allow pte > * shootdowns would increase the complexity quite a bit. > * > - * Interface:: > + * Interface: > + * > + * .. code-block:: c > * > - * int dma_buf_mmap(struct dma_buf \*, struct vm_area_struct \*, > - *unsigned long); > + * int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned > long); > * > * If the importing subsystem simply provides a special-purpose mmap call > to > * set up a mapping in userspace, calling do_mmap with &dma_buf.file will > -- > 2.43.0.381.gb435a96ce8-goog >
Re: [PATCH v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory
Le 19/02/2024 à 09:37, Dan Carpenter a écrit : On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote: If 'list_limit' is set to a very high value, 'lsize' computation could overflow if 'head.count' is big enough. The "list_limit" is set via module parameter so if you set that high enough to lead to an integer overflow then you kind of deserve what you get. This patch is nice for kernel hardening and making the code easier to read/audit but the real world security impact is negligible. Agreed. That is what I meant by "and unlikely". Maybe the commit message could be more explicit if needed. Let me know if ok as-is or if I should try to re-word the description. CJ regards, dan carpenter
Re: [PATCH v5] drm/dp: add an API to indicate if sink supports VSC SDP
Hi DRM maintainers
Gentle ping for reviews on this one.
Since the dependent series is mostly complete, would like to get your
reviews on this one to land it.
Thanks
Abhinav
On 2/15/2024 11:15 AM, Abhinav Kumar wrote:
From: Paloma Arellano
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
changes in v5:
- rebased on top of drm-tip
changes in v4:
- bail out early if dpcd rev check fails
changes in v3:
- fix the commit title prefix to drm/dp
- get rid of redundant !!
- break out this change from series [1] to get acks from drm core
maintainers
Changes in v2:
- Move VSC SDP support check API from dp_panel.c to
drm_dp_helper.c
[1]: https://patchwork.freedesktop.org/series/129180/
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Paloma Arellano
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 23 +++
include/drm/display/drm_dp_helper.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..61b11cb45245 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,29 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_supported() - check if vsc sdp is supported
+ * @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
+ *
+ * Returns true if vsc sdp is supported, else returns false
+ */
+bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 rx_feature;
+
+ if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_13)
+ return false;
+
+ if (drm_dp_dpcd_readb(aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
&rx_feature) != 1) {
+ drm_dbg_dp(aux->drm_dev, "failed to read
DP_DPRX_FEATURE_ENUMERATION_LIST\n");
+ return false;
+ }
+
+ return (rx_feature & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED);
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_supported);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index d02014a87f12..36351f3cdba9 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -100,6 +100,8 @@ struct drm_dp_vsc_sdp {
void drm_dp_vsc_sdp_log(struct drm_printer *p, const struct drm_dp_vsc_sdp *vsc);
+bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
+
int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
static inline int
Re: [PATCH 1/6] drm/bridge: aux-hpd: fix OF node leaks
> The two device node references taken during allocation need to be
> dropped when the auxiliary device is freed.
…
> +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
…
> @@ -74,6 +75,8 @@ struct device *drm_dp_hpd_bridge_register(struct device
> *parent,
>
> ret = auxiliary_device_init(adev);
> if (ret) {
> + of_node_put(adev->dev.platform_data);
> + of_node_put(adev->dev.of_node);
> ida_free(&drm_aux_hpd_bridge_ida, adev->id);
> kfree(adev);
> return ERR_PTR(ret);
The last two statements are also used in a previous if branch.
https://elixir.bootlin.com/linux/v6.8-rc5/source/drivers/gpu/drm/bridge/aux-hpd-bridge.c#L63
How do you think about to avoid such a bit of duplicate source code
by adding a label here?
Regards,
Markus
Re: [PATCH 1/3] drm/ci: update IGT test names
On Mon, 19 Feb 2024 at 18:48, Helen Koike wrote: > > > > On 19/02/2024 11:33, Dmitry Baryshkov wrote: > > On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote: > >> > >> Hi Dmitry, > >> > >> > >> On 18/02/2024 01:12, Dmitry Baryshkov wrote: > >>> Since the addition of testlist.txt the IGT has changed some of test > >>> names. Some test names were changed to use '-' instead of '_'. In other > >>> cases tests were just renamed. Follow those changes. > >>> > >>> Signed-off-by: Dmitry Baryshkov > >> > >> Thanks for the patchset > >> > >> Do you have a pipeline link with those patches I can check? > > > > https://gitlab.freedesktop.org/drm/msm/-/pipelines/1106149/ > > I see two jobs failing, both had a timeout on the serial. > > msm:apq8016 had: > > Pass: 26, Fail: 1, ExpectedFail: 2, Skip: 1044, Duration: 17:40, > Remaining: 27:48 > > but it didn't generate the fails.csv due to the timeout. > > In any case, should it also be updated on xfails? I could not get apq8016 to finish. Once it works in a stable way, I'll update corresponding xfails. > > Regards, > Helen > > > > >> > >> Thanks > >> Helen > >> > >>> --- > >>>drivers/gpu/drm/ci/testlist.txt | 1888 ++- > >>>1 file changed, 844 insertions(+), 1044 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/ci/testlist.txt > >>> b/drivers/gpu/drm/ci/testlist.txt > >>> index eaeb751bb0ad..3377f002f8c5 100644 > >>> --- a/drivers/gpu/drm/ci/testlist.txt > >>> +++ b/drivers/gpu/drm/ci/testlist.txt > >>> @@ -100,7 +100,7 @@ kms_atomic@plane-invalid-params-fence > >>>kms_atomic@crtc-invalid-params > >>>kms_atomic@crtc-invalid-params-fence > >>>kms_atomic@atomic-invalid-params > >>> -kms_atomic@atomic_plane_damage > >>> +kms_atomic@atomic-plane-damage > >>>kms_atomic_interruptible@legacy-setmode > >>>kms_atomic_interruptible@atomic-setmode > >>>kms_atomic_interruptible@legacy-dpms > >>> @@ -321,726 +321,726 @@ kms_bw@linear-tiling-7-displays-3840x2160p > >>>kms_bw@linear-tiling-8-displays-1920x1080p > >>>kms_bw@linear-tiling-8-displays-2560x1440p > >>>kms_bw@linear-tiling-8-displays-3840x2160p > >>> -kms_ccs@pipe-A-bad-pixel-format-y_tiled_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-yf_tiled_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs_cc > >>> -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_mc_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_mc_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs_cc > >>> -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_mc_ccs > >>> -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs_cc > >>> -kms_ccs@pipe-A-bad-rotation-90-y_tiled_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-yf_tiled_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs_cc > >>> -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_mc_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_mc_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs_cc > >>> -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_mc_ccs > >>> -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs_cc > >>> -kms_ccs@pipe-A-crc-primary-basic-y_tiled_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-yf_tiled_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs_cc > >>> -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_mc_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_mc_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs_cc > >>> -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_mc_ccs > >>> -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs_cc > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-yf_tiled_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_mc_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_mc_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_mc_ccs > >>> -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs_cc > >>> -kms_ccs@pipe-A-random-ccs-data-y_tiled_ccs > >>> -kms_ccs@pipe-A-random-ccs-data-yf_tiled_ccs > >>> -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs > >>> -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Adam, On 19/02/2024 16:38, Adam Ford wrote: > On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote: >> >> Hi Adam, >> >>> -Original Message- >>> From: Adam Ford >>> Sent: Sunday, February 18, 2024 11:26 PM >>> Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend >>> on ARCH_K3 >>> >>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > Hi Maxime Ripard, > >> -Original Message- >> From: Maxime Ripard >> Sent: Friday, February 16, 2024 9:05 AM >> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should >> depend on >> ARCH_K3 >> >> On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: >>> Hi Adam Ford, >>> -Original Message- From: Adam Ford Sent: Thursday, February 15, 2024 11:36 PM Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3 On Thu, Feb 15, 2024 at 11:22 AM Adam Ford >>> wrote: > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > >> wrote: >> >> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven >> wrote: >>> >>> Hi Maxime, >>> >>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard >>> wrote: On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote: > Using the Imagination Technologies PowerVR Series 6 > GPU requires a proprietary firmware image, which is > currently only available for Texas Instruments K3 > AM62x SoCs. Hence add a dependency on ARCH_K3, to > prevent asking the user about this driver when > configuring a kernel without Texas Instruments K3 Multicore SoC support. This wasn't making sense the first time you sent it, and now that commit log is just plain wrong. We have firmwares for the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least) Renesas, Mediatek, Rockchip, TI and StarFive, so across three >>> >>> I am so happy to be proven wrong! >>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. >>> R-Car M3- W. >>> architectures and 5 platforms. In two months. >>> >>> That sounds like great progress, thanks a lot! >>> >> Geert, >> >>> Where can I find these firmwares? Linux-firmware[1] >>> seems to lack all but the original K3 AM62x one. >> >> I think PowerVR has a repo [1], but the last time I >> checked it, the BVNC for the firmware didn't match what >> was necessary for the GX6250 on the RZ/G2M. I can't >> remember what the corresponding R-Car3 model is. I >> haven't tried recently because I was told more >> documentation for firmware porting would be delayed until >>> everything was pushed into the kernel and Mesa. >> Maybe there is a better repo and/or newer firmware somewhere >>> else. >> > I should have doubled checked the repo contents before I > sent my last e-mail , but it appears the firmware [2] for > the RZ/G2M, might be present now. I don't know if there are > driver updates necessary. I checked my e-mails, but I didn't > see any notification, or I would have tried it earlier. > Either way, thank you Frank for adding it. I'll try to test >>> when I have some time. > I don't have the proper version of Mesa setup yet, but for what it's worth, the firmware loads without error, and it >>> doesn't hang. >>> >>> Based on [1] and [2], >>> >>> kmscube should work on R-Car as it works on RZ/G2L with panfrost >>> as earlier version of RZ/G2L which uses drm based on RCar-Du, >>> later changed >> to rzg2l-du. >> >> IIRC, the mesa support isn't there yet for kmscube to start. > > What about glmark2? I tested glmark2 as well. It's not really a matter of kmscube itself, but the interaction with the compositor entirely. You can run a headless vulkan rendering, but an application that renders to a window won't work. >>> >>> I have made a little progress. I have Ubuntu running on an RZ/G2M (Rogue >>> GX6250) with a device tree configuring the GPU and the GPU loads with >>> firmware. >>> >>> powervr fd00.gpu: [drm] loaded firmware >>> powervr/rogue_4.45.2.58_v1.fw >>> powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS) >>> [drm] Initialized powervr 1.0.0 20230904 for fd00.gpu on minor 0 >>> >>> drmdevice lists card0 and renderD128 >>> --- Checking the number of DRM device available --- >>> --- Devices reporte
Re: [PATCH] drm/ci: skip suspend tests for both msm-sc7180 machines
On 19/02/2024 11:47, Vignesh Raman wrote:
On 17/02/24 02:26, Dmitry Baryshkov wrote:
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM
tests. However testing shows that STR tests still can fail. Restore the
skiplist, applying it to both limozeen and kingoftown machines.
Fixes: ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt | 2 ++
.../drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt | 2 ++
2 files changed, 4 insertions(+)
create mode 100644
drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
create mode 100644
drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
diff --git
a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
new file mode 100644
index ..327039f70252
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
@@ -0,0 +1,2 @@
+# Suspend to RAM seems to be broken on this machine
+.*suspend.*
diff --git
a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
new file mode 100644
index ..327039f70252
--- /dev/null
+++
b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
@@ -0,0 +1,2 @@
+# Suspend to RAM seems to be broken on this machine
+.*suspend.*
Acked-by: Vignesh Raman
Applied to drm-misc/drm-misc-next
Thanks
Helen
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Mon, Feb 19, 2024 at 10:38:12AM -0600, Adam Ford wrote: > On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote: > > > > Hi Adam, > > > > > -Original Message- > > > From: Adam Ford > > > Sent: Sunday, February 18, 2024 11:26 PM > > > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend > > > on ARCH_K3 > > > > > > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > > > > > > > > On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > > > > > Hi Maxime Ripard, > > > > > > > > > > > -Original Message- > > > > > > From: Maxime Ripard > > > > > > Sent: Friday, February 16, 2024 9:05 AM > > > > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should > > > > > > depend on > > > > > > ARCH_K3 > > > > > > > > > > > > On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > > > > > > > Hi Adam Ford, > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Adam Ford > > > > > > > > Sent: Thursday, February 15, 2024 11:36 PM > > > > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should > > > > > > > > depend on > > > > > > > > ARCH_K3 > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Maxime, > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert > > > > > > > > > > > > Uytterhoeven > > > > > > > > wrote: > > > > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6 > > > > > > > > > > > > > GPU requires a proprietary firmware image, which is > > > > > > > > > > > > > currently only available for Texas Instruments K3 > > > > > > > > > > > > > AM62x SoCs. Hence add a dependency on ARCH_K3, to > > > > > > > > > > > > > prevent asking the user about this driver when > > > > > > > > > > > > > configuring a kernel without Texas Instruments K3 > > > > > > > > Multicore SoC support. > > > > > > > > > > > > > > > > > > > > > > > > This wasn't making sense the first time you sent it, > > > > > > > > > > > > and now that commit log is just plain wrong. We have > > > > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and > > > > > > > > > > > > BXS-4-64 models, which can be found on (at least) > > > > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so > > > > > > > > > > > > across three > > > > > > > > > > > > > > > > > > > > > > I am so happy to be proven wrong! > > > > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > > > > > > > > > > > R-Car M3- > > > > > > > > W. > > > > > > > > > > > > > > > > > > > > > > > architectures and 5 platforms. In two months. > > > > > > > > > > > > > > > > > > > > > > That sounds like great progress, thanks a lot! > > > > > > > > > > > > > > > > > > > > > Geert, > > > > > > > > > > > > > > > > > > > > > Where can I find these firmwares? Linux-firmware[1] > > > > > > > > > > > seems to lack all but the original K3 AM62x one. > > > > > > > > > > > > > > > > > > > > I think PowerVR has a repo [1], but the last time I > > > > > > > > > > checked it, the BVNC for the firmware didn't match what > > > > > > > > > > was necessary for the GX6250 on the RZ/G2M. I can't > > > > > > > > > > remember what the corresponding R-Car3 model is. I > > > > > > > > > > haven't tried recently because I was told more > > > > > > > > > > documentation for firmware porting would be delayed until > > > everything was pushed into the kernel and Mesa. > > > > > > > > > > Maybe there is a better repo and/or newer firmware somewhere > > > else. > > > > > > > > > > > > > > > > > > > I should have doubled checked the repo contents before I > > > > > > > > > sent my last e-mail , but it appears the firmware [2] for > > > > > > > > > the RZ/G2M, might be present now. I don't know if there are > > > > > > > > > driver updates necessary. I checked my e-mails, but I didn't > > > > > > > > > see any notification, or I would have tried it earlier. > > > > > > > > > Either way, thank you Frank for adding it. I'll try to test > > > when I have some time. > > > > > > > > > > > > > > > > > > > > > > > > > I don't have the proper version of Mesa setup yet, but for > > > > > > > > what it's worth, the firmware loads without error, and it > > > doesn't hang. > > > > > > > > > > > > > > Based on [1] and [2], > > > > > > > > > > > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost > > > > > > > as earlier version of RZ/G2L which uses drm based on RCar-Du, > > > > > > > later changed > > > > > > to rzg2l-du. > > > > > > > > > > > > IIRC, the mesa support isn't there yet for kmscube to
Re: [PATCH 1/3] drm/ci: update IGT test names
On 19/02/2024 11:33, Dmitry Baryshkov wrote: On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote: Hi Dmitry, On 18/02/2024 01:12, Dmitry Baryshkov wrote: Since the addition of testlist.txt the IGT has changed some of test names. Some test names were changed to use '-' instead of '_'. In other cases tests were just renamed. Follow those changes. Signed-off-by: Dmitry Baryshkov Thanks for the patchset Do you have a pipeline link with those patches I can check? https://gitlab.freedesktop.org/drm/msm/-/pipelines/1106149/ I see two jobs failing, both had a timeout on the serial. msm:apq8016 had: Pass: 26, Fail: 1, ExpectedFail: 2, Skip: 1044, Duration: 17:40, Remaining: 27:48 but it didn't generate the fails.csv due to the timeout. In any case, should it also be updated on xfails? Regards, Helen Thanks Helen --- drivers/gpu/drm/ci/testlist.txt | 1888 ++- 1 file changed, 844 insertions(+), 1044 deletions(-) diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt index eaeb751bb0ad..3377f002f8c5 100644 --- a/drivers/gpu/drm/ci/testlist.txt +++ b/drivers/gpu/drm/ci/testlist.txt @@ -100,7 +100,7 @@ kms_atomic@plane-invalid-params-fence kms_atomic@crtc-invalid-params kms_atomic@crtc-invalid-params-fence kms_atomic@atomic-invalid-params -kms_atomic@atomic_plane_damage +kms_atomic@atomic-plane-damage kms_atomic_interruptible@legacy-setmode kms_atomic_interruptible@atomic-setmode kms_atomic_interruptible@legacy-dpms @@ -321,726 +321,726 @@ kms_bw@linear-tiling-7-displays-3840x2160p kms_bw@linear-tiling-8-displays-1920x1080p kms_bw@linear-tiling-8-displays-2560x1440p kms_bw@linear-tiling-8-displays-3840x2160p -kms_ccs@pipe-A-bad-pixel-format-y_tiled_ccs -kms_ccs@pipe-A-bad-pixel-format-yf_tiled_ccs -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-y_tiled_ccs -kms_ccs@pipe-A-bad-rotation-90-yf_tiled_ccs -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-y_tiled_ccs -kms_ccs@pipe-A-crc-primary-basic-yf_tiled_ccs -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-yf_tiled_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-y_tiled_ccs -kms_ccs@pipe-A-random-ccs-data-yf_tiled_ccs -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs_cc -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_rc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_mc_ccs -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_rc_ccs_cc -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_ccs -kms_ccs@pipe-A-missing-ccs-buffer-yf_tiled_ccs -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_gen12_rc_ccs -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_gen12_mc_ccs -kms_ccs@pipe-A-missing-ccs-buffer-4_tiled_mtl_r
Re: [PATCH 2/2] drm/omapdrm: Fix console with deferred ops
Hi
Am 19.02.24 um 15:19 schrieb Tony Lindgren:
Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
broke console because there is no damage handling in fb_sys_write()
unlike we have in drm_fb_helper_sys_write().
Let's fix the issue by using deferred ops with fb helpers for damage.
Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/Kconfig | 1 +
drivers/gpu/drm/omapdrm/omap_fbdev.c | 8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -5,6 +5,7 @@ config DRM_OMAP
depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
select FB_DMAMEM_HELPERS if DRM_FBDEV_EMULATION
+ select FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION
Anything named _IOMEM_ is for framebuffer's in I/O memory space. Just
keep DMAMEM_HELPERS with the few changes below.
select VIDEOMODE_HELPERS
select HDMI
default n
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -51,6 +51,10 @@ static void pan_worker(struct work_struct *work)
omap_gem_roll(bo, fbi->var.yoffset * npages);
}
+FB_GEN_DEFAULT_DEFERRED_IOMEM_OPS(omap_fbdev,
+ drm_fb_helper_damage_range,
+ drm_fb_helper_damage_area)
+
Please create FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS() by duplicating
FB_GEN_DEFAULT_DEFERRED_SYSMEM_OPS() in
static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
{
@@ -106,13 +110,13 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
- __FB_DEFAULT_DMAMEM_OPS_RDWR,
+ __FB_DEFAULT_DEFERRED_OPS_RDWR(omap_fbdev),
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
- __FB_DEFAULT_DMAMEM_OPS_DRAW,
+ __FB_DEFAULT_DEFERRED_OPS_DRAW(omap_fbdev),
.fb_ioctl = drm_fb_helper_ioctl,
.fb_mmap= omap_fbdev_fb_mmap,
The write and draw callbacks track the written pages and flush them to
the backbuffer. But mmap is a problem here, because mmap needs to do
this as well. You'd have to use fb_deferred_io_mmap() here and call
fb_deferred_io_init() in omap's fbdev init. See the generic fbdev in
drm_fbdev_generic() for a working example. But IDK whether that works
easily for omap's DMA memory. You have to mmap and track memory pages
(i.e., struct page).
The easy solution is to clear the fb_mmap callback and mmap() will thne
not be available to userspace.
Best regards
Thomas
.fb_destroy = omap_fbdev_fb_destroy,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote: > > Hi Adam, > > > -Original Message- > > From: Adam Ford > > Sent: Sunday, February 18, 2024 11:26 PM > > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend > > on ARCH_K3 > > > > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > > > > > > On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > > > > Hi Maxime Ripard, > > > > > > > > > -Original Message- > > > > > From: Maxime Ripard > > > > > Sent: Friday, February 16, 2024 9:05 AM > > > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should > > > > > depend on > > > > > ARCH_K3 > > > > > > > > > > On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > > > > > > Hi Adam Ford, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Adam Ford > > > > > > > Sent: Thursday, February 15, 2024 11:36 PM > > > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should > > > > > > > depend on > > > > > > > ARCH_K3 > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford > > wrote: > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Maxime, > > > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert > > > > > > > > > > > Uytterhoeven > > > > > > > wrote: > > > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6 > > > > > > > > > > > > GPU requires a proprietary firmware image, which is > > > > > > > > > > > > currently only available for Texas Instruments K3 > > > > > > > > > > > > AM62x SoCs. Hence add a dependency on ARCH_K3, to > > > > > > > > > > > > prevent asking the user about this driver when > > > > > > > > > > > > configuring a kernel without Texas Instruments K3 > > > > > > > Multicore SoC support. > > > > > > > > > > > > > > > > > > > > > > This wasn't making sense the first time you sent it, > > > > > > > > > > > and now that commit log is just plain wrong. We have > > > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and > > > > > > > > > > > BXS-4-64 models, which can be found on (at least) > > > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so > > > > > > > > > > > across three > > > > > > > > > > > > > > > > > > > > I am so happy to be proven wrong! > > > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > > > > > > > > > > R-Car M3- > > > > > > > W. > > > > > > > > > > > > > > > > > > > > > architectures and 5 platforms. In two months. > > > > > > > > > > > > > > > > > > > > That sounds like great progress, thanks a lot! > > > > > > > > > > > > > > > > > > > Geert, > > > > > > > > > > > > > > > > > > > Where can I find these firmwares? Linux-firmware[1] > > > > > > > > > > seems to lack all but the original K3 AM62x one. > > > > > > > > > > > > > > > > > > I think PowerVR has a repo [1], but the last time I > > > > > > > > > checked it, the BVNC for the firmware didn't match what > > > > > > > > > was necessary for the GX6250 on the RZ/G2M. I can't > > > > > > > > > remember what the corresponding R-Car3 model is. I > > > > > > > > > haven't tried recently because I was told more > > > > > > > > > documentation for firmware porting would be delayed until > > everything was pushed into the kernel and Mesa. > > > > > > > > > Maybe there is a better repo and/or newer firmware somewhere > > else. > > > > > > > > > > > > > > > > > I should have doubled checked the repo contents before I > > > > > > > > sent my last e-mail , but it appears the firmware [2] for > > > > > > > > the RZ/G2M, might be present now. I don't know if there are > > > > > > > > driver updates necessary. I checked my e-mails, but I didn't > > > > > > > > see any notification, or I would have tried it earlier. > > > > > > > > Either way, thank you Frank for adding it. I'll try to test > > when I have some time. > > > > > > > > > > > > > > > > > > > > > > I don't have the proper version of Mesa setup yet, but for > > > > > > > what it's worth, the firmware loads without error, and it > > doesn't hang. > > > > > > > > > > > > Based on [1] and [2], > > > > > > > > > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost > > > > > > as earlier version of RZ/G2L which uses drm based on RCar-Du, > > > > > > later changed > > > > > to rzg2l-du. > > > > > > > > > > IIRC, the mesa support isn't there yet for kmscube to start. > > > > > > > > What about glmark2? I tested glmark2 as well. > > > > > > It's not really a matter of kmscube itself, but the interaction with > > > the compositor entirely. You can run a headless vulkan rendering, but > > > an application that renders to a window won't
Re: [PATCH] gpu: host1x: Skip reset assert on Tegra186
On Mon Feb 19, 2024 at 3:18 AM CET, Mikko Perttunen wrote: > On 2/16/24 19:02, Thierry Reding wrote: > > On Wed Feb 14, 2024 at 12:40 PM CET, Mikko Perttunen wrote: > >> From: Mikko Perttunen > >> > >> On Tegra186, other software components may rely on the kernel to > >> keep Host1x operational even during suspend. As such, as a quirk, > >> skip asserting Host1x's reset on Tegra186. > > > > This all sounds a bit vague. What other software components rely on the > > kernel to keep host1x operational during suspend? And why do they do so? > > Why is this not a problem elsewhere? > > My assumption is that it's due to a secure world application accessing > NVDEC or display engines during suspend or resume. This happening > without kernel knowledge is a bad thing, but it's hard to change at this > point. > > The reset line (CAR vs BPMP vs non-accessible reset line), and the > secure application code programming this stuff is slightly different in > every chip generation, which is where I think the differences happen. *sigh* I guess it is what it is. Please add a bit more background information to the commit message and also a comment for the skip_reset field so that people (including myself) will remember down the road why this exists. Thierry signature.asc Description: PGP signature
Re: [PATCH 1/2] drm/omapdrm: Fix console by implementing fb_dirty
Hi
Am 19.02.24 um 15:19 schrieb Tony Lindgren:
The framebuffer console stopped updating with commit f231af498c29
("drm/fb-helper: Disconnect damage worker from update logic").
Let's fix the issue by implementing fb_dirty similar to what was done
with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
custom fb helper").
Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update
logic")
Signed-off-by: Tony Lindgren
Looks reasonable.
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -238,8 +238,20 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
return ret;
}
+static int omap_fbdev_dirty(struct drm_fb_helper *helper, struct drm_clip_rect *clip)
+{
+ if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+ return 0;
+
+ if (helper->fb->funcs->dirty)
+ return helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, clip,
1);
+
+ return 0;
+}
+
static const struct drm_fb_helper_funcs omap_fb_helper_funcs = {
.fb_probe = omap_fbdev_create,
+ .fb_dirty = omap_fbdev_dirty,
};
static struct drm_fb_helper *get_fb(struct fb_info *fbi)
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Re: [PATCH 3/8] clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support
On Mon, 19 Feb 2024 at 17:01, Konrad Dybcio wrote:
>
> On 19.02.2024 15:54, Andrew Halaney wrote:
> > On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
> >> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> >> introduced an entry to the alpha offsets array, but diving into QCM2290
> >> downstream and some documentation, it turned out that the name Huayra
> >> apparently has been used quite liberally across many chips, even with
> >> noticeably different hardware.
> >>
> >> Introduce another set of offsets and a new configure function for the
> >> Huayra PLL found on QCM2290. This is required e.g. for the consumers
> >> of GPUCC_PLL0 to properly start.
> >>
> >> Signed-off-by: Konrad Dybcio
> >> ---
> >> drivers/clk/qcom/clk-alpha-pll.c | 45
> >>
> >> drivers/clk/qcom/clk-alpha-pll.h | 3 +++
> >> 2 files changed, 48 insertions(+)
> >>
> >> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> >> b/drivers/clk/qcom/clk-alpha-pll.c
> >> index 8a412ef47e16..61b5abd13782 100644
> >> --- a/drivers/clk/qcom/clk-alpha-pll.c
> >> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> >> @@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
> >> [PLL_OFF_OPMODE] = 0x30,
> >> [PLL_OFF_STATUS] = 0x3c,
> >> },
> >> +[CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
> >> +[PLL_OFF_L_VAL] = 0x04,
> >> +[PLL_OFF_ALPHA_VAL] = 0x08,
> >> +[PLL_OFF_USER_CTL] = 0x0c,
> >> +[PLL_OFF_CONFIG_CTL] = 0x10,
> >> +[PLL_OFF_CONFIG_CTL_U] = 0x14,
> >> +[PLL_OFF_CONFIG_CTL_U1] = 0x18,
> >> +[PLL_OFF_TEST_CTL] = 0x1c,
> >> +[PLL_OFF_TEST_CTL_U] = 0x20,
> >> +[PLL_OFF_TEST_CTL_U1] = 0x24,
> >> +[PLL_OFF_OPMODE] = 0x28,
> >> +[PLL_OFF_STATUS] = 0x38,
> >> +},
> >> };
> >> EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
> >>
> >> @@ -779,6 +792,38 @@ static long clk_alpha_pll_round_rate(struct clk_hw
> >> *hw, unsigned long rate,
> >> return clamp(rate, min_freq, max_freq);
> >> }
> >>
> >> +void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct
> >> regmap *regmap,
> >> + const struct alpha_pll_config *config)
> >> +{
> >> +clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL(pll),
> >> config->config_ctl_val);
> >> +clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U(pll),
> >> config->config_ctl_hi_val);
> >> +clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U1(pll),
> >> config->config_ctl_hi1_val);
> >> +clk_alpha_pll_write_config(regmap, PLL_TEST_CTL(pll),
> >> config->test_ctl_val);
> >> +clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U(pll),
> >> config->test_ctl_hi_val);
> >> +clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U1(pll),
> >> config->test_ctl_hi1_val);
> >> +clk_alpha_pll_write_config(regmap, PLL_L_VAL(pll), config->l);
> >> +clk_alpha_pll_write_config(regmap, PLL_ALPHA_VAL(pll), config->alpha);
> >> +clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
> >> config->user_ctl_val);
> >> +
> >> +/* Set PLL_BYPASSNL */
> >> +regmap_update_bits(regmap, PLL_MODE(pll), PLL_BYPASSNL, PLL_BYPASSNL);
> >> +
> >> +/* Wait 5 us between setting BYPASS and deasserting reset */
> >> +mb();
> >> +udelay(5);
> >> +
> >> +/* Take PLL out from reset state */
> >> +regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> >> +
> >> +/* Wait 50us for PLL_LOCK_DET bit to go high */
> >> +mb();
> >> +usleep_range(50, 55);
> >
> > I *think* you'd want to use a read to ensure your write goes through
> > prior to your sleep... from memory-barriers.txt:
> >
> > 5. A readX() by a CPU thread from the peripheral will complete before
> > any subsequent delay() loop can begin execution on the same thread.
> > This ensures that two MMIO register writes by the CPU to a
> > peripheral
> > will arrive at least 1us apart if the first write is immediately
> > read
> > back with readX() and udelay(1) is called prior to the second
> > writeX():
> >
> > writel(42, DEVICE_REGISTER_0); // Arrives at the device...
> > readl(DEVICE_REGISTER_0);
> > udelay(1);
> > writel(42, DEVICE_REGISTER_1); // ...at least 1us before this.
> >
> > also https://youtu.be/i6DayghhA8Q?si=7lp0be35q1HRmlnV&t=1677
> > for more references on this topic.
>
> I mentioned this feels very iffy in the cover letter, but it's a combination
> of two things:
>
> 1. i followed what qualcomm downstream code did
>
> 2. qualcomm downstream code is not known for being always correct
>
>
>
> I suppose a readback would be the correct solution, but then it should be
> done for all similar calls in this driver.
>
> Although this code has shipped in literally hundreds of millions of devices
> and it didn't explode badly :P (i
Re: [PATCH 3/8] clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support
On 19.02.2024 15:53, Dmitry Baryshkov wrote:
> On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>>
>> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
>> introduced an entry to the alpha offsets array, but diving into QCM2290
>> downstream and some documentation, it turned out that the name Huayra
>> apparently has been used quite liberally across many chips, even with
>> noticeably different hardware.
>>
>> Introduce another set of offsets and a new configure function for the
>> Huayra PLL found on QCM2290. This is required e.g. for the consumers
>> of GPUCC_PLL0 to properly start.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> drivers/clk/qcom/clk-alpha-pll.c | 45
>>
>> drivers/clk/qcom/clk-alpha-pll.h | 3 +++
>> 2 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
>> b/drivers/clk/qcom/clk-alpha-pll.c
>> index 8a412ef47e16..61b5abd13782 100644
>> --- a/drivers/clk/qcom/clk-alpha-pll.c
>> +++ b/drivers/clk/qcom/clk-alpha-pll.c
>> @@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
>> [PLL_OFF_OPMODE] = 0x30,
>> [PLL_OFF_STATUS] = 0x3c,
>> },
>> + [CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
>> + [PLL_OFF_L_VAL] = 0x04,
>> + [PLL_OFF_ALPHA_VAL] = 0x08,
>> + [PLL_OFF_USER_CTL] = 0x0c,
>> + [PLL_OFF_CONFIG_CTL] = 0x10,
>> + [PLL_OFF_CONFIG_CTL_U] = 0x14,
>> + [PLL_OFF_CONFIG_CTL_U1] = 0x18,
>> + [PLL_OFF_TEST_CTL] = 0x1c,
>> + [PLL_OFF_TEST_CTL_U] = 0x20,
>> + [PLL_OFF_TEST_CTL_U1] = 0x24,
>> + [PLL_OFF_OPMODE] = 0x28,
>> + [PLL_OFF_STATUS] = 0x38,
>> + },
>
> Can you please move them next to the standard huayra PLL regs?
Sure, no prob
Konrad
Re: [PATCH] phy: constify of_phandle_args in xlate
On Sat Feb 17, 2024 at 10:39 AM CET, Krzysztof Kozlowski wrote: > The xlate callbacks are supposed to translate of_phandle_args to proper > provider without modifying the of_phandle_args. Make the argument > pointer to const for code safety and readability. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/phy/allwinner/phy-sun4i-usb.c | 2 +- > drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c | 2 +- > drivers/phy/broadcom/phy-bcm-sr-pcie.c | 2 +- > drivers/phy/broadcom/phy-bcm-sr-usb.c | 2 +- > drivers/phy/broadcom/phy-bcm63xx-usbh.c| 2 +- > drivers/phy/broadcom/phy-brcm-usb.c| 2 +- > drivers/phy/freescale/phy-fsl-imx8qm-lvds-phy.c| 2 +- > drivers/phy/freescale/phy-fsl-lynx-28g.c | 2 +- > drivers/phy/hisilicon/phy-histb-combphy.c | 2 +- > drivers/phy/intel/phy-intel-lgm-combo.c| 2 +- > drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c| 2 +- > drivers/phy/marvell/phy-armada375-usb2.c | 2 +- > drivers/phy/marvell/phy-armada38x-comphy.c | 2 +- > drivers/phy/marvell/phy-berlin-sata.c | 2 +- > drivers/phy/marvell/phy-mvebu-a3700-comphy.c | 2 +- > drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 2 +- > drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c| 2 +- > drivers/phy/mediatek/phy-mtk-tphy.c| 2 +- > drivers/phy/mediatek/phy-mtk-xsphy.c | 2 +- > drivers/phy/microchip/lan966x_serdes.c | 2 +- > drivers/phy/microchip/sparx5_serdes.c | 2 +- > drivers/phy/mscc/phy-ocelot-serdes.c | 2 +- > drivers/phy/phy-core.c | 8 > drivers/phy/phy-xgene.c| 2 +- > drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 2 +- > drivers/phy/ralink/phy-mt7621-pci.c| 2 +- > drivers/phy/renesas/phy-rcar-gen2.c| 2 +- > drivers/phy/renesas/phy-rcar-gen3-usb2.c | 2 +- > drivers/phy/renesas/r8a779f0-ether-serdes.c| 2 +- > drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 2 +- > drivers/phy/rockchip/phy-rockchip-pcie.c | 2 +- > drivers/phy/samsung/phy-exynos-mipi-video.c| 2 +- > drivers/phy/samsung/phy-exynos5-usbdrd.c | 2 +- > drivers/phy/samsung/phy-samsung-usb2.c | 2 +- > drivers/phy/socionext/phy-uniphier-usb2.c | 2 +- > drivers/phy/st/phy-miphy28lp.c | 2 +- > drivers/phy/st/phy-spear1310-miphy.c | 2 +- > drivers/phy/st/phy-spear1340-miphy.c | 2 +- > drivers/phy/st/phy-stm32-usbphyc.c | 2 +- > drivers/phy/tegra/xusb.c | 2 +- > drivers/phy/ti/phy-am654-serdes.c | 2 +- > drivers/phy/ti/phy-da8xx-usb.c | 2 +- > drivers/phy/ti/phy-gmii-sel.c | 2 +- > drivers/phy/xilinx/phy-zynqmp.c| 2 +- > drivers/pinctrl/tegra/pinctrl-tegra-xusb.c | 2 +- > include/linux/phy/phy.h| 14 +++--- > 46 files changed, 55 insertions(+), 55 deletions(-) Makes sense: Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH] drm/amd: Only allow one entity to control ABM
On Mon, Feb 19, 2024 at 10:19 AM Christian König wrote: > > Am 16.02.24 um 19:37 schrieb Alex Deucher: > > On Fri, Feb 16, 2024 at 10:42 AM Christian König > > wrote: > >> Am 16.02.24 um 16:12 schrieb Mario Limonciello: > >>> On 2/16/2024 09:05, Harry Wentland wrote: > > On 2024-02-16 09:47, Christian König wrote: > > Am 16.02.24 um 15:42 schrieb Mario Limonciello: > >> On 2/16/2024 08:38, Christian König wrote: > >>> Am 16.02.24 um 15:07 schrieb Mario Limonciello: > By exporting ABM to sysfs it's possible that DRM master and software > controlling the sysfs file fight over the value programmed for ABM. > > Adjust the module parameter behavior to control who control ABM: > -2: DRM > -1: sysfs (IE via software like power-profiles-daemon) > >>> Well that sounds extremely awkward. Why should a > >>> power-profiles-deamon has control over the panel power saving > >>> features? > >>> > >>> I mean we are talking about things like reducing backlight level > >>> when the is inactivity, don't we? > >> We're talking about activating the ABM algorithm when the system is > >> in power saving mode; not from inactivity. This allows the user to > >> squeeze out some extra power "just" in that situation. > >> > >> But given the comments on the other patch, I tend to agree with > >> Harry's proposal instead that we just drop the DRM property > >> entirely as there are no consumers of it. > > Yeah, but even then the design to let this be controlled by an > > userspace deamon is questionable. Stuff like that is handled inside > > the kernel and not exposed to userspace usually. > > > >>> Regarding the "how" and "why" of PPD; besides this panel power savings > >>> sysfs file there are two other things that are nominally changed. > >>> > >>> ACPI platform profile: > >>> https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html > >>> > >>> AMD-Pstate EPP value: > >>> https://www.kernel.org/doc/html//latest/admin-guide/pm/amd-pstate.html > >>> > >>> When a user goes into "power saving" mode both of those are tweaked. > >>> Before we introduced the EPP tweaking in PPD we did discuss a callback > >>> within the kernel so that userspace could change "just" the ACPI > >>> platform profile and everything else would react. There was pushback > >>> on this, and so instead knobs are offered for things that should be > >>> tweaked and the userspace daemon can set up policy for what to do when > >>> a a user uses a userspace client (such as GNOME or KDE) to change the > >>> desired system profile. > >> Ok, well who came up with the idea of the userspace deamon? Cause I > >> think there will be even more push back on this approach. > >> > >> Basically when we go from AC to battery (or whatever) the drivers > >> usually handle that all inside the kernel today. Involving userspace is > >> only done when there is a need for that, e.g. inactivity detection or > >> similar. > > Well, we don't want policy in the kernel unless it's a platform or > > hardware requirement. Kernel should provide the knobs and then > > userspace can set them however they want depending on user preference. > > Well, you not have the policy itself but usually the handling inside the > kernel. > > In other words when I connect/disconnect AC from my laptop I can hear > the fan changing, which is a switch in power state. Only the beep which > comes out of the speakers as conformation is handled in userspace I think. > > And IIRC changing background light is also handled completely inside the > kernel and when I close the lid the display turns off on its own and not > because of some userspace deamon. > > So why is for this suddenly a userspace deamon involved? It's a user preference. Some people won't like ABM, some will. They set the policy from user space. It's similar to the backlight level. Some users always prefer a bright backlight regardless of AC/DC state, others want the backlight to get brighter when on AC power. The kernel provides the knobs to set the ABM level and then user space can specify the level and also device when they want it enabled (never, only on DC, etc.). The kernel driver for the backlight doesn't change the backlight at AC/DC switch, userspace gets an event when the power source changes and it then talks to the kernel to change the backlight level. I think lid is handled the same way. Userspace gets a lid event and it turns off the displays and maybe enters suspend or maybe not depending on what the user wants. Alex > > Christian. > > > > > Alex > > > > > I think we'll need a bit in our kernel docs describing ABM. > Assumptions around what it is and does seem to lead to confusion. > > The thing is that ABM has a visual impact that not all users like. It > would make sense for users to be able to change the ABM level as > desired, and/o
Re: [PATCH] drm/amd: Only allow one entity to control ABM
Am 16.02.24 um 19:37 schrieb Alex Deucher:
On Fri, Feb 16, 2024 at 10:42 AM Christian König
wrote:
Am 16.02.24 um 16:12 schrieb Mario Limonciello:
On 2/16/2024 09:05, Harry Wentland wrote:
On 2024-02-16 09:47, Christian König wrote:
Am 16.02.24 um 15:42 schrieb Mario Limonciello:
On 2/16/2024 08:38, Christian König wrote:
Am 16.02.24 um 15:07 schrieb Mario Limonciello:
By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.
Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)
Well that sounds extremely awkward. Why should a
power-profiles-deamon has control over the panel power saving
features?
I mean we are talking about things like reducing backlight level
when the is inactivity, don't we?
We're talking about activating the ABM algorithm when the system is
in power saving mode; not from inactivity. This allows the user to
squeeze out some extra power "just" in that situation.
But given the comments on the other patch, I tend to agree with
Harry's proposal instead that we just drop the DRM property
entirely as there are no consumers of it.
Yeah, but even then the design to let this be controlled by an
userspace deamon is questionable. Stuff like that is handled inside
the kernel and not exposed to userspace usually.
Regarding the "how" and "why" of PPD; besides this panel power savings
sysfs file there are two other things that are nominally changed.
ACPI platform profile:
https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html
AMD-Pstate EPP value:
https://www.kernel.org/doc/html//latest/admin-guide/pm/amd-pstate.html
When a user goes into "power saving" mode both of those are tweaked.
Before we introduced the EPP tweaking in PPD we did discuss a callback
within the kernel so that userspace could change "just" the ACPI
platform profile and everything else would react. There was pushback
on this, and so instead knobs are offered for things that should be
tweaked and the userspace daemon can set up policy for what to do when
a a user uses a userspace client (such as GNOME or KDE) to change the
desired system profile.
Ok, well who came up with the idea of the userspace deamon? Cause I
think there will be even more push back on this approach.
Basically when we go from AC to battery (or whatever) the drivers
usually handle that all inside the kernel today. Involving userspace is
only done when there is a need for that, e.g. inactivity detection or
similar.
Well, we don't want policy in the kernel unless it's a platform or
hardware requirement. Kernel should provide the knobs and then
userspace can set them however they want depending on user preference.
Well, you not have the policy itself but usually the handling inside the
kernel.
In other words when I connect/disconnect AC from my laptop I can hear
the fan changing, which is a switch in power state. Only the beep which
comes out of the speakers as conformation is handled in userspace I think.
And IIRC changing background light is also handled completely inside the
kernel and when I close the lid the display turns off on its own and not
because of some userspace deamon.
So why is for this suddenly a userspace deamon involved?
Christian.
Alex
I think we'll need a bit in our kernel docs describing ABM.
Assumptions around what it is and does seem to lead to confusion.
The thing is that ABM has a visual impact that not all users like. It
would make sense for users to be able to change the ABM level as
desired, and/or configure their power profiles to select a certain
ABM level.
ABM will reduce the backlight and compensate by adjusting brightness
and contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means
off. 4 means maximum backlight reduction. IMO, 1 and 2 look okay. 3
and 4 can be quite impactful, both to power and visual fidelity.
Aside from this patch Hamza did make some improvements to the kdoc in
the recent patches, can you read through again and see if you think it
still needs improvements?
Well what exactly is the requirement? That we have different ABM
settings for AC and battery? If yes providing different DRM properties
would sound like the right approach to me.
Regards,
Christian.
Harry
Regards,
Christian.
Regards,
Christian.
0-4: User via command line
Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.
Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings
sysfs entry to eDP connectors")
Signed-off-by: Mario Limonciello
---
Cc: Hamza Mahfooz
Cc: Harry Wentland
Cc: Sun peng (Leo) Li
drivers/gpu/drm/amd/amdgpu/Kconfig| 72
+++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 23 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +-
3 files changed, 90 insertions(+), 11 deletions(
Re: [PATCH 00/10] backlight: Replace struct fb_info in interfaces
On Thu, 15 Feb 2024, Thomas Zimmermann wrote: > Hi > > Am 15.02.24 um 13:13 schrieb Daniel Thompson: > > On Mon, Feb 12, 2024 at 05:16:33PM +0100, Thomas Zimmermann wrote: > > > Backlight drivers implement struct backlight_ops.check_fb, which > > > uses struct fb_info in its interface. Replace the callback with one > > > the does not use fb_info. > > > > > > In DRM, we have several drivers that implement backlight support. By > > > including these drivers depend on . > > > At the same time, fbdev is deprecated for new drivers and likely to > > > be replaced on many systems. > > > > > > This patchset is part of a larger effort to implement the backlight > > > code without depending on fbdev. > > > > > > Patch 1 makes the backlight core match backlight and framebuffer > > > devices via struct fb_info.bl_dev. Patches 2 to 9 then go through > > > drivers and remove unnecessary implementations of check_fb. Finally, > > > patch 10 replaces the check_fb hook with controls_device, which > > > uses the framebuffer's Linux device instead of the framebuffer. > > I won't reply individually but I also took a look at the patches for > > the combo devices and it all looked good to me from a backlight > > point of view. > > > > However I don't want to drop Reviewed-by: on them since it risks those > > bit being mistaken for an ack and merged ahead of the patch 1... > > Thanks for reviewing. Unless someone objects, my intention is to merge > everything via the drm-misc, so all patches should go in at once. I do have > a lot more patches that untangle backlight and fbdev almost completely, but > most of these changes are in the actual graphics drivers rather than the > backlight core code. So hopefully everything can go through the DRM tree; or > maybe the fbdev tree. This is only acceptable if the maintainers of those trees can provide me with a pull-request to a succinct (_only_ these patches) immutable branch. If this is not possible, then I should like to merge the set through the Backlight tree and I can provide everyone else with said PR. -- Lee Jones [李琼斯]
Re: [PATCH 3/8] clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support
On 19.02.2024 15:54, Andrew Halaney wrote:
> On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
>> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
>> introduced an entry to the alpha offsets array, but diving into QCM2290
>> downstream and some documentation, it turned out that the name Huayra
>> apparently has been used quite liberally across many chips, even with
>> noticeably different hardware.
>>
>> Introduce another set of offsets and a new configure function for the
>> Huayra PLL found on QCM2290. This is required e.g. for the consumers
>> of GPUCC_PLL0 to properly start.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> drivers/clk/qcom/clk-alpha-pll.c | 45
>>
>> drivers/clk/qcom/clk-alpha-pll.h | 3 +++
>> 2 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
>> b/drivers/clk/qcom/clk-alpha-pll.c
>> index 8a412ef47e16..61b5abd13782 100644
>> --- a/drivers/clk/qcom/clk-alpha-pll.c
>> +++ b/drivers/clk/qcom/clk-alpha-pll.c
>> @@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
>> [PLL_OFF_OPMODE] = 0x30,
>> [PLL_OFF_STATUS] = 0x3c,
>> },
>> +[CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
>> +[PLL_OFF_L_VAL] = 0x04,
>> +[PLL_OFF_ALPHA_VAL] = 0x08,
>> +[PLL_OFF_USER_CTL] = 0x0c,
>> +[PLL_OFF_CONFIG_CTL] = 0x10,
>> +[PLL_OFF_CONFIG_CTL_U] = 0x14,
>> +[PLL_OFF_CONFIG_CTL_U1] = 0x18,
>> +[PLL_OFF_TEST_CTL] = 0x1c,
>> +[PLL_OFF_TEST_CTL_U] = 0x20,
>> +[PLL_OFF_TEST_CTL_U1] = 0x24,
>> +[PLL_OFF_OPMODE] = 0x28,
>> +[PLL_OFF_STATUS] = 0x38,
>> +},
>> };
>> EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
>>
>> @@ -779,6 +792,38 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw,
>> unsigned long rate,
>> return clamp(rate, min_freq, max_freq);
>> }
>>
>> +void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap
>> *regmap,
>> + const struct alpha_pll_config *config)
>> +{
>> +clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL(pll),
>> config->config_ctl_val);
>> +clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U(pll),
>> config->config_ctl_hi_val);
>> +clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U1(pll),
>> config->config_ctl_hi1_val);
>> +clk_alpha_pll_write_config(regmap, PLL_TEST_CTL(pll),
>> config->test_ctl_val);
>> +clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U(pll),
>> config->test_ctl_hi_val);
>> +clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U1(pll),
>> config->test_ctl_hi1_val);
>> +clk_alpha_pll_write_config(regmap, PLL_L_VAL(pll), config->l);
>> +clk_alpha_pll_write_config(regmap, PLL_ALPHA_VAL(pll), config->alpha);
>> +clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
>> config->user_ctl_val);
>> +
>> +/* Set PLL_BYPASSNL */
>> +regmap_update_bits(regmap, PLL_MODE(pll), PLL_BYPASSNL, PLL_BYPASSNL);
>> +
>> +/* Wait 5 us between setting BYPASS and deasserting reset */
>> +mb();
>> +udelay(5);
>> +
>> +/* Take PLL out from reset state */
>> +regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
>> +
>> +/* Wait 50us for PLL_LOCK_DET bit to go high */
>> +mb();
>> +usleep_range(50, 55);
>
> I *think* you'd want to use a read to ensure your write goes through
> prior to your sleep... from memory-barriers.txt:
>
> 5. A readX() by a CPU thread from the peripheral will complete before
> any subsequent delay() loop can begin execution on the same thread.
> This ensures that two MMIO register writes by the CPU to a peripheral
> will arrive at least 1us apart if the first write is immediately read
> back with readX() and udelay(1) is called prior to the second
> writeX():
>
> writel(42, DEVICE_REGISTER_0); // Arrives at the device...
> readl(DEVICE_REGISTER_0);
> udelay(1);
> writel(42, DEVICE_REGISTER_1); // ...at least 1us before this.
>
> also https://youtu.be/i6DayghhA8Q?si=7lp0be35q1HRmlnV&t=1677
> for more references on this topic.
I mentioned this feels very iffy in the cover letter, but it's a combination
of two things:
1. i followed what qualcomm downstream code did
2. qualcomm downstream code is not known for being always correct
I suppose a readback would be the correct solution, but then it should be
done for all similar calls in this driver.
Although this code has shipped in literally hundreds of millions of devices
and it didn't explode badly :P (i'm not defending it, though)
Konrad
Re: [PATCH 7/8] arm64: dts: qcom: qcm2290: Add GPU nodes
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote: > > Describe the GPU hardware on the QCM2290. > > Signed-off-by: Konrad Dybcio > --- > arch/arm64/boot/dts/qcom/qcm2290.dtsi | 154 > ++ > 1 file changed, 154 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v5 07/14] drm/panthor: Add the MMU/VM logical block
On 18/02/2024 21:41, Boris Brezillon wrote: > MMU and VM management is related and placed in the same source file. > > Page table updates are delegated to the io-pgtable-arm driver that's in > the iommu subsystem. > > The VM management logic is based on drm_gpuva_mgr, and is assuming the > VA space is mostly managed by the usermode driver, except for a reserved > portion of this VA-space that's used for kernel objects (like the heap > contexts/chunks). > > Both asynchronous and synchronous VM operations are supported, and > internal helpers are exposed to allow other logical blocks to map their > buffers in the GPU VA space. > > There's one VM_BIND queue per-VM (meaning the Vulkan driver can only > expose one sparse-binding queue), and this bind queue is managed with > a 1:1 drm_sched_entity:drm_gpu_scheduler, such that each VM gets its own > independent execution queue, avoiding VM operation serialization at the > device level (things are still serialized at the VM level). > > The rest is just implementation details that are hopefully well explained > in the documentation. > > v5: > - Fix a double panthor_vm_cleanup_op_ctx() call > - Fix a race between panthor_vm_prepare_map_op_ctx() and > panthor_vm_bo_put() > - Fix panthor_vm_pool_destroy_vm() kernel doc > - Fix paddr adjustment in panthor_vm_map_pages() > - Fix bo_offset calculation in panthor_vm_get_bo_for_va() > > v4: > - Add an helper to return the VM state > - Check drmm_mutex_init() return code > - Remove the VM from the AS reclaim list when panthor_vm_active() is > called > - Count the number of active VM users instead of considering there's > at most one user (several scheduling groups can point to the same > vM) > - Pre-allocate a VMA object for unmap operations (unmaps can trigger > a sm_step_remap() call) > - Check vm->root_page_table instead of vm->pgtbl_ops to detect if > the io-pgtable is trying to allocate the root page table > - Don't memset() the va_node in panthor_vm_alloc_va(), make it a > caller requirement > - Fix the kernel doc in a few places > - Drop the panthor_vm::base offset constraint and modify > panthor_vm_put() to explicitly check for a NULL value > - Fix unbalanced vm_bo refcount in panthor_gpuva_sm_step_remap() > - Drop stale comments about the shared_bos list > - Patch mmu_features::va_bits on 32-bit builds to reflect the > io_pgtable limitation and let the UMD know about it > > v3: > - Add acks for the MIT/GPL2 relicensing > - Propagate MMU faults to the scheduler > - Move pages pinning/unpinning out of the dma_signalling path > - Fix 32-bit support > - Rework the user/kernel VA range calculation > - Make the auto-VA range explicit (auto-VA range doesn't cover the full > kernel-VA range on the MCU VM) > - Let callers of panthor_vm_alloc_va() allocate the drm_mm_node > (embedded in panthor_kernel_bo now) > - Adjust things to match the latest drm_gpuvm changes (extobj tracking, > resv prep and more) > - Drop the per-AS lock and use slots_lock (fixes a race on vm->as.id) > - Set as.id to -1 when reusing an address space from the LRU list > - Drop misleading comment about page faults > - Remove check for irq being assigned in panthor_mmu_unplug() > > Co-developed-by: Steven Price > Signed-off-by: Steven Price > Signed-off-by: Boris Brezillon > Acked-by: Steven Price # MIT+GPL2 relicensing,Arm > Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro > Acked-by: Boris Brezillon # MIT+GPL2 > relicensing,Collabora LGTM Reviewed-by: Steven Price Thanks, Stev
Re: [PATCH 4/8] clk: qcom: Add QCM2290 GPU clock controller driver
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote: > > Add a driver for the GPU clock controller block found on the QCM2290 SoC. > > Signed-off-by: Konrad Dybcio > --- > drivers/clk/qcom/Kconfig | 9 + > drivers/clk/qcom/Makefile| 1 + > drivers/clk/qcom/gpucc-qcm2290.c | 423 > +++ > 3 files changed, 433 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 3/8] clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support
On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> introduced an entry to the alpha offsets array, but diving into QCM2290
> downstream and some documentation, it turned out that the name Huayra
> apparently has been used quite liberally across many chips, even with
> noticeably different hardware.
>
> Introduce another set of offsets and a new configure function for the
> Huayra PLL found on QCM2290. This is required e.g. for the consumers
> of GPUCC_PLL0 to properly start.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/clk/qcom/clk-alpha-pll.c | 45
>
> drivers/clk/qcom/clk-alpha-pll.h | 3 +++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index 8a412ef47e16..61b5abd13782 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
> [PLL_OFF_OPMODE] = 0x30,
> [PLL_OFF_STATUS] = 0x3c,
> },
> + [CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
> + [PLL_OFF_L_VAL] = 0x04,
> + [PLL_OFF_ALPHA_VAL] = 0x08,
> + [PLL_OFF_USER_CTL] = 0x0c,
> + [PLL_OFF_CONFIG_CTL] = 0x10,
> + [PLL_OFF_CONFIG_CTL_U] = 0x14,
> + [PLL_OFF_CONFIG_CTL_U1] = 0x18,
> + [PLL_OFF_TEST_CTL] = 0x1c,
> + [PLL_OFF_TEST_CTL_U] = 0x20,
> + [PLL_OFF_TEST_CTL_U1] = 0x24,
> + [PLL_OFF_OPMODE] = 0x28,
> + [PLL_OFF_STATUS] = 0x38,
> + },
> };
> EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
>
> @@ -779,6 +792,38 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw,
> unsigned long rate,
> return clamp(rate, min_freq, max_freq);
> }
>
> +void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
> +const struct alpha_pll_config *config)
> +{
> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL(pll),
> config->config_ctl_val);
> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U(pll),
> config->config_ctl_hi_val);
> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U1(pll),
> config->config_ctl_hi1_val);
> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL(pll),
> config->test_ctl_val);
> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U(pll),
> config->test_ctl_hi_val);
> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U1(pll),
> config->test_ctl_hi1_val);
> + clk_alpha_pll_write_config(regmap, PLL_L_VAL(pll), config->l);
> + clk_alpha_pll_write_config(regmap, PLL_ALPHA_VAL(pll), config->alpha);
> + clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
> config->user_ctl_val);
> +
> + /* Set PLL_BYPASSNL */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_BYPASSNL, PLL_BYPASSNL);
> +
> + /* Wait 5 us between setting BYPASS and deasserting reset */
> + mb();
> + udelay(5);
> +
> + /* Take PLL out from reset state */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> +
> + /* Wait 50us for PLL_LOCK_DET bit to go high */
> + mb();
> + usleep_range(50, 55);
I *think* you'd want to use a read to ensure your write goes through
prior to your sleep... from memory-barriers.txt:
5. A readX() by a CPU thread from the peripheral will complete before
any subsequent delay() loop can begin execution on the same thread.
This ensures that two MMIO register writes by the CPU to a peripheral
will arrive at least 1us apart if the first write is immediately read
back with readX() and udelay(1) is called prior to the second
writeX():
writel(42, DEVICE_REGISTER_0); // Arrives at the device...
readl(DEVICE_REGISTER_0);
udelay(1);
writel(42, DEVICE_REGISTER_1); // ...at least 1us before this.
also https://youtu.be/i6DayghhA8Q?si=7lp0be35q1HRmlnV&t=1677
for more references on this topic.
> +
> + /* Enable PLL output */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_OUTCTRL, PLL_OUTCTRL);
> +}
> +EXPORT_SYMBOL(clk_huayra_2290_pll_configure);
> +
> static unsigned long
> alpha_huayra_pll_calc_rate(u64 prate, u32 l, u32 a)
> {
> diff --git a/drivers/clk/qcom/clk-alpha-pll.h
> b/drivers/clk/qcom/clk-alpha-pll.h
> index fb6d50263bb9..91d3d6f19eae 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.h
> +++ b/drivers/clk/qcom/clk-alpha-pll.h
> @@ -29,6 +29,7 @@ enum {
> CLK_ALPHA_PLL_TYPE_BRAMMO_EVO,
> CLK_ALPHA_PLL_TYPE_STROMER,
> CLK_ALPHA_PLL_TYPE_STROMER_PLUS,
> + CLK_ALPHA_PLL_TYPE_HUAYRA_2290,
> CLK_ALPHA_PLL_TYPE_MAX,
> };
>
> @@ -191,6 +192,8 @@ extern const struct clk_ops clk_alpha_pll_rivian_evo_ops;
>
> void clk_alpha_pll_configure(struct clk_alp
Re: [PATCH 3/8] clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>
> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> introduced an entry to the alpha offsets array, but diving into QCM2290
> downstream and some documentation, it turned out that the name Huayra
> apparently has been used quite liberally across many chips, even with
> noticeably different hardware.
>
> Introduce another set of offsets and a new configure function for the
> Huayra PLL found on QCM2290. This is required e.g. for the consumers
> of GPUCC_PLL0 to properly start.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/clk/qcom/clk-alpha-pll.c | 45
>
> drivers/clk/qcom/clk-alpha-pll.h | 3 +++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> b/drivers/clk/qcom/clk-alpha-pll.c
> index 8a412ef47e16..61b5abd13782 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.c
> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> @@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
> [PLL_OFF_OPMODE] = 0x30,
> [PLL_OFF_STATUS] = 0x3c,
> },
> + [CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
> + [PLL_OFF_L_VAL] = 0x04,
> + [PLL_OFF_ALPHA_VAL] = 0x08,
> + [PLL_OFF_USER_CTL] = 0x0c,
> + [PLL_OFF_CONFIG_CTL] = 0x10,
> + [PLL_OFF_CONFIG_CTL_U] = 0x14,
> + [PLL_OFF_CONFIG_CTL_U1] = 0x18,
> + [PLL_OFF_TEST_CTL] = 0x1c,
> + [PLL_OFF_TEST_CTL_U] = 0x20,
> + [PLL_OFF_TEST_CTL_U1] = 0x24,
> + [PLL_OFF_OPMODE] = 0x28,
> + [PLL_OFF_STATUS] = 0x38,
> + },
Can you please move them next to the standard huayra PLL regs?
> };
> EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
>
> @@ -779,6 +792,38 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw,
> unsigned long rate,
> return clamp(rate, min_freq, max_freq);
> }
>
> +void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
> + const struct alpha_pll_config *config)
> +{
> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL(pll),
> config->config_ctl_val);
> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U(pll),
> config->config_ctl_hi_val);
> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U1(pll),
> config->config_ctl_hi1_val);
> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL(pll),
> config->test_ctl_val);
> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U(pll),
> config->test_ctl_hi_val);
> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U1(pll),
> config->test_ctl_hi1_val);
> + clk_alpha_pll_write_config(regmap, PLL_L_VAL(pll), config->l);
> + clk_alpha_pll_write_config(regmap, PLL_ALPHA_VAL(pll), config->alpha);
> + clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
> config->user_ctl_val);
> +
> + /* Set PLL_BYPASSNL */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_BYPASSNL, PLL_BYPASSNL);
> +
> + /* Wait 5 us between setting BYPASS and deasserting reset */
> + mb();
> + udelay(5);
> +
> + /* Take PLL out from reset state */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> +
> + /* Wait 50us for PLL_LOCK_DET bit to go high */
> + mb();
> + usleep_range(50, 55);
> +
> + /* Enable PLL output */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_OUTCTRL, PLL_OUTCTRL);
> +}
> +EXPORT_SYMBOL(clk_huayra_2290_pll_configure);
> +
> static unsigned long
> alpha_huayra_pll_calc_rate(u64 prate, u32 l, u32 a)
> {
> diff --git a/drivers/clk/qcom/clk-alpha-pll.h
> b/drivers/clk/qcom/clk-alpha-pll.h
> index fb6d50263bb9..91d3d6f19eae 100644
> --- a/drivers/clk/qcom/clk-alpha-pll.h
> +++ b/drivers/clk/qcom/clk-alpha-pll.h
> @@ -29,6 +29,7 @@ enum {
> CLK_ALPHA_PLL_TYPE_BRAMMO_EVO,
> CLK_ALPHA_PLL_TYPE_STROMER,
> CLK_ALPHA_PLL_TYPE_STROMER_PLUS,
> + CLK_ALPHA_PLL_TYPE_HUAYRA_2290,
Also next to standard huayra PLL, please.
> CLK_ALPHA_PLL_TYPE_MAX,
> };
>
> @@ -191,6 +192,8 @@ extern const struct clk_ops clk_alpha_pll_rivian_evo_ops;
>
> void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
> const struct alpha_pll_config *config);
> +void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
> + const struct alpha_pll_config *config);
> void clk_fabia_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
> const struct alpha_pll_config *config);
> void clk_trion_pll_configure(struct clk_alpha_pll *pll, struct regmap
> *regmap,
>
> --
> 2.43.2
>
--
With best wishes
Dmitry
Re: [PATCH 8/8] arm64: dts: qcom: qrb2210-rb1: Enable the GPU
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote: > > Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol). Is it not? > > [1] > https://docs.qualcomm.com/bundle/publicresource/87-61720-1_REV_A_QUALCOMM_ROBOTICS_RB1_PLATFORM__QUALCOMM_QRB2210__PRODUCT_BRIEF.pdf > Signed-off-by: Konrad Dybcio With the exception of the commit message: Reviewed-by: Dmitry Baryshkov > --- > arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 8 > 1 file changed, 8 insertions(+) -- With best wishes Dmitry
Re: [PATCH] drm/ci: skip suspend tests for both msm-sc7180 machines
On 17/02/24 02:26, Dmitry Baryshkov wrote:
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM
tests. However testing shows that STR tests still can fail. Restore the
skiplist, applying it to both limozeen and kingoftown machines.
Fixes: ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt | 2 ++
.../drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt | 2 ++
2 files changed, 4 insertions(+)
create mode 100644
drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
create mode 100644
drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
diff --git a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
new file mode 100644
index ..327039f70252
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
@@ -0,0 +1,2 @@
+# Suspend to RAM seems to be broken on this machine
+.*suspend.*
diff --git
a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
new file mode 100644
index ..327039f70252
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
@@ -0,0 +1,2 @@
+# Suspend to RAM seems to be broken on this machine
+.*suspend.*
Acked-by: Vignesh Raman
Re: [PATCH 1/3] drm/ci: update IGT test names
On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote: > > Hi Dmitry, > > > On 18/02/2024 01:12, Dmitry Baryshkov wrote: > > Since the addition of testlist.txt the IGT has changed some of test > > names. Some test names were changed to use '-' instead of '_'. In other > > cases tests were just renamed. Follow those changes. > > > > Signed-off-by: Dmitry Baryshkov > > Thanks for the patchset > > Do you have a pipeline link with those patches I can check? https://gitlab.freedesktop.org/drm/msm/-/pipelines/1106149/ > > Thanks > Helen > > > --- > > drivers/gpu/drm/ci/testlist.txt | 1888 ++- > > 1 file changed, 844 insertions(+), 1044 deletions(-) > > > > diff --git a/drivers/gpu/drm/ci/testlist.txt > > b/drivers/gpu/drm/ci/testlist.txt > > index eaeb751bb0ad..3377f002f8c5 100644 > > --- a/drivers/gpu/drm/ci/testlist.txt > > +++ b/drivers/gpu/drm/ci/testlist.txt > > @@ -100,7 +100,7 @@ kms_atomic@plane-invalid-params-fence > > kms_atomic@crtc-invalid-params > > kms_atomic@crtc-invalid-params-fence > > kms_atomic@atomic-invalid-params > > -kms_atomic@atomic_plane_damage > > +kms_atomic@atomic-plane-damage > > kms_atomic_interruptible@legacy-setmode > > kms_atomic_interruptible@atomic-setmode > > kms_atomic_interruptible@legacy-dpms > > @@ -321,726 +321,726 @@ kms_bw@linear-tiling-7-displays-3840x2160p > > kms_bw@linear-tiling-8-displays-1920x1080p > > kms_bw@linear-tiling-8-displays-2560x1440p > > kms_bw@linear-tiling-8-displays-3840x2160p > > -kms_ccs@pipe-A-bad-pixel-format-y_tiled_ccs > > -kms_ccs@pipe-A-bad-pixel-format-yf_tiled_ccs > > -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs > > -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_rc_ccs_cc > > -kms_ccs@pipe-A-bad-pixel-format-y_tiled_gen12_mc_ccs > > -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs > > -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_mc_ccs > > -kms_ccs@pipe-A-bad-pixel-format-4_tiled_dg2_rc_ccs_cc > > -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs > > -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_mc_ccs > > -kms_ccs@pipe-A-bad-pixel-format-4_tiled_mtl_rc_ccs_cc > > -kms_ccs@pipe-A-bad-rotation-90-y_tiled_ccs > > -kms_ccs@pipe-A-bad-rotation-90-yf_tiled_ccs > > -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs > > -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_rc_ccs_cc > > -kms_ccs@pipe-A-bad-rotation-90-y_tiled_gen12_mc_ccs > > -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs > > -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_mc_ccs > > -kms_ccs@pipe-A-bad-rotation-90-4_tiled_dg2_rc_ccs_cc > > -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs > > -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_mc_ccs > > -kms_ccs@pipe-A-bad-rotation-90-4_tiled_mtl_rc_ccs_cc > > -kms_ccs@pipe-A-crc-primary-basic-y_tiled_ccs > > -kms_ccs@pipe-A-crc-primary-basic-yf_tiled_ccs > > -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs > > -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_rc_ccs_cc > > -kms_ccs@pipe-A-crc-primary-basic-y_tiled_gen12_mc_ccs > > -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs > > -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_mc_ccs > > -kms_ccs@pipe-A-crc-primary-basic-4_tiled_dg2_rc_ccs_cc > > -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs > > -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_mc_ccs > > -kms_ccs@pipe-A-crc-primary-basic-4_tiled_mtl_rc_ccs_cc > > -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-yf_tiled_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc > > -kms_ccs@pipe-A-crc-primary-rotation-180-y_tiled_gen12_mc_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_mc_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_dg2_rc_ccs_cc > > -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_mc_ccs > > -kms_ccs@pipe-A-crc-primary-rotation-180-4_tiled_mtl_rc_ccs_cc > > -kms_ccs@pipe-A-random-ccs-data-y_tiled_ccs > > -kms_ccs@pipe-A-random-ccs-data-yf_tiled_ccs > > -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs > > -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_rc_ccs_cc > > -kms_ccs@pipe-A-random-ccs-data-y_tiled_gen12_mc_ccs > > -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs > > -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_mc_ccs > > -kms_ccs@pipe-A-random-ccs-data-4_tiled_dg2_rc_ccs_cc > > -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_rc_ccs > > -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_mc_ccs > > -kms_ccs@pipe-A-random-ccs-data-4_tiled_mtl_rc_ccs_cc > > -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_ccs > > -kms_ccs@pipe-A-missing-ccs-buffer-yf_tiled_ccs > > -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_gen12_rc_ccs > > -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc > > -kms_ccs@pipe-A-missing-ccs-buffer-y_tiled_gen12_mc_ccs > > -kms_ccs@pipe-A-missing-ccs-buffer-
Re: [PATCH 2/8] dt-bindings: clock: Add Qcom QCM2290 GPUCC
On Mon, 19 Feb 2024 14:35:47 +0100, Konrad Dybcio wrote:
> Add device tree bindings for graphics clock controller for Qualcomm
> Technology Inc's QCM2290 SoCs.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/clock/qcom,qcm2290-gpucc.yaml | 76
> ++
> include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 +
> 2 files changed, 108 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml:
properties:compatible: [{'const': 'qcom,qcm2290-gpucc'}] is not of type
'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml:
properties:compatible: [{'const': 'qcom,qcm2290-gpucc'}] is not of type
'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml:
ignoring, error in schema: properties: compatible
Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.example.dtb:
/example-0/soc/clock-controller@599: failed to match any schema with
compatible: ['qcom,qcm2290-gpucc']
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240219-topic-rb1_gpu-v1-2-d260fa854...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
[PATCH 2/2] drm/omapdrm: Fix console with deferred ops
Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
broke console because there is no damage handling in fb_sys_write()
unlike we have in drm_fb_helper_sys_write().
Let's fix the issue by using deferred ops with fb helpers for damage.
Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/Kconfig | 1 +
drivers/gpu/drm/omapdrm/omap_fbdev.c | 8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -5,6 +5,7 @@ config DRM_OMAP
depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
select FB_DMAMEM_HELPERS if DRM_FBDEV_EMULATION
+ select FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION
select VIDEOMODE_HELPERS
select HDMI
default n
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -51,6 +51,10 @@ static void pan_worker(struct work_struct *work)
omap_gem_roll(bo, fbi->var.yoffset * npages);
}
+FB_GEN_DEFAULT_DEFERRED_IOMEM_OPS(omap_fbdev,
+ drm_fb_helper_damage_range,
+ drm_fb_helper_damage_area)
+
static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
{
@@ -106,13 +110,13 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
- __FB_DEFAULT_DMAMEM_OPS_RDWR,
+ __FB_DEFAULT_DEFERRED_OPS_RDWR(omap_fbdev),
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
- __FB_DEFAULT_DMAMEM_OPS_DRAW,
+ __FB_DEFAULT_DEFERRED_OPS_DRAW(omap_fbdev),
.fb_ioctl = drm_fb_helper_ioctl,
.fb_mmap= omap_fbdev_fb_mmap,
.fb_destroy = omap_fbdev_fb_destroy,
--
2.43.1
[PATCH 1/2] drm/omapdrm: Fix console by implementing fb_dirty
The framebuffer console stopped updating with commit f231af498c29
("drm/fb-helper: Disconnect damage worker from update logic").
Let's fix the issue by implementing fb_dirty similar to what was done
with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
custom fb helper").
Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update
logic")
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -238,8 +238,20 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
return ret;
}
+static int omap_fbdev_dirty(struct drm_fb_helper *helper, struct drm_clip_rect
*clip)
+{
+ if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+ return 0;
+
+ if (helper->fb->funcs->dirty)
+ return helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, clip,
1);
+
+ return 0;
+}
+
static const struct drm_fb_helper_funcs omap_fb_helper_funcs = {
.fb_probe = omap_fbdev_create,
+ .fb_dirty = omap_fbdev_dirty,
};
static struct drm_fb_helper *get_fb(struct fb_info *fbi)
--
2.43.1
Re: Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote: > On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote: > > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > > > wrote: > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > > > * > > > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full > > > > > > > > > > > > > > vs Limited) used. > > > > > > > > > > > > > > + * Infoframes will be generated according to > > > > > > > > > > > > > > that value. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * The value of this property can be one of > > > > > > > > > > > > > > the following: > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > > > + * RGB Range is selected > > > > > > > > > > > > > > automatically based on the mode > > > > > > > > > > > > > > + * according to the HDMI > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Full: > > > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > > > + * Limited RGB Range is forced. > > > > > > > > > > > > > > Unlike the name suggests, > > > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > > > There might be two > > > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color > > > > > > > > > > > > > pipeline processing > > > > > > > > > > > > > such that a full-range input to the CRTC is converted > > > > > > > > > > > > > to either full- or > > > > > > > > > > > > > limited-range, depending on what the monitor is > > > > > > > > > > > > > supposed to accept. > > > > > > > > > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there > > > > > > > > > > > > > is no signalling, > > > > > > > > > > > > > or that the signalling matches what the monitor is > > > > > > > > > > > > > supposed to accept > > > > > > > > > > > > > according to the spec? Also, is this really HDMI > > > > > > > > > > > > > specific? > > > > > > > > > > > > > > > > > > > > > > > > > > When full or limited is selected and the monitor > > > > > > > > > > > > > doesn't support the > > > > > > > > > > > > > signalling, what happens? > > > > > > > > > > > > > > > > > > > > > > > > Forgot to mention: user-space still has no control over > > > > > > > > > > > > RGB vs YCbCr on > > > > > > > > > > > > the cable, so is this only affecting RGB? If not, how > > > > > > > > > > > > does it affect > > > > > > > > > > > > YCbCr? > > > > > > > > > > > > > > > > > > > > > > So I dug a bit into both the i915 and vc4 drivers, and it > > > > > > > > > > > looks like if > > > > > > > > > > > we're using a YCbCr format, i915 will always use a > > > > > > > > > > > limited range while > > > > > > > > > > > vc4 will follow the value of the property. > > > > > > > > > > > > > > > > > > > > The property is literally called "Broadcast *RGB*". > > > > > > > > > > That should explain why it's only affecting RGB. > > > > > > > > > > > > > > > > > > Right. And the limited range option is called "Limited > > > > > > > > > 16:235" despite > > > > > > > > > being usable on bpc > 8 bits. Naming errors occurs, and > > > > > > > > > history happens > > > > > > > > >
[PATCH v4] drm/msm/dpu: add current resource allocation to dumped state
else + drm_puts(p, "- "); + drm_puts(p, "\n"); + + drm_puts(p, "\tcdm="); + if (rm->cdm_blk) + drm_printf(p, "%d ", global_state->cdm_to_enc_id); + else + drm_puts(p, "- "); + drm_puts(p, "\n"); +} diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h index e3f83ebc656b..e63db8ace6b9 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h @@ -89,6 +89,14 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm, struct dpu_global_state *global_state, uint32_t enc_id, enum dpu_hw_blk_type type, struct dpu_hw_blk **blks, int blks_size); +/** + * dpu_rm_print_state - output the RM private state + * @p: DRM printer + * @global_state: global state + */ +void dpu_rm_print_state(struct drm_printer *p, + const struct dpu_global_state *global_state); + /** * dpu_rm_get_intf - Return a struct dpu_hw_intf instance given it's index. * @rm: DPU Resource Manager handle --- base-commit: 41c177cf354126a22443b5c80cec9fdd313e67e1 change-id: 20240219-fd-rm-state-bd1218954b78 Best regards, -- Dmitry Baryshkov
Re: drm/msm: Second DisplayPort regression in 6.8-rc1
On Mon, Feb 19, 2024 at 11:41:41AM +0100, Johan Hovold wrote: > It seems my initial suspicion that at least some of these regressions > were related to the runtime PM work was correct. The hard resets happens > when the DP controller is runtime suspended after being probed: > [ 17.074925] bus: 'platform': __driver_probe_device: matched device > aea.displayport-controller with driver msm-dp-display > [ 17.112000] msm-dp-display aea.displayport-controller: > dp_display_probe - populate aux bus > [ 17.125208] msm-dp-display aea.displayport-controller: > dp_pm_runtime_resume > [ 17.197909] msm-dp-display aea.displayport-controller: > dp_pm_runtime_suspend > [ 17.198079] probe of aea0Format: Log Type - Time(microsec) - Message - > Optional Info > Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic > S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1 > S - IMAGE_VARIANT_STRING=SocMakenaWP > S - OEM_IMAGE_VERSION_STRING=crm-ubuntu92 > > < machine is reset by hypervisor > > > Presumably the reset happens when controller is being shut down while > still being used by the EFI framebuffer. > > In the cases where the machines survives boot, the controller is never > suspended. > > When investigating this I've also seen intermittent: > > [drm:dp_display_probe [msm]] *ERROR* device tree parsing failed Note that there are further indications there may be more than one bug here too. I definitely see hard resets when dp_pm_runtime_suspend() is shutting down the eDP PHY, but there are occasional resets also if I instrument DP controller probe() to resume and then prevent the controller from suspending until after a timeout (e.g. to be used as a temporary workaround): [ 15.676495] bus: 'platform': __driver_probe_device: matched device aea.displayport-controller with driver msm-dp-display [ 15.769392] msm-dp-display aea.displayport-controller: dp_display_probe - populate aux bus [ 15.778808] msm-dp-display aea.displayport-controller: dp_display_probe - scheduling handover [ 15.789931] probe of aea.displayport-controller returned 0 after 91121 usecs [ 15.790460] bus: 'dp-aux': __driver_probe_device: matched device aux-aea.displayport-controller with driver panel-simple-dp-aux Format: Log Type - Time(microsec) - Message - Optional Info Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1 I'll wait for the maintainers and authors of this code to comment, but it seems the runtime PM work is broken in multiple ways. Johan
[PATCH 8/8] arm64: dts: qcom: qrb2210-rb1: Enable the GPU
Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol).
[1]
https://docs.qualcomm.com/bundle/publicresource/87-61720-1_REV_A_QUALCOMM_ROBOTICS_RB1_PLATFORM__QUALCOMM_QRB2210__PRODUCT_BRIEF.pdf
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
index 6e9dd0312adc..c9abca5a7e39 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
@@ -199,6 +199,14 @@ &gpi_dma0 {
status = "okay";
};
+&gpu {
+ status = "okay";
+
+ zap-shader {
+ firmware-name = "qcom/qcm2290/a702_zap.mbn";
+ };
+};
+
&i2c2 {
clock-frequency = <40>;
status = "okay";
--
2.43.2
[PATCH 7/8] arm64: dts: qcom: qcm2290: Add GPU nodes
Describe the GPU hardware on the QCM2290.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 154 ++
1 file changed, 154 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
index 89beac833d43..ec5aef5d9c69 100644
--- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -737,6 +738,11 @@ qusb2_hstx_trim: hstx-trim@25b {
reg = <0x25b 0x1>;
bits = <1 4>;
};
+
+ gpu_speed_bin: gpu-speed-bin@2006 {
+ reg = <0x2006 0x2>;
+ bits = <5 8>;
+ };
};
pmu@1b8e300 {
@@ -1383,6 +1389,154 @@ usb_dwc3: usb@4e0 {
};
};
+ gpu: gpu@590 {
+ compatible = "qcom,adreno-07000200", "qcom,adreno";
+ reg = <0x0 0x0590 0x0 0x4>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = ;
+
+ clocks = <&gpucc GPU_CC_GX_GFX3D_CLK>,
+<&gpucc GPU_CC_AHB_CLK>,
+<&gcc GCC_BIMC_GPU_AXI_CLK>,
+<&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+<&gpucc GPU_CC_CX_GMU_CLK>,
+<&gpucc GPU_CC_CXO_CLK>;
+ clock-names = "core",
+ "iface",
+ "mem_iface",
+ "alt_mem_iface",
+ "gmu",
+ "xo";
+
+ interconnects = <&bimc MASTER_GFX3D RPM_ALWAYS_TAG
+&bimc SLAVE_EBI1 RPM_ALWAYS_TAG>;
+ interconnect-names = "gfx-mem";
+
+ iommus = <&adreno_smmu 0 1>,
+<&adreno_smmu 2 0>;
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&rpmpd QCM2290_VDDCX>;
+ qcom,gmu = <&gmu_wrapper>;
+
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+ #cooling-cells = <2>;
+
+ status = "disabled";
+
+ zap-shader {
+ memory-region = <&pil_gpu_mem>;
+ };
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ /* TODO: Scale RPM_SMD_BIMC_GPU_CLK w/ turbo
freqs */
+ opp-112320 {
+ opp-hz = /bits/ 64 <112320>;
+ required-opps = <&rpmpd_opp_turbo_plus>;
+ opp-peak-kBps = <6881000>;
+ opp-supported-hw = <0x3>;
+ turbo-mode;
+ };
+
+ opp-101760 {
+ opp-hz = /bits/ 64 <101760>;
+ required-opps = <&rpmpd_opp_turbo>;
+ opp-peak-kBps = <6881000>;
+ opp-supported-hw = <0x3>;
+ turbo-mode;
+ };
+
+ opp-92160 {
+ opp-hz = /bits/ 64 <92160>;
+ required-opps = <&rpmpd_opp_nom_plus>;
+ opp-peak-kBps = <6881000>;
+ opp-supported-hw = <0x3>;
+ };
+
+ opp-84480 {
+ opp-hz = /bits/ 64 <84480>;
+ required-opps = <&rpmpd_opp_nom>;
+ opp-peak-kBps = <6881000>;
+ opp-supported-hw = <0x7>;
+ };
+
+ opp-67200 {
+ opp-hz = /bits/ 64 <67200>;
+ required-opps = <&rpmpd_opp_svs_plus>;
+ opp-peak-kBps = <3879000>;
+ opp-supported-hw = <0xf>;
+ };
+
+ opp-53760 {
+
[PATCH 6/8] drm/msm/adreno: Add A702 support
The A702 is a weird mix of 600 and 700 series.. Perhaps even a
testing ground for some A7xx features with good ol' A6xx silicon.
It's basically A610 that's been beefed up with some new registers
and hw features (like APRIV!), that was then cut back in size,
memory bus and some other ways.
Add support for it, tested with QCM2290 / RB1.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 92 +++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 18 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 16 +-
3 files changed, 117 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c9c55e2ea584..2a491a486ca1 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -837,6 +837,65 @@ const struct adreno_reglist a690_hwcg[] = {
{}
};
+const struct adreno_reglist a702_hwcg[] = {
+ { REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0081 },
+ { REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xf3cf },
+ { REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001 },
+ { REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007 },
+ { REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0120 },
+ { REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220 },
+ { REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040f00 },
+ { REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x05522022 },
+ { REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x },
+ { REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011 },
+ { REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044 },
+ { REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422 },
+ { REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x },
+ { REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0222 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002 },
+ { REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x },
+ { REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x },
+ { REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004 },
+ { REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002 },
+ { REG_A6XX_RBBM_ISDB_CNT, 0x0182 },
+ { REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x },
+ { REG_A6XX_RBBM_SP_HYST_CNT, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111 },
+ { REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555 },
+ { REG_A6XX_RBBM_CLOCK_CNTL_FCHE, 0x0222 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_FCHE, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_FCHE, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL_GLC, 0x0022 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_GLC, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_GLC, 0x },
+ { REG_A6XX_RBBM_CLOCK_CNTL_MHUB, 0x0002 },
+ { REG_A6XX_RBBM_CLOCK_DELAY_MHUB, 0x },
+ { REG_A6XX_RBBM_CLOCK_HYST_MHUB, 0x },
+ {}
+};
+
const struct adreno_reglist a730_hwcg[] = {
{ REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222 },
{ REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0202 },
@@ -968,6 +1027,8 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
clock_cntl_on = 0x8aa8aa02;
else if (adreno_is_a610(adreno_gpu))
clock_cntl_on = 0xaaa8aa82;
+ else if (adreno_is_a702(adreno_gpu))
+ clock_cntl_on = 0xaa82;
else
clock_cntl_on = 0x8aa8aa82;
@@ -989,14 +1050,14 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool
state)
return;
/* Disable SP clock before programming HWCG registers */
- if (!adreno_is_a610(adreno_gpu) && !adreno_is_a7xx(adreno_gpu))
+ if (!adreno_is_a610_family(adreno_gpu) && !adreno_is_a7xx(adreno_gpu))
gmu_rmw(gmu, REG_A6XX_GPU_GMU_GX_SPTPRAC_CLOCK_CONTROL, 1, 0);
for (i = 0; (reg = &adreno_gpu->info->hw
[PATCH 5/8] drm/msm/adreno: Add missing defines for A702
Add some defines required for A702. Can be substituted with a header
sync after merging mesa!27665 [1].
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27665
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 863b5e3b0e67..1ec4dbc0e746 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -1945,6 +1945,24 @@ static inline uint32_t
REG_A6XX_RBBM_PERFCTR_RBBM_SEL(uint32_t i0) { return 0x00
#define REG_A6XX_RBBM_CLOCK_HYST_TEX_FCHE 0x0122
+#define REG_A6XX_RBBM_CLOCK_CNTL_FCHE 0x0123
+
+#define REG_A6XX_RBBM_CLOCK_DELAY_FCHE 0x0124
+
+#define REG_A6XX_RBBM_CLOCK_HYST_FCHE 0x0125
+
+#define REG_A6XX_RBBM_CLOCK_CNTL_MHUB 0x0126
+
+#define REG_A6XX_RBBM_CLOCK_DELAY_MHUB 0x0127
+
+#define REG_A6XX_RBBM_CLOCK_HYST_MHUB 0x0128
+
+#define REG_A6XX_RBBM_CLOCK_DELAY_GLC 0x0129
+
+#define REG_A6XX_RBBM_CLOCK_HYST_GLC 0x012a
+
+#define REG_A6XX_RBBM_CLOCK_CNTL_GLC 0x012b
+
#define REG_A7XX_RBBM_CLOCK_HYST2_VFD 0x012f
#define REG_A6XX_RBBM_LPAC_GBIF_CLIENT_QOS_CNTL
0x05ff
--
2.43.2
[PATCH 3/8] clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support
Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
introduced an entry to the alpha offsets array, but diving into QCM2290
downstream and some documentation, it turned out that the name Huayra
apparently has been used quite liberally across many chips, even with
noticeably different hardware.
Introduce another set of offsets and a new configure function for the
Huayra PLL found on QCM2290. This is required e.g. for the consumers
of GPUCC_PLL0 to properly start.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/clk-alpha-pll.c | 45
drivers/clk/qcom/clk-alpha-pll.h | 3 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 8a412ef47e16..61b5abd13782 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
[PLL_OFF_OPMODE] = 0x30,
[PLL_OFF_STATUS] = 0x3c,
},
+ [CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
+ [PLL_OFF_L_VAL] = 0x04,
+ [PLL_OFF_ALPHA_VAL] = 0x08,
+ [PLL_OFF_USER_CTL] = 0x0c,
+ [PLL_OFF_CONFIG_CTL] = 0x10,
+ [PLL_OFF_CONFIG_CTL_U] = 0x14,
+ [PLL_OFF_CONFIG_CTL_U1] = 0x18,
+ [PLL_OFF_TEST_CTL] = 0x1c,
+ [PLL_OFF_TEST_CTL_U] = 0x20,
+ [PLL_OFF_TEST_CTL_U1] = 0x24,
+ [PLL_OFF_OPMODE] = 0x28,
+ [PLL_OFF_STATUS] = 0x38,
+ },
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
@@ -779,6 +792,38 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw,
unsigned long rate,
return clamp(rate, min_freq, max_freq);
}
+void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap
*regmap,
+ const struct alpha_pll_config *config)
+{
+ clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL(pll),
config->config_ctl_val);
+ clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U(pll),
config->config_ctl_hi_val);
+ clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U1(pll),
config->config_ctl_hi1_val);
+ clk_alpha_pll_write_config(regmap, PLL_TEST_CTL(pll),
config->test_ctl_val);
+ clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U(pll),
config->test_ctl_hi_val);
+ clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U1(pll),
config->test_ctl_hi1_val);
+ clk_alpha_pll_write_config(regmap, PLL_L_VAL(pll), config->l);
+ clk_alpha_pll_write_config(regmap, PLL_ALPHA_VAL(pll), config->alpha);
+ clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll),
config->user_ctl_val);
+
+ /* Set PLL_BYPASSNL */
+ regmap_update_bits(regmap, PLL_MODE(pll), PLL_BYPASSNL, PLL_BYPASSNL);
+
+ /* Wait 5 us between setting BYPASS and deasserting reset */
+ mb();
+ udelay(5);
+
+ /* Take PLL out from reset state */
+ regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
+
+ /* Wait 50us for PLL_LOCK_DET bit to go high */
+ mb();
+ usleep_range(50, 55);
+
+ /* Enable PLL output */
+ regmap_update_bits(regmap, PLL_MODE(pll), PLL_OUTCTRL, PLL_OUTCTRL);
+}
+EXPORT_SYMBOL(clk_huayra_2290_pll_configure);
+
static unsigned long
alpha_huayra_pll_calc_rate(u64 prate, u32 l, u32 a)
{
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index fb6d50263bb9..91d3d6f19eae 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -29,6 +29,7 @@ enum {
CLK_ALPHA_PLL_TYPE_BRAMMO_EVO,
CLK_ALPHA_PLL_TYPE_STROMER,
CLK_ALPHA_PLL_TYPE_STROMER_PLUS,
+ CLK_ALPHA_PLL_TYPE_HUAYRA_2290,
CLK_ALPHA_PLL_TYPE_MAX,
};
@@ -191,6 +192,8 @@ extern const struct clk_ops clk_alpha_pll_rivian_evo_ops;
void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
const struct alpha_pll_config *config);
+void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap
*regmap,
+ const struct alpha_pll_config *config);
void clk_fabia_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
const struct alpha_pll_config *config);
void clk_trion_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
--
2.43.2
[PATCH 4/8] clk: qcom: Add QCM2290 GPU clock controller driver
Add a driver for the GPU clock controller block found on the QCM2290 SoC.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/Kconfig | 9 +
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/gpucc-qcm2290.c | 423 +++
3 files changed, 433 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 4580edbd13ea..d70ea4548755 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -65,6 +65,15 @@ config CLK_X1E80100_TCSRCC
Support for the TCSR clock controller on X1E80100 devices.
Say Y if you want to use peripheral devices such as SD/UFS.
+config CLK_QCM2290_GPUCC
+ tristate "QCM2290 Graphics Clock Controller"
+ depends on ARM64 || COMPILE_TEST
+ select CLK_QCM2290_GCC
+ help
+ Support for the graphics clock controller on QCM2290 devices.
+ Say Y if you want to support graphics controller devices and
+ functionality such as 3D graphics.
+
config QCOM_A53PLL
tristate "MSM8916 A53 PLL"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 1da65ca78e24..b8d49c054558 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_CLK_X1E80100_DISPCC) += dispcc-x1e80100.o
obj-$(CONFIG_CLK_X1E80100_GCC) += gcc-x1e80100.o
obj-$(CONFIG_CLK_X1E80100_GPUCC) += gpucc-x1e80100.o
obj-$(CONFIG_CLK_X1E80100_TCSRCC) += tcsrcc-x1e80100.o
+obj-$(CONFIG_CLK_QCM2290_GPUCC) += gpucc-qcm2290.o
obj-$(CONFIG_IPQ_APSS_PLL) += apss-ipq-pll.o
obj-$(CONFIG_IPQ_APSS_6018) += apss-ipq6018.o
obj-$(CONFIG_IPQ_GCC_4019) += gcc-ipq4019.o
diff --git a/drivers/clk/qcom/gpucc-qcm2290.c b/drivers/clk/qcom/gpucc-qcm2290.c
new file mode 100644
index ..b6e20d63ac85
--- /dev/null
+++ b/drivers/clk/qcom/gpucc-qcm2290.c
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "clk-regmap-phy-mux.h"
+#include "gdsc.h"
+#include "reset.h"
+
+enum {
+ DT_GCC_AHB_CLK,
+ DT_BI_TCXO,
+ DT_GCC_GPU_GPLL0_CLK_SRC,
+ DT_GCC_GPU_GPLL0_DIV_CLK_SRC,
+};
+
+enum {
+ P_BI_TCXO,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL0_OUT_MAIN_DIV,
+ P_GPU_CC_PLL0_2X_DIV_CLK_SRC,
+ P_GPU_CC_PLL0_OUT_AUX,
+ P_GPU_CC_PLL0_OUT_AUX2,
+ P_GPU_CC_PLL0_OUT_MAIN,
+};
+
+static const struct pll_vco huayra_vco[] = {
+ { 6, 33, 0 },
+ { 6, 22, 1 },
+};
+
+static const struct alpha_pll_config gpu_cc_pll0_config = {
+ .l = 0x25,
+ .config_ctl_val = 0x200d4828,
+ .config_ctl_hi_val = 0x6,
+ .test_ctl_val = GENMASK(28, 26),
+ .test_ctl_hi_val = BIT(14),
+ .user_ctl_val = 0xf,
+};
+
+static struct clk_alpha_pll gpu_cc_pll0 = {
+ .offset = 0x0,
+ .vco_table = huayra_vco,
+ .num_vco = ARRAY_SIZE(huayra_vco),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_HUAYRA_2290],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "gpu_cc_pll0",
+ .parent_data = &(const struct clk_parent_data) {
+ .index = DT_BI_TCXO,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_huayra_ops,
+ },
+ },
+};
+
+static const struct parent_map gpu_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_GPU_CC_PLL0_OUT_MAIN, 1 },
+ { P_GPLL0_OUT_MAIN, 5 },
+ { P_GPLL0_OUT_MAIN_DIV, 6 },
+};
+
+static const struct clk_parent_data gpu_cc_parent_data_0[] = {
+ { .index = DT_BI_TCXO, },
+ { .hw = &gpu_cc_pll0.clkr.hw, },
+ { .index = DT_GCC_GPU_GPLL0_CLK_SRC, },
+ { .index = DT_GCC_GPU_GPLL0_DIV_CLK_SRC, },
+};
+
+static const struct parent_map gpu_cc_parent_map_1[] = {
+ { P_BI_TCXO, 0 },
+ { P_GPU_CC_PLL0_2X_DIV_CLK_SRC, 1 },
+ { P_GPU_CC_PLL0_OUT_AUX2, 2 },
+ { P_GPU_CC_PLL0_OUT_AUX, 3 },
+ { P_GPLL0_OUT_MAIN, 5 },
+};
+
+static const struct clk_parent_data gpu_cc_parent_data_1[] = {
+ { .index = DT_BI_TCXO, },
+ { .hw = &gpu_cc_pll0.clkr.hw, },
+ { .hw = &gpu_cc_pll0.clkr.hw, },
+ { .hw = &gpu_cc_pll0.clkr.hw, },
+ { .index = DT_GCC_GPU_GPLL0_CLK_SRC, },
+};
+
+static const struct freq_tbl ftbl_gpu_cc_gmu_clk_src[] = {
+ F(2, P_GPLL0_OUT_MAIN, 3, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 gpu_cc_gmu_clk_src = {
+ .cmd_rcgr = 0x1120,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = gpu_cc_parent_map_0,
+
[PATCH 1/8] dt-bindings: arm-smmu: Add QCM2290 GPU SMMU
The GPU SMMU on QCM2290 nicely fits into the description we already have for SM61[12]5. Add it. Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index a4042ae24770..4a8d4022aebc 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -83,6 +83,7 @@ properties: - description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500" items: - enum: + - qcom,qcm2290-smmu-500 - qcom,sa8775p-smmu-500 - qcom,sc7280-smmu-500 - qcom,sc8280xp-smmu-500 @@ -462,6 +463,7 @@ allOf: compatible: items: - enum: +- qcom,qcm2290-smmu-500 - qcom,sm6115-smmu-500 - qcom,sm6125-smmu-500 - const: qcom,adreno-smmu @@ -534,7 +536,6 @@ allOf: - cavium,smmu-v2 - marvell,ap806-smmu-500 - nvidia,smmu-500 - - qcom,qcm2290-smmu-500 - qcom,qdu1000-smmu-500 - qcom,sc7180-smmu-500 - qcom,sc8180x-smmu-500 -- 2.43.2
[PATCH 2/8] dt-bindings: clock: Add Qcom QCM2290 GPUCC
Add device tree bindings for graphics clock controller for Qualcomm
Technology Inc's QCM2290 SoCs.
Signed-off-by: Konrad Dybcio
---
.../bindings/clock/qcom,qcm2290-gpucc.yaml | 76 ++
include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 +
2 files changed, 108 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
new file mode 100644
index ..a16cb7e87e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,qcm2290-gpucc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Graphics Clock & Reset Controller on QCM2290
+
+maintainers:
+ - Konrad Dybcio
+
+description: |
+ Qualcomm graphics clock control module provides the clocks, resets and power
+ domains on Qualcomm SoCs.
+
+ See also::
+include/dt-bindings/clock/qcom,qcm2290-gpucc.h
+
+properties:
+ compatible:
+- const: qcom,qcm2290-gpucc
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: AHB interface clock,
+ - description: SoC CXO clock
+ - description: GPLL0 main branch source
+ - description: GPLL0 div branch source
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+clock-controller@599 {
+compatible = "qcom,qcm2290-gpucc";
+reg = <0x0 0x0599 0x0 0x9000>;
+clocks = <&gcc GCC_GPU_CFG_AHB_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+power-domains = <&rpmpd QCM2290_VDDCX>;
+required-opps = <&rpmpd_opp_low_svs>;
+#clock-cells = <1>;
+#reset-cells = <1>;
+#power-domain-cells = <1>;
+};
+};
+...
diff --git a/include/dt-bindings/clock/qcom,qcm2290-gpucc.h
b/include/dt-bindings/clock/qcom,qcm2290-gpucc.h
new file mode 100644
index ..7c76dd05278f
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,qcm2290-gpucc.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Limited
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GPU_CC_QCM2290_H
+#define _DT_BINDINGS_CLK_QCOM_GPU_CC_QCM2290_H
+
+/* GPU_CC clocks */
+#define GPU_CC_AHB_CLK 0
+#define GPU_CC_CRC_AHB_CLK 1
+#define GPU_CC_CX_GFX3D_CLK2
+#define GPU_CC_CX_GMU_CLK 3
+#define GPU_CC_CX_SNOC_DVM_CLK 4
+#define GPU_CC_CXO_AON_CLK 5
+#define GPU_CC_CXO_CLK 6
+#define GPU_CC_GMU_CLK_SRC 7
+#define GPU_CC_GX_GFX3D_CLK8
+#define GPU_CC_GX_GFX3D_CLK_SRC9
+#define GPU_CC_PLL010
+#define GPU_CC_SLEEP_CLK 11
+#define GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK 12
+
+/* Resets */
+#define GPU_GX_BCR 0
+
+/* GDSCs */
+#define GPU_CX_GDSC0
+#define GPU_GX_GDSC1
+
+#endif
--
2.43.2
[PATCH 0/8] A702 support
Bit of a megaseries, bunched together for your testing convenience.. Needs mesa!27665 [1] on the userland part, kmscube happily spins. I'm feeling quite lukewarm about the memory barriers in patch 3.. Patch 1 for Will/smmu, 5-6 for drm/msm, rest for qcom [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27665 Signed-off-by: Konrad Dybcio --- Konrad Dybcio (8): dt-bindings: arm-smmu: Add QCM2290 GPU SMMU dt-bindings: clock: Add Qcom QCM2290 GPUCC clk: qcom: clk-alpha-pll: Add HUAYRA_2290 support clk: qcom: Add QCM2290 GPU clock controller driver drm/msm/adreno: Add missing defines for A702 drm/msm/adreno: Add A702 support arm64: dts: qcom: qcm2290: Add GPU nodes arm64: dts: qcom: qrb2210-rb1: Enable the GPU .../bindings/clock/qcom,qcm2290-gpucc.yaml | 76 .../devicetree/bindings/iommu/arm,smmu.yaml| 3 +- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 154 arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 8 + drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/clk-alpha-pll.c | 45 +++ drivers/clk/qcom/clk-alpha-pll.h | 3 + drivers/clk/qcom/gpucc-qcm2290.c | 423 + drivers/gpu/drm/msm/adreno/a6xx.xml.h | 18 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 92 - drivers/gpu/drm/msm/adreno/adreno_device.c | 18 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 16 +- include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 ++ 14 files changed, 888 insertions(+), 10 deletions(-) --- base-commit: 26d7d52b6253574d5b6fec16a93e1110d1489cef change-id: 20240219-topic-rb1_gpu-3ec8c6830384 Best regards, -- Konrad Dybcio
Re: [PATCH] drm/i915: Add some boring kerneldoc
On Mon, 2024-02-19 at 13:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tooling appears very strict so lets pacify it by adding some comments,
> even if fields are completely self-explanatory.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Tvrtko Ursulin
> Fixes: b11236486749 ("drm/i915: Add GuC submission interface version query")
> Reported-by: Stephen Rothwell
> Cc: Jose Souza
> ---
> include/uapi/drm/i915_drm.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bd87386a8243..2ee338860b7e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3572,9 +3572,13 @@ struct drm_i915_query_memory_regions {
> * struct drm_i915_query_guc_submission_version - query GuC submission
> interface version
> */
> struct drm_i915_query_guc_submission_version {
> + /** @branch: Firmware branch version. */
> __u32 branch;
> + /** @major: Firmware major version. */
> __u32 major;
> + /** @minor: Firmware minor version. */
> __u32 minor;
> + /** @patch: Firmware patch version. */
> __u32 patch;
> };
>
[PATCH] drm/i915: Add some boring kerneldoc
From: Tvrtko Ursulin
Tooling appears very strict so lets pacify it by adding some comments,
even if fields are completely self-explanatory.
Signed-off-by: Tvrtko Ursulin
Fixes: b11236486749 ("drm/i915: Add GuC submission interface version query")
Reported-by: Stephen Rothwell
Cc: Jose Souza
---
include/uapi/drm/i915_drm.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index bd87386a8243..2ee338860b7e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3572,9 +3572,13 @@ struct drm_i915_query_memory_regions {
* struct drm_i915_query_guc_submission_version - query GuC submission
interface version
*/
struct drm_i915_query_guc_submission_version {
+ /** @branch: Firmware branch version. */
__u32 branch;
+ /** @major: Firmware major version. */
__u32 major;
+ /** @minor: Firmware minor version. */
__u32 minor;
+ /** @patch: Firmware patch version. */
__u32 patch;
};
--
2.40.1
Re: [PATCH] drm: document userspace expectations around the Colorspace connector property
On Tue, Feb 13, 2024 at 11:26:44AM +0200, Ville Syrjälä wrote: > On Mon, Feb 12, 2024 at 05:50:36PM +0100, Sebastian Wick wrote: > > On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote: > > > On Fri, 9 Feb 2024 17:53:07 +0100 > > > Xaver Hugl wrote: > > > > > > > Signed-off-by: Xaver Hugl > > > > --- > > > > drivers/gpu/drm/drm_connector.c | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/drm_connector.c > > > > b/drivers/gpu/drm/drm_connector.c > > > > index b0516505f7ae..01e13984629b 100644 > > > > --- a/drivers/gpu/drm/drm_connector.c > > > > +++ b/drivers/gpu/drm/drm_connector.c > > > > @@ -2158,6 +2158,14 @@ > > > > EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); > > > > * one supported. Sink supported colorspaces should be retrieved by > > > > * userspace from EDID and driver will not explicitly expose them. > > > > * > > > > + * As userspace can't currently know whether or not the output is > > > > using > > > > + * RGB or YCC signalling, the driver must translate properties to > > > > their > > > > + * relevant RGB or YCC counterparts, depending on the actually used > > > > + * signalling. Property values that are only valid for either YCC > > > > or RGB > > > > + * and have no equivalent for the other signalling type must not be > > > > + * exposed as supported, unless the driver can guarantee it never > > > > uses > > > > + * the signalling that doesn't match the property. > > > > + * > > > > * Basically the expectation from userspace is: > > > > * - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink > > > > *colorspace > > > > > > While this addition is good, I have another question: > > > > > > Does "Colorspace" property choose also the RGB->YCbCr matrix that the > > > driver will use when it happens to use YCbCr signalling? > > > > > > So far we have only been talking about the primaries and white point. > > > > Uh, yeah, good point. The InfoFrames do affect both the YCbCr conversion > > and the transfer characteristics that the sink expects. Drivers should > > do the RGB to YCbCr conversion with the new matrix. I think (and very > > much hope) that drivers don't rely on the TF for any internal processing > > but if they did, they also should use the one the sink expects. > > What we need is: > - list of the property values that are still allowd (the ones that still > make sense with the changed semantics) > - mark all the other ones as deprecated > - filter/reject the deprecated values when creating the property > - document each valid enum value fully (for both RGB and YCbCr output): > * what exacly is signalled to the sink via infoframe/msa/vsc sdp > * what processing is the driver expected to perform on the actual data I'm starting to agree that this is a better idea than coming up with a number of rules. We only rely on the default colorimetry as indicated by EDID and BT.2020. Xaver, are you going to update the patch accordingly? > -- > Ville Syrjälä > Intel >
