[PATCH] MAINTAINERS: qaic: Drop Pranjal as reviewer
Pranjal's email address is bouncing. Signed-off-by: Jeffrey Hugo --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 71b739b40921..258f6236ac1c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18461,7 +18461,6 @@ F: include/dt-bindings/clock/qcom,* QUALCOMM CLOUD AI (QAIC) DRIVER M: Jeffrey Hugo R: Carl Vanderlip -R: Pranjal Ramajor Asha Kanojiya L: linux-arm-...@vger.kernel.org L: dri-devel@lists.freedesktop.org S: Supported -- 2.34.1
Re: [PATCH] accel/qaic: Remove the description of DRM_IOCTL_QAIC_PART_DEV
On 7/16/2024 1:30 AM, Zenghui Yu wrote: The partition device ioctl was removed during the development of the initial version of qaic driver. Remove its description from the documentation to avoid confusing readers. Signed-off-by: Zenghui Yu Pushed to drm-misc-next -Jeff
Re: [PATCH] accel/qaic: Remove the description of DRM_IOCTL_QAIC_PART_DEV
On 7/16/2024 1:30 AM, Zenghui Yu wrote: The partition device ioctl was removed during the development of the initial version of qaic driver. Remove its description from the documentation to avoid confusing readers. Signed-off-by: Zenghui Yu Reviewed-by: Jeffrey Hugo
Re: [PATCH 2/2] drm/mipi-dsi: Change multi functions to use quiet member of mipi_dsi_multi_context
Hi, On Fri, Jul 26, 2024 at 2:15 AM Maxime Ripard wrote: > > > c) Declare that, since there are no known cases where we want to > > suppress the error printouts, that suppressing the error printouts is > > a "tomorrow" problem. We transition everyone to _multi but don't > > provide a way to suppress the printouts. > > That's my preferred solution. OK, fair enough. So I guess the transition plan would be: 1. Add a wrapper like we're doing today. 2. Transition everyone to the _multi variant. 3. Delete the non-multi variant which will cause us to delete the wrapper. -Doug
Re: [PATCH v2 2/2] drm/radeon: convert bios_hardcoded_edid to drm_edid
Applied the series. Thanks!
Alex
On Fri, Jul 26, 2024 at 9:40 AM Thomas Weißschuh wrote:
>
> Instead of manually passing around 'struct edid *' and its size,
> use 'struct drm_edid', which encapsulates a validated combination of
> both.
>
> As the drm_edid_ can handle NULL gracefully, the explicit checks can be
> dropped.
>
> Also save a few characters by transforming '[0]' to the equivalent
> 'array' and using 'max_t(int, ...)' instead of manual casts.
>
> Signed-off-by: Thomas Weißschuh
> ---
> drivers/gpu/drm/radeon/radeon_atombios.c | 17 ++---
> drivers/gpu/drm/radeon/radeon_combios.c| 26 +-
> drivers/gpu/drm/radeon/radeon_connectors.c | 4 ++--
> drivers/gpu/drm/radeon/radeon_display.c| 2 +-
> drivers/gpu/drm/radeon/radeon_mode.h | 4 ++--
> 5 files changed, 16 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
> b/drivers/gpu/drm/radeon/radeon_atombios.c
> index 168f3f94003b..81a0a91921b9 100644
> --- a/drivers/gpu/drm/radeon/radeon_atombios.c
> +++ b/drivers/gpu/drm/radeon/radeon_atombios.c
> @@ -1716,23 +1716,18 @@ struct radeon_encoder_atom_dig
> *radeon_atombios_get_lvds_info(struct
> case LCD_FAKE_EDID_PATCH_RECORD_TYPE:
> fake_edid_record =
> (ATOM_FAKE_EDID_PATCH_RECORD *)record;
> if
> (fake_edid_record->ucFakeEDIDLength) {
> - struct edid *edid;
> + const struct drm_edid *edid;
> int edid_size;
>
> if
> (fake_edid_record->ucFakeEDIDLength == 128)
> edid_size =
> fake_edid_record->ucFakeEDIDLength;
> else
> edid_size =
> fake_edid_record->ucFakeEDIDLength * 128;
> - edid =
> kmemdup(_edid_record->ucFakeEDIDString[0],
> - edid_size,
> GFP_KERNEL);
> - if (edid) {
> - if
> (drm_edid_is_valid(edid)) {
> -
> rdev->mode_info.bios_hardcoded_edid = edid;
> -
> rdev->mode_info.bios_hardcoded_edid_size = edid_size;
> - } else {
> - kfree(edid);
> - }
> - }
> + edid =
> drm_edid_alloc(fake_edid_record->ucFakeEDIDString, edid_size);
> + if (drm_edid_valid(edid))
> +
> rdev->mode_info.bios_hardcoded_edid = edid;
> + else
> + drm_edid_free(edid);
> record +=
> struct_size(fake_edid_record,
>
> ucFakeEDIDString,
>
> edid_size);
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 41ddc576f8f8..df8d7f56b028 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -370,7 +370,7 @@ static uint16_t combios_get_table_offset(struct
> drm_device *dev,
> bool radeon_combios_check_hardcoded_edid(struct radeon_device *rdev)
> {
> int edid_info, size;
> - struct edid *edid;
> + const struct drm_edid *edid;
> unsigned char *raw;
> edid_info = combios_get_table_offset(rdev_to_drm(rdev),
> COMBIOS_HARDCODED_EDID_TABLE);
> if (!edid_info)
> @@ -378,19 +378,14 @@ bool radeon_combios_check_hardcoded_edid(struct
> radeon_device *rdev)
>
> raw = rdev->bios + edid_info;
> size = EDID_LENGTH * (raw[0x7e] + 1);
> - edid = kmalloc(size, GFP_KERNEL);
> - if (edid == NULL)
> - return false;
> -
> - memcpy((unsigned char *)edid, raw, size);
> + edid = drm_edid_alloc(raw, size);
>
> - if (!drm_edid_is_valid(edid)) {
> - kfree(edid);
> + if (!drm_edid_valid(edid)) {
> + drm_edid_free(edid);
> return false;
> }
>
> rdev->mode_info.bios_hardcoded_edid = edid;
> - rdev->mode_info.bios_hardcoded_edid_size = size;
>
Re: [PATCH] drm/sched: add optional errno to drm_sched_start()
On Fri, Jul 26, 2024 at 09:55:50AM +0200, Christian König wrote:
> The current implementation of drm_sched_start uses a hardcoded
> -ECANCELED to dispose of a job when the parent/hw fence is NULL.
> This results in drm_sched_job_done being called with -ECANCELED for
> each job with a NULL parent in the pending list, making it difficult
> to distinguish between recovery methods, whether a queue reset or a
> full GPU reset was used.
>
> To improve this, we first try a soft recovery for timeout jobs and
> use the error code -ENODATA. If soft recovery fails, we proceed with
> a queue reset, where the error code remains -ENODATA for the job.
> Finally, for a full GPU reset, we use error codes -ECANCELED or
> -ETIME. This patch adds an error code parameter to drm_sched_start,
> allowing us to differentiate between queue reset and GPU reset
> failures. This enables user mode and test applications to validate
> the expected correctness of the requested operation. After a
> successful queue reset, the only way to continue normal operation is
> to call drm_sched_job_done with the specific error code -ENODATA.
>
> v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain
> and amdgpu_device_unlock_reset_domain to allow user mode to track
> the queue reset status and distinguish between queue reset and
> GPU reset.
> v2: Christian suggested using the error codes -ENODATA for queue reset
> and -ECANCELED or -ETIME for GPU reset, returned to
> amdgpu_cs_wait_ioctl.
> v3: To meet the requirements, we introduce a new function
> drm_sched_start_ex with an additional parameter to set
> dma_fence_set_error, allowing us to handle the specific error
> codes appropriately and dispose of bad jobs with the selected
> error code depending on whether it was a queue reset or GPU reset.
> v4: Alex suggested using a new name, drm_sched_start_with_recovery_error,
> which more accurately describes the function's purpose.
> Additionally, it was recommended to add documentation details
> about the new method.
> v5: Fixed declaration of new function
> drm_sched_start_with_recovery_error.(Alex)
> v6 (chk): rebase on upstream changes, cleanup the commit message,
> drop the new function again and update all callers,
> apply the errno also to scheduler fences with hw fences
>
> Signed-off-by: Jesse Zhang
> Signed-off-by: Vitaly Prosyak
> Signed-off-by: Christian König
> Cc: Alex Deucher
Maybe I'm extremely missing the point, but it's kind hard to be sure
without the testcase/mesa side code too, but for gl robustness I don't
think this is enough, because you also need to know whether it was your
context or someone else that caused the gpu reset. Probably biased, but I
think the per-ctx guilty/reset counters is more then right code here. Or
something along those lines.
If we really want to stuff this into per-job fences then I think we should
at least try to document this mess in the sync_file uapi, for a bit of
consistency.
But yeah without the full picture no idea really what we want here.
-Sima
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 4 ++--
> drivers/gpu/drm/imagination/pvr_queue.c | 4 ++--
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_sched.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 7 ---
> drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
> include/drm/gpu_scheduler.h | 2 +-
> 11 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> index 2320df51c914..18135d8235f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> @@ -300,7 +300,7 @@ static int suspend_resume_compute_scheduler(struct
> amdgpu_device *adev, bool sus
> if (r)
> goto out;
> } else {
> - drm_sched_start(>sched);
> + drm_sched_start(>sched, 0);
> }
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c186fdb198ad..861827deb03f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device
Re: [PATCH 2/2] drm/amd/display: use drm_crtc_vblank_on_config()
On Thu, Jul 25, 2024 at 04:51:09PM -0400, Hamza Mahfooz wrote:
> Hook up drm_crtc_vblank_on_config() in amdgpu_dm. So, that we can enable
> PSR and other static screen optimizations more quickly, while avoiding
> stuttering issues that are accompanied by the following dmesg error:
>
> [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle:
> status=3
>
> This also allows us to mimic how vblanking is handled by the windows
> amdgpu driver.
>
> Signed-off-by: Hamza Mahfooz
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 49 +--
> 1 file changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 07e373deb814..780e31a2d456 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7952,7 +7952,7 @@ static int amdgpu_dm_encoder_init(struct drm_device
> *dev,
>
> static void manage_dm_interrupts(struct amdgpu_device *adev,
>struct amdgpu_crtc *acrtc,
> - bool enable)
> + struct dm_crtc_state *acrtc_state)
> {
> /*
>* We have no guarantee that the frontend index maps to the same
> @@ -7964,9 +7964,47 @@ static void manage_dm_interrupts(struct amdgpu_device
> *adev,
> amdgpu_display_crtc_idx_to_irq_type(
> adev,
> acrtc->crtc_id);
> + struct dc_crtc_timing *timing;
> + int vsync_rate_hz;
> + int offdelay = 30;
> +
> + if (acrtc_state) {
> + timing = _state->stream->timing;
> +
> + vsync_rate_hz = div64_u64(div64_u64((timing->pix_clk_100hz *
> + (uint64_t)100),
> + timing->v_total),
> + timing->h_total);
> +
> + if (amdgpu_ip_version(adev, DCE_HWIP, 0) >=
> + IP_VERSION(3, 5, 0) && (adev->flags & AMD_IS_APU)) {
> + if (vsync_rate_hz)
> + /* at least 2 frames */
> + offdelay = 2000 / vsync_rate_hz + 1;
> +
> + if (acrtc_state->stream->link->psr_settings.psr_version
> <
> + DC_PSR_VERSION_UNSUPPORTED) {
> + const struct drm_vblank_crtc_config config = {
> + .offdelay_ms = offdelay,
> + .disable_immediate = false
> + };
> +
> + drm_crtc_vblank_on_config(>base,
> + );
> + } else {
> + const struct drm_vblank_crtc_config config = {
> + .offdelay_ms = 0,
> + .disable_immediate = true
Uh, I think it'd be better to use drm_crtc_vblank_on() here and then have
a 2nd patch which re-enables the immediate vblank disabling and references
the right revert for context.
Plus this feels like a demidlayer hack, but I don't understand enough DC
code to know a better place ...
-Sima
> + };
> +
> + drm_crtc_vblank_on_config(>base,
> + );
> + }
> +
> + } else {
> + drm_crtc_vblank_on(>base);
> + }
>
> - if (enable) {
> - drm_crtc_vblank_on(>base);
> amdgpu_irq_get(
> adev,
> >pageflip_irq,
> @@ -8947,7 +8985,7 @@ static void amdgpu_dm_commit_streams(struct
> drm_atomic_state *state,
> if (old_crtc_state->active &&
> (!new_crtc_state->active ||
>drm_atomic_crtc_needs_modeset(new_crtc_state))) {
> - manage_dm_interrupts(adev, acrtc, false);
> + manage_dm_interrupts(adev, acrtc, NULL);
> dc_stream_release(dm_old_crtc_state->stream);
> }
> }
> @@ -9465,7 +9503,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
> drm_atomic_state *state)
>drm_atomic_crtc_needs_modeset(new_crtc_state))) {
> dc_stream_retain(dm_new_crtc_state->stream);
> acrtc->dm_irq_params.stream = dm_new_crtc_state->
Re: [PATCH 1/2] drm/vblank: add dynamic per-crtc vblank configuration support
On Thu, Jul 25, 2024 at 04:51:08PM -0400, Hamza Mahfooz wrote:
> We would like to be able to enable vblank_disable_immediate
> unconditionally, however there are a handful of cases where a small off
> delay is necessary (e.g. with PSR enabled). So, we would like to be able
> to adjust the vblank off delay and disable imminent values dynamically
> for a given CRTC. Since, it will allow drivers to apply static screen
> optimizations more quickly and consequently allow users to benefit more
> so from the power savings afforded by the aforementioned optimizations,
> while avoiding issues in cases where an off delay is still warranted.
> In particular, the PSR case requires a small off delay of 2 frames,
> otherwise display firmware isn't able to keep up with all of the
> requests made to amdgpu. So, introduce drm_crtc_vblank_on_config() which
> is like drm_crtc_vblank_on(), but it allows drivers to specify the
> vblank CRTC configuration before enabling vblanking support for a given
> CRTC.
>
> Signed-off-by: Hamza Mahfooz
Yeah looks reasonable, bunch of details below. With those addressed:
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_vblank.c | 57 ++--
> include/drm/drm_vblank.h | 25
> 2 files changed, 66 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index cc3571e25a9a..c9de7d18389a 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
The intro kerneldoc at the top of this needs to be updated. Might be good
to grep for vblank_disable_immediate to make sure you haven't missed any
reference.
> @@ -1241,6 +1241,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_get);
> void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
> + int vblank_offdelay = vblank->config.offdelay_ms;
>
> if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
> return;
> @@ -1250,13 +1251,13 @@ void drm_vblank_put(struct drm_device *dev, unsigned
> int pipe)
>
> /* Last user schedules interrupt disable */
> if (atomic_dec_and_test(>refcount)) {
> - if (drm_vblank_offdelay == 0)
> + if (!vblank_offdelay)
> return;
> - else if (drm_vblank_offdelay < 0)
> + else if (vblank_offdelay < 0)
> vblank_disable_fn(>disable_timer);
> - else if (!dev->vblank_disable_immediate)
> + else if (!vblank->config.disable_immediate)
> mod_timer(>disable_timer,
> - jiffies + ((drm_vblank_offdelay * HZ)/1000));
> + jiffies + ((vblank_offdelay * HZ) / 1000));
> }
> }
The kerneldoc for drm_crtc_vblank_put also needs updating to point at
drm_vblank_config.offdelay_ms.
>
> @@ -1466,16 +1467,16 @@ void drm_crtc_set_max_vblank_count(struct drm_crtc
> *crtc,
> EXPORT_SYMBOL(drm_crtc_set_max_vblank_count);
>
> /**
> - * drm_crtc_vblank_on - enable vblank events on a CRTC
> + * drm_crtc_vblank_on_config - enable vblank events on a CRTC with custom
> + * configuration options
> * @crtc: CRTC in question
> + * @config: Vblank configuration value
> *
> - * This functions restores the vblank interrupt state captured with
> - * drm_crtc_vblank_off() again and is generally called when enabling @crtc.
> Note
> - * that calls to drm_crtc_vblank_on() and drm_crtc_vblank_off() can be
> - * unbalanced and so can also be unconditionally called in driver load code
> to
> - * reflect the current hardware state of the crtc.
> + * See drm_crtc_vblank_on(). In addition, this function allows you to
> provide a
> + * custom vblank configuration for a given CRTC.
I'd add
"Note that @config is copied, the pointer does not need to stay
valid beyond this function call. For details of the parameters see struct
drm_vblank_crtc_config."
to make the kerneldoc more meaningful.
> */
> -void drm_crtc_vblank_on(struct drm_crtc *crtc)
> +void drm_crtc_vblank_on_config(struct drm_crtc *crtc,
> +const struct drm_vblank_crtc_config *config)
> {
> struct drm_device *dev = crtc->dev;
> unsigned int pipe = drm_crtc_index(crtc);
> @@ -1488,6 +1489,8 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
> drm_dbg_vbl(dev, "crtc %d, vblank enabled %d, inmodeset %d\n",
> pipe, vblank->enabled, vblank->inmodeset);
>
> + vblank->config = *config;
> +
> /* Drop our private "prevent drm_vblank_get" refcount */
> if (vblank->inmodeset) {
> atomic_dec(>refcount);
> @@ -1500,10 +1503,31 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
>* re-enable interrupts if there are users left, or the
>* user wishes vblank interrupts to be enabled all the time.
>*/
> - if (atomic_read(>refcount) != 0 || drm_vblank_offdelay ==
Re: [PATCH -next] drm/amd/display: Use ARRAY_SIZE for array length
Applied. Thanks!
On Fri, Jul 26, 2024 at 5:55 AM Jiapeng Chong
wrote:
>
> Use of macro ARRAY_SIZE to calculate array size minimizes
> the redundant code and improves code reusability.
>
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1552:57-58:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1561:57-58:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1573:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1578:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1592:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1597:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1611:50-51:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1616:50-51:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1630:50-51:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1635:50-51:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1649:60-61:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1663:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1677:52-53:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1691:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1705:53-54:
> WARNING: Use ARRAY_SIZE.
> ./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1719:54-55:
> WARNING: Use ARRAY_SIZE.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9580
> Signed-off-by: Jiapeng Chong
> ---
> .../display/dc/spl/dc_spl_scl_easf_filters.c | 63 ++-
> 1 file changed, 20 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
> b/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
> index 09bf82f7d468..e847af94419a 100644
> --- a/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
> +++ b/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
> @@ -1530,14 +1530,13 @@ static uint32_t
> spl_easf_get_scale_ratio_to_reg_value(struct spl_fixed31_32 rati
> value = lookup_table_index_ptr->reg_value;
>
> while (count < num_entries) {
> -
> lookup_table_index_ptr = (lookup_table_base_ptr + count);
> if (lookup_table_index_ptr->numer < 0)
> break;
>
> if (ratio.value < spl_fixpt_from_fraction(
> - lookup_table_index_ptr->numer,
> - lookup_table_index_ptr->denom).value) {
> + lookup_table_index_ptr->numer,
> + lookup_table_index_ptr->denom).value) {
> value = lookup_table_index_ptr->reg_value;
> break;
> }
> @@ -1548,21 +1547,13 @@ static uint32_t
> spl_easf_get_scale_ratio_to_reg_value(struct spl_fixed31_32 rati
> }
> uint32_t spl_get_v_bf3_mode(struct spl_fixed31_32 ratio)
> {
> - uint32_t value;
> - unsigned int num_entries = sizeof(easf_v_bf3_mode_lookup) /
> - sizeof(struct scale_ratio_to_reg_value_lookup);
> - value = spl_easf_get_scale_ratio_to_reg_value(ratio,
> - easf_v_bf3_mode_lookup, num_entries);
> - return value;
> + unsigned int num_entries = ARRAY_SIZE(easf_v_bf3_mode_lookup);
> + return spl_easf_get_scale_ratio_to_reg_value(ratio,
> easf_v_bf3_mode_lookup, num_entries);
> }
> uint32_t spl_get_h_bf3_mode(struct spl_fixed31_32 ratio)
> {
> - uint32_t value;
> - unsigned int num_entries = sizeof(easf_h_bf3_mode_lookup) /
> - sizeof(struct scale_ratio_to_reg_value_lookup);
> - value = spl_easf_get_scale_ratio_to_reg_value(ratio,
> - easf_h_bf3_mode_lookup, num_entries);
> - return value;
> + unsigned int num_entries = ARRAY_SIZE(easf_h_bf3_mode_lookup);
> + return spl_easf_get_scale_ratio_to_reg_value(ratio,
> easf_h_bf3_mode_lookup, num_entries);
> }
> uint32_t spl_get_reducer_gain6(int taps, struct spl_fixed31_32 ratio)
> {
> @@ -1570,13 +1561,11 @@ uint32_t spl_get_reducer_gain6(int taps, struct
> spl_fixed31_32 ratio)
> unsigned int num_entries;
>
> if (taps == 4) {
> - num_entries = sizeof(easf_reducer_gain6_4tap_lookup) /
> - sizeof(struct scale_ratio_to_reg_value_lookup);
> + num_entries = ARRAY_SIZE(easf_reducer_gain6_4tap_lookup);
> value =
Re: [PATCH v7 1/2] drm/buddy: Add start address support to trim function
On 7/24/2024 8:42 PM, Jani Nikula wrote:
On Tue, 23 Jul 2024, Arunpravin Paneer Selvam
wrote:
- Add a new start parameter in trim function to specify exact
address from where to start the trimming. This would help us
in situations like if drivers would like to do address alignment
for specific requirements.
- Add a new flag DRM_BUDDY_TRIM_DISABLE. Drivers can use this
flag to disable the allocator trimming part. This patch enables
the drivers control trimming and they can do it themselves
based on the application requirements.
v1:(Matthew)
- check new_start alignment with min chunk_size
- use range_overflows()
Signed-off-by: Arunpravin Paneer Selvam
Acked-by: Alex Deucher
Acked-by: Christian König
---
drivers/gpu/drm/drm_buddy.c | 25 +++--
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 2 +-
include/drm/drm_buddy.h | 2 ++
3 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 6a8e45e9d0ec..103c185bb1c8 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -851,6 +851,7 @@ static int __alloc_contig_try_harder(struct drm_buddy *mm,
* drm_buddy_block_trim - free unused pages
*
* @mm: DRM buddy manager
+ * @start: start address to begin the trimming.
* @new_size: original size requested
* @blocks: Input and output list of allocated blocks.
* MUST contain single block as input to be trimmed.
@@ -866,11 +867,13 @@ static int __alloc_contig_try_harder(struct drm_buddy *mm,
* 0 on success, error code on failure.
*/
int drm_buddy_block_trim(struct drm_buddy *mm,
+u64 *start,
Is this a pointer only to allow passing NULL as "don't specify"? It's
not used for returning anything in *start. Maybe it should be a const
pointer?
Not the prettiest of interfaces, and the kernel-doc does not reflect any
of this.
We have a plan to improve the interface and add multiple block trim
support as well.
I will modify in the follow-up patch.
Thanks,
Arun.
BR,
Jani.
u64 new_size,
struct list_head *blocks)
{
struct drm_buddy_block *parent;
struct drm_buddy_block *block;
+ u64 block_start, block_end;
LIST_HEAD(dfs);
u64 new_start;
int err;
@@ -882,6 +885,9 @@ int drm_buddy_block_trim(struct drm_buddy *mm,
struct drm_buddy_block,
link);
+ block_start = drm_buddy_block_offset(block);
+ block_end = block_start + drm_buddy_block_size(mm, block);
+
if (WARN_ON(!drm_buddy_block_is_allocated(block)))
return -EINVAL;
@@ -894,6 +900,20 @@ int drm_buddy_block_trim(struct drm_buddy *mm,
if (new_size == drm_buddy_block_size(mm, block))
return 0;
+ new_start = block_start;
+ if (start) {
+ new_start = *start;
+
+ if (new_start < block_start)
+ return -EINVAL;
+
+ if (!IS_ALIGNED(new_start, mm->chunk_size))
+ return -EINVAL;
+
+ if (range_overflows(new_start, new_size, block_end))
+ return -EINVAL;
+ }
+
list_del(>link);
mark_free(mm, block);
mm->avail += drm_buddy_block_size(mm, block);
@@ -904,7 +924,6 @@ int drm_buddy_block_trim(struct drm_buddy *mm,
parent = block->parent;
block->parent = NULL;
- new_start = drm_buddy_block_offset(block);
list_add(>tmp_link, );
err = __alloc_range(mm, , new_start, new_size, blocks, NULL);
if (err) {
@@ -1066,7 +1085,8 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
} while (1);
/* Trim the allocated block to the required size */
- if (original_size != size) {
+ if (!(flags & DRM_BUDDY_TRIM_DISABLE) &&
+ original_size != size) {
struct list_head *trim_list;
LIST_HEAD(temp);
u64 trim_size;
@@ -1083,6 +1103,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
}
drm_buddy_block_trim(mm,
+NULL,
trim_size,
trim_list);
diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
index fe3779fdba2c..423b261ea743 100644
--- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
+++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
@@ -150,7 +150,7 @@ static int xe_ttm_vram_mgr_new(struct ttm_resource_manager
*man,
} while (remaining_size);
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
- if (!drm_buddy_block_trim(mm, vres->base.size, >blocks))
+ if (!drm_buddy_block_trim(mm, NULL, vres->base.size,
>blocks))
[PATCH v2 0/2] drm/{amdgpu,radeon}: convert bios_hardcoded_edid to drm_edid
Instead of manually passing around 'struct edid *' and its size, use 'struct drm_edid', which encapsulates a validated combination of both. While this series introduces new users for drm_edid_raw(), these can be removed when the drivers get converted to 'struct drm_edid' completely for which this series provides the foundation. Only compile-tested. Signed-off-by: Thomas Weißschuh --- Changes in v2: - Rebase onto current amdgpu/drm-next and recent changes to hardcoded bios handling - Add patch for drm/radeon - Link to v1: https://lore.kernel.org/r/20240616-amdgpu-edid-bios-v1-1-2874f212b...@weissschuh.net --- Thomas Weißschuh (2): drm/amdgpu: convert bios_hardcoded_edid to drm_edid drm/radeon: convert bios_hardcoded_edid to drm_edid drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 2 +- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 17 ++--- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- drivers/gpu/drm/radeon/radeon_atombios.c | 17 ++--- drivers/gpu/drm/radeon/radeon_combios.c| 26 +- drivers/gpu/drm/radeon/radeon_connectors.c | 4 ++-- drivers/gpu/drm/radeon/radeon_display.c| 2 +- drivers/gpu/drm/radeon/radeon_mode.h | 4 ++-- 13 files changed, 30 insertions(+), 60 deletions(-) --- base-commit: 644e49d582fd53d4d218d27e404043f56f2c286f change-id: 20240616-amdgpu-edid-bios-a31aa16b0321 Best regards, -- Thomas Weißschuh
[PATCH v2 1/2] drm/amdgpu: convert bios_hardcoded_edid to drm_edid
Instead of manually passing around 'struct edid *' and its size,
use 'struct drm_edid', which encapsulates a validated combination of
both.
As the drm_edid_ can handle NULL gracefully, the explicit checks can be
dropped.
Also save a few characters by transforming '[0]' to the equivalent
'array' and using 'max_t(int, ...)' instead of manual casts.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 2 +-
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 17 ++---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
8 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index bd0fbdc5f55d..344e0a9ee08a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -249,11 +249,7 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
static struct edid *
amdgpu_connector_get_hardcoded_edid(struct amdgpu_device *adev)
{
- if (adev->mode_info.bios_hardcoded_edid) {
- return kmemdup((unsigned char
*)adev->mode_info.bios_hardcoded_edid,
- adev->mode_info.bios_hardcoded_edid_size,
GFP_KERNEL);
- }
- return NULL;
+ return
drm_edid_duplicate(drm_edid_raw(adev->mode_info.bios_hardcoded_edid));
}
static void amdgpu_connector_get_edid(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index d002b845d8ac..5e3faefc5510 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -51,6 +51,7 @@ struct amdgpu_encoder;
struct amdgpu_router;
struct amdgpu_hpd;
struct edid;
+struct drm_edid;
#define to_amdgpu_crtc(x) container_of(x, struct amdgpu_crtc, base)
#define to_amdgpu_connector(x) container_of(x, struct amdgpu_connector, base)
@@ -326,8 +327,7 @@ struct amdgpu_mode_info {
/* FMT dithering */
struct drm_property *dither_property;
/* hardcoded DFP edid from BIOS */
- struct edid *bios_hardcoded_edid;
- int bios_hardcoded_edid_size;
+ const struct drm_edid *bios_hardcoded_edid;
/* firmware flags */
u32 firmware_flags;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index 6415d0d039e1..e5f508d34ed8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -549,7 +549,7 @@ static int amdgpu_vkms_sw_fini(void *handle)
adev->mode_info.mode_config_initialized = false;
- kfree(adev->mode_info.bios_hardcoded_edid);
+ drm_edid_free(adev->mode_info.bios_hardcoded_edid);
kfree(adev->amdgpu_vkms_output);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index ebf83fee43bb..8defca3705d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -2064,23 +2064,18 @@ amdgpu_atombios_encoder_get_lcd_info(struct
amdgpu_encoder *encoder)
case LCD_FAKE_EDID_PATCH_RECORD_TYPE:
fake_edid_record =
(ATOM_FAKE_EDID_PATCH_RECORD *)record;
if (fake_edid_record->ucFakeEDIDLength)
{
- struct edid *edid;
+ const struct drm_edid *edid;
int edid_size;
if
(fake_edid_record->ucFakeEDIDLength == 128)
edid_size =
fake_edid_record->ucFakeEDIDLength;
else
edid_size =
fake_edid_record->ucFakeEDIDLength * 128;
- edid =
kmemdup(_edid_record->ucFakeEDIDString[0],
- edid_size,
GFP_KERNEL);
- if (edid) {
- if
(drm_edid_is_valid(edid)) {
-
adev->mode_info.bios_hardcoded_edid = edid;
-
adev->mode_info.bios_hardcoded_edid_size = edid_size;
- } else {
-
[PATCH v2 2/2] drm/radeon: convert bios_hardcoded_edid to drm_edid
Instead of manually passing around 'struct edid *' and its size,
use 'struct drm_edid', which encapsulates a validated combination of
both.
As the drm_edid_ can handle NULL gracefully, the explicit checks can be
dropped.
Also save a few characters by transforming '[0]' to the equivalent
'array' and using 'max_t(int, ...)' instead of manual casts.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/radeon/radeon_atombios.c | 17 ++---
drivers/gpu/drm/radeon/radeon_combios.c| 26 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 4 ++--
drivers/gpu/drm/radeon/radeon_display.c| 2 +-
drivers/gpu/drm/radeon/radeon_mode.h | 4 ++--
5 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 168f3f94003b..81a0a91921b9 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1716,23 +1716,18 @@ struct radeon_encoder_atom_dig
*radeon_atombios_get_lvds_info(struct
case LCD_FAKE_EDID_PATCH_RECORD_TYPE:
fake_edid_record =
(ATOM_FAKE_EDID_PATCH_RECORD *)record;
if (fake_edid_record->ucFakeEDIDLength)
{
- struct edid *edid;
+ const struct drm_edid *edid;
int edid_size;
if
(fake_edid_record->ucFakeEDIDLength == 128)
edid_size =
fake_edid_record->ucFakeEDIDLength;
else
edid_size =
fake_edid_record->ucFakeEDIDLength * 128;
- edid =
kmemdup(_edid_record->ucFakeEDIDString[0],
- edid_size,
GFP_KERNEL);
- if (edid) {
- if
(drm_edid_is_valid(edid)) {
-
rdev->mode_info.bios_hardcoded_edid = edid;
-
rdev->mode_info.bios_hardcoded_edid_size = edid_size;
- } else {
- kfree(edid);
- }
- }
+ edid =
drm_edid_alloc(fake_edid_record->ucFakeEDIDString, edid_size);
+ if (drm_edid_valid(edid))
+
rdev->mode_info.bios_hardcoded_edid = edid;
+ else
+ drm_edid_free(edid);
record +=
struct_size(fake_edid_record,
ucFakeEDIDString,
edid_size);
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 41ddc576f8f8..df8d7f56b028 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -370,7 +370,7 @@ static uint16_t combios_get_table_offset(struct drm_device
*dev,
bool radeon_combios_check_hardcoded_edid(struct radeon_device *rdev)
{
int edid_info, size;
- struct edid *edid;
+ const struct drm_edid *edid;
unsigned char *raw;
edid_info = combios_get_table_offset(rdev_to_drm(rdev),
COMBIOS_HARDCODED_EDID_TABLE);
if (!edid_info)
@@ -378,19 +378,14 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
raw = rdev->bios + edid_info;
size = EDID_LENGTH * (raw[0x7e] + 1);
- edid = kmalloc(size, GFP_KERNEL);
- if (edid == NULL)
- return false;
-
- memcpy((unsigned char *)edid, raw, size);
+ edid = drm_edid_alloc(raw, size);
- if (!drm_edid_is_valid(edid)) {
- kfree(edid);
+ if (!drm_edid_valid(edid)) {
+ drm_edid_free(edid);
return false;
}
rdev->mode_info.bios_hardcoded_edid = edid;
- rdev->mode_info.bios_hardcoded_edid_size = size;
return true;
}
@@ -398,18 +393,7 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
struct edid *
radeon_bios_get_hardcoded_edid(struct radeon_device *rdev)
{
- struct edid *edid;
-
- if (rdev->mode_info.bios_hardcoded_edid) {
- edid =
Re: [RFC PATCH] drm: panthor: add dev_coredumpv support
On Thu, Jul 25, 2024 at 03:35:18PM -0400, Lyude Paul wrote:
> On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> > On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> > > Hi Sima!
> > >
> > >
> > > >
> > > > Yeah I'm not sure a partially converted driver where the main driver is
> > > > still C really works, that pretty much has to throw out all the type
> > > > safety in the interfaces.
> > > >
> > > > What I think might work is if such partial drivers register as full rust
> > > > drivers, and then largely delegate the implementation to their existing
> > > > C
> > > > code with a big "safety: trust me, the C side is bug free" comment since
> > > > it's all going to be unsafe :-)
> > > >
> > > > It would still be a big change, since all the driver's callbacks need to
> > > > switch from container_of to upcast to their driver structure to some
> > > > small
> > > > rust shim (most likely, I didn't try this out) to get at the driver
> > > > parts
> > > > on the C side. And I think you also need a small function to downcast to
> > > > the drm base class. But that should be all largely mechanical.
> > > >
> > > > More freely allowing to mix is imo going to be endless pains. We
> > > > kinda tried that with the atomic conversion helpers for legacy kms
> > > > drivers, and the impendance mismatch was just endless amounts of very
> > > > subtle pain. Rust will exacerbate this, because it encodes semantics
> > > > into
> > > > the types and interfaces. And that was with just one set of helpers, for
> > > > rust we'll likely need a custom one for each driver that's partially
> > > > written in rust.
> > > > -Sima
> > > >
> > >
> > > I humbly disagree here.
> > >
> > > I know this is a bit tangential, but earlier this year I converted a
> > > bunch of codec libraries to Rust in v4l2. That worked just fine with the
> > > C codec drivers. There were no regressions as per our test tools.
> > >
> > > The main idea is that you isolate all unsafety to a single point: so
> > > long as the C code upholds the safety guarantees when calling into Rust,
> > > the Rust layer will be safe. This is just the same logic used in unsafe
> > > blocks in Rust itself, nothing new really.
> > >
> > > This is not unlike what is going on here, for example:
> > >
> > >
> > > ```
> > > +unsafe extern "C" fn open_callback, U:
> > > BaseObject>(
> > > + raw_obj: *mut bindings::drm_gem_object,
> > > + raw_file: *mut bindings::drm_file,
> > > +) -> core::ffi::c_int {
> > > + // SAFETY: The pointer we got has to be valid.
> > > + let file = unsafe {
> > > + file::File::<<::Driver as
> > > drv::Driver>::File>::from_raw(raw_file)
> > > + };
> > > + let obj =
> > > + <<::Driver as drv::Driver>::Object as
> > > IntoGEMObject>::from_gem_obj(
> > > + raw_obj,
> > > + );
> > > +
> > > + // SAFETY: from_gem_obj() returns a valid pointer as long as the type is
> > > + // correct and the raw_obj we got is valid.
> > > + match T::open(unsafe { &*obj }, ) {
> > > + Err(e) => e.to_errno(),
> > > + Ok(()) => 0,
> > > + }
> > > +}
> > > ```
> > >
> > > We have to trust that the kernel is passing in a valid pointer. By the
> > > same token, we can choose to trust drivers if we so desire.
> > >
> > > > that pretty much has to throw out all the type
> > > > safety in the interfaces.
> > >
> > > Can you expand on that?
> >
> > Essentially what you've run into, in a pure rust driver we assume that
> > everything is living in the rust world. In a partial conversion you might
> > want to freely convert GEMObject back, but everything else
> > (drm_file, drm_device, ...) is still living in the pure C world. I think
> > there's roughly three solutions to this:
> >
> > - we allow this on the rust side, but that means the associated
> > types/generics go away. We drop a lot of enforced type safety for pure
> > rust drivers.
> >
> > - we don't allow this. Your mixed driver is screwed.
> >
> > - we allow this for specific functions, with a pinky finger promise that
> > those rust functions will not look at any of the associated types. From
> > my experience these kind of in-between worlds functions are really
> > brittle and a pain, e.g. rust-native driver people might accidentally
> > change the code to again assume a drv::Driver exists, or people don't
> > want to touch the code because it's too risky, or we're forced to
> > implement stuff in C instead of rust more than necessary.
> >
> > > In particular, I believe that we should ideally be able to convert from
> > > a C "struct Foo * " to a Rust “FooRef" for types whose lifetimes are
> > > managed either by the kernel itself or by a C driver. In practical
> > > terms, this has run into the issues we’ve been discussing in this
> > > thread, but there may be solutions e.g.:
> > >
> > > > One thing that comes to my mindis , you could probably create some
> > > > driver specific
> > > > "dummy" types to satisfy the type generics of the types you want to
Re: [PATCH 2/3] MAINTAINERS: Update Konrad Dybcio's email address
On 26/07/2024 13:18, Konrad Dybcio wrote: Use my @kernel.org address everywhere. Signed-off-by: Konrad Dybcio --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9200d953868e..6c7d3951192f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2745,7 +2745,7 @@ F:include/linux/soc/qcom/ ARM/QUALCOMM SUPPORT M:Bjorn Andersson -M: Konrad Dybcio +M: Konrad Dybcio L:linux-arm-...@vger.kernel.org S:Maintained T:git git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git @@ -7107,7 +7107,7 @@ F:drivers/gpu/drm/tiny/panel-mipi-dbi.c DRM DRIVER for Qualcomm Adreno GPUs M:Rob Clark R:Sean Paul -R: Konrad Dybcio +R: Konrad Dybcio L:linux-arm-...@vger.kernel.org L:dri-devel@lists.freedesktop.org L:freedr...@lists.freedesktop.org @@ -18765,7 +18765,7 @@ F: include/uapi/drm/qaic_accel.h QUALCOMM CORE POWER REDUCTION (CPR) AVS DRIVER M:Bjorn Andersson -M: Konrad Dybcio +M: Konrad Dybcio L:linux...@vger.kernel.org L:linux-arm-...@vger.kernel.org S:Maintained Acked-by: Neil Armstrong
Re: [PATCH 1/3] mailmap: Add an entry for Konrad Dybcio
On 26/07/2024 13:18, Konrad Dybcio wrote: Map my old addresses. Signed-off-by: Konrad Dybcio --- .mailmap | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.mailmap b/.mailmap index e51d76df75c2..d189c6424697 100644 --- a/.mailmap +++ b/.mailmap @@ -353,6 +353,8 @@ Kenneth Westfield Kiran Gunda Kirill Tkhai Kishon Vijay Abraham I +Konrad Dybcio +Konrad Dybcio Konstantin Khlebnikov Konstantin Khlebnikov Koushik Acked-by: Neil Armstrong
Re: [PATCH] drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
On Fri, Jul 26, 2024 at 3:05 AM Christian König
wrote:
>
> Am 25.07.24 um 20:09 schrieb Nikita Zhandarovich:
> > Several cs track offsets (such as 'track->db_s_read_offset')
> > either are initialized with or plainly take big enough values that,
> > once shifted 8 bits left, may be hit with integer overflow if the
> > resulting values end up going over u32 limit.
> >
> > Some debug prints take this into account (see according dev_warn() in
> > evergreen_cs_track_validate_stencil()), even if the actual
> > calculated value assigned to local 'offset' variable is missing
> > similar proper expansion.
> >
> > Mitigate the problem by casting the type of right operands to the
> > wider type of corresponding left ones in all such cases.
> >
> > Found by Linux Verification Center (linuxtesting.org) with static
> > analysis tool SVACE.
> >
> > Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling
> > informations v11")
> > Cc: sta...@vger.kernel.org
>
> Well first of all the long cast doesn't makes the value 64bit, it
> depends on the architecture.
>
> Then IIRC the underlying hw can only handle a 32bit address space so
> having the offset as long is incorrect to begin with.
Evergreen chips support a 36 bit internal address space and NI and
newer support a 40 bit one, so this is applicable.
Alex
>
> And finally that is absolutely not material for stable.
>
> Regards,
> Christian.
>
> > Signed-off-by: Nikita Zhandarovich
> > ---
> > P.S. While I am not certain that track->cb_color_bo_offset[id]
> > actually ends up taking values high enough to cause an overflow,
> > nonetheless I thought it prudent to cast it to ulong as well.
> >
> > drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> > b/drivers/gpu/drm/radeon/evergreen_cs.c
> > index 1fe6e0d883c7..d734d221e2da 100644
> > --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> > +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> > @@ -433,7 +433,7 @@ static int evergreen_cs_track_validate_cb(struct
> > radeon_cs_parser *p, unsigned i
> > return r;
> > }
> >
> > - offset = track->cb_color_bo_offset[id] << 8;
> > + offset = (unsigned long)track->cb_color_bo_offset[id] << 8;
> > if (offset & (surf.base_align - 1)) {
> > dev_warn(p->dev, "%s:%d cb[%d] bo base %ld not aligned with
> > %ld\n",
> >__func__, __LINE__, id, offset, surf.base_align);
> > @@ -455,7 +455,7 @@ static int evergreen_cs_track_validate_cb(struct
> > radeon_cs_parser *p, unsigned i
> > min = surf.nby - 8;
> > }
> > bsize = radeon_bo_size(track->cb_color_bo[id]);
> > - tmp = track->cb_color_bo_offset[id] << 8;
> > + tmp = (unsigned long)track->cb_color_bo_offset[id] <<
> > 8;
> > for (nby = surf.nby; nby > min; nby--) {
> > size = nby * surf.nbx * surf.bpe *
> > surf.nsamples;
> > if ((tmp + size * mslice) <= bsize) {
> > @@ -476,10 +476,10 @@ static int evergreen_cs_track_validate_cb(struct
> > radeon_cs_parser *p, unsigned i
> > }
> > }
> > dev_warn(p->dev, "%s:%d cb[%d] bo too small (layer size %d, "
> > - "offset %d, max layer %d, bo size %ld, slice %d)\n",
> > + "offset %ld, max layer %d, bo size %ld, slice %d)\n",
> >__func__, __LINE__, id, surf.layer_size,
> > - track->cb_color_bo_offset[id] << 8, mslice,
> > - radeon_bo_size(track->cb_color_bo[id]), slice);
> > + (unsigned long)track->cb_color_bo_offset[id] << 8,
> > + mslice, radeon_bo_size(track->cb_color_bo[id]),
> > slice);
> > dev_warn(p->dev, "%s:%d problematic surf: (%d %d) (%d %d %d
> > %d %d %d %d)\n",
> >__func__, __LINE__, surf.nbx, surf.nby,
> > surf.mode, surf.bpe, surf.nsamples,
> > @@ -608,7 +608,7 @@ static int evergreen_cs_track_validate_stencil(struct
> > radeon_cs_parser *p)
> > return r;
> > }
> >
> > - offset = track->db_s_read_offset << 8;
> > + offset = (unsigned long)track->db_s_read_offset << 8;
> > if (offset & (surf.base_align - 1)) {
> > dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned
> > with %ld\n",
> >__func__, __LINE__, offset, surf.base_align);
> > @@ -627,7 +627,7 @@ static int evergreen_cs_track_validate_stencil(struct
> > radeon_cs_parser *p)
> > return -EINVAL;
> > }
> >
> > - offset = track->db_s_write_offset << 8;
> > + offset = (unsigned long)track->db_s_write_offset << 8;
> > if (offset & (surf.base_align - 1)) {
> >
Re: [PATCH] drm/sched: add optional errno to drm_sched_start()
On Fri, Jul 26, 2024 at 09:55:50AM +0200, Christian König wrote:
> The current implementation of drm_sched_start uses a hardcoded
> -ECANCELED to dispose of a job when the parent/hw fence is NULL.
> This results in drm_sched_job_done being called with -ECANCELED for
> each job with a NULL parent in the pending list, making it difficult
> to distinguish between recovery methods, whether a queue reset or a
> full GPU reset was used.
>
> To improve this, we first try a soft recovery for timeout jobs and
> use the error code -ENODATA. If soft recovery fails, we proceed with
> a queue reset, where the error code remains -ENODATA for the job.
> Finally, for a full GPU reset, we use error codes -ECANCELED or
> -ETIME. This patch adds an error code parameter to drm_sched_start,
> allowing us to differentiate between queue reset and GPU reset
> failures. This enables user mode and test applications to validate
> the expected correctness of the requested operation. After a
> successful queue reset, the only way to continue normal operation is
> to call drm_sched_job_done with the specific error code -ENODATA.
>
> v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain
> and amdgpu_device_unlock_reset_domain to allow user mode to track
> the queue reset status and distinguish between queue reset and
> GPU reset.
> v2: Christian suggested using the error codes -ENODATA for queue reset
> and -ECANCELED or -ETIME for GPU reset, returned to
> amdgpu_cs_wait_ioctl.
> v3: To meet the requirements, we introduce a new function
> drm_sched_start_ex with an additional parameter to set
> dma_fence_set_error, allowing us to handle the specific error
> codes appropriately and dispose of bad jobs with the selected
> error code depending on whether it was a queue reset or GPU reset.
> v4: Alex suggested using a new name, drm_sched_start_with_recovery_error,
> which more accurately describes the function's purpose.
> Additionally, it was recommended to add documentation details
> about the new method.
> v5: Fixed declaration of new function
> drm_sched_start_with_recovery_error.(Alex)
> v6 (chk): rebase on upstream changes, cleanup the commit message,
> drop the new function again and update all callers,
> apply the errno also to scheduler fences with hw fences
>
Seems responablie to me, but all the caller pass in an errno of zero to
drm_sched_start. Going to change in a follow up?
Anyways, LGTM but will leave RB for a user a user of this interface.
Acked-by: Matthew Brost
> Signed-off-by: Jesse Zhang
> Signed-off-by: Vitaly Prosyak
> Signed-off-by: Christian König
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 4 ++--
> drivers/gpu/drm/imagination/pvr_queue.c | 4 ++--
> drivers/gpu/drm/lima/lima_sched.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_sched.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 7 ---
> drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
> include/drm/gpu_scheduler.h | 2 +-
> 11 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> index 2320df51c914..18135d8235f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> @@ -300,7 +300,7 @@ static int suspend_resume_compute_scheduler(struct
> amdgpu_device *adev, bool sus
> if (r)
> goto out;
> } else {
> - drm_sched_start(>sched);
> + drm_sched_start(>sched, 0);
> }
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c186fdb198ad..861827deb03f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -5862,7 +5862,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device
> *adev,
> if (!amdgpu_ring_sched_ready(ring))
> continue;
>
> - drm_sched_start(>sched);
> + drm_sched_start(>sched, 0);
> }
>
> if (!drm_drv_uses_atomic_modeset(adev_to_d
Re: [PATCH v3] rockchip/drm: vop2: add support for gamma LUT
Hi Piotr,
On Thu, 25 Jul 2024 at 20:06, Piotr Zalewski wrote:
> I based my patch on how gamma LUT is handled in VOP. There, in atomic
> enable, gamma LUT write takes places at the end too, after the mutex was
> already first-time unlocked. I understand the concept of DRM atomic state
> updates and what you wrote makes sense.
Yeah, no problem - the old VOP1 code is clearly incorrect here. I'm
glad you can improve VOP2. :)
> static void vop2_dither_setup(struct drm_crtc *crtc, u32 *dsp_ctrl)
> @@ -2152,6 +2127,9 @@ static void vop2_crtc_atomic_enable(struct drm_crtc
> *crtc,
>
> vop2_post_config(crtc);
>
> + if (crtc->state->gamma_lut)
> + vop2_crtc_gamma_set(vop2, crtc, old_state, _ctrl);
I think this call should be unconditional, so that we correctly
program LUT_DIS if there is no LUT set up during enable.
> @@ -2599,8 +2575,17 @@ static void vop2_crtc_atomic_begin(struct drm_crtc
> *crtc,
> vop2_setup_alpha(vp);
> vop2_setup_dly_for_windows(vop2);
>
> - if (crtc_state->color_mgmt_changed && !crtc_state->active_changed)
> - vop2_crtc_gamma_set(vop2, crtc, old_crtc_state);
> + if (crtc_state->color_mgmt_changed && !crtc_state->active_changed) {
> + u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);;
> +
> + vop2_lock(vop2);
> +
> + vop2_crtc_gamma_set(vop2, crtc, old_crtc_state, _ctrl);
> +
> + vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
> + vop2_cfg_done(vp);
> + vop2_unlock(vop2);
> + }
Calling lock/set/write/done/unlock here seems like an anti-pattern;
the cfg_done is already written in atomic_flush, so at least that part
is not necessary.
On platforms like RK3588, it looks like the new LUT can just be
written directly from atomic_begin without needing to program
DSP_CTRL, take locks, or synchronise against anything, so that should
be an easy straight-line path.
On platforms like RK3568, it would probably be better to set
mode_changed when the colour management configuration changes. That
will give you a good point to synchronise the cross-VOP dependencies
(i.e. claim or release the shared LUT when it is being
enabled/disabled), and also a hint to userspace that it is not going
to be a seamless transition as the LUT is disabled, programmed, then
re-enabled.
I think this would end up in a net reduction of LoC as well as a net
reduction of code weirdness.
Cheers,
Daniel
Re: [PATCH 3/3] dt-bindings: Batch-update Konrad Dybcio's email
On 26/07/2024 13:18, Konrad Dybcio wrote: > Use my @kernel.org address everywhere. > > Signed-off-by: Konrad Dybcio > --- FWIW: Acked-by: Krzysztof Kozlowski Rob, will you take it directly? Best regards, Krzysztof
Re: [PATCH 0/3] Update Konrad Dybcio's email addresses
On 26.07.2024 1:18 PM, Konrad Dybcio wrote: > Patch 3 should probably go straight to Rob's dt-bindings tree > > Signed-off-by: Konrad Dybcio > --- > Konrad Dybcio (3): > mailmap: Add an entry for Konrad Dybcio > MAINTAINERS: Update Konrad Dybcio's email address > dt-bindings: Batch-update Konrad Dybcio's email Err, please excuse the mismatched From: address.. it is definitely the same Konrad speaking.. Konrad
[PATCH 2/3] MAINTAINERS: Update Konrad Dybcio's email address
Use my @kernel.org address everywhere. Signed-off-by: Konrad Dybcio --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9200d953868e..6c7d3951192f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2745,7 +2745,7 @@ F:include/linux/soc/qcom/ ARM/QUALCOMM SUPPORT M: Bjorn Andersson -M: Konrad Dybcio +M: Konrad Dybcio L: linux-arm-...@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git @@ -7107,7 +7107,7 @@ F:drivers/gpu/drm/tiny/panel-mipi-dbi.c DRM DRIVER for Qualcomm Adreno GPUs M: Rob Clark R: Sean Paul -R: Konrad Dybcio +R: Konrad Dybcio L: linux-arm-...@vger.kernel.org L: dri-devel@lists.freedesktop.org L: freedr...@lists.freedesktop.org @@ -18765,7 +18765,7 @@ F: include/uapi/drm/qaic_accel.h QUALCOMM CORE POWER REDUCTION (CPR) AVS DRIVER M: Bjorn Andersson -M: Konrad Dybcio +M: Konrad Dybcio L: linux...@vger.kernel.org L: linux-arm-...@vger.kernel.org S: Maintained -- 2.45.2
[PATCH 3/3] dt-bindings: Batch-update Konrad Dybcio's email
Use my @kernel.org address everywhere. Signed-off-by: Konrad Dybcio --- Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6375-dispcc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6375-gcc.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml | 2 +- Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml | 2 +- .../devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml | 2 +- Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml| 2 +- Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml| 2 +- Documentation/devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml | 2 +- Documentation/devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml| 2 +- Documentation/devicetree/bindings/iommu/qcom,iommu.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml| 2 +- Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml | 2 +- Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml | 2 +- Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml | 2 +- 24 files changed, 24 insertions(+), 24 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml index a584b4953e68..46403b98411f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display Clock & Reset Controller on SM6350 maintainers: - - Konrad Dybcio + - Konrad Dybcio description: | Qualcomm display clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml index 6b9c1d198b14..10afe984e2fb 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller on MSM8994 maintainers: - - Konrad Dybcio + - Konrad Dybcio description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml index a5a29dc75ae1..1fe68e07a2b2 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller on SM6125 maintainers: - - Konrad Dybcio + - Konrad Dybcio description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml index 2280b859b2ad..78e232fa95dc 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller on SM6350 maintainers: - - Konrad Dybcio + - Konrad Dybcio description: | Qualcomm global clock control module provides the clocks, resets and power diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml index cf19f44af774..4ff17a91344b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Graphics Clock & Reset Controller on SM6115 maintainers: - - Konrad Dybcio + - Konrad Dybcio description: | Qualcomm graphics clock
[PATCH 1/3] mailmap: Add an entry for Konrad Dybcio
Map my old addresses. Signed-off-by: Konrad Dybcio --- .mailmap | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.mailmap b/.mailmap index e51d76df75c2..d189c6424697 100644 --- a/.mailmap +++ b/.mailmap @@ -353,6 +353,8 @@ Kenneth Westfield Kiran Gunda Kirill Tkhai Kishon Vijay Abraham I +Konrad Dybcio +Konrad Dybcio Konstantin Khlebnikov Konstantin Khlebnikov Koushik -- 2.45.2
[PATCH 0/3] Update Konrad Dybcio's email addresses
Patch 3 should probably go straight to Rob's dt-bindings tree Signed-off-by: Konrad Dybcio --- Konrad Dybcio (3): mailmap: Add an entry for Konrad Dybcio MAINTAINERS: Update Konrad Dybcio's email address dt-bindings: Batch-update Konrad Dybcio's email .mailmap| 2 ++ Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6350-camcc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6375-dispcc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm6375-gcc.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml | 2 +- Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml| 2 +- Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml | 2 +- Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml | 2 +- .../devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml | 2 +- .../devicetree/bindings/display/panel/sony,td4353-jdi.yaml | 2 +- .../devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml | 2 +- .../devicetree/bindings/interconnect/qcom,sc8280xp-rpmh.yaml| 2 +- .../devicetree/bindings/interconnect/qcom,sm8450-rpmh.yaml | 2 +- Documentation/devicetree/bindings/iommu/qcom,iommu.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml| 2 +- Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml | 2 +- Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml | 2 +- Documentation/devicetree/bindings/remoteproc/qcom,rpm-proc.yaml | 2 +- .../devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml | 2 +- MAINTAINERS | 6 +++--- 26 files changed, 29 insertions(+), 27 deletions(-) --- base-commit: 2347b4c79f5e6cd3f4996e80c2d3c15f53006bf5 change-id: 20240726-topic-konrad_email-808c630bcb3a Best regards, -- Konrad Dybcio
Re: [PATCH v8 5/5] drm/ci: rockchip: add tests for rockchip display driver
Hi Daniel, On 26/07/24 13:06, Daniel Stone wrote: Hi Vignesh, On Wed, 24 Jul 2024 at 11:12, Vignesh Raman wrote: For rockchip rk3288 and rk3399, the display driver is rockchip and gpu driver is panfrost. Currently, in drm-ci for rockchip rk3288 and rk3399, only the gpu driver is tested. Refactor the existing rockchip jobs to test both display and gpu driver and update xfails. Could you also please add RK3588 in a new series (no need to hold this one up), with Rockchip KMS and Panthor GPU? You can use the rk3588-rock5-b device type in LAVA. Sure. I Will add and send it in a new series. diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt b/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt index cf3a747f7cec..826cca5efbff 100644 --- a/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt This is in the wrong patch? Yes, this needs to be dropped. Thanks for pointing that out. +++ b/drivers/gpu/drm/ci/xfails/panfrost-rk3288-skips.txt @@ -0,0 +1,71 @@ +# Suspend to RAM seems to be broken on this machine +.*suspend.* + +# Too unstable, machine ends up hanging after lots of Oopses +kms_cursor_legacy.* + +# Started hanging the machine on Linux 5.19-rc2: +# +# [IGT] kms_plane_lowres: executing +# [IGT] kms_plane_lowres: starting subtest pipe-F-tiling-y +# [IGT] kms_plane_lowres: exiting, ret=77 ret 77 is a pure skip here, as you'd expect from a pipe F test, because Rockchip doesn't have six CRTCs. +# Console: switching to colour frame buffer device 170x48 +# rockchip-drm display-subsystem: [drm] *ERROR* flip_done timed out +# rockchip-drm display-subsystem: [drm] *ERROR* [CRTC:35:crtc-0] commit wait timed out +# BUG: spinlock bad magic on CPU#3, kms_plane_lowre/482 +# 8<--- cut here --- +# Unable to handle kernel paging request at virtual address 7812078e +# [7812078e] *pgd= +# Internal error: Oops: 5 [#1] SMP ARM +# Modules linked in: +# CPU: 3 PID: 482 Comm: kms_plane_lowre Tainted: GW 5.19.0-rc2-323596-g00535de92171 #1 +# Hardware name: Rockchip (Device Tree) +# Process kms_plane_lowre (pid: 482, stack limit = 0x1193ac2b) +# spin_dump from do_raw_spin_lock+0xa4/0xe8 +# do_raw_spin_lock from wait_for_completion_timeout+0x2c/0x120 +# wait_for_completion_timeout from drm_crtc_commit_wait+0x18/0x7c +# drm_crtc_commit_wait from drm_atomic_helper_wait_for_dependencies+0x44/0x168 +# drm_atomic_helper_wait_for_dependencies from commit_tail+0x34/0x180 +# commit_tail from drm_atomic_helper_commit+0x164/0x18c +# drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe4 +# drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x284 +# drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1c8 +# drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40 +# drm_client_modeset_commit from drm_fbdev_client_restore+0x58/0x94 +# drm_fbdev_client_restore from drm_client_dev_restore+0x70/0xbc +# drm_client_dev_restore from drm_release+0xf4/0x114 +# drm_release from __fput+0x74/0x240 +# __fput from task_work_run+0x84/0xb4 +# task_work_run from do_exit+0x34c/0xa20 +# do_exit from do_group_exit+0x34/0x98 So this is pointing to the error being that, when a client exits, the kernel attempts to restore fbdev and then it's broken. Pinning pipe-F-tiling-y as specifically responsible for this seems quite odd to me, given that it doesn't do anything but only skips. Is that maybe just because it's the last test running in the kms_plane_lowres group before it exits? Or does it occur more wildly on other test groups? This was skipped for Linux 5.19-rc2. I will remove from skips and will check the behavior. +tools_test@tools_test,Fail I keep noticing this failing everywhere. What's up with that? Have you reported these logs to the igt list? I will check this issue and report to igt developers. Thanks. Regards, Vignesh
[PATCH -next] drm/amd/display: Use ARRAY_SIZE for array length
Use of macro ARRAY_SIZE to calculate array size minimizes
the redundant code and improves code reusability.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1552:57-58:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1561:57-58:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1573:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1578:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1592:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1597:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1611:50-51:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1616:50-51:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1630:50-51:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1635:50-51:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1649:60-61:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1663:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1677:52-53:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1691:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1705:53-54:
WARNING: Use ARRAY_SIZE.
./drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c:1719:54-55:
WARNING: Use ARRAY_SIZE.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9580
Signed-off-by: Jiapeng Chong
---
.../display/dc/spl/dc_spl_scl_easf_filters.c | 63 ++-
1 file changed, 20 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
b/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
index 09bf82f7d468..e847af94419a 100644
--- a/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
+++ b/drivers/gpu/drm/amd/display/dc/spl/dc_spl_scl_easf_filters.c
@@ -1530,14 +1530,13 @@ static uint32_t
spl_easf_get_scale_ratio_to_reg_value(struct spl_fixed31_32 rati
value = lookup_table_index_ptr->reg_value;
while (count < num_entries) {
-
lookup_table_index_ptr = (lookup_table_base_ptr + count);
if (lookup_table_index_ptr->numer < 0)
break;
if (ratio.value < spl_fixpt_from_fraction(
- lookup_table_index_ptr->numer,
- lookup_table_index_ptr->denom).value) {
+ lookup_table_index_ptr->numer,
+ lookup_table_index_ptr->denom).value) {
value = lookup_table_index_ptr->reg_value;
break;
}
@@ -1548,21 +1547,13 @@ static uint32_t
spl_easf_get_scale_ratio_to_reg_value(struct spl_fixed31_32 rati
}
uint32_t spl_get_v_bf3_mode(struct spl_fixed31_32 ratio)
{
- uint32_t value;
- unsigned int num_entries = sizeof(easf_v_bf3_mode_lookup) /
- sizeof(struct scale_ratio_to_reg_value_lookup);
- value = spl_easf_get_scale_ratio_to_reg_value(ratio,
- easf_v_bf3_mode_lookup, num_entries);
- return value;
+ unsigned int num_entries = ARRAY_SIZE(easf_v_bf3_mode_lookup);
+ return spl_easf_get_scale_ratio_to_reg_value(ratio,
easf_v_bf3_mode_lookup, num_entries);
}
uint32_t spl_get_h_bf3_mode(struct spl_fixed31_32 ratio)
{
- uint32_t value;
- unsigned int num_entries = sizeof(easf_h_bf3_mode_lookup) /
- sizeof(struct scale_ratio_to_reg_value_lookup);
- value = spl_easf_get_scale_ratio_to_reg_value(ratio,
- easf_h_bf3_mode_lookup, num_entries);
- return value;
+ unsigned int num_entries = ARRAY_SIZE(easf_h_bf3_mode_lookup);
+ return spl_easf_get_scale_ratio_to_reg_value(ratio,
easf_h_bf3_mode_lookup, num_entries);
}
uint32_t spl_get_reducer_gain6(int taps, struct spl_fixed31_32 ratio)
{
@@ -1570,13 +1561,11 @@ uint32_t spl_get_reducer_gain6(int taps, struct
spl_fixed31_32 ratio)
unsigned int num_entries;
if (taps == 4) {
- num_entries = sizeof(easf_reducer_gain6_4tap_lookup) /
- sizeof(struct scale_ratio_to_reg_value_lookup);
+ num_entries = ARRAY_SIZE(easf_reducer_gain6_4tap_lookup);
value = spl_easf_get_scale_ratio_to_reg_value(ratio,
easf_reducer_gain6_4tap_lookup, num_entries);
} else if (taps == 6) {
- num_entries = sizeof(easf_reducer_gain6_6tap_lookup) /
- sizeof(struct scale_ratio_to_reg_value_lookup);
+
Re: [PATCH v1] drm/i915/hwmon: expose fan speed
On Wed, Jul 24, 2024 at 02:11:40PM +0530, Nilawar, Badal wrote:
>
>
> On 12-07-2024 17:53, Raag Jadav wrote:
> > Add hwmon support for fan1_input attribute, which will expose fan speed
> > in RPM. With this in place we can monitor fan speed using lm-sensors tool.
> >
> > $ sensors
> > i915-pci-0300
> > Adapter: PCI adapter
> > in0: 653.00 mV
> > fan1:3833 RPM
> > power1: N/A (max = 43.00 W)
> > energy1: 32.02 kJ
> >
> > Signed-off-by: Raag Jadav
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 +
> > drivers/gpu/drm/i915/i915_hwmon.c | 71 +
> > 2 files changed, 73 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index e42b3a5d4e63..407d8152755a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1553,6 +1553,8 @@
> > #define VLV_RENDER_C0_COUNT _MMIO(0x138118)
> > #define VLV_MEDIA_C0_COUNT_MMIO(0x13811c)
> > +#define GEN12_PWM_FAN_SPEED_MMIO(0x138140)
> > +
> > #define GEN12_RPSTAT1 _MMIO(0x1381b4)
> > #define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> > #define GEN12_CAGF_MASK REG_GENMASK(19, 11)
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 49db3e09826c..f829c7837d83 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -36,6 +36,7 @@ struct hwm_reg {
> > i915_reg_t pkg_rapl_limit;
> > i915_reg_t energy_status_all;
> > i915_reg_t energy_status_tile;
> > + i915_reg_t fan_speed;
> > };
> > struct hwm_energy_info {
> > @@ -43,11 +44,17 @@ struct hwm_energy_info {
> > long accum_energy; /* Accumulated energy for
> > energy1_input */
> > };
> > +struct hwm_fan_info {
> > + u32 reg_val_prev;
> > + u32 time_prev;
> > +};
> > +
> > struct hwm_drvdata {
> > struct i915_hwmon *hwmon;
> > struct intel_uncore *uncore;
> > struct device *hwmon_dev;
> > struct hwm_energy_info ei; /* Energy info for
> > energy1_input */
> > + struct hwm_fan_info fi; /* Fan info for fan1_input */
> > char name[12];
> > int gt_n;
> > bool reset_in_progress;
> > @@ -276,6 +283,7 @@ static const struct hwmon_channel_info * const
> > hwm_info[] = {
> > HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
> > HWMON_P_CRIT),
> > HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
> > HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
> > + HWMON_CHANNEL_INFO(fan, HWMON_F_INPUT),
> > NULL
> > };
> > @@ -613,6 +621,55 @@ hwm_curr_write(struct hwm_drvdata *ddat, u32 attr,
> > long val)
> > }
> > }
> > +static umode_t
> > +hwm_fan_is_visible(const struct hwm_drvdata *ddat, u32 attr)
> > +{
> > + struct i915_hwmon *hwmon = ddat->hwmon;
> > +
> > + switch (attr) {
> > + case hwmon_fan_input:
> > + return i915_mmio_reg_valid(hwmon->rg.fan_speed) ? 0444 : 0;
> > + default:
> > + return 0;
> > + }
> > +}
> > +
> > +static int
> > +hwm_fan_read(struct hwm_drvdata *ddat, u32 attr, long *val)
> > +{
> > + struct i915_hwmon *hwmon = ddat->hwmon;
> > + u32 reg_val, rotation, time, time_now;
> > + intel_wakeref_t wakeref;
> > +
> > + switch (attr) {
> > + case hwmon_fan_input:
> > + with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
> Do we expect fan running when device is in D3? If not then we should use
> with_intel_runtime_pm_if_active here otherwise report fan speed 0.
Yes, it can be running depending on package temperature.
So better to rely on hardware value.
Raag
Re: [PATCH] drm/lima: Mark simple_ondemand governor as softdep
On 2024-07-26 10:54, Qiang Yu wrote: On Fri, Jul 26, 2024 at 4:03 PM Dragan Simic wrote: On 2024-07-26 08:07, Qiang Yu wrote: > Yeah, I agree weakdep is a better choice here. It solves the confusion > of softdep which the depend module is optional. Thanks, I'm glad that you agree. > But I prefer using weakdep directly instead of creating an aliasing of > it which has no actual difference. Just checking, did you have a chance to read what I wrote in my earlier response on the linux-modules mailing list, [7] which includes a rather elaborate explanation of the intent behind MODULE_HARDDEP being currently just a proposed alias for MODULE_WEAKDEP? It also describes why using this alias might save use some time and effort in the future. [7] https://lore.kernel.org/linux-modules/0720a516416a92a8f683053d37ee9...@manjaro.org/ Yeah, I've seen that mail. But I haven't seen clearly how weakdep will change in the future which could break our usage here. As an interface exposed to other users, I expect it should be stable. Let me clarify, please. The intent isn't to prevent breakage, but to future-proof our weakdeps that are actually harddeps under the hood. Of course, weakdeps aren't expected to become unsuitable for our needs in the future, but we might actually need to treat our uses of weakdeps as harddeps at some point, so marking them as (currently aliased) harddeps leaves clear "earmarks" for us in the future. The Btrfs example, which I used in my earlier response on linux-modules, shows how such "earmarks" can be useful after some time passes. > On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic > wrote: >> >> Hello Qiang, >> >> On 2024-06-26 08:49, Dragan Simic wrote: >> > On 2024-06-26 03:11, Qiang Yu wrote: >> >> On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic >> >> wrote: >> >>> Just checking, any further thoughts about this patch? >> >>> >> >> I'm OK with this as a temp workaround because it's simple and do no >> >> harm >> >> even it's not perfect. If no other better suggestion for short term, >> >> I'll submit >> >> this at weekend. >> > >> > Thanks. Just as you described it, it's far from perfect, but it's >> > still >> > fine until there's a better solution, such as harddeps. I'll continue >> > my >> > research about the possibility for adding harddeps, which would >> > hopefully >> > replace quite a few instances of the softdep (ab)use. >> >> Another option has become available for expressing additional module >> dependencies, weakdeps. [1][2] Long story short, weakdeps are similar >> to softdeps, in the sense of telling the initial ramdisk utilities to >> include additional kernel modules, but weakdeps result in no module >> loading being performed by userspace. >> >> Maybe "weak" isn't the best possible word choice (arguably, "soft" >> also >> wasn't the best word choice), but weakdeps should be a better choice >> for >> use with Lima and governor_simpleondemand, because weakdeps provide >> the >> required information to the utilities used to generate initial >> ramdisk, >> while the actual module loading is left to the kernel. >> >> The recent addition of weakdeps renders the previously mentioned >> harddeps >> obsolete, because weakdeps actually do what we need. Obviously, >> "weak" >> doesn't go along very well with the actual nature of the dependency >> between >> Lima and governor_simpleondemand, but it's pretty much just the >> somewhat >> unfortunate word choice. >> >> The support for weakdeps has been already added to the kmod [3][4] and >> Dracut [5] userspace utilities. I'll hopefully add support for >> weakdeps >> to mkinitcpio [6] rather soon. >> >> Maybe we could actually add MODULE_HARDDEP() as some kind of syntactic >> sugar, which would currently be an alias for MODULE_WEAKDEP(), so the >> actual hard module dependencies could be expressed properly, and >> possibly >> handled differently in the future, with no need to go back and track >> all >> such instances of hard module dependencies. >> >> With all this in mind, here's what I'm going to do: >> >> 1) Submit a patch that adds MODULE_HARDDEP() as syntactic sugar >> 2) Implement support for weakdeps in Arch Linux's mkinitcpio [6] >> 3) Depending on what kind of feedback the MODULE_HARDDEP() patch >> receives, >> I'll submit follow-up patches for Lima and Panfrost, which will >> swap >> uses of MODULE_SOFTDEP() w
Re: [PATCH v8 2/5] drm/ci: mediatek: add tests for mediatek display driver
Hi Daniel, On 26/07/24 12:54, Daniel Stone wrote: Hi Vignesh, On Wed, 24 Jul 2024 at 11:11, Vignesh Raman wrote: +dumb_buffer@create-clear,Fail +dumb_buffer@create-valid-dumb,Fail +dumb_buffer@invalid-bpp,Fail +dumb_buffer@map-invalid-size,Fail +dumb_buffer@map-uaf,Fail +dumb_buffer@map-valid,Fail +fbdev@eof,Fail +fbdev@read,Fail +fbdev@unaligned-read,Fail Please skip dumb_buffer and fbdev tests for all GPU-only drivers, because those are testing display functionality. Will skip these tests for gpu-only drivers. Thanks. Regards, Vignesh
Re: [PATCH 2/2] drm/mipi-dsi: Change multi functions to use quiet member of mipi_dsi_multi_context
Hi,
On Thu, Jul 25, 2024 at 10:12:46AM GMT, Doug Anderson wrote:
> On Thu, Jul 25, 2024 at 1:28 AM Maxime Ripard wrote:
> >
> > On Wed, Jul 24, 2024 at 06:32:14PM GMT, Jani Nikula wrote:
> > > On Wed, 24 Jul 2024, Tejas Vipin wrote:
> > > > Changes all the multi functions to check if the current context requires
> > > > errors to be printed or not using the quiet member.
> > > >
> > > > Signed-off-by: Tejas Vipin
> > > > ---
> > > > drivers/gpu/drm/drm_mipi_dsi.c | 20
> > > > 1 file changed, 20 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c
> > > > b/drivers/gpu/drm/drm_mipi_dsi.c
> > > > index a471c46f5ca6..cbb77342d201 100644
> > > > --- a/drivers/gpu/drm/drm_mipi_dsi.c
> > > > +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> > > > @@ -814,6 +814,8 @@ void mipi_dsi_generic_write_multi(struct
> > > > mipi_dsi_multi_context *ctx,
> > > > ret = mipi_dsi_generic_write(dsi, payload, size);
> > > > if (ret < 0) {
> > > > ctx->accum_err = ret;
> > > > + if (ctx->quiet)
> > > > + return;
> > > > dev_err(dev, "sending generic data %*ph failed: %d\n",
> > > > (int)size, payload, ctx->accum_err);
> > >
> > > A maintainability nitpick. Imagine someone wishing to add some more
> > > error handling here. Or something else after the block.
> > >
> > > IMO the dev_err() should be wrapped in if (!ctx->quiet) instead of
> > > adding an early return.
> > >
> > > Ditto everywhere.
> >
> > I'm not even sure why we need that parameter in the first place.
> >
> > Like, what's the expected use of that parameter? Is it supposed to be
> > set in users of that function?
> >
> > If so, wouldn't it prevent any sort of meaningful debugging if some
> > drivers set it and some don't?
> >
> > It looks to me like you're reimplementing drm.debug.
>
> I can explain how we got here and maybe you can explain how it should
> be designed differently.
>
> 1. The majority of MIPI panels drivers just have a pile of commands
> that need to be sent during panel init time. Each time you send a
> command it technically can fail but it's very unlikely. In order to
> make things debuggable in the unlikely case of failure, you want a
> printout about which command failed. In order to avoid massive numbers
> of printouts in each driver you want the printout in the core. This is
> the impetus behind the "_multi" functions that were introduced
> recently and I think most people who have looked at converted drivers
> are pretty pleased. The functions are readable/non-bloated but still
> check for errors and print messages in the right place.
>
> 2. As Tejas was adding more "_multi" variants things were starting to
> feel a bit awkward. Dmitry proposed [1] that maybe the answer was that
> we should work to get rid of the non-multi variants and then we don't
> need these awkward wrappers.
Makes sense to me so far
> 3. The issue with telling everyone to use the "_multi" variants is
> that they print the error message for you. While this is the correct
> default behavior and the correct behavior for the vast majority of
> users, I can imagine there being a legitimate case where a driver
> might not want error messages printed.
That's the part I disagree with actually. I don't think that message
printing is a driver's decision, but a context one. Users might want to
increase / decrease the log levels, but drivers shouldn't and just
provide a consistent behaviour there.
> I don't personally know of a case, but in my experience there's always
> some case where you're dealing with weird hardware and the driver
> knows that a command has a high chance of failure. Maybe the driver
> will retry or maybe it'll detect /handle the error, but the idea is
> that the driver wouldn't want a printout.
Then we'll address it when the time comes and we're sure what we're
actually trying to fix. And even that theoretical scenario might just
disappear when the printk threaded printing work is done.
> Said another way: I think of the errors of these MIPI initialization
> functions a lot like errors allocating memory. By default kmalloc()
> reports an error so all drivers calling kmalloc() don't need to print,
> but if your driver specifically knows that an allocation failure is
> likely and it knows how to handle it then it can pass a flag to tell
> the core kernel not to print.
>
>
> So I guess options are:
>
> a) Accept what Tejas is doing here as reasonable.
I don't think it's unreasonable, however I do think it's an API that has
no current users and will just lead to inconsistencies in the drivers,
without any benefit at the moment.
> b) Don't accept what Tejas is doing here and always keep the "_multi"
> functions as wrappers.
>
> c) Declare that, since there are no known cases where we want to
> suppress the error printouts, that suppressing the error printouts is
> a "tomorrow" problem. We transition everyone to _multi but don't
>
Re: [PATCH v3] rockchip/drm: vop2: add support for gamma LUT
Hi Piotr,
Thanks for your work.
On 7/25/24 06:05, Piotr Zalewski wrote:
Add support for gamma LUT in VOP2 driver. The implementation is based on
the one found in VOP driver and modified to be compatible with VOP2. Blue
and red channels in gamma LUT register write were swapped with respect to
how gamma LUT values are written in VOP. Write of the current video port id
to VOP2_SYS_LUT_PORT_SEL register was added before the write of DSP_LUT_EN
bit. Gamma size is set and drm color management is enabled for each video
port's CRTC except ones which have no associated device. Tested on RK3566
(Pinetab2).
Helped-by: Dragan Simic
Signed-off-by: Piotr Zalewski
---
Notes:
Changes in v3:
- v3 is patch v2 "resend", by mistake the incremental patch were
sent in v2
Changes in v2:
- Apply code styling corrections [1]
- Move gamma LUT write inside the vop2 lock
Link to v2:
https://lore.kernel.org/linux-rockchip/Hk03HDb6wSSHWtEFZHUye06HR0-9YzP5nCHx9A8_kHzWSZawDrU1o1pjEGkCOJFoRg0nTB4BWEv6V0XBOjF4-0Mj44lp2TrjaQfnytzp-Pk=@proton.me/T/#u
Link to v1:
https://lore.kernel.org/linux-rockchip/9736eadf6a9d8e97eef919c6b3d88...@manjaro.org/T/#t
[1]
https://lore.kernel.org/linux-rockchip/d019761504b540600d9fc7a585d6f...@manjaro.org/
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 9873172e3fd3..37fcf544a5fd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -278,6 +278,15 @@ static u32 vop2_readl(struct vop2 *vop2, u32 offset)
return val;
}
+static u32 vop2_vp_read(struct vop2_video_port *vp, u32 offset)
+{
+ u32 val;
+
+ regmap_read(vp->vop2->map, vp->data->offset + offset, );
+
+ return val;
+}
+
static void vop2_win_write(const struct vop2_win *win, unsigned int reg, u32
v)
{
regmap_field_write(win->reg[reg], v);
@@ -1482,6 +1491,95 @@ static bool vop2_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
}
+static bool vop2_vp_dsp_lut_is_enabled(struct vop2_video_port *vp)
+{
+ return (u32) (vop2_vp_read(vp, RK3568_VP_DSP_CTRL) &
RK3568_VP_DSP_CTRL__DSP_LUT_EN) >
+ 0;
+}
+
+static void vop2_vp_dsp_lut_enable(struct vop2_video_port *vp)
+{
+ u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
+
+ dsp_ctrl |= RK3568_VP_DSP_CTRL__DSP_LUT_EN;
+ vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
+}
+
+static void vop2_vp_dsp_lut_disable(struct vop2_video_port *vp)
+{
+ u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
+
+ dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
+ vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
+}
+
+static void vop2_crtc_write_gamma_lut(struct vop2 *vop2, struct drm_crtc *crtc)
+{
+ const struct vop2_video_port *vp = to_vop2_video_port(crtc);
+ const struct vop2_video_port_data *vp_data = >data->vp[vp->id];
+
+ struct drm_color_lut *lut = crtc->state->gamma_lut->data;
+ unsigned int i, bpc = ilog2(vp_data->gamma_lut_len);
+ u32 word;
+
+ for (i = 0; i < crtc->gamma_size; i++) {
+ word = (drm_color_lut_extract(lut[i].blue, bpc) << (2 * bpc)) |
+ (drm_color_lut_extract(lut[i].green, bpc) << bpc) |
+ drm_color_lut_extract(lut[i].red, bpc);
+
+ writel(word, vop2->lut_regs + i * 4);
+ }
+}
+
+static void vop2_crtc_gamma_set(struct vop2 *vop2, struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct drm_crtc_state *state = crtc->state;
+ struct vop2_video_port *vp = to_vop2_video_port(crtc);
+ u32 dsp_ctrl;
+ int ret;
+
+ if (!vop2->lut_regs)
+ return;
+
+ if (!state->gamma_lut) {
What's the purpose of checking !state->gamma_lut here,
and you check it again at the end for return.
This makes me very confused.
+ /*
+* To disable gamma (gamma_lut is null) or to write
+* an update to the LUT, clear dsp_lut_en.
+*/
+ vop2_lock(vop2);
+
+ vop2_vp_dsp_lut_disable(vp);
+
+ vop2_cfg_done(vp);
+ vop2_unlock(vop2);
+ /*
+* In order to write the LUT to the internal memory,
+* we need to first make sure the dsp_lut_en bit is cleared.
+*/
+ ret = readx_poll_timeout(vop2_vp_dsp_lut_is_enabled, vp,
dsp_ctrl,
+ !dsp_ctrl, 5, 30 * 1000);
+
+ if (ret) {
+ DRM_DEV_ERROR(vop2->dev, "display LUT RAM enable
timeout!\n");
+ return;
+ }
+
+ if (!state->gamma_lut)
+ return;
+ }
+
+
+ vop2_lo
Re: [PATCH] drm/scheduler: Fix drm_sched_entity_set_priority()
On 24/07/2024 12:16, Christian König wrote: Am 24.07.24 um 10:16 schrieb Tvrtko Ursulin: [SNIP] Absolutely. Absolutely good and absolutely me, or absolutely you? :) You, I don't even have time to finish all the stuff I already started :/ Okay, I think I can squeeze it in. These are the TODO points and their opens: - Adjust amdgpu_ctx_set_entity_priority() to call drm_sched_entity_modify_sched() regardless of the hw_type - to fix priority changes on a single sched other than gfx or compute. Either that or to stop using the scheduler priority to implement userspace priorities and always use different HW queues for that. - Document sched_list array lifetime must align with the entity and adjust the callers. Open: Do you still oppose keeping sched_list for num_scheds == 1? Not if you can fix up all callers. If so do you propose drm_sched_entity_modify_sched() keeps disagreeing with drm_sched_entity_init() on this detail? And keep the "one shot single sched_list" quirk in? Why is that nicer than simply keeping the list and remove that quirk? Once lifetime rules are clear it IMO is okay to always keep the list. Yeah if every caller of drm_sched_entity_init() can be fixed I'm fine with that as well. Okay so I will tackle the above few first. - Remove drm_sched_entity_set_priority(). Open: Should we at this point also modify amdgpu_device_init_schedulers() to stop initialising schedulers with DRM_SCHED_PRIORITY_COUNT run queues? One step at a time. And leave this for later. Regards, Tvrtko
Re: [PATCH] drm/lima: Mark simple_ondemand governor as softdep
On Fri, Jul 26, 2024 at 4:03 PM Dragan Simic wrote: > > Hello Qiang Yu, > > On 2024-07-26 08:07, Qiang Yu wrote: > > Yeah, I agree weakdep is a better choice here. It solves the confusion > > of softdep which the depend module is optional. > > Thanks, I'm glad that you agree. > > > But I prefer using weakdep directly instead of creating an aliasing of > > it which has no actual difference. > > Just checking, did you have a chance to read what I wrote in my earlier > response on the linux-modules mailing list, [7] which includes a rather > elaborate explanation of the intent behind MODULE_HARDDEP being > currently > just a proposed alias for MODULE_WEAKDEP? It also describes why using > this alias might save use some time and effort in the future. > > [7] > https://lore.kernel.org/linux-modules/0720a516416a92a8f683053d37ee9...@manjaro.org/ > Yeah, I've seen that mail. But I haven't seen clearly how weakdep will change in the future which could break our usage here. As an interface exposed to other users, I expect it should be stable. > > On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic > > wrote: > >> > >> Hello Qiang, > >> > >> On 2024-06-26 08:49, Dragan Simic wrote: > >> > On 2024-06-26 03:11, Qiang Yu wrote: > >> >> On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic > >> >> wrote: > >> >>> Just checking, any further thoughts about this patch? > >> >>> > >> >> I'm OK with this as a temp workaround because it's simple and do no > >> >> harm > >> >> even it's not perfect. If no other better suggestion for short term, > >> >> I'll submit > >> >> this at weekend. > >> > > >> > Thanks. Just as you described it, it's far from perfect, but it's > >> > still > >> > fine until there's a better solution, such as harddeps. I'll continue > >> > my > >> > research about the possibility for adding harddeps, which would > >> > hopefully > >> > replace quite a few instances of the softdep (ab)use. > >> > >> Another option has become available for expressing additional module > >> dependencies, weakdeps. [1][2] Long story short, weakdeps are similar > >> to softdeps, in the sense of telling the initial ramdisk utilities to > >> include additional kernel modules, but weakdeps result in no module > >> loading being performed by userspace. > >> > >> Maybe "weak" isn't the best possible word choice (arguably, "soft" > >> also > >> wasn't the best word choice), but weakdeps should be a better choice > >> for > >> use with Lima and governor_simpleondemand, because weakdeps provide > >> the > >> required information to the utilities used to generate initial > >> ramdisk, > >> while the actual module loading is left to the kernel. > >> > >> The recent addition of weakdeps renders the previously mentioned > >> harddeps > >> obsolete, because weakdeps actually do what we need. Obviously, > >> "weak" > >> doesn't go along very well with the actual nature of the dependency > >> between > >> Lima and governor_simpleondemand, but it's pretty much just the > >> somewhat > >> unfortunate word choice. > >> > >> The support for weakdeps has been already added to the kmod [3][4] and > >> Dracut [5] userspace utilities. I'll hopefully add support for > >> weakdeps > >> to mkinitcpio [6] rather soon. > >> > >> Maybe we could actually add MODULE_HARDDEP() as some kind of syntactic > >> sugar, which would currently be an alias for MODULE_WEAKDEP(), so the > >> actual hard module dependencies could be expressed properly, and > >> possibly > >> handled differently in the future, with no need to go back and track > >> all > >> such instances of hard module dependencies. > >> > >> With all this in mind, here's what I'm going to do: > >> > >> 1) Submit a patch that adds MODULE_HARDDEP() as syntactic sugar > >> 2) Implement support for weakdeps in Arch Linux's mkinitcpio [6] > >> 3) Depending on what kind of feedback the MODULE_HARDDEP() patch > >> receives, > >> I'll submit follow-up patches for Lima and Panfrost, which will > >> swap > >> uses of MODULE_SOFTDEP() with MODULE_HARDDEP() or MODULE_WEAKDEP() > >> > >> Looking forward to your thoughts. > >> > >> [1] > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/module.h?id=61842868de13aa7fd7391c626e889f4d6f1450bf > >> [2] > >> https://lore.kernel.org/linux-kernel/20240724102349.430078-1-jtorn...@redhat.com/T/#u > >> [3] > >> https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7 > >> [4] > >> https://github.com/kmod-project/kmod/commit/d06712b51404061eef92cb275b8303814fca86ec > >> [5] > >> https://github.com/dracut-ng/dracut-ng/commit/8517a6be5e20f4a6d87e55fce35ee3e29e2a1150 > >> [6] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio
Re: [PATCH 2/2] drm/tiny: Add driver for Sharp Memory LCD
On 26/07/2024 03:25, Alex Lanzano wrote:
> On Thu, Jul 25, 2024 at 08:08:57AM GMT, Krzysztof Kozlowski wrote:
>> On 25/07/2024 02:47, Alex Lanzano wrote:
>>> +static const struct spi_device_id sharp_memory_ids[] = {
>>> + {"ls010b7dh04", LS010B7DH04},
>>> + {"ls011b7dh03", LS011B7DH03},
>>> + {"ls012b7dd01", LS012B7DD01},
>>> + {"ls013b7dh03", LS013B7DH03},
>>> + {"ls013b7dh05", LS013B7DH05},
>>> + {"ls018b7dh02", LS018B7DH02},
>>> + {"ls027b7dh01", LS027B7DH01},
>>> + {"ls027b7dh01a", LS027B7DH01A},
>>> + {"ls032b7dd02", LS032B7DD02},
>>> + {"ls044q7dh01", LS044Q7DH01},
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(spi, sharp_memory_ids);
>>> +
>>> +static const struct of_device_id sharp_memory_of_match[] = {
>>> + {.compatible = "sharp,ls010b7dh04"},
>>
>> Both ID tables should be in sync. See not-so-recent IIO discussions and
>> commits.
>>
>>> + {.compatible = "sharp,ls011b7dh03"},
>>> + {.compatible = "sharp,ls012b7dd01"},
>>> + {.compatible = "sharp,ls013b7dh03"},
>>> + {.compatible = "sharp,ls013b7dh05"},
>>> + {.compatible = "sharp,ls018b7dh02"},
>>> + {.compatible = "sharp,ls027b7dh01"},
>>> + {.compatible = "sharp,ls027b7dh01a"},
>>> + {.compatible = "sharp,ls032b7dd02"},
>>> + {.compatible = "sharp,ls044q7dh01"},
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, sharp_memory_of_match);
>
> I'm having some trouble finding the discussions and commits you're referring
> to.
> When you say the tables should be in sync are you referring to the ordering of
> entries in the tables? Like at index x of both tables should define model y?
No, the match data.
62d3fb9dcc091ccdf25eb3b716e90e07e3ed861f
Best regards,
Krzysztof
Re: [PATCH] drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll()
On Thu, 25 Jul 2024, Nikita Zhandarovich wrote:
> Hi,
>
> On 7/25/24 01:17, Jani Nikula wrote:
>> On Wed, 24 Jul 2024, Nikita Zhandarovich wrote:
>>> On the off chance that clock value ends up being too high (by means
>>> of skl_ddi_calculate_wrpll() having benn called with big enough
>>> value of crtc_state->port_clock * 1000), one possible consequence
>>> may be that the result will not be able to fit into signed int.
>>>
>>> Fix this, albeit unlikely, issue by first casting one of the operands
>>> to u32, then to u64, and thus avoid causing an integer overflow.
>>
>> Okay, thanks for the patch, but please let's not do this.
>>
>> Currently the highest possible port clock is 200 kHz, and 1000 times
>> that fits into 31 bits. When we need to support higher clocks, we'll
>> need to handle this. But not like this.
>>
>> That (u64)(u32) is just too unintuitive, and assumes the caller has
>> already passed in something that has overflown. People are just going to
>> pause there, and wonder what's going on.
>>
>> If we want to appease the static analyzer, I think a better approach
>> would be to change the parameter to u64 clock_hz, and have the caller
>> do:
>>
>> ret = skl_ddi_calculate_wrpll((u64)crtc_state->port_clock * 1000,
>>i915->display.dpll.ref_clks.nssc,
>> _params);
>>
>> BR,
>> Jani.
>>
>
> First, I agree that using (u64)(u32) is confusing and not intuitive,
> even if there are some similar examples in kernel code.
>
> The reason why I thought I had to opt for it though is the following: I
> was worried that if the int value of 'clock' in
> skl_ddi_calculate_wrpll() is big enough (specifically, high bit is 1),
> then after casting it to long or u64 in this case, the resulting value
> of wider type will have all its ~32 upper bits also set to 1, per rules
> of Integer Promotion. Changing the type from signed to unsigned, then to
> bigger unsigned seems to mitigate *this* particular issue and I can't
> come up with a more elegant solution at the moment. Correct me if I'm
> wrong somewhere.
>
> Also, while port clock may be able to fit its value timed 1000 into 31
> bits, multiplying it by 5 to get AFE Clock value, as far as I can see,
> *will* lead to overflow, as 2,000,000,000 * 5 won't fit into 32 bits.
>
> To sum it up, with current max possible port clock values an integer
> overflow can occur and changing 'clock' parameter from int to u64 may
> lead to a different issue. If my understanding about integer promotion
> is flawed, I'll gladly send v2 patch with your solution.
This is what I'm suggesting. Cast the clock (which is in kHz) to u64
before multiplication, and avoid overflows.
Option 1, preferred:
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 90998b037349..292d163036b1 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -1658,7 +1658,7 @@ static void skl_wrpll_params_populate(struct
skl_wrpll_params *params,
}
static int
-skl_ddi_calculate_wrpll(int clock /* in Hz */,
+skl_ddi_calculate_wrpll(int clock,
int ref_clock,
struct skl_wrpll_params *wrpll_params)
{
@@ -1683,7 +1683,7 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
};
unsigned int dco, d, i;
unsigned int p0, p1, p2;
- u64 afe_clock = clock * 5; /* AFE Clock is 5x Pixel clock */
+ u64 afe_clock = (u64)clock * 1000 * 5; /* AFE Clock is 5x Pixel clock,
in Hz */
for (d = 0; d < ARRAY_SIZE(dividers); d++) {
for (dco = 0; dco < ARRAY_SIZE(dco_central_freq); dco++) {
@@ -1808,7 +1808,7 @@ static int skl_ddi_hdmi_pll_dividers(struct
intel_crtc_state *crtc_state)
struct skl_wrpll_params wrpll_params = {};
int ret;
- ret = skl_ddi_calculate_wrpll(crtc_state->port_clock * 1000,
+ ret = skl_ddi_calculate_wrpll(crtc_state->port_clock,
i915->display.dpll.ref_clks.nssc,
_params);
if (ret)
return ret;
Option 2, this is what I suggested earlier:
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 90998b037349..a48a45f30f17 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -1658,7 +1658,7 @@ static void skl_wrpll_params_populate(struct
skl_wrpll_params *params,
}
static int
-skl_ddi_calculate_wrpll(int clock /* in Hz */,
+skl_ddi_calculate_wrpll(u64 clock_hz,
int ref_clock,
struct
Re: [PATCH v1 1/2] drm/panel: jd9365da: Move the sending location of the 11/29 command
On Fri, 26 Jul 2024, zhaoxiong lv
wrote:
> On Thu, Jul 25, 2024 at 4:41 PM Jani Nikula
> wrote:
>>
>> On Thu, 25 Jul 2024, Zhaoxiong Lv
>> wrote:
>> > Move the 11/29 command from enable() to init() function
>>
>> OOC, what is the "11/29" command?
>>
>> BR,
>> Jani.
>
> hi Jani
> Sorry, maybe I didn't describe it clearly. The 11/29 commands are sent
> by these two functions.
>
> mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
> mipi_dsi_dcs_set_display_on_multi(_ctx);
>
> MIPI_DCS_EXIT_SLEEP_MODE = 0x11,
> MIPI_DCS_SET_DISPLAY_ON= 0x29,
Maybe refer to the commands with their names then? Exit sleep mode and
set display on.
BR,
Jani.
>
> BR,
>>
>> >
>> > As mentioned in the patch:
>> > https://lore.kernel.org/all/20240624141926.5250-2-lvzhaoxi...@huaqin.corp-partner.google.com/
>> >
>> > Our DSI host has different modes in prepare() and enable()
>> > functions. prepare() is in LP mode and enable() is in HS mode.
>> > Since the 11/29 command must also be sent in LP mode,
>> > so we also move 11/29 command to the init() function.
>> >
>> > After moving the 11/29 command to the init() function,
>> > we no longer need additional delay judgment, so we delete
>> > variables "exit_sleep_to_display_on_delay_ms" and
>> > "display_on_delay_ms".
>> >
>> > Signed-off-by: Zhaoxiong Lv
>> > ---
>> > .../gpu/drm/panel/panel-jadard-jd9365da-h3.c | 59 ++-
>> > 1 file changed, 32 insertions(+), 27 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>> > b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>> > index 04d315d96bff..ce73e8cb1db5 100644
>> > --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>> > +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>> > @@ -31,8 +31,6 @@ struct jadard_panel_desc {
>> > bool reset_before_power_off_vcioo;
>> > unsigned int vcioo_to_lp11_delay_ms;
>> > unsigned int lp11_to_reset_delay_ms;
>> > - unsigned int exit_sleep_to_display_on_delay_ms;
>> > - unsigned int display_on_delay_ms;
>> > unsigned int backlight_off_to_display_off_delay_ms;
>> > unsigned int display_off_to_enter_sleep_delay_ms;
>> > unsigned int enter_sleep_to_reset_down_delay_ms;
>> > @@ -66,26 +64,6 @@ static inline struct jadard *panel_to_jadard(struct
>> > drm_panel *panel)
>> > return container_of(panel, struct jadard, panel);
>> > }
>> >
>> > -static int jadard_enable(struct drm_panel *panel)
>> > -{
>> > - struct jadard *jadard = panel_to_jadard(panel);
>> > - struct mipi_dsi_multi_context dsi_ctx = { .dsi = jadard->dsi };
>> > -
>> > - msleep(120);
>> > -
>> > - mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
>> > -
>> > - if (jadard->desc->exit_sleep_to_display_on_delay_ms)
>> > - mipi_dsi_msleep(_ctx,
>> > jadard->desc->exit_sleep_to_display_on_delay_ms);
>> > -
>> > - mipi_dsi_dcs_set_display_on_multi(_ctx);
>> > -
>> > - if (jadard->desc->display_on_delay_ms)
>> > - mipi_dsi_msleep(_ctx, jadard->desc->display_on_delay_ms);
>> > -
>> > - return dsi_ctx.accum_err;
>> > -}
>> > -
>> > static int jadard_disable(struct drm_panel *panel)
>> > {
>> > struct jadard *jadard = panel_to_jadard(panel);
>> > @@ -202,7 +180,6 @@ static const struct drm_panel_funcs jadard_funcs = {
>> > .disable = jadard_disable,
>> > .unprepare = jadard_unprepare,
>> > .prepare = jadard_prepare,
>> > - .enable = jadard_enable,
>> > .get_modes = jadard_get_modes,
>> > .get_orientation = jadard_panel_get_orientation,
>> > };
>> > @@ -382,6 +359,12 @@ static int radxa_display_8hd_ad002_init_cmds(struct
>> > jadard *jadard)
>> >
>> > jd9365da_switch_page(_ctx, 0x00);
>> >
>> > + mipi_dsi_msleep(_ctx, 120);
>> > +
>> > + mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
>> > +
>> > + mipi_dsi_dcs_set_display_on_multi(_ctx);
>> > +
>> > return dsi_ctx.accum_err;
>> > };
>> >
>> > @@ -608,6 +591,12 @@ static int cz101b4001_init_cmds(struct jadard *jadard)
>> > mi
Re: [PATCH] drm/lima: Mark simple_ondemand governor as softdep
Hello Qiang Yu, On 2024-07-26 08:07, Qiang Yu wrote: Yeah, I agree weakdep is a better choice here. It solves the confusion of softdep which the depend module is optional. Thanks, I'm glad that you agree. But I prefer using weakdep directly instead of creating an aliasing of it which has no actual difference. Just checking, did you have a chance to read what I wrote in my earlier response on the linux-modules mailing list, [7] which includes a rather elaborate explanation of the intent behind MODULE_HARDDEP being currently just a proposed alias for MODULE_WEAKDEP? It also describes why using this alias might save use some time and effort in the future. [7] https://lore.kernel.org/linux-modules/0720a516416a92a8f683053d37ee9...@manjaro.org/ On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic wrote: Hello Qiang, On 2024-06-26 08:49, Dragan Simic wrote: > On 2024-06-26 03:11, Qiang Yu wrote: >> On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic >> wrote: >>> Just checking, any further thoughts about this patch? >>> >> I'm OK with this as a temp workaround because it's simple and do no >> harm >> even it's not perfect. If no other better suggestion for short term, >> I'll submit >> this at weekend. > > Thanks. Just as you described it, it's far from perfect, but it's > still > fine until there's a better solution, such as harddeps. I'll continue > my > research about the possibility for adding harddeps, which would > hopefully > replace quite a few instances of the softdep (ab)use. Another option has become available for expressing additional module dependencies, weakdeps. [1][2] Long story short, weakdeps are similar to softdeps, in the sense of telling the initial ramdisk utilities to include additional kernel modules, but weakdeps result in no module loading being performed by userspace. Maybe "weak" isn't the best possible word choice (arguably, "soft" also wasn't the best word choice), but weakdeps should be a better choice for use with Lima and governor_simpleondemand, because weakdeps provide the required information to the utilities used to generate initial ramdisk, while the actual module loading is left to the kernel. The recent addition of weakdeps renders the previously mentioned harddeps obsolete, because weakdeps actually do what we need. Obviously, "weak" doesn't go along very well with the actual nature of the dependency between Lima and governor_simpleondemand, but it's pretty much just the somewhat unfortunate word choice. The support for weakdeps has been already added to the kmod [3][4] and Dracut [5] userspace utilities. I'll hopefully add support for weakdeps to mkinitcpio [6] rather soon. Maybe we could actually add MODULE_HARDDEP() as some kind of syntactic sugar, which would currently be an alias for MODULE_WEAKDEP(), so the actual hard module dependencies could be expressed properly, and possibly handled differently in the future, with no need to go back and track all such instances of hard module dependencies. With all this in mind, here's what I'm going to do: 1) Submit a patch that adds MODULE_HARDDEP() as syntactic sugar 2) Implement support for weakdeps in Arch Linux's mkinitcpio [6] 3) Depending on what kind of feedback the MODULE_HARDDEP() patch receives, I'll submit follow-up patches for Lima and Panfrost, which will swap uses of MODULE_SOFTDEP() with MODULE_HARDDEP() or MODULE_WEAKDEP() Looking forward to your thoughts. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/module.h?id=61842868de13aa7fd7391c626e889f4d6f1450bf [2] https://lore.kernel.org/linux-kernel/20240724102349.430078-1-jtorn...@redhat.com/T/#u [3] https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7 [4] https://github.com/kmod-project/kmod/commit/d06712b51404061eef92cb275b8303814fca86ec [5] https://github.com/dracut-ng/dracut-ng/commit/8517a6be5e20f4a6d87e55fce35ee3e29e2a1150 [6] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio
Re: [Linux-stm32] [PATCH RESEND v3 0/3] Update STM DSI PHY driver
On 7/22/24 10:38, Yanjun Yang wrote: On Fri, Jun 28, 2024 at 8:47 PM Philippe CORNU wrote: On 1/29/24 11:41, Raphael Gallais-Pou wrote: This patch series aims to add several features of the dw-mipi-dsi phy driver that are missing or need to be updated. First patch update a PM macro. Second patch adds runtime PM functionality to the driver. Third patch adds a clock provider generated by the PHY itself. As explained in the commit log of the second patch, a clock declaration is missing. Since this clock is parent of 'dsi_k', it leads to an orphan clock. Most importantly this patch is an anticipation for future versions of the DSI PHY, and its inclusion within the display subsystem and the DRM framework. Last patch fixes a corner effect introduced previously. Since 'dsi' and 'dsi_k' are gated by the same bit on the same register, both reference work as peripheral clock in the device-tree. This patch (commit id:185f99b614427360) seems to break the dsi of stm32f469 chip. I'm not familiar with the drm and the clock framework, maybe it's because there is no "ck_dsi_phy" defined for stm32f469. PS: Sorry for receiving multiple copies of this email, I forgot to use plain text mode last time. Hi, Thank you for letting us know that there was this error. We should have detected this before merging, really sorry for the problems caused by this patch. We will investigate the issue and get back to you as soon as possible. In the meantime, I think you can revert this patch in your git tree. Philippe :-) --- Changes in v3-resend: - Removed last patch as it has been merged https://lore.kernel.org/lkml/bf49f4c9-9e81-4c91-972d-13782d996...@foss.st.com/ Changes in v3: - Fix smatch warning (disable dsi->pclk when clk_register fails) Changes in v2: - Added patch 1/4 to use SYSTEM_SLEEP_PM_OPS instead of old macro and removed __maybe_used for accordingly - Changed SET_RUNTIME_PM_OPS to RUNTIME_PM_OPS Raphael Gallais-Pou (3): drm/stm: dsi: use new SYSTEM_SLEEP_PM_OPS() macro drm/stm: dsi: expose DSI PHY internal clock Yannick Fertre (1): drm/stm: dsi: add pm runtime ops drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 279 ++ 1 file changed, 238 insertions(+), 41 deletions(-) Hi Raphaël & Yannick, Applied on drm-misc-next. Many thanks, Philippe :-) ___ Linux-stm32 mailing list linux-st...@st-md-mailman.stormreply.com https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
[PATCH] drm/sched: add optional errno to drm_sched_start()
The current implementation of drm_sched_start uses a hardcoded
-ECANCELED to dispose of a job when the parent/hw fence is NULL.
This results in drm_sched_job_done being called with -ECANCELED for
each job with a NULL parent in the pending list, making it difficult
to distinguish between recovery methods, whether a queue reset or a
full GPU reset was used.
To improve this, we first try a soft recovery for timeout jobs and
use the error code -ENODATA. If soft recovery fails, we proceed with
a queue reset, where the error code remains -ENODATA for the job.
Finally, for a full GPU reset, we use error codes -ECANCELED or
-ETIME. This patch adds an error code parameter to drm_sched_start,
allowing us to differentiate between queue reset and GPU reset
failures. This enables user mode and test applications to validate
the expected correctness of the requested operation. After a
successful queue reset, the only way to continue normal operation is
to call drm_sched_job_done with the specific error code -ENODATA.
v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain
and amdgpu_device_unlock_reset_domain to allow user mode to track
the queue reset status and distinguish between queue reset and
GPU reset.
v2: Christian suggested using the error codes -ENODATA for queue reset
and -ECANCELED or -ETIME for GPU reset, returned to
amdgpu_cs_wait_ioctl.
v3: To meet the requirements, we introduce a new function
drm_sched_start_ex with an additional parameter to set
dma_fence_set_error, allowing us to handle the specific error
codes appropriately and dispose of bad jobs with the selected
error code depending on whether it was a queue reset or GPU reset.
v4: Alex suggested using a new name, drm_sched_start_with_recovery_error,
which more accurately describes the function's purpose.
Additionally, it was recommended to add documentation details
about the new method.
v5: Fixed declaration of new function drm_sched_start_with_recovery_error.(Alex)
v6 (chk): rebase on upstream changes, cleanup the commit message,
drop the new function again and update all callers,
apply the errno also to scheduler fences with hw fences
Signed-off-by: Jesse Zhang
Signed-off-by: Vitaly Prosyak
Signed-off-by: Christian König
Cc: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 4 ++--
drivers/gpu/drm/imagination/pvr_queue.c | 4 ++--
drivers/gpu/drm/lima/lima_sched.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sched.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 7 ---
drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
include/drm/gpu_scheduler.h | 2 +-
11 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index 2320df51c914..18135d8235f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -300,7 +300,7 @@ static int suspend_resume_compute_scheduler(struct
amdgpu_device *adev, bool sus
if (r)
goto out;
} else {
- drm_sched_start(>sched);
+ drm_sched_start(>sched, 0);
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c186fdb198ad..861827deb03f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -5862,7 +5862,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
if (!amdgpu_ring_sched_ready(ring))
continue;
- drm_sched_start(>sched);
+ drm_sched_start(>sched, 0);
}
if (!drm_drv_uses_atomic_modeset(adev_to_drm(tmp_adev)) &&
!job_signaled)
@@ -6360,7 +6360,7 @@ void amdgpu_pci_resume(struct pci_dev *pdev)
if (!amdgpu_ring_sched_ready(ring))
continue;
- drm_sched_start(>sched);
+ drm_sched_start(>sched, 0);
}
amdgpu_device_unset_mp1_state(adev);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index c53641aa146f..2c8666f8ec4a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -72,12 +72,12 @@ static enum drm_gpu_sched_stat
etnaviv_sched_timedout_job(struct drm_sched_job
drm_sched_resubmit_jobs(>sche
[PATCH] staging: fbtft: Remove ftrace-like logging
Adhere to Linux kernel coding style
Reported by checkpatch:
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
Signed-off-by: Riyan Dhiman
---
drivers/staging/fbtft/fb_ili9320.c | 2 --
drivers/staging/fbtft/fb_ra8875.c | 7 ---
drivers/staging/fbtft/fb_sh1106.c | 3 ---
drivers/staging/fbtft/fb_ssd1289.c | 3 ---
drivers/staging/fbtft/fb_ssd1306.c | 3 ---
drivers/staging/fbtft/fb_ssd1325.c | 9 -
drivers/staging/fbtft/fb_ssd1331.c | 2 --
drivers/staging/fbtft/fb_ssd1351.c | 3 ---
drivers/staging/fbtft/fb_uc1611.c | 3 ---
drivers/staging/fbtft/fbtft-bus.c | 9 -
drivers/staging/fbtft/fbtft-core.c | 7 ---
drivers/staging/fbtft/fbtft-sysfs.c | 4
12 files changed, 55 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ili9320.c
b/drivers/staging/fbtft/fb_ili9320.c
index 0be7c2d51548..050fc2367c12 100644
--- a/drivers/staging/fbtft/fb_ili9320.c
+++ b/drivers/staging/fbtft/fb_ili9320.c
@@ -35,8 +35,6 @@ static int init_display(struct fbtft_par *par)
par->fbtftops.reset(par);
devcode = read_devicecode(par);
- fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code: 0x%04X\n",
- devcode);
if ((devcode != 0x) && (devcode != 0x9320))
dev_warn(par->info->device,
"Unrecognized Device code: 0x%04X (expected 0x9320)\n",
diff --git a/drivers/staging/fbtft/fb_ra8875.c
b/drivers/staging/fbtft/fb_ra8875.c
index 398bdbf53c9a..0ab1de6647d0 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -41,13 +41,6 @@ static int init_display(struct fbtft_par *par)
{
gpiod_set_value(par->gpio.dc, 1);
- fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
- "%s()\n", __func__);
- fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
- "display size %dx%d\n",
- par->info->var.xres,
- par->info->var.yres);
-
par->fbtftops.reset(par);
if ((par->info->var.xres == 320) && (par->info->var.yres == 240)) {
diff --git a/drivers/staging/fbtft/fb_sh1106.c
b/drivers/staging/fbtft/fb_sh1106.c
index 9685ca516a0e..e4c50c1ffed0 100644
--- a/drivers/staging/fbtft/fb_sh1106.c
+++ b/drivers/staging/fbtft/fb_sh1106.c
@@ -88,9 +88,6 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
ys, int xe, int ye)
static int blank(struct fbtft_par *par, bool on)
{
- fbtft_par_dbg(DEBUG_BLANK, par, "(%s=%s)\n",
- __func__, on ? "true" : "false");
-
write_reg(par, on ? 0xAE : 0xAF);
return 0;
diff --git a/drivers/staging/fbtft/fb_ssd1289.c
b/drivers/staging/fbtft/fb_ssd1289.c
index f27bab38b3ec..255a6d21ca8e 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -93,9 +93,6 @@ static int set_var(struct fbtft_par *par)
{
if (par->fbtftops.init_display != init_display) {
/* don't risk messing up register 11h */
- fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
- "%s: skipping since custom init_display() is
used\n",
- __func__);
return 0;
}
diff --git a/drivers/staging/fbtft/fb_ssd1306.c
b/drivers/staging/fbtft/fb_ssd1306.c
index 6cf9df579e88..478d710469b9 100644
--- a/drivers/staging/fbtft/fb_ssd1306.c
+++ b/drivers/staging/fbtft/fb_ssd1306.c
@@ -148,9 +148,6 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
ys, int xe, int ye)
static int blank(struct fbtft_par *par, bool on)
{
- fbtft_par_dbg(DEBUG_BLANK, par, "(%s=%s)\n",
- __func__, on ? "true" : "false");
-
if (on)
write_reg(par, 0xAE);
else
diff --git a/drivers/staging/fbtft/fb_ssd1325.c
b/drivers/staging/fbtft/fb_ssd1325.c
index 796a2ac3e194..256b0b87a930 100644
--- a/drivers/staging/fbtft/fb_ssd1325.c
+++ b/drivers/staging/fbtft/fb_ssd1325.c
@@ -72,10 +72,6 @@ static uint8_t rgb565_to_g16(u16 pixel)
static void set_addr_win(struct fbtft_par *par, int xs, int ys, int xe, int ye)
{
- fbtft_par_dbg(DEBUG_SET_ADDR_WIN, par,
- "%s(xs=%d, ys=%d, xe=%d, ye=%d)\n", __func__, xs, ys, xe,
- ye);
-
write_reg(par, 0x75);
write_reg(par, 0x00);
write_reg(par, 0x3f);
@@ -86,9 +82,6 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
ys, int xe, int ye)
static int blank(struct fbtft_par *par, bool on)
{
- fbtft_par_dbg(DEBUG_BLANK, par, "(%s=%s)\n",
- __func__, on ? "true" : "false");
-
if (on)
write_reg(par, 0xAE);
else
@@ -109,8 +102,6 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
{
int i;
- fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "%s()\n", __func__);
-
for (i = 0; i < GAMMA_LEN; i++) {
if (i > 0 && curves[i] < 1) {
dev_err(par->info->device,
diff
Re: [PATCH v3] rockchip/drm: vop2: add support for gamma LUT
On Thursday, July 25th, 2024 at 12:28 PM, Daniel Stone
wrote:
> Hi Piotr,
Hi, Daniel!
Thank you for the review.
>
> In the atomic_enable callback, we are already holding the VOP lock,
> and waiting to set cfg_done etc - we then do it all over again here.
> This should all be atomic, so that we configure the LUT whilst doing
> the setup, and then only call cfg_done once, to avoid showing the user
> intermediate states which only later converge on the desired final
> state.
>
I based my patch on how gamma LUT is handled in VOP. There, in atomic
enable, gamma LUT write takes places at the end too, after the mutex was
already first-time unlocked. I understand the concept of DRM atomic state
updates and what you wrote makes sense.
Below is what I came up with to make it fulfill atomicity requirement.
Frankly, the code ended up simpler. I tested it on RK3566 (Pinetab2).
Let me know what do you think.
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 37fcf544a5fd..cba92239dcbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1497,22 +1497,6 @@ static bool vop2_vp_dsp_lut_is_enabled(struct
vop2_video_port *vp)
0;
}
-static void vop2_vp_dsp_lut_enable(struct vop2_video_port *vp)
-{
- u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
-
- dsp_ctrl |= RK3568_VP_DSP_CTRL__DSP_LUT_EN;
- vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
-}
-
-static void vop2_vp_dsp_lut_disable(struct vop2_video_port *vp)
-{
- u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);
-
- dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
- vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
-}
-
static void vop2_crtc_write_gamma_lut(struct vop2 *vop2, struct drm_crtc *crtc)
{
const struct vop2_video_port *vp = to_vop2_video_port(crtc);
@@ -1532,11 +1516,12 @@ static void vop2_crtc_write_gamma_lut(struct vop2
*vop2, struct drm_crtc *crtc)
}
static void vop2_crtc_gamma_set(struct vop2 *vop2, struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_crtc_state *old_state,
+ u32* dsp_ctrl)
{
struct drm_crtc_state *state = crtc->state;
struct vop2_video_port *vp = to_vop2_video_port(crtc);
- u32 dsp_ctrl;
+ u32 _dsp_ctrl;
int ret;
if (!vop2->lut_regs)
@@ -1547,37 +1532,27 @@ static void vop2_crtc_gamma_set(struct vop2 *vop2,
struct drm_crtc *crtc,
* To disable gamma (gamma_lut is null) or to write
* an update to the LUT, clear dsp_lut_en.
*/
- vop2_lock(vop2);
-
- vop2_vp_dsp_lut_disable(vp);
-
- vop2_cfg_done(vp);
- vop2_unlock(vop2);
- /*
-* In order to write the LUT to the internal memory,
-* we need to first make sure the dsp_lut_en bit is cleared.
-*/
- ret = readx_poll_timeout(vop2_vp_dsp_lut_is_enabled, vp,
dsp_ctrl,
- !dsp_ctrl, 5, 30 * 1000);
-
- if (ret) {
- DRM_DEV_ERROR(vop2->dev, "display LUT RAM enable
timeout!\n");
- return;
- }
+ *dsp_ctrl &= ~RK3568_VP_DSP_CTRL__DSP_LUT_EN;
if (!state->gamma_lut)
return;
}
+ /*
+* In order to write the LUT to the internal memory,
+* we need to first make sure the dsp_lut_en bit is cleared.
+*/
+ ret = readx_poll_timeout(vop2_vp_dsp_lut_is_enabled, vp, _dsp_ctrl,
+ !_dsp_ctrl, 5, 30 * 1000);
+ if (ret) {
+ DRM_DEV_ERROR(vop2->dev, "display LUT RAM enable timeout!\n");
+ return;
+ }
- vop2_lock(vop2);
vop2_crtc_write_gamma_lut(vop2, crtc);
vop2_writel(vp->vop2, RK3568_LUT_PORT_SEL, vp->id);
- vop2_vp_dsp_lut_enable(vp);
-
- vop2_cfg_done(vp);
- vop2_unlock(vop2);
+ *dsp_ctrl |= RK3568_VP_DSP_CTRL__DSP_LUT_EN;
}
static void vop2_dither_setup(struct drm_crtc *crtc, u32 *dsp_ctrl)
@@ -2152,6 +2127,9 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
vop2_post_config(crtc);
+ if (crtc->state->gamma_lut)
+ vop2_crtc_gamma_set(vop2, crtc, old_state, _ctrl);
+
vop2_cfg_done(vp);
vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
@@ -2160,8 +2138,6 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
vop2_unlock(vop2);
- if (crtc->state->gamma_lut)
- vop2_crtc_gamma_set(vop2, crtc, old_state);
}
static int vop2_crtc_atomic_check(struct drm_crtc *crtc,
@@ -2599,8 +2575,17
Re: [PATCH v8 5/5] drm/ci: rockchip: add tests for rockchip display driver
Hi Vignesh, On Wed, 24 Jul 2024 at 11:12, Vignesh Raman wrote: > For rockchip rk3288 and rk3399, the display driver is rockchip > and gpu driver is panfrost. Currently, in drm-ci for rockchip > rk3288 and rk3399, only the gpu driver is tested. Refactor > the existing rockchip jobs to test both display and gpu driver > and update xfails. Could you also please add RK3588 in a new series (no need to hold this one up), with Rockchip KMS and Panthor GPU? You can use the rk3588-rock5-b device type in LAVA. > diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt > b/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt > index cf3a747f7cec..826cca5efbff 100644 > --- a/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt > +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8183-fails.txt This is in the wrong patch? > +++ b/drivers/gpu/drm/ci/xfails/panfrost-rk3288-skips.txt > @@ -0,0 +1,71 @@ > +# Suspend to RAM seems to be broken on this machine > +.*suspend.* > + > +# Too unstable, machine ends up hanging after lots of Oopses > +kms_cursor_legacy.* > + > +# Started hanging the machine on Linux 5.19-rc2: > +# > +# [IGT] kms_plane_lowres: executing > +# [IGT] kms_plane_lowres: starting subtest pipe-F-tiling-y > +# [IGT] kms_plane_lowres: exiting, ret=77 ret 77 is a pure skip here, as you'd expect from a pipe F test, because Rockchip doesn't have six CRTCs. > +# Console: switching to colour frame buffer device 170x48 > +# rockchip-drm display-subsystem: [drm] *ERROR* flip_done timed out > +# rockchip-drm display-subsystem: [drm] *ERROR* [CRTC:35:crtc-0] commit wait > timed out > +# BUG: spinlock bad magic on CPU#3, kms_plane_lowre/482 > +# 8<--- cut here --- > +# Unable to handle kernel paging request at virtual address 7812078e > +# [7812078e] *pgd= > +# Internal error: Oops: 5 [#1] SMP ARM > +# Modules linked in: > +# CPU: 3 PID: 482 Comm: kms_plane_lowre Tainted: GW > 5.19.0-rc2-323596-g00535de92171 #1 > +# Hardware name: Rockchip (Device Tree) > +# Process kms_plane_lowre (pid: 482, stack limit = 0x1193ac2b) > +# spin_dump from do_raw_spin_lock+0xa4/0xe8 > +# do_raw_spin_lock from wait_for_completion_timeout+0x2c/0x120 > +# wait_for_completion_timeout from drm_crtc_commit_wait+0x18/0x7c > +# drm_crtc_commit_wait from > drm_atomic_helper_wait_for_dependencies+0x44/0x168 > +# drm_atomic_helper_wait_for_dependencies from commit_tail+0x34/0x180 > +# commit_tail from drm_atomic_helper_commit+0x164/0x18c > +# drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe4 > +# drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x284 > +# drm_client_modeset_commit_atomic from > drm_client_modeset_commit_locked+0x60/0x1c8 > +# drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40 > +# drm_client_modeset_commit from drm_fbdev_client_restore+0x58/0x94 > +# drm_fbdev_client_restore from drm_client_dev_restore+0x70/0xbc > +# drm_client_dev_restore from drm_release+0xf4/0x114 > +# drm_release from __fput+0x74/0x240 > +# __fput from task_work_run+0x84/0xb4 > +# task_work_run from do_exit+0x34c/0xa20 > +# do_exit from do_group_exit+0x34/0x98 So this is pointing to the error being that, when a client exits, the kernel attempts to restore fbdev and then it's broken. Pinning pipe-F-tiling-y as specifically responsible for this seems quite odd to me, given that it doesn't do anything but only skips. Is that maybe just because it's the last test running in the kms_plane_lowres group before it exits? Or does it occur more wildly on other test groups? > +tools_test@tools_test,Fail I keep noticing this failing everywhere. What's up with that? Have you reported these logs to the igt list? Cheers, Daniel
Re: [PATCH v8 2/5] drm/ci: mediatek: add tests for mediatek display driver
Hi Vignesh, On Wed, 24 Jul 2024 at 11:11, Vignesh Raman wrote: > +dumb_buffer@create-clear,Fail > +dumb_buffer@create-valid-dumb,Fail > +dumb_buffer@invalid-bpp,Fail > +dumb_buffer@map-invalid-size,Fail > +dumb_buffer@map-uaf,Fail > +dumb_buffer@map-valid,Fail > +fbdev@eof,Fail > +fbdev@read,Fail > +fbdev@unaligned-read,Fail Please skip dumb_buffer and fbdev tests for all GPU-only drivers, because those are testing display functionality. Cheers, Daniel
Re: [PATCH] drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
I strongly suggest to revert that again. See my other mail.
Christian.
Am 25.07.24 um 22:59 schrieb Alex Deucher:
Applied. Thanks!
Alex
On Thu, Jul 25, 2024 at 2:20 PM Nikita Zhandarovich
wrote:
Several cs track offsets (such as 'track->db_s_read_offset')
either are initialized with or plainly take big enough values that,
once shifted 8 bits left, may be hit with integer overflow if the
resulting values end up going over u32 limit.
Some debug prints take this into account (see according dev_warn() in
evergreen_cs_track_validate_stencil()), even if the actual
calculated value assigned to local 'offset' variable is missing
similar proper expansion.
Mitigate the problem by casting the type of right operands to the
wider type of corresponding left ones in all such cases.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling informations
v11")
Cc: sta...@vger.kernel.org
Signed-off-by: Nikita Zhandarovich
---
P.S. While I am not certain that track->cb_color_bo_offset[id]
actually ends up taking values high enough to cause an overflow,
nonetheless I thought it prudent to cast it to ulong as well.
drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 1fe6e0d883c7..d734d221e2da 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -433,7 +433,7 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
return r;
}
- offset = track->cb_color_bo_offset[id] << 8;
+ offset = (unsigned long)track->cb_color_bo_offset[id] << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d cb[%d] bo base %ld not aligned with
%ld\n",
__func__, __LINE__, id, offset, surf.base_align);
@@ -455,7 +455,7 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
min = surf.nby - 8;
}
bsize = radeon_bo_size(track->cb_color_bo[id]);
- tmp = track->cb_color_bo_offset[id] << 8;
+ tmp = (unsigned long)track->cb_color_bo_offset[id] << 8;
for (nby = surf.nby; nby > min; nby--) {
size = nby * surf.nbx * surf.bpe *
surf.nsamples;
if ((tmp + size * mslice) <= bsize) {
@@ -476,10 +476,10 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
}
}
dev_warn(p->dev, "%s:%d cb[%d] bo too small (layer size %d, "
-"offset %d, max layer %d, bo size %ld, slice %d)\n",
+"offset %ld, max layer %d, bo size %ld, slice %d)\n",
__func__, __LINE__, id, surf.layer_size,
- track->cb_color_bo_offset[id] << 8, mslice,
- radeon_bo_size(track->cb_color_bo[id]), slice);
+ (unsigned long)track->cb_color_bo_offset[id] << 8,
+ mslice, radeon_bo_size(track->cb_color_bo[id]), slice);
dev_warn(p->dev, "%s:%d problematic surf: (%d %d) (%d %d %d %d %d
%d %d)\n",
__func__, __LINE__, surf.nbx, surf.nby,
surf.mode, surf.bpe, surf.nsamples,
@@ -608,7 +608,7 @@ static int evergreen_cs_track_validate_stencil(struct
radeon_cs_parser *p)
return r;
}
- offset = track->db_s_read_offset << 8;
+ offset = (unsigned long)track->db_s_read_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned with
%ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -627,7 +627,7 @@ static int evergreen_cs_track_validate_stencil(struct
radeon_cs_parser *p)
return -EINVAL;
}
- offset = track->db_s_write_offset << 8;
+ offset = (unsigned long)track->db_s_write_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil write bo base %ld not aligned with
%ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -706,7 +706,7 @@ static int evergreen_cs_track_validate_depth(struct
radeon_cs_parser *p)
return r;
}
- offset = track->db_z_read_offset << 8;
+ offset = (unsigned long)track->db_z_read_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned with
%ld\n",
__func__, __LINE__, offset, surf.base_align);
Re: [PATCH] drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
Am 25.07.24 um 20:09 schrieb Nikita Zhandarovich:
Several cs track offsets (such as 'track->db_s_read_offset')
either are initialized with or plainly take big enough values that,
once shifted 8 bits left, may be hit with integer overflow if the
resulting values end up going over u32 limit.
Some debug prints take this into account (see according dev_warn() in
evergreen_cs_track_validate_stencil()), even if the actual
calculated value assigned to local 'offset' variable is missing
similar proper expansion.
Mitigate the problem by casting the type of right operands to the
wider type of corresponding left ones in all such cases.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling informations
v11")
Cc: sta...@vger.kernel.org
Well first of all the long cast doesn't makes the value 64bit, it
depends on the architecture.
Then IIRC the underlying hw can only handle a 32bit address space so
having the offset as long is incorrect to begin with.
And finally that is absolutely not material for stable.
Regards,
Christian.
Signed-off-by: Nikita Zhandarovich
---
P.S. While I am not certain that track->cb_color_bo_offset[id]
actually ends up taking values high enough to cause an overflow,
nonetheless I thought it prudent to cast it to ulong as well.
drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 1fe6e0d883c7..d734d221e2da 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -433,7 +433,7 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
return r;
}
- offset = track->cb_color_bo_offset[id] << 8;
+ offset = (unsigned long)track->cb_color_bo_offset[id] << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d cb[%d] bo base %ld not aligned with
%ld\n",
__func__, __LINE__, id, offset, surf.base_align);
@@ -455,7 +455,7 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
min = surf.nby - 8;
}
bsize = radeon_bo_size(track->cb_color_bo[id]);
- tmp = track->cb_color_bo_offset[id] << 8;
+ tmp = (unsigned long)track->cb_color_bo_offset[id] << 8;
for (nby = surf.nby; nby > min; nby--) {
size = nby * surf.nbx * surf.bpe *
surf.nsamples;
if ((tmp + size * mslice) <= bsize) {
@@ -476,10 +476,10 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
}
}
dev_warn(p->dev, "%s:%d cb[%d] bo too small (layer size %d, "
-"offset %d, max layer %d, bo size %ld, slice %d)\n",
+"offset %ld, max layer %d, bo size %ld, slice %d)\n",
__func__, __LINE__, id, surf.layer_size,
- track->cb_color_bo_offset[id] << 8, mslice,
- radeon_bo_size(track->cb_color_bo[id]), slice);
+ (unsigned long)track->cb_color_bo_offset[id] << 8,
+ mslice, radeon_bo_size(track->cb_color_bo[id]), slice);
dev_warn(p->dev, "%s:%d problematic surf: (%d %d) (%d %d %d %d %d %d
%d)\n",
__func__, __LINE__, surf.nbx, surf.nby,
surf.mode, surf.bpe, surf.nsamples,
@@ -608,7 +608,7 @@ static int evergreen_cs_track_validate_stencil(struct
radeon_cs_parser *p)
return r;
}
- offset = track->db_s_read_offset << 8;
+ offset = (unsigned long)track->db_s_read_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned with
%ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -627,7 +627,7 @@ static int evergreen_cs_track_validate_stencil(struct
radeon_cs_parser *p)
return -EINVAL;
}
- offset = track->db_s_write_offset << 8;
+ offset = (unsigned long)track->db_s_write_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil write bo base %ld not aligned with
%ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -706,7 +706,7 @@ static int evergreen_cs_track_validate_depth(struct
radeon_cs_parser *p)
return r;
}
- offset = track->db_z_read_offset << 8;
+ offset = (unsigned long)track->db_z_read_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil read bo
[RFC PATCH] ARM: dts: imx53-qsb: Add MCIMX-LVDS1 display module support
MCIMX-LVDS1[1] display module integrates a HannStar HSD100PXN1 LVDS
display panel and a touch IC. Add an overlay to support the LVDS
panel on i.MX53 QSB / QSRB platforms.
[1] https://www.nxp.com/part/MCIMX-LVDS1
Signed-off-by: Liu Ying
---
I mark RFC in patch subject prefix because if the DT overlay is used, both ldb
and panel devices end up as devices deferred. However, if the DT overlay is
not used and the devices are defined in imx53-qsb-common.dtsi, then they can be
probed ok.
With a dev_err_probe() added to imx_ldb_probe() in imx-ldb.c, devices_deferred
indicates 53fa8008.ldb and panel-lvds kind of depend on each other.
root@imx53qsb:~# cat /sys/kernel/debug/devices_deferred
53fa8008.ldbimx-ldb: failed to find panel or bridge for channel0
panel-lvds platform: wait for supplier
/soc/bus@5000/ldb@53fa8008/lvds-channel@0
It looks like the issue is related to fw_devlink, because if "fw_devlink=off"
is added to kernel bootup command line, then the issue doesn't happen.
Saravana, DT folks, any ideas?
Thanks.
arch/arm/boot/dts/nxp/imx/Makefile| 4 ++
.../boot/dts/nxp/imx/imx53-qsb-common.dtsi| 4 +-
.../dts/nxp/imx/imx53-qsb-mcimx-lvds1.dtso| 43 +++
3 files changed, 49 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/nxp/imx/imx53-qsb-mcimx-lvds1.dtso
diff --git a/arch/arm/boot/dts/nxp/imx/Makefile
b/arch/arm/boot/dts/nxp/imx/Makefile
index 92e291603ea1..7116889e1515 100644
--- a/arch/arm/boot/dts/nxp/imx/Makefile
+++ b/arch/arm/boot/dts/nxp/imx/Makefile
@@ -46,8 +46,10 @@ dtb-$(CONFIG_SOC_IMX53) += \
imx53-ppd.dtb \
imx53-qsb.dtb \
imx53-qsb-hdmi.dtb \
+ imx53-qsb-mcimx-lvds1.dtb \
imx53-qsrb.dtb \
imx53-qsrb-hdmi.dtb \
+ imx53-qsrb-mcimx-lvds1.dtb \
imx53-sk-imx53.dtb \
imx53-sk-imx53-atm0700d4-lvds.dtb \
imx53-sk-imx53-atm0700d4-rgb.dtb \
@@ -57,7 +59,9 @@ dtb-$(CONFIG_SOC_IMX53) += \
imx53-usbarmory.dtb \
imx53-voipac-bsb.dtb
imx53-qsb-hdmi-dtbs := imx53-qsb.dtb imx53-qsb-hdmi.dtbo
+imx53-qsb-mcimx-lvds1-dtbs := imx53-qsb.dtb imx53-qsb-mcimx-lvds1.dtbo
imx53-qsrb-hdmi-dtbs := imx53-qsrb.dtb imx53-qsb-hdmi.dtbo
+imx53-qsrb-mcimx-lvds1-dtbs := imx53-qsrb.dtb imx53-qsb-mcimx-lvds1.dtbo
dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-alti6p.dtb \
imx6dl-apf6dev.dtb \
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
index 05d7a462ea25..430792a91ccf 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
@@ -16,7 +16,7 @@ memory@7000 {
<0xb000 0x2000>;
};
- backlight_parallel: backlight-parallel {
+ backlight: backlight {
compatible = "pwm-backlight";
pwms = < 0 500 0>;
brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -89,7 +89,7 @@ panel_dpi: panel {
compatible = "sii,43wvf1g";
pinctrl-names = "default";
pinctrl-0 = <_display_power>;
- backlight = <_parallel>;
+ backlight = <>;
enable-gpios = < 24 GPIO_ACTIVE_HIGH>;
port {
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-qsb-mcimx-lvds1.dtso
b/arch/arm/boot/dts/nxp/imx/imx53-qsb-mcimx-lvds1.dtso
new file mode 100644
index ..27f6bedf3d39
--- /dev/null
+++ b/arch/arm/boot/dts/nxp/imx/imx53-qsb-mcimx-lvds1.dtso
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ panel-lvds {
+ compatible = "hannstar,hsd100pxn1";
+ backlight = <>;
+ power-supply = <_3p2v>;
+
+ port {
+ panel_lvds_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ lvds-channel@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <18>;
+ status = "okay";
+
+ port@2 {
+ reg = <2>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <_lvds_in>;
+ };
+ };
+ };
+};
--
2.34.1
Re: [PATCH v2] misc: fastrpc: Add support for multiple PD from one process
On 7/22/2024 1:48 PM, Dmitry Baryshkov wrote:
> On Sat, Jul 20, 2024 at 09:16:11AM GMT, Ekansh Gupta wrote:
>> Memory intensive applications(which requires more tha 4GB) that wants
>> to offload tasks to DSP might have to split the tasks to multiple
>> user PD to make the resources available.
>>
>> For every call to DSP, fastrpc driver passes the process tgid which
>> works as an identifier for the DSP to enqueue the tasks to specific PD.
>> With current design, if any process opens device node more than once
>> and makes PD initmrequest, same tgid will be passed to DSP which will
>> be considered a bad request and this will result in failure as the same
>> identifier cannot be used for multiple DSP PD.
>>
>> Allocate and pass an effective pgid to DSP which would be allocated
> effective pgid makes me think about the setegid() system call. Can we
> just name them "client ID" (granted that session is already reserved)?
> Or is it really session ID? Can we use the index of the session instead
> and skip the whole IDR allocation?
Thanks for the suggestion, I'm trying out experiments with the index of session
as
client ID to avoid idr operations. This sounds much better. I will update the
patch
soon.
--Ekansh
>> during device open and will have a lifetime till the device is closed.
>> This will allow the same process to open the device more than once and
>> spawn multiple dynamic PD for ease of processing.
>>
>> Signed-off-by: Ekansh Gupta
>> ---
>> Changes in v2:
>> - Reformatted commit text.
>> - Moved from ida to idr.
>> - Changed dsp_pgid data type.
>> - Resolved memory leak.
>>
>> drivers/misc/fastrpc.c | 49 +++---
>> 1 file changed, 37 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>> index a7a2bcedb37e..b4a5af2d2dfa 100644
>> --- a/drivers/misc/fastrpc.c
>> +++ b/drivers/misc/fastrpc.c
>> @@ -105,6 +105,10 @@
>>
>> #define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device,
>> miscdev)
>>
>> +#define MAX_DSP_PD 64 /* Maximum 64 PDs are allowed on DSP */
> Why?
>
>> +#define MIN_FRPC_PGID 1000
> Is it some random number or some pre-defined constant? Can we use 0
> instead?
>
>> +#define MAX_FRPC_PGID (MIN_FRPC_PGID + MAX_DSP_PD)
>> +
>> static const char *domains[FASTRPC_DEV_MAX] = { "adsp", "mdsp",
>> "sdsp", "cdsp"};
>> struct fastrpc_phy_page {
>
Re: [PATCH 0/2] Add driver for Sharp Memory LCD
Hello, On Thu, 25 Jul 2024 20:07:01 -0400 Alex Lanzano wrote: > What would be the best way to go about doing this? I'm guessing appending to > MODULE_AUTHOR and adding a Signed-of-by or Co-Developed-by? Depends on how much you've changed things compared to Mehdi's version. If you've mostly kept what Mehdi did, then I guess you should keep him as the author of the commits (i.e the Author: field of the git commit + the first Signed-off-by), and add your Signed-off-by underneath. If you've made very significant changes to the point where the code isn't really Mehdi's code anymore, but just inspired, then you should set yourself as the author (Author: field of the git commit + the first Signed-off-by), and credit Mehdi via a Co-developed-by: tag. In any case, thanks a lot for this pushing this work, much appreciated! Thomas -- Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com
Re: [PATCH] drm/lima: Mark simple_ondemand governor as softdep
Yeah, I agree weakdep is a better choice here. It solves the confusion of softdep which the depend module is optional. But I prefer using weakdep directly instead of creating an aliasing of it which has no actual difference. On Thu, Jul 25, 2024 at 4:21 PM Dragan Simic wrote: > > Hello Qiang, > > On 2024-06-26 08:49, Dragan Simic wrote: > > On 2024-06-26 03:11, Qiang Yu wrote: > >> On Wed, Jun 26, 2024 at 2:15 AM Dragan Simic > >> wrote: > >>> Just checking, any further thoughts about this patch? > >>> > >> I'm OK with this as a temp workaround because it's simple and do no > >> harm > >> even it's not perfect. If no other better suggestion for short term, > >> I'll submit > >> this at weekend. > > > > Thanks. Just as you described it, it's far from perfect, but it's > > still > > fine until there's a better solution, such as harddeps. I'll continue > > my > > research about the possibility for adding harddeps, which would > > hopefully > > replace quite a few instances of the softdep (ab)use. > > Another option has become available for expressing additional module > dependencies, weakdeps. [1][2] Long story short, weakdeps are similar > to softdeps, in the sense of telling the initial ramdisk utilities to > include additional kernel modules, but weakdeps result in no module > loading being performed by userspace. > > Maybe "weak" isn't the best possible word choice (arguably, "soft" also > wasn't the best word choice), but weakdeps should be a better choice for > use with Lima and governor_simpleondemand, because weakdeps provide the > required information to the utilities used to generate initial ramdisk, > while the actual module loading is left to the kernel. > > The recent addition of weakdeps renders the previously mentioned > harddeps > obsolete, because weakdeps actually do what we need. Obviously, "weak" > doesn't go along very well with the actual nature of the dependency > between > Lima and governor_simpleondemand, but it's pretty much just the somewhat > unfortunate word choice. > > The support for weakdeps has been already added to the kmod [3][4] and > Dracut [5] userspace utilities. I'll hopefully add support for weakdeps > to mkinitcpio [6] rather soon. > > Maybe we could actually add MODULE_HARDDEP() as some kind of syntactic > sugar, which would currently be an alias for MODULE_WEAKDEP(), so the > actual hard module dependencies could be expressed properly, and > possibly > handled differently in the future, with no need to go back and track all > such instances of hard module dependencies. > > With all this in mind, here's what I'm going to do: > > 1) Submit a patch that adds MODULE_HARDDEP() as syntactic sugar > 2) Implement support for weakdeps in Arch Linux's mkinitcpio [6] > 3) Depending on what kind of feedback the MODULE_HARDDEP() patch > receives, > I'll submit follow-up patches for Lima and Panfrost, which will swap > uses of MODULE_SOFTDEP() with MODULE_HARDDEP() or MODULE_WEAKDEP() > > Looking forward to your thoughts. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/module.h?id=61842868de13aa7fd7391c626e889f4d6f1450bf > [2] > https://lore.kernel.org/linux-kernel/20240724102349.430078-1-jtorn...@redhat.com/T/#u > [3] > https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7 > [4] > https://github.com/kmod-project/kmod/commit/d06712b51404061eef92cb275b8303814fca86ec > [5] > https://github.com/dracut-ng/dracut-ng/commit/8517a6be5e20f4a6d87e55fce35ee3e29e2a1150 > [6] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio > > > >>> On 2024-06-18 21:22, Dragan Simic wrote: > >>> > On 2024-06-18 12:33, Dragan Simic wrote: > >>> >> On 2024-06-18 10:13, Maxime Ripard wrote: > >>> >>> On Tue, Jun 18, 2024 at 04:01:26PM GMT, Qiang Yu wrote: > >>> >>>> On Tue, Jun 18, 2024 at 12:33 PM Qiang Yu wrote: > >>> >>>> > > >>> >>>> > I see the problem that initramfs need to build a module dependency > >>> >>>> > chain, > >>> >>>> > but lima does not call any symbol from simpleondemand governor > >>> >>>> > module. > >>> >>>> > softdep module seems to be optional while our dependency is hard > >>> >>>> > one, > >>> >>>> > can we just add MODULE_INFO(depends, _depends), or create a new > >>> >>>> > macro called MOD
Re: [PATCH 2/2] drm/tiny: Add driver for Sharp Memory LCD
On Thu, Jul 25, 2024 at 08:08:57AM GMT, Krzysztof Kozlowski wrote:
> On 25/07/2024 02:47, Alex Lanzano wrote:
> > +static const struct spi_device_id sharp_memory_ids[] = {
> > + {"ls010b7dh04", LS010B7DH04},
> > + {"ls011b7dh03", LS011B7DH03},
> > + {"ls012b7dd01", LS012B7DD01},
> > + {"ls013b7dh03", LS013B7DH03},
> > + {"ls013b7dh05", LS013B7DH05},
> > + {"ls018b7dh02", LS018B7DH02},
> > + {"ls027b7dh01", LS027B7DH01},
> > + {"ls027b7dh01a", LS027B7DH01A},
> > + {"ls032b7dd02", LS032B7DD02},
> > + {"ls044q7dh01", LS044Q7DH01},
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(spi, sharp_memory_ids);
> > +
> > +static const struct of_device_id sharp_memory_of_match[] = {
> > + {.compatible = "sharp,ls010b7dh04"},
>
> Both ID tables should be in sync. See not-so-recent IIO discussions and
> commits.
>
> > + {.compatible = "sharp,ls011b7dh03"},
> > + {.compatible = "sharp,ls012b7dd01"},
> > + {.compatible = "sharp,ls013b7dh03"},
> > + {.compatible = "sharp,ls013b7dh05"},
> > + {.compatible = "sharp,ls018b7dh02"},
> > + {.compatible = "sharp,ls027b7dh01"},
> > + {.compatible = "sharp,ls027b7dh01a"},
> > + {.compatible = "sharp,ls032b7dd02"},
> > + {.compatible = "sharp,ls044q7dh01"},
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, sharp_memory_of_match);
I'm having some trouble finding the discussions and commits you're referring to.
When you say the tables should be in sync are you referring to the ordering of
entries in the tables? Like at index x of both tables should define model y?
Best regards,
Alex
Re: [PATCH v1 1/2] drm/panel: jd9365da: Move the sending location of the 11/29 command
On Thu, Jul 25, 2024 at 4:41 PM Jani Nikula wrote:
>
> On Thu, 25 Jul 2024, Zhaoxiong Lv
> wrote:
> > Move the 11/29 command from enable() to init() function
>
> OOC, what is the "11/29" command?
>
> BR,
> Jani.
hi Jani
Sorry, maybe I didn't describe it clearly. The 11/29 commands are sent
by these two functions.
mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
mipi_dsi_dcs_set_display_on_multi(_ctx);
MIPI_DCS_EXIT_SLEEP_MODE = 0x11,
MIPI_DCS_SET_DISPLAY_ON= 0x29,
BR,
>
> >
> > As mentioned in the patch:
> > https://lore.kernel.org/all/20240624141926.5250-2-lvzhaoxi...@huaqin.corp-partner.google.com/
> >
> > Our DSI host has different modes in prepare() and enable()
> > functions. prepare() is in LP mode and enable() is in HS mode.
> > Since the 11/29 command must also be sent in LP mode,
> > so we also move 11/29 command to the init() function.
> >
> > After moving the 11/29 command to the init() function,
> > we no longer need additional delay judgment, so we delete
> > variables "exit_sleep_to_display_on_delay_ms" and
> > "display_on_delay_ms".
> >
> > Signed-off-by: Zhaoxiong Lv
> > ---
> > .../gpu/drm/panel/panel-jadard-jd9365da-h3.c | 59 ++-
> > 1 file changed, 32 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> > b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> > index 04d315d96bff..ce73e8cb1db5 100644
> > --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> > +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> > @@ -31,8 +31,6 @@ struct jadard_panel_desc {
> > bool reset_before_power_off_vcioo;
> > unsigned int vcioo_to_lp11_delay_ms;
> > unsigned int lp11_to_reset_delay_ms;
> > - unsigned int exit_sleep_to_display_on_delay_ms;
> > - unsigned int display_on_delay_ms;
> > unsigned int backlight_off_to_display_off_delay_ms;
> > unsigned int display_off_to_enter_sleep_delay_ms;
> > unsigned int enter_sleep_to_reset_down_delay_ms;
> > @@ -66,26 +64,6 @@ static inline struct jadard *panel_to_jadard(struct
> > drm_panel *panel)
> > return container_of(panel, struct jadard, panel);
> > }
> >
> > -static int jadard_enable(struct drm_panel *panel)
> > -{
> > - struct jadard *jadard = panel_to_jadard(panel);
> > - struct mipi_dsi_multi_context dsi_ctx = { .dsi = jadard->dsi };
> > -
> > - msleep(120);
> > -
> > - mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
> > -
> > - if (jadard->desc->exit_sleep_to_display_on_delay_ms)
> > - mipi_dsi_msleep(_ctx,
> > jadard->desc->exit_sleep_to_display_on_delay_ms);
> > -
> > - mipi_dsi_dcs_set_display_on_multi(_ctx);
> > -
> > - if (jadard->desc->display_on_delay_ms)
> > - mipi_dsi_msleep(_ctx, jadard->desc->display_on_delay_ms);
> > -
> > - return dsi_ctx.accum_err;
> > -}
> > -
> > static int jadard_disable(struct drm_panel *panel)
> > {
> > struct jadard *jadard = panel_to_jadard(panel);
> > @@ -202,7 +180,6 @@ static const struct drm_panel_funcs jadard_funcs = {
> > .disable = jadard_disable,
> > .unprepare = jadard_unprepare,
> > .prepare = jadard_prepare,
> > - .enable = jadard_enable,
> > .get_modes = jadard_get_modes,
> > .get_orientation = jadard_panel_get_orientation,
> > };
> > @@ -382,6 +359,12 @@ static int radxa_display_8hd_ad002_init_cmds(struct
> > jadard *jadard)
> >
> > jd9365da_switch_page(_ctx, 0x00);
> >
> > + mipi_dsi_msleep(_ctx, 120);
> > +
> > + mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
> > +
> > + mipi_dsi_dcs_set_display_on_multi(_ctx);
> > +
> > return dsi_ctx.accum_err;
> > };
> >
> > @@ -608,6 +591,12 @@ static int cz101b4001_init_cmds(struct jadard *jadard)
> > mipi_dsi_dcs_write_seq_multi(_ctx, 0xE6, 0x02);
> > mipi_dsi_dcs_write_seq_multi(_ctx, 0xE7, 0x0C);
> >
> > + mipi_dsi_msleep(_ctx, 120);
> > +
> > + mipi_dsi_dcs_exit_sleep_mode_multi(_ctx);
> > +
> > + mipi_dsi_dcs_set_display_on_multi(_ctx);
> > +
> > return dsi_ctx.accum_err;
> > };
> >
> > @@ -831,6 +820,16 @@ static int kingdisplay_kd101ne3_init_cmds(struct
> > jadard *jadard)
> >
> > jd9365da_switch_page(_ctx, 0x00);
> >
> > + mipi_dsi_msleep(_ctx, 120);
> > +
> > +
Re: [PATCH 1/2] dt-bindings: display: Add Sharp Memory LCD bindings
On Thu, Jul 25, 2024 at 08:18:44AM GMT, Krzysztof Kozlowski wrote: > On 25/07/2024 02:47, Alex Lanzano wrote: > > Add device tree bindings for the monochrome Sharp Memory LCD > > > > Signed-off-by: Alex Lanzano > > --- > > .../bindings/display/sharp,sharp-memory.yaml | 97 +++ > > include/dt-bindings/display/sharp-memory.h| 9 ++ > > 2 files changed, 106 insertions(+) > > BTW, look at your original binding: > https://lore.kernel.org/dri-devel/2a7c51b6e619c02ec175a5c219b0a0fd7a24499d.1701267411.git.mehdi.dj...@bootlin.com/ > > Why did you decide to introduce mistakes? Eg. dropping all $refs? > > And finally look at the comment: > https://lore.kernel.org/dri-devel/5dbdf7bd-cfa3-492b-a0a3-fdc323cf1...@linaro.org/ > You just ignored it completely > > Best regards, > Krzysztof > Will fix in V2. Best regards, Alex
Re: [PATCH 1/2] dt-bindings: display: Add Sharp Memory LCD bindings
Thank you for the review! I will address these comments in V2
On Thu, Jul 25, 2024 at 08:17:01AM GMT, Krzysztof Kozlowski wrote:
> On 25/07/2024 02:47, Alex Lanzano wrote:
> > Add device tree bindings for the monochrome Sharp Memory LCD
> >
> > Signed-off-by: Alex Lanzano
> > ---
> > .../bindings/display/sharp,sharp-memory.yaml | 97 +++
> > include/dt-bindings/display/sharp-memory.h| 9 ++
> > 2 files changed, 106 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/sharp,sharp-memory.yaml
> > create mode 100644 include/dt-bindings/display/sharp-memory.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/sharp,sharp-memory.yaml
> > b/Documentation/devicetree/bindings/display/sharp,sharp-memory.yaml
> > new file mode 100644
> > index ..a79edd97c857
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sharp,sharp-memory.yaml
>
> Filename based on compatible, so e.g. sharp,ls010b7dh04.yaml.
>
> > @@ -0,0 +1,97 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/sharp,sharp-memory.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Sharp Memory LCD panels
> > +
> > +maintainers:
> > + - Alex Lanzano
> > +
> > +description:
> > + This binding is for the Sharp Memory LCD monochrome displays.
>
> Do not say that binding is a binding... instead describe hardware.
>
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - sharp,ls010b7dh04
> > + - sharp,ls011b7dh03
> > + - sharp,ls012b7dd01
> > + - sharp,ls013b7dh03
> > + - sharp,ls013b7dh05
> > + - sharp,ls018b7dh02
> > + - sharp,ls027b7dh01
> > + - sharp,ls027b7dh01a
> > + - sharp,ls032b7dd02
> > + - sharp,ls044q7dh01
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + spi-cs-high: true
>
> You can drop it.
>
> > +
> > + spi-max-frequency:
> > +maximum: 200
> > +
> > + vcom-mode:
>
> Missing vendor prefix.
>
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +description: |
> > + VCOM is a signal that prevents DC bias from being built up in
> > + the panel resulting in pixels being forever stuck in one state.
> > + vcom-mode can be set to one of three modes
> > +
> > + SHARP_MEMORY_SOFTWARE_VCOM - This method uses a kthread to
> > periodically send a
> > + "maintain display" message to the display, toggling the vcom
> > + bit on and off with each message
>
> You described Linux, this is not suitable for bindings.
>
> > +
> > + SHARP_MEMORY_EXTERNAL_VCOM - This method relies on an external clock
> > to generate
> > + the signal on the EXTCOMM pin
> > +
> > + SHARP_MEMORY_PWM_VCOM - This method uses a pwm device to generate
> > the signal
> > + on the EXTCOMM pin
>
> I don't see why do you even need this property. Just choose the best
> option based on available connections/pins.
>
I wanted to cover most of the hardware configurations I've seen with these
displays. This property simplifies the driver implementation and allows the user
to explicitly state how the VCOM signal will be generated on their platform.
> > +
> > +enum: [ 0, 1, 2 ]
>
> Here 0/1/2 but above something entirely else. Just use strings.
>
> > +
> > + enable-gpios:
> > +maxItems: 1
> > +description: Enables display
>
> Drop description and maxItems. :true is enough
>
> > +
> > + pwms:
> > +maxItems: 1
> > +description: External VCOM signal
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - spi-cs-high
> > + - vcom-mode
> > +
>
> allOf:
>
> and missing ref to spi peripheral props
>
> > +if:
> > + properties:
> > +vcom-mode:
> > + # SHARP_MEMORY_PWM_VCOM
> > + enum: [2]
> > +then:
> > + required:
> > +- pwms
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +spi {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
>
> Mess indentation.
>
> Use 4 spaces for example indentation.
>
> > +
> > +display@0{
> > +compatible = "sharp,ls013b7dh03";
> > +reg = <0>;
> > +spi-cs-high;
> > +spi-max-frequency = <100>;
> > +vcom-mode = ;
> > +};
> > +};
> > +...
> > diff --git a/include/dt-bindings/display/sharp-memory.h
> > b/include/dt-bindings/display/sharp-memory.h
> > new file mode 100644
> > index ..dea14c7bd7ec
> > --- /dev/null
> > +++ b/include/dt-bindings/display/sharp-memory.h
> > @@ -0,0 +1,9 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +#ifndef _DT_BINDINGS_SHARP_MEMORY
> > +#define _DT_BINDINGS_SHARP_MEMORY
> > +
> > +#define SHARP_MEMORY_SOFTWARE_VCOM 0
> > +#define SHARP_MEMORY_EXTERNAL_VCOM 1
> > +#define
Re: [PATCH 0/2] Add driver for Sharp Memory LCD
On Thu, Jul 25, 2024 at 07:45:32AM GMT, Thomas Petazzoni wrote: > Hello Alex, > > On Wed, 24 Jul 2024 20:47:01 -0400 > Alex Lanzano wrote: > > > This patch series add support for the monochrome Sharp Memory LCD > > panels. This series is based off of the work done by Mehdi Djait. > > Thanks for resuming the effort on this patch series! Since this patch > series is clearly heavily based on Mehdi's work, wouldn't it make sense > to preserve Mehdi's authorship for the patches? Hi! Thanks for the review. What would be the best way to go about doing this? I'm guessing appending to MODULE_AUTHOR and adding a Signed-of-by or Co-Developed-by?
Re: [PATCH] drm/ci: update link to Gitlab server
On 18/07/2024 08:16, Helen Koike wrote: On 17/07/2024 20:52, Deborah Brouwer wrote: Before building an image, the build script looks to see if there are fixes to apply from an upstream repository. The link for the upstream repository git://anongit.freedesktop.org/drm/drm became obsolete with the move to Gitlab server in March 2024. Until recently, this obsolete link was harmless because anongit would at least respond that there were no such fixes available. In the last few days anongit has stopped responding to requests causing the build script to hang indefinitely. Update the link from anongit to the Gitlab server to prevent the build script from hanging indefinitely. Signed-off-by: Deborah Brouwer Acked-by: Helen Koike Thanks Helen Applied to drm-misc-next Thanks Helen --- Link to pipeline for this change: https://gitlab.freedesktop.org/dbrouwer/kernel/-/pipelines/1226742 drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/ gitlab-ci.yml index b09976c3d2c2..259fb1c9a855 100644 --- a/drivers/gpu/drm/ci/gitlab-ci.yml +++ b/drivers/gpu/drm/ci/gitlab-ci.yml @@ -2,7 +2,7 @@ variables: DRM_CI_PROJECT_PATH: mesa/mesa DRM_CI_COMMIT_SHA: e2b9c5a9e3e4f9b532067af8022eaef8d6fc6c00 - UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm + UPSTREAM_REPO: https://gitlab.freedesktop.org/drm/kernel.git TARGET_BRANCH: drm-next IGT_VERSION: f13702b8e4e847c56da3ef6f0969065d686049c5
[PATCH] phy: qcom: com-qmp-combo: fix swing and pre-emphasis table for sm8350
Fix the voltage swing and pre-emphasis tables for sm8350 as the current
one do not match the hardware docs.
Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support")
Signed-off-by: Abhinav Kumar
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 31e43638a649..c15b01aa5a48 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -1946,8 +1946,8 @@ static const struct qmp_phy_cfg sm8350_usb3dpphy_cfg = {
.swing_hbr_rbr = _dp_v4_voltage_swing_hbr_rbr,
.pre_emphasis_hbr_rbr = _dp_v4_pre_emphasis_hbr_rbr,
- .swing_hbr3_hbr2= _dp_v3_voltage_swing_hbr3_hbr2,
- .pre_emphasis_hbr3_hbr2 = _dp_v4_pre_emphasis_hbr3_hbr2,
+ .swing_hbr3_hbr2= _dp_v5_voltage_swing_hbr3_hbr2,
+ .pre_emphasis_hbr3_hbr2 = _dp_v5_pre_emphasis_hbr3_hbr2,
.dp_aux_init= qmp_v4_dp_aux_init,
.configure_dp_tx= qmp_v4_configure_dp_tx,
--
2.44.0
[PATCH] drm/msm/dp: reset the link phy params before link training
Before re-starting link training reset the link phy params namely
the pre-emphasis and voltage swing levels otherwise the next
link training begins at the previously cached levels which can result
in link training failures.
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index cdfcb54a3618..c7a89ab21e09 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1286,6 +1286,8 @@ static int dp_ctrl_link_train(struct dp_ctrl_private
*ctrl,
link_info.rate = ctrl->link->link_params.rate;
link_info.capabilities = DP_LINK_CAP_ENHANCED_FRAMING;
+ dp_link_reset_phy_params_vx_px(ctrl->link);
+
dp_aux_link_configure(ctrl->aux, _info);
if (drm_dp_max_downspread(dpcd))
--
2.44.0
[PATCH] drm/msm/dp: fix the max supported bpp logic
Currently the DP driver hard-codes the max supported bpp to 30.
This is incorrect because the number of lanes and max data rate
supported by the lanes need to be taken into account.
Replace the hardcoded limit with the appropriate math which accounts
for the accurate number of lanes and max data rate.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_panel.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index a916b5f3b317..56ce5e4008f8 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -397,6 +397,7 @@ int dp_panel_init_panel_info(struct dp_panel *dp_panel)
{
struct drm_display_mode *drm_mode;
struct dp_panel_private *panel;
+ u32 max_supported_bpp;
drm_mode = _panel->dp_mode.drm_mode;
@@ -423,8 +424,10 @@ int dp_panel_init_panel_info(struct dp_panel *dp_panel)
drm_mode->clock);
drm_dbg_dp(panel->drm_dev, "bpp = %d\n", dp_panel->dp_mode.bpp);
- dp_panel->dp_mode.bpp = max_t(u32, 18,
- min_t(u32, dp_panel->dp_mode.bpp, 30));
+ max_supported_bpp = dp_panel_get_mode_bpp(dp_panel,
dp_panel->dp_mode.bpp,
+
dp_panel->dp_mode.drm_mode.clock);
+ dp_panel->dp_mode.bpp = max_t(u32, 18, max_supported_bpp);
+
drm_dbg_dp(panel->drm_dev, "updated bpp = %d\n",
dp_panel->dp_mode.bpp);
--
2.44.0
Re: [PATCH] drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
Applied. Thanks!
Alex
On Thu, Jul 25, 2024 at 2:20 PM Nikita Zhandarovich
wrote:
>
> Several cs track offsets (such as 'track->db_s_read_offset')
> either are initialized with or plainly take big enough values that,
> once shifted 8 bits left, may be hit with integer overflow if the
> resulting values end up going over u32 limit.
>
> Some debug prints take this into account (see according dev_warn() in
> evergreen_cs_track_validate_stencil()), even if the actual
> calculated value assigned to local 'offset' variable is missing
> similar proper expansion.
>
> Mitigate the problem by casting the type of right operands to the
> wider type of corresponding left ones in all such cases.
>
> Found by Linux Verification Center (linuxtesting.org) with static
> analysis tool SVACE.
>
> Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling
> informations v11")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Nikita Zhandarovich
> ---
> P.S. While I am not certain that track->cb_color_bo_offset[id]
> actually ends up taking values high enough to cause an overflow,
> nonetheless I thought it prudent to cast it to ulong as well.
>
> drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 1fe6e0d883c7..d734d221e2da 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -433,7 +433,7 @@ static int evergreen_cs_track_validate_cb(struct
> radeon_cs_parser *p, unsigned i
> return r;
> }
>
> - offset = track->cb_color_bo_offset[id] << 8;
> + offset = (unsigned long)track->cb_color_bo_offset[id] << 8;
> if (offset & (surf.base_align - 1)) {
> dev_warn(p->dev, "%s:%d cb[%d] bo base %ld not aligned with
> %ld\n",
> __func__, __LINE__, id, offset, surf.base_align);
> @@ -455,7 +455,7 @@ static int evergreen_cs_track_validate_cb(struct
> radeon_cs_parser *p, unsigned i
> min = surf.nby - 8;
> }
> bsize = radeon_bo_size(track->cb_color_bo[id]);
> - tmp = track->cb_color_bo_offset[id] << 8;
> + tmp = (unsigned long)track->cb_color_bo_offset[id] <<
> 8;
> for (nby = surf.nby; nby > min; nby--) {
> size = nby * surf.nbx * surf.bpe *
> surf.nsamples;
> if ((tmp + size * mslice) <= bsize) {
> @@ -476,10 +476,10 @@ static int evergreen_cs_track_validate_cb(struct
> radeon_cs_parser *p, unsigned i
> }
> }
> dev_warn(p->dev, "%s:%d cb[%d] bo too small (layer size %d, "
> -"offset %d, max layer %d, bo size %ld, slice %d)\n",
> +"offset %ld, max layer %d, bo size %ld, slice %d)\n",
> __func__, __LINE__, id, surf.layer_size,
> - track->cb_color_bo_offset[id] << 8, mslice,
> - radeon_bo_size(track->cb_color_bo[id]), slice);
> + (unsigned long)track->cb_color_bo_offset[id] << 8,
> + mslice, radeon_bo_size(track->cb_color_bo[id]),
> slice);
> dev_warn(p->dev, "%s:%d problematic surf: (%d %d) (%d %d %d
> %d %d %d %d)\n",
> __func__, __LINE__, surf.nbx, surf.nby,
> surf.mode, surf.bpe, surf.nsamples,
> @@ -608,7 +608,7 @@ static int evergreen_cs_track_validate_stencil(struct
> radeon_cs_parser *p)
> return r;
> }
>
> - offset = track->db_s_read_offset << 8;
> + offset = (unsigned long)track->db_s_read_offset << 8;
> if (offset & (surf.base_align - 1)) {
> dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned
> with %ld\n",
> __func__, __LINE__, offset, surf.base_align);
> @@ -627,7 +627,7 @@ static int evergreen_cs_track_validate_stencil(struct
> radeon_cs_parser *p)
> return -EINVAL;
> }
>
> - offset = track->db_s_write_offset << 8;
> + offset = (unsigned long)track->db_s_write_offset << 8;
> if (offset & (surf.base_align - 1)) {
> dev_warn(p->dev, "%s:%d stencil write bo base %ld not aligned
> with %ld\n",
> __func__, __LINE__, offset, surf.base_align);
> @@ -706,7 +706,7 @@ static int evergreen_cs_track_validate_depth(struct
> radeon_cs_parser *p)
> return r;
> }
>
> - offset = track->db_z_read_offset << 8;
> + offset = (unsigned long)track->db_z_read_offset << 8;
> if (offset & (surf.base_align - 1)) {
> dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned
> with %ld\n",
>
[PATCH 2/2] drm/amd/display: use drm_crtc_vblank_on_config()
Hook up drm_crtc_vblank_on_config() in amdgpu_dm. So, that we can enable
PSR and other static screen optimizations more quickly, while avoiding
stuttering issues that are accompanied by the following dmesg error:
[drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle:
status=3
This also allows us to mimic how vblanking is handled by the windows
amdgpu driver.
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 49 +--
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 07e373deb814..780e31a2d456 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7952,7 +7952,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
static void manage_dm_interrupts(struct amdgpu_device *adev,
struct amdgpu_crtc *acrtc,
-bool enable)
+struct dm_crtc_state *acrtc_state)
{
/*
* We have no guarantee that the frontend index maps to the same
@@ -7964,9 +7964,47 @@ static void manage_dm_interrupts(struct amdgpu_device
*adev,
amdgpu_display_crtc_idx_to_irq_type(
adev,
acrtc->crtc_id);
+ struct dc_crtc_timing *timing;
+ int vsync_rate_hz;
+ int offdelay = 30;
+
+ if (acrtc_state) {
+ timing = _state->stream->timing;
+
+ vsync_rate_hz = div64_u64(div64_u64((timing->pix_clk_100hz *
+(uint64_t)100),
+ timing->v_total),
+ timing->h_total);
+
+ if (amdgpu_ip_version(adev, DCE_HWIP, 0) >=
+ IP_VERSION(3, 5, 0) && (adev->flags & AMD_IS_APU)) {
+ if (vsync_rate_hz)
+ /* at least 2 frames */
+ offdelay = 2000 / vsync_rate_hz + 1;
+
+ if (acrtc_state->stream->link->psr_settings.psr_version
<
+ DC_PSR_VERSION_UNSUPPORTED) {
+ const struct drm_vblank_crtc_config config = {
+ .offdelay_ms = offdelay,
+ .disable_immediate = false
+ };
+
+ drm_crtc_vblank_on_config(>base,
+ );
+ } else {
+ const struct drm_vblank_crtc_config config = {
+ .offdelay_ms = 0,
+ .disable_immediate = true
+ };
+
+ drm_crtc_vblank_on_config(>base,
+ );
+ }
+
+ } else {
+ drm_crtc_vblank_on(>base);
+ }
- if (enable) {
- drm_crtc_vblank_on(>base);
amdgpu_irq_get(
adev,
>pageflip_irq,
@@ -8947,7 +8985,7 @@ static void amdgpu_dm_commit_streams(struct
drm_atomic_state *state,
if (old_crtc_state->active &&
(!new_crtc_state->active ||
drm_atomic_crtc_needs_modeset(new_crtc_state))) {
- manage_dm_interrupts(adev, acrtc, false);
+ manage_dm_interrupts(adev, acrtc, NULL);
dc_stream_release(dm_old_crtc_state->stream);
}
}
@@ -9465,7 +9503,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_crtc_needs_modeset(new_crtc_state))) {
dc_stream_retain(dm_new_crtc_state->stream);
acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
- manage_dm_interrupts(adev, acrtc, true);
+ manage_dm_interrupts(adev, acrtc,
+to_dm_crtc_state(new_crtc_state));
}
/* Handle vrr on->off / off->on transitions */
amdgpu_dm_handle_vrr_transition(dm_old_crtc_state,
dm_new_crtc_state);
--
2.45.2
[PATCH 1/2] drm/vblank: add dynamic per-crtc vblank configuration support
We would like to be able to enable vblank_disable_immediate
unconditionally, however there are a handful of cases where a small off
delay is necessary (e.g. with PSR enabled). So, we would like to be able
to adjust the vblank off delay and disable imminent values dynamically
for a given CRTC. Since, it will allow drivers to apply static screen
optimizations more quickly and consequently allow users to benefit more
so from the power savings afforded by the aforementioned optimizations,
while avoiding issues in cases where an off delay is still warranted.
In particular, the PSR case requires a small off delay of 2 frames,
otherwise display firmware isn't able to keep up with all of the
requests made to amdgpu. So, introduce drm_crtc_vblank_on_config() which
is like drm_crtc_vblank_on(), but it allows drivers to specify the
vblank CRTC configuration before enabling vblanking support for a given
CRTC.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_vblank.c | 57 ++--
include/drm/drm_vblank.h | 25
2 files changed, 66 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index cc3571e25a9a..c9de7d18389a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1241,6 +1241,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_get);
void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
{
struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
+ int vblank_offdelay = vblank->config.offdelay_ms;
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return;
@@ -1250,13 +1251,13 @@ void drm_vblank_put(struct drm_device *dev, unsigned
int pipe)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(>refcount)) {
- if (drm_vblank_offdelay == 0)
+ if (!vblank_offdelay)
return;
- else if (drm_vblank_offdelay < 0)
+ else if (vblank_offdelay < 0)
vblank_disable_fn(>disable_timer);
- else if (!dev->vblank_disable_immediate)
+ else if (!vblank->config.disable_immediate)
mod_timer(>disable_timer,
- jiffies + ((drm_vblank_offdelay * HZ)/1000));
+ jiffies + ((vblank_offdelay * HZ) / 1000));
}
}
@@ -1466,16 +1467,16 @@ void drm_crtc_set_max_vblank_count(struct drm_crtc
*crtc,
EXPORT_SYMBOL(drm_crtc_set_max_vblank_count);
/**
- * drm_crtc_vblank_on - enable vblank events on a CRTC
+ * drm_crtc_vblank_on_config - enable vblank events on a CRTC with custom
+ * configuration options
* @crtc: CRTC in question
+ * @config: Vblank configuration value
*
- * This functions restores the vblank interrupt state captured with
- * drm_crtc_vblank_off() again and is generally called when enabling @crtc.
Note
- * that calls to drm_crtc_vblank_on() and drm_crtc_vblank_off() can be
- * unbalanced and so can also be unconditionally called in driver load code to
- * reflect the current hardware state of the crtc.
+ * See drm_crtc_vblank_on(). In addition, this function allows you to provide a
+ * custom vblank configuration for a given CRTC.
*/
-void drm_crtc_vblank_on(struct drm_crtc *crtc)
+void drm_crtc_vblank_on_config(struct drm_crtc *crtc,
+ const struct drm_vblank_crtc_config *config)
{
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
@@ -1488,6 +1489,8 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
drm_dbg_vbl(dev, "crtc %d, vblank enabled %d, inmodeset %d\n",
pipe, vblank->enabled, vblank->inmodeset);
+ vblank->config = *config;
+
/* Drop our private "prevent drm_vblank_get" refcount */
if (vblank->inmodeset) {
atomic_dec(>refcount);
@@ -1500,10 +1503,31 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
* re-enable interrupts if there are users left, or the
* user wishes vblank interrupts to be enabled all the time.
*/
- if (atomic_read(>refcount) != 0 || drm_vblank_offdelay == 0)
+ if (atomic_read(>refcount) != 0 || !vblank->config.offdelay_ms)
drm_WARN_ON(dev, drm_vblank_enable(dev, pipe));
spin_unlock_irq(>vbl_lock);
}
+EXPORT_SYMBOL(drm_crtc_vblank_on_config);
+
+/**
+ * drm_crtc_vblank_on - enable vblank events on a CRTC
+ * @crtc: CRTC in question
+ *
+ * This functions restores the vblank interrupt state captured with
+ * drm_crtc_vblank_off() again and is generally called when enabling @crtc.
Note
+ * that calls to drm_crtc_vblank_on() and drm_crtc_vblank_off() can be
+ * unbalanced and so can also be unconditionally called in driver load code to
+ * reflect the current hardware state of the crtc.
+ */
+void drm_crtc_vblank_on(struct drm_crtc *crtc)
+{
+ const struct
Re: [PATCH] drm/amd/display: Fix documentation warning for mpc.h
This is already fixed in:
https://gitlab.freedesktop.org/agd5f/linux/-/commit/6e169c7e0f842c48c7bf683fb789dbf5a8b1dfd8
Alex
On Wed, Jul 24, 2024 at 3:55 PM Ricardo B. Marliere
wrote:
>
> On 24 Jul 24 23:24, Abhishek Tamboli wrote:
> > Fix documentation compile warning by adding description
> > for program_3dlut_size function.
> >
> > Remove the following warning:
> > ./drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h:1043: warning: Function
> > parameter or struct member 'program_3dlut_size' not described in 'mpc_funcs'
> >
> > Signed-off-by: Abhishek Tamboli
> > ---
> > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
> > b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
> > index 40a9b3471208..615c69d966e7 100644
> > --- a/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
> > +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
> > @@ -1039,7 +1039,21 @@ struct mpc_funcs {
> > */
> > void (*program_lut_mode)(struct mpc *mpc, const enum MCM_LUT_ID id,
> > const enum MCM_LUT_XABLE xable,
> > bool lut_bank_a, int mpcc_id);
> > - void (*program_3dlut_size)(struct mpc *mpc, bool is_17x17x17, int
> > mpcc_id);
> > + /**
> > + * @program_3dlut_size:
> > + *
> > + * Program 3D LUT size.
> > + *
> > + * Parameters:
> > + * - [in/out] mpc - MPC context.
> > + * - [in] is_17x17x17 - Boolean Flag.
> > + * - [in] mpcc_id - MPCC physical instance.
> > + *
> > + * Return:
> > + *
> > + * void
> > + */
>
> Reviewed-by: Ricardo B. Marliere
>
>
> > + void (*program_3dlut_size)(struct mpc *mpc, bool is_17x17x17, int
> > mpcc_id);
> > };
> >
> > #endif
> > --
> > 2.34.1
> >
Re: [PATCH -next] drm/amd/display: remove unneeded semicolon
Applied. Thanks! Alex On Wed, Jul 24, 2024 at 10:35 PM Jiapeng Chong wrote: > > No functional modification involved. > > ./drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:481:2-3: > Unneeded semicolon. > ./drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3783:168-169: > Unneeded semicolon. > ./drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3782:166-167: > Unneeded semicolon. > > Reported-by: Abaci Robot > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9575 > Signed-off-by: Jiapeng Chong > --- > .../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c > > b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c > index 0b671c665373..e4a14d41fb85 100644 > --- > a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c > +++ > b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c > @@ -478,7 +478,7 @@ static unsigned int dml_get_tile_block_size_bytes(enum > dml2_swizzle_mode sw_mode > default: > DML2_ASSERT(0); > return 256; > - }; > + } > } > > static bool dml_is_vertical_rotation(enum dml2_rotation_angle Scan) > @@ -3779,8 +3779,8 @@ static void CalculateSwathAndDETConfiguration(struct > dml2_core_internal_scratch > p->SwathHeightC[k] = MaximumSwathHeightC[k] / 2; > RoundedUpSwathSizeBytesY[k] = > p->full_swath_bytes_l[k] / 2; > RoundedUpSwathSizeBytesC[k] = > p->full_swath_bytes_c[k] / 2; > - p->request_size_bytes_luma[k] = ((p->BytePerPixY[k] > == 2) == > dml_is_vertical_rotation(p->display_cfg->plane_descriptors[k].composition.rotation_angle)) > ? 128 : 64;; > - p->request_size_bytes_chroma[k] = ((p->BytePerPixC[k] > == 2) == > dml_is_vertical_rotation(p->display_cfg->plane_descriptors[k].composition.rotation_angle)) > ? 128 : 64;; > + p->request_size_bytes_luma[k] = ((p->BytePerPixY[k] > == 2) == > dml_is_vertical_rotation(p->display_cfg->plane_descriptors[k].composition.rotation_angle)) > ? 128 : 64; > + p->request_size_bytes_chroma[k] = ((p->BytePerPixC[k] > == 2) == > dml_is_vertical_rotation(p->display_cfg->plane_descriptors[k].composition.rotation_angle)) > ? 128 : 64; > } > > if (p->SwathHeightC[k] == 0) > -- > 2.32.0.3.g01195cf9f >
Re: [RFC PATCH] drm: panthor: add dev_coredumpv support
On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> > Hi Sima!
> >
> >
> > >
> > > Yeah I'm not sure a partially converted driver where the main driver is
> > > still C really works, that pretty much has to throw out all the type
> > > safety in the interfaces.
> > >
> > > What I think might work is if such partial drivers register as full rust
> > > drivers, and then largely delegate the implementation to their existing C
> > > code with a big "safety: trust me, the C side is bug free" comment since
> > > it's all going to be unsafe :-)
> > >
> > > It would still be a big change, since all the driver's callbacks need to
> > > switch from container_of to upcast to their driver structure to some small
> > > rust shim (most likely, I didn't try this out) to get at the driver parts
> > > on the C side. And I think you also need a small function to downcast to
> > > the drm base class. But that should be all largely mechanical.
> > >
> > > More freely allowing to mix is imo going to be endless pains. We
> > > kinda tried that with the atomic conversion helpers for legacy kms
> > > drivers, and the impendance mismatch was just endless amounts of very
> > > subtle pain. Rust will exacerbate this, because it encodes semantics into
> > > the types and interfaces. And that was with just one set of helpers, for
> > > rust we'll likely need a custom one for each driver that's partially
> > > written in rust.
> > > -Sima
> > >
> >
> > I humbly disagree here.
> >
> > I know this is a bit tangential, but earlier this year I converted a
> > bunch of codec libraries to Rust in v4l2. That worked just fine with the
> > C codec drivers. There were no regressions as per our test tools.
> >
> > The main idea is that you isolate all unsafety to a single point: so
> > long as the C code upholds the safety guarantees when calling into Rust,
> > the Rust layer will be safe. This is just the same logic used in unsafe
> > blocks in Rust itself, nothing new really.
> >
> > This is not unlike what is going on here, for example:
> >
> >
> > ```
> > +unsafe extern "C" fn open_callback, U: BaseObject>(
> > + raw_obj: *mut bindings::drm_gem_object,
> > + raw_file: *mut bindings::drm_file,
> > +) -> core::ffi::c_int {
> > + // SAFETY: The pointer we got has to be valid.
> > + let file = unsafe {
> > + file::File::<<::Driver as
> > drv::Driver>::File>::from_raw(raw_file)
> > + };
> > + let obj =
> > + <<::Driver as drv::Driver>::Object as
> > IntoGEMObject>::from_gem_obj(
> > + raw_obj,
> > + );
> > +
> > + // SAFETY: from_gem_obj() returns a valid pointer as long as the type is
> > + // correct and the raw_obj we got is valid.
> > + match T::open(unsafe { &*obj }, ) {
> > + Err(e) => e.to_errno(),
> > + Ok(()) => 0,
> > + }
> > +}
> > ```
> >
> > We have to trust that the kernel is passing in a valid pointer. By the same
> > token, we can choose to trust drivers if we so desire.
> >
> > > that pretty much has to throw out all the type
> > > safety in the interfaces.
> >
> > Can you expand on that?
>
> Essentially what you've run into, in a pure rust driver we assume that
> everything is living in the rust world. In a partial conversion you might
> want to freely convert GEMObject back, but everything else
> (drm_file, drm_device, ...) is still living in the pure C world. I think
> there's roughly three solutions to this:
>
> - we allow this on the rust side, but that means the associated
> types/generics go away. We drop a lot of enforced type safety for pure
> rust drivers.
>
> - we don't allow this. Your mixed driver is screwed.
>
> - we allow this for specific functions, with a pinky finger promise that
> those rust functions will not look at any of the associated types. From
> my experience these kind of in-between worlds functions are really
> brittle and a pain, e.g. rust-native driver people might accidentally
> change the code to again assume a drv::Driver exists, or people don't
> want to touch the code because it's too risky, or we're forced to
> implement stuff in C instead of rust more than necessary.
>
> > In particular, I believe that we should ideally be able to convert from
> > a C "struct Foo * " to a Rust “FooRef" for types whose lifetimes are
> > managed either by the kernel itself or by a C driver. In practical
> > terms, this has run into the issues we’ve been discussing in this
> > thread, but there may be solutions e.g.:
> >
> > > One thing that comes to my mindis , you could probably create some driver
> > > specific
> > > "dummy" types to satisfy the type generics of the types you want to use.
> > > Not sure
> > > how well this works out though.
> >
> > I haven’t thought of anything yet - which is why I haven’t replied.
> > OTOH, IIRC, Faith seems to have something in mind that can work with the
> > current abstractions, so I am waiting on her reply.
>
> This might work, but I see issue here
Re: [PATCH v7 04/28] dma-buf: heaps: Deduplicate docs and adopt common format
On Thu, Jul 25, 2024 at 4:52 AM Christian König wrote: > > Am 20.07.24 um 09:15 schrieb Yunfei Dong: > > From: "T.J. Mercier" > > > > The docs for dma_heap_get_name were incorrect, and since they were > > duplicated in the header they were wrong there too. > > > > The docs formatting was inconsistent so I tried to make it more > > consistent across functions since I'm already in here doing cleanup. > > > > Remove multiple unused includes and alphabetize. > > > > Signed-off-by: T.J. Mercier > > Signed-off-by: Yong Wu > > [Yong: Just add a comment for "priv" to mute build warning] > > Signed-off-by: Yunfei Dong > > Since this is essentially a complete independent documentation fix I've > gone ahead and pushed it to drm-misc-next. > > Regards, > Christian. Thanks!
[PATCH] drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
Several cs track offsets (such as 'track->db_s_read_offset')
either are initialized with or plainly take big enough values that,
once shifted 8 bits left, may be hit with integer overflow if the
resulting values end up going over u32 limit.
Some debug prints take this into account (see according dev_warn() in
evergreen_cs_track_validate_stencil()), even if the actual
calculated value assigned to local 'offset' variable is missing
similar proper expansion.
Mitigate the problem by casting the type of right operands to the
wider type of corresponding left ones in all such cases.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling
informations v11")
Cc: sta...@vger.kernel.org
Signed-off-by: Nikita Zhandarovich
---
P.S. While I am not certain that track->cb_color_bo_offset[id]
actually ends up taking values high enough to cause an overflow,
nonetheless I thought it prudent to cast it to ulong as well.
drivers/gpu/drm/radeon/evergreen_cs.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 1fe6e0d883c7..d734d221e2da 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -433,7 +433,7 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
return r;
}
- offset = track->cb_color_bo_offset[id] << 8;
+ offset = (unsigned long)track->cb_color_bo_offset[id] << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d cb[%d] bo base %ld not aligned with
%ld\n",
__func__, __LINE__, id, offset, surf.base_align);
@@ -455,7 +455,7 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
min = surf.nby - 8;
}
bsize = radeon_bo_size(track->cb_color_bo[id]);
- tmp = track->cb_color_bo_offset[id] << 8;
+ tmp = (unsigned long)track->cb_color_bo_offset[id] << 8;
for (nby = surf.nby; nby > min; nby--) {
size = nby * surf.nbx * surf.bpe *
surf.nsamples;
if ((tmp + size * mslice) <= bsize) {
@@ -476,10 +476,10 @@ static int evergreen_cs_track_validate_cb(struct
radeon_cs_parser *p, unsigned i
}
}
dev_warn(p->dev, "%s:%d cb[%d] bo too small (layer size %d, "
-"offset %d, max layer %d, bo size %ld, slice %d)\n",
+"offset %ld, max layer %d, bo size %ld, slice %d)\n",
__func__, __LINE__, id, surf.layer_size,
- track->cb_color_bo_offset[id] << 8, mslice,
- radeon_bo_size(track->cb_color_bo[id]), slice);
+ (unsigned long)track->cb_color_bo_offset[id] << 8,
+ mslice, radeon_bo_size(track->cb_color_bo[id]), slice);
dev_warn(p->dev, "%s:%d problematic surf: (%d %d) (%d %d %d %d
%d %d %d)\n",
__func__, __LINE__, surf.nbx, surf.nby,
surf.mode, surf.bpe, surf.nsamples,
@@ -608,7 +608,7 @@ static int evergreen_cs_track_validate_stencil(struct
radeon_cs_parser *p)
return r;
}
- offset = track->db_s_read_offset << 8;
+ offset = (unsigned long)track->db_s_read_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned
with %ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -627,7 +627,7 @@ static int evergreen_cs_track_validate_stencil(struct
radeon_cs_parser *p)
return -EINVAL;
}
- offset = track->db_s_write_offset << 8;
+ offset = (unsigned long)track->db_s_write_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil write bo base %ld not aligned
with %ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -706,7 +706,7 @@ static int evergreen_cs_track_validate_depth(struct
radeon_cs_parser *p)
return r;
}
- offset = track->db_z_read_offset << 8;
+ offset = (unsigned long)track->db_z_read_offset << 8;
if (offset & (surf.base_align - 1)) {
dev_warn(p->dev, "%s:%d stencil read bo base %ld not aligned
with %ld\n",
__func__, __LINE__, offset, surf.base_align);
@@ -722,7 +722,7 @@ static int evergreen_cs_track_validate_depth(struct
radeon_cs_parser *p)
return -EINVAL;
}
- offset = track->db_z_write_offset << 8;
+ offset = (unsigned
Re: [PATCH 2/2] drm/mipi-dsi: Change multi functions to use quiet member of mipi_dsi_multi_context
Hi,
On Thu, Jul 25, 2024 at 1:28 AM Maxime Ripard wrote:
>
> On Wed, Jul 24, 2024 at 06:32:14PM GMT, Jani Nikula wrote:
> > On Wed, 24 Jul 2024, Tejas Vipin wrote:
> > > Changes all the multi functions to check if the current context requires
> > > errors to be printed or not using the quiet member.
> > >
> > > Signed-off-by: Tejas Vipin
> > > ---
> > > drivers/gpu/drm/drm_mipi_dsi.c | 20
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c
> > > b/drivers/gpu/drm/drm_mipi_dsi.c
> > > index a471c46f5ca6..cbb77342d201 100644
> > > --- a/drivers/gpu/drm/drm_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> > > @@ -814,6 +814,8 @@ void mipi_dsi_generic_write_multi(struct
> > > mipi_dsi_multi_context *ctx,
> > > ret = mipi_dsi_generic_write(dsi, payload, size);
> > > if (ret < 0) {
> > > ctx->accum_err = ret;
> > > + if (ctx->quiet)
> > > + return;
> > > dev_err(dev, "sending generic data %*ph failed: %d\n",
> > > (int)size, payload, ctx->accum_err);
> >
> > A maintainability nitpick. Imagine someone wishing to add some more
> > error handling here. Or something else after the block.
> >
> > IMO the dev_err() should be wrapped in if (!ctx->quiet) instead of
> > adding an early return.
> >
> > Ditto everywhere.
>
> I'm not even sure why we need that parameter in the first place.
>
> Like, what's the expected use of that parameter? Is it supposed to be
> set in users of that function?
>
> If so, wouldn't it prevent any sort of meaningful debugging if some
> drivers set it and some don't?
>
> It looks to me like you're reimplementing drm.debug.
I can explain how we got here and maybe you can explain how it should
be designed differently.
1. The majority of MIPI panels drivers just have a pile of commands
that need to be sent during panel init time. Each time you send a
command it technically can fail but it's very unlikely. In order to
make things debuggable in the unlikely case of failure, you want a
printout about which command failed. In order to avoid massive numbers
of printouts in each driver you want the printout in the core. This is
the impetus behind the "_multi" functions that were introduced
recently and I think most people who have looked at converted drivers
are pretty pleased. The functions are readable/non-bloated but still
check for errors and print messages in the right place.
2. As Tejas was adding more "_multi" variants things were starting to
feel a bit awkward. Dmitry proposed [1] that maybe the answer was that
we should work to get rid of the non-multi variants and then we don't
need these awkward wrappers.
3. The issue with telling everyone to use the "_multi" variants is
that they print the error message for you. While this is the correct
default behavior and the correct behavior for the vast majority of
users, I can imagine there being a legitimate case where a driver
might not want error messages printed. I don't personally know of a
case, but in my experience there's always some case where you're
dealing with weird hardware and the driver knows that a command has a
high chance of failure. Maybe the driver will retry or maybe it'll
detect /handle the error, but the idea is that the driver wouldn't
want a printout.
Said another way: I think of the errors of these MIPI initialization
functions a lot like errors allocating memory. By default kmalloc()
reports an error so all drivers calling kmalloc() don't need to print,
but if your driver specifically knows that an allocation failure is
likely and it knows how to handle it then it can pass a flag to tell
the core kernel not to print.
So I guess options are:
a) Accept what Tejas is doing here as reasonable.
b) Don't accept what Tejas is doing here and always keep the "_multi"
functions as wrappers.
c) Declare that, since there are no known cases where we want to
suppress the error printouts, that suppressing the error printouts is
a "tomorrow" problem. We transition everyone to _multi but don't
provide a way to suppress the printouts.
d) Declare that the _multi functions are terrible and undo all the
recent changes. Hopefully we don't do this. :-P
[1]
https://lore.kernel.org/r/p7fahem6egnooi5org4lv3gtz2elafylvlnyily7buvzcpv2qh@vssvpfci3lwn
[PATCH] drm/sched: Add error code parameter to drm_sched_start
From: Vitaly Prosyak
The current implementation of drm_sched_start uses a hardcoded -ECANCELED to
dispose of a job when
the parent/hw fence is NULL. This results in drm_sched_job_done being called
with -ECANCELED for
each job with a NULL parent in the pending list, making it difficult to
distinguish between recovery
methods, whether a queue reset or a full GPU reset was used.
To improve this, we first try a soft recovery for timeout jobs and use the
error code -ENODATA.
If soft recovery fails, we proceed with a queue reset, where the error code
remains -ENODATA for
the job. Finally, for a full GPU reset, we use error codes -ECANCELED or
-ETIME. This patch adds
an error code parameter to drm_sched_start, allowing us to differentiate
between queue reset and
GPU reset failures. This enables user mode and test applications to validate
the expected
correctness of the requested operation. After a successful queue reset, the
only way to continue
normal operation is to call drm_sched_job_done with the specific error code
-ENODATA.
v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain and
amdgpu_device_unlock_reset_domain to allow user mode to track the queue
reset status and distinguish
between queue reset and GPU reset.
v2: Christian suggested using the error codes -ENODATA for queue reset and
-ECANCELED or -ETIME for GPU
reset, returned to amdgpu_cs_wait_ioctl.
v3: To meet the requirements, we introduce a new function drm_sched_start_ex
with an additional parameter
to set dma_fence_set_error, allowing us to handle the specific error codes
appropriately and dispose
of bad jobs with the selected error code depending on whether it was a
queue reset or GPU reset.
v4: Alex suggested using a new name, drm_sched_start_with_recovery_error, which
more accurately describes
the function's purpose. Additionally, it was recommended to add
documentation details about the new method.
v5: Fixed declaration of new function drm_sched_start_with_recovery_error.(Alex)
Cc: Alex Deucher
Cc: Christian Koenig
Signed-off-by: Jesse Zhang
Signed-off-by: Vitaly Prosyak
---
drivers/gpu/drm/scheduler/sched_main.c | 30 +++---
include/drm/gpu_scheduler.h| 1 +
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 7e90c9f95611..c42449358b3f 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -671,13 +671,24 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad)
EXPORT_SYMBOL(drm_sched_stop);
/**
- * drm_sched_start - recover jobs after a reset
+ * drm_sched_start_with_recovery_error - recover jobs after a reset with
+ * custom error
*
* @sched: scheduler instance
* @full_recovery: proceed with complete sched restart
+ * @error : err code for set dma_fence_set_error
+ *
+ * Starts the scheduler and allows setting a custom dma_fence_set_error,
+ * which can be used to identify the recovery mechanism actually used.
*
+ * For example:
+ * - If a soft or queue reset was used, dma_fence_set_error is set to -ENODATA.
+ * - If an entire GPU reset was used, the error code is set to -ECANCELED.
+ *
+ * This approach enables user mode and test applications to know which
+ * recovery method was used for a given bad job.
*/
-void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery)
+void drm_sched_start_with_recovery_error(struct drm_gpu_scheduler *sched, bool
full_recovery, int error)
{
struct drm_sched_job *s_job, *tmp;
int r;
@@ -704,7 +715,7 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
full_recovery)
DRM_DEV_ERROR(sched->dev, "fence add callback
failed (%d)\n",
r);
} else
- drm_sched_job_done(s_job, -ECANCELED);
+ drm_sched_job_done(s_job, error);
}
if (full_recovery)
@@ -712,6 +723,19 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool
full_recovery)
drm_sched_wqueue_start(sched);
}
+EXPORT_SYMBOL(drm_sched_start_with_recovery_error);
+
+/**
+ * drm_sched_start - recover jobs after a reset
+ *
+ * @sched: scheduler instance
+ * @full_recovery: proceed with complete sched restart
+ *
+ */
+void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery)
+{
+ drm_sched_start_with_recovery_error(sched, full_recovery, -ECANCELED);
+}
EXPORT_SYMBOL(drm_sched_start);
/**
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 5acc64954a88..e80ea947a864 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -580,6 +580,7 @@ void drm_sched_wqueue_stop(struct drm_gpu_scheduler *sched);
void drm_sched_wqueue_start(struct drm_gpu_scheduler *sched);
void drm_sche
Re: [PATCH v4 10/11] drm/amd/display: get SADB from drm_eld when parsing EDID caps
On 2024-07-05 21:35, Melissa Wen wrote:
instead of parsing struct edid.
A more informative commit message will be helpful.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 45c04de08c65..3fb07f437793 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -97,9 +97,8 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
const struct drm_edid *drm_edid = aconnector->drm_edid;
struct drm_edid_product_id product_id;
struct edid *edid_buf = edid ? (struct edid *) edid->raw_edid : NULL;
- int sad_count, sadb_count;
+ int sad_count;
int i = 0;
- uint8_t *sadb = NULL;
enum dc_edid_status result = EDID_OK;
@@ -143,20 +142,12 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
edid_caps->audio_modes[i].sample_size = sad.byte2;
}
- sadb_count = drm_edid_to_speaker_allocation((struct edid *) edid->raw_edid, );
- if (sadb_count < 0) {
- DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n",
sadb_count);
- sadb_count = 0;
- }
-
- if (sadb_count)
- edid_caps->speaker_flags = sadb[0];
+ if (connector->eld[DRM_ELD_SPEAKER])
+ edid_caps->speaker_flags = connector->eld[DRM_ELD_SPEAKER];
else
edid_caps->speaker_flags = DEFAULT_SPEAKER_LOCATION;
- kfree(sadb);
-
return result;
}
Re: [PATCH v4 09/11] drm/amd/display: get SAD from drm_eld when parsing EDID caps
On 2024-07-05 21:35, Melissa Wen wrote:
instead of parsing struct edid.
A more informative commit message will be helpful.
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 7657b1051c54..45c04de08c65 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -97,7 +97,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
const struct drm_edid *drm_edid = aconnector->drm_edid;
struct drm_edid_product_id product_id;
struct edid *edid_buf = edid ? (struct edid *) edid->raw_edid : NULL;
- struct cea_sad *sads;
int sad_count, sadb_count;
int i = 0;
uint8_t *sadb = NULL;
@@ -127,18 +126,21 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
apply_edid_quirks(_id, edid_caps);
- sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
+ sad_count = drm_eld_sad_count(connector->eld);
if (sad_count <= 0)
return result;
edid_caps->audio_mode_count = min(sad_count, DC_MAX_AUDIO_DESC_COUNT);
for (i = 0; i < edid_caps->audio_mode_count; ++i) {
- struct cea_sad *sad = [i];
+ struct cea_sad sad;
- edid_caps->audio_modes[i].format_code = sad->format;
- edid_caps->audio_modes[i].channel_count = sad->channels + 1;
- edid_caps->audio_modes[i].sample_rate = sad->freq;
- edid_caps->audio_modes[i].sample_size = sad->byte2;
+ if (drm_eld_sad_get(connector->eld, i, ) < 0)
+ continue;
+
+ edid_caps->audio_modes[i].format_code = sad.format;
+ edid_caps->audio_modes[i].channel_count = sad.channels + 1;
+ edid_caps->audio_modes[i].sample_rate = sad.freq;
+ edid_caps->audio_modes[i].sample_size = sad.byte2;
}
sadb_count = drm_edid_to_speaker_allocation((struct edid *) edid->raw_edid, );
@@ -153,7 +155,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
else
edid_caps->speaker_flags = DEFAULT_SPEAKER_LOCATION;
- kfree(sads);
kfree(sadb);
return result;
Re: [PATCH v4 07/11] drm/amd/display: don't give initial values for sad/b_count
Can this be merged with [PATCH 10/11] drm/amd/display: get SADB from drm_eld when parsing EDID caps On 2024-07-05 21:35, Melissa Wen wrote: Signed-off-by: Melissa Wen --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c index 85704fd75ee4..6df55161d6df 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c @@ -97,8 +97,7 @@ enum dc_edid_status dm_helpers_parse_edid_caps( struct drm_edid_product_id product_id; struct edid *edid_buf = edid ? (struct edid *) edid->raw_edid : NULL; struct cea_sad *sads; - int sad_count = -1; - int sadb_count = -1; + int sad_count, sadb_count; int i = 0; uint8_t *sadb = NULL;
Re: [PATCH v4 03/11] drm/amd/display: switch to setting physical address directly
On 2024-07-05 21:35, Melissa Wen wrote:
Connectors have source physical address available in display
info. Use drm_dp_cec_attach() to use it instead of parsing the EDID
again.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 49b8c5b00728..163850aeac4a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3477,10 +3477,9 @@ void amdgpu_dm_update_connector_after_detect(
aconnector->drm_edid = drm_edid_alloc(edid,
sink->dc_edid.length);
drm_edid_connector_update(connector,
aconnector->drm_edid);
- /* FIXME: Get rid of drm_edid_raw() */
if (aconnector->dc_link->aux_mode)
- drm_dp_cec_set_edid(>dm_dp_aux.aux,
-
drm_edid_raw(aconnector->drm_edid));
drm_dp_cec_set_edid is removed here. I guess it doesn't matter if edid
or drm_edid_raw(aconnector->drm_edid) is past here.
+ drm_dp_cec_attach(>dm_dp_aux.aux,
+
connector->display_info.source_physical_address);
}
if (!aconnector->timing_requested) {
Re: [PATCH v4 02/11] drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid
Please see inline comments.
On 2024-07-05 21:35, Melissa Wen wrote:
Replace raw edid handling (struct edid) with the opaque EDID type
(struct drm_edid) on amdgpu_dm_connector for consistency. It may also
prevent mismatch of approaches in different parts of the driver code.
Working in progress. It was only exercised with IGT tests.
v2: use const to fix warnings (Alex Hung)
v3: fix general protection fault on mst
v4: rename edid to drm_edid in amdgpu_connector (Jani)
call drm_edid_connector_update to clear edid in case of NULL (Jani)
keep setting NULL instead of free drm_edid (Jani)
check drm_edid not NULL, instead of valid (Jani)
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 106 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 +-
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 13 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 32 +++---
4 files changed, 79 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1dfa7ec9af35..49b8c5b00728 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3408,7 +3408,7 @@ void amdgpu_dm_update_connector_after_detect(
aconnector->dc_sink = sink;
dc_sink_retain(aconnector->dc_sink);
amdgpu_dm_update_freesync_caps(connector,
- aconnector->edid);
+ aconnector->drm_edid);
} else {
amdgpu_dm_update_freesync_caps(connector, NULL);
if (!aconnector->dc_sink) {
@@ -3467,18 +3467,20 @@ void amdgpu_dm_update_connector_after_detect(
aconnector->dc_sink = sink;
dc_sink_retain(aconnector->dc_sink);
if (sink->dc_edid.length == 0) {
- aconnector->edid = NULL;
+ aconnector->drm_edid = NULL;
if (aconnector->dc_link->aux_mode) {
drm_dp_cec_unset_edid(
>dm_dp_aux.aux);
}
} else {
- aconnector->edid =
- (struct edid *)sink->dc_edid.raw_edid;
+ const struct edid *edid = (const struct edid
*)sink->dc_edid.raw_edid;
+ aconnector->drm_edid = drm_edid_alloc(edid,
sink->dc_edid.length);
+ drm_edid_connector_update(connector,
aconnector->drm_edid);
+ /* FIXME: Get rid of drm_edid_raw() */
if (aconnector->dc_link->aux_mode)
drm_dp_cec_set_edid(>dm_dp_aux.aux,
- aconnector->edid);
Why not pass edid but drm_edid_raw(aconnector->drm_edid)?
+
drm_edid_raw(aconnector->drm_edid));
}
if (!aconnector->timing_requested) {
@@ -3489,17 +3491,18 @@ void amdgpu_dm_update_connector_after_detect(
"failed to create
aconnector->requested_timing\n");
}
- drm_connector_update_edid_property(connector, aconnector->edid);
- amdgpu_dm_update_freesync_caps(connector, aconnector->edid);
+ drm_edid_connector_update(connector, aconnector->drm_edid);
+ amdgpu_dm_update_freesync_caps(connector, aconnector->drm_edid);
update_connector_ext_caps(aconnector);
} else {
drm_dp_cec_unset_edid(>dm_dp_aux.aux);
amdgpu_dm_update_freesync_caps(connector, NULL);
- drm_connector_update_edid_property(connector, NULL);
+ drm_edid_connector_update(connector, NULL);
aconnector->num_modes = 0;
dc_sink_release(aconnector->dc_sink);
aconnector->dc_sink = NULL;
- aconnector->edid = NULL;
+ drm_edid_free(aconnector->drm_edid);
+ aconnector->drm_edid = NULL;
kfree(aconnector->timing_requested);
aconnector->timing_requested = NULL;
/* Set CP to DESIRED if it was ENABLED, so we can re-enable it
again on hotplug */
@@ -7002,13 +7005,7 @@ static void amdgpu_dm_connector_funcs_force(struct
drm_connector *connector)
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct dc_link *dc_link = aconnector->dc_link;
struct dc_sink *dc_em_sink = aconnector->dc_em_sink;
- struct edid *edid;
- struct i2c_adapter *ddc;
-
- if (dc_link && dc_link->aux_mode)
- ddc = >dm_dp_aux.aux.ddc;
- else
- ddc = >i2c->base;
+ const struct drm_edid *drm_edid;
Re: [PATCH 1/2] drm/sched: Add error code parameter to drm_sched_start
On Wed, Jul 24, 2024 at 11:30 PM wrote:
>
> From: Vitaly Prosyak
>
> The current implementation of drm_sched_start uses a hardcoded -ECANCELED to
> dispose of a job when
> the parent/hw fence is NULL. This results in drm_sched_job_done being called
> with -ECANCELED for
> each job with a NULL parent in the pending list, making it difficult to
> distinguish between recovery
> methods, whether a queue reset or a full GPU reset was used.
>
> To improve this, we first try a soft recovery for timeout jobs and use the
> error code -ENODATA.
> If soft recovery fails, we proceed with a queue reset, where the error code
> remains -ENODATA for
> the job. Finally, for a full GPU reset, we use error codes -ECANCELED or
> -ETIME. This patch adds
> an error code parameter to drm_sched_start, allowing us to differentiate
> between queue reset and
> GPU reset failures. This enables user mode and test applications to validate
> the expected
> correctness of the requested operation. After a successful queue reset, the
> only way to continue
> normal operation is to call drm_sched_job_done with the specific error code
> -ENODATA.
>
> v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain
> and
> amdgpu_device_unlock_reset_domain to allow user mode to track the queue
> reset status and distinguish
> between queue reset and GPU reset.
> v2: Christian suggested using the error codes -ENODATA for queue reset and
> -ECANCELED or -ETIME for GPU
> reset, returned to amdgpu_cs_wait_ioctl.
> v3: To meet the requirements, we introduce a new function drm_sched_start_ex
> with an additional parameter
> to set dma_fence_set_error, allowing us to handle the specific error
> codes appropriately and dispose
> of bad jobs with the selected error code depending on whether it was a
> queue reset or GPU reset.
> v4: Alex suggested using a new name, drm_sched_start_with_recovery_error,
> which more accurately describes
> the function's purpose. Additionally, it was recommended to add
> documentation details about the new method.
>
> Cc: Alex Deucher
> Cc: Christian Koenig
> Signed-off-by: Jesse Zhang
> Signed-off-by: Vitaly Prosyak
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 30 +++---
> include/drm/gpu_scheduler.h| 1 +
> 2 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 7e90c9f95611..c42449358b3f 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -671,13 +671,24 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
> struct drm_sched_job *bad)
> EXPORT_SYMBOL(drm_sched_stop);
>
> /**
> - * drm_sched_start - recover jobs after a reset
> + * drm_sched_start_with_recovery_error - recover jobs after a reset with
> + * custom error
> *
> * @sched: scheduler instance
> * @full_recovery: proceed with complete sched restart
> + * @error : err code for set dma_fence_set_error
> + *
> + * Starts the scheduler and allows setting a custom dma_fence_set_error,
> + * which can be used to identify the recovery mechanism actually used.
> *
> + * For example:
> + * - If a soft or queue reset was used, dma_fence_set_error is set to
> -ENODATA.
> + * - If an entire GPU reset was used, the error code is set to -ECANCELED.
> + *
> + * This approach enables user mode and test applications to know which
> + * recovery method was used for a given bad job.
> */
> -void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery)
> +void drm_sched_start_with_recovery_error(struct drm_gpu_scheduler *sched,
> bool full_recovery, int error)
> {
> struct drm_sched_job *s_job, *tmp;
> int r;
> @@ -704,7 +715,7 @@ void drm_sched_start(struct drm_gpu_scheduler *sched,
> bool full_recovery)
> DRM_DEV_ERROR(sched->dev, "fence add callback
> failed (%d)\n",
> r);
> } else
> - drm_sched_job_done(s_job, -ECANCELED);
> + drm_sched_job_done(s_job, error);
> }
>
> if (full_recovery)
> @@ -712,6 +723,19 @@ void drm_sched_start(struct drm_gpu_scheduler *sched,
> bool full_recovery)
>
> drm_sched_wqueue_start(sched);
> }
> +EXPORT_SYMBOL(drm_sched_start_with_recovery_error);
> +
> +/**
> + * drm_sched_start - recover jobs after a reset
> + *
> + * @sched: scheduler instance
> + * @full_recovery: proceed with complete sched restart
> + *
> + */
> +void drm_sched_start(
Re: (subset) [PATCH v7 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
On Mon, 22 Jul 2024 08:53:32 +0200, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set the > optional voltage values according to the hardware. > The properties are: > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Also, add the audio power supply property which is dedicated for > the audio codec sub-device. > > [...] Applied, thanks! [03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC commit: 3821149eb101fe2d45a4697659e60930828400d8 -- Lee Jones [李琼斯]
Re: (subset) [PATCH RESEND v5 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
On Fri, 14 Jun 2024 09:27:46 +0200, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set the > optional voltage values according to the hardware. > The properties are: > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Also, add the audio power supply property which is dedicated for > the audio codec sub-device. > > [...] Applied, thanks! [03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC commit: 3821149eb101fe2d45a4697659e60930828400d8 -- Lee Jones [李琼斯]
Re: [PATCH v4 01/11] drm/amd/display: clean unused variables for hdmi freesync parser
Hi Melissa,
There are no commit messages in this patch.
Also, do you think this can be merged with Patch 5 "drm/amd/display:
remove redundant freesync parser for DP"?
On 2024-07-05 21:35, Melissa Wen wrote:
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 98cf523a629e..1dfa7ec9af35 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -12108,9 +12108,6 @@ void amdgpu_dm_update_freesync_caps(struct
drm_connector *connector,
} else if (edid && sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A) {
i = parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, _info);
if (i >= 0 && vsdb_info.freesync_supported) {
- timing = >detailed_timings[i];
- data= >data.other_data;
-
amdgpu_dm_connector->min_vfreq =
vsdb_info.min_refresh_rate_hz;
amdgpu_dm_connector->max_vfreq =
vsdb_info.max_refresh_rate_hz;
if (amdgpu_dm_connector->max_vfreq -
amdgpu_dm_connector->min_vfreq > 10)
[PATCH] drm/i915/guc: prevent a possible int overflow in wq offsets
It may be possible for the sum of the values derived from
i915_ggtt_offset() and __get_parent_scratch_offset()/
i915_ggtt_offset() to go over the u32 limit before being assigned
to wq offsets of u64 type.
Mitigate these issues by expanding one of the right operands
to u64 to avoid any overflow issues just in case.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Cc: sta...@vger.kernel.org
Signed-off-by: Nikita Zhandarovich
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9400d0eb682b..908ebfa22933 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2842,9 +2842,9 @@ static void prepare_context_registration_info_v70(struct
intel_context *ce,
ce->parallel.guc.wqi_tail = 0;
ce->parallel.guc.wqi_head = 0;
- wq_desc_offset = i915_ggtt_offset(ce->state) +
+ wq_desc_offset = (u64)i915_ggtt_offset(ce->state) +
__get_parent_scratch_offset(ce);
- wq_base_offset = i915_ggtt_offset(ce->state) +
+ wq_base_offset = (u64)i915_ggtt_offset(ce->state) +
__get_wq_offset(ce);
info->wq_desc_lo = lower_32_bits(wq_desc_offset);
info->wq_desc_hi = upper_32_bits(wq_desc_offset);
Re: (subset) [PATCH v1 0/4] Break some CMDS into helper functions
Hi, On Wed, 10 Jul 2024 16:47:11 +0800, Cong Yang wrote: > This series main purpose is to break some common CMDS into helper > functions (select page and reload CMDS), refer to the discussion > between Linus and Doug [1]. It is expected that there will be no > impact on the functionality, but I don’t have an actual board to > verify it. > > [1] > https://lore.kernel.org/dri-devel/CAD=FV=vssfzbxwh6i4e_mhht8vz_cnxcruhoetueo5xn-fm...@mail.gmail.com/ > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/4] drm/panel: boe-tv101wum-nl6: Break some CMDS into helper functions https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/93183c9959d456530ae502865586522acf21adf7 [2/4] drm/panel: nt35521: Break some CMDS into helper functions https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3c8d2d5da3e29f73fec6e04a424e789422f697db [3/4] drm/panel: nt36672e: Break some CMDS into helper functions https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d969b31afa439f71f810076a5612596dae38fd86 -- Neil
Re: [PATCH] drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll()
Hi,
On 7/25/24 01:17, Jani Nikula wrote:
> On Wed, 24 Jul 2024, Nikita Zhandarovich wrote:
>> On the off chance that clock value ends up being too high (by means
>> of skl_ddi_calculate_wrpll() having benn called with big enough
>> value of crtc_state->port_clock * 1000), one possible consequence
>> may be that the result will not be able to fit into signed int.
>>
>> Fix this, albeit unlikely, issue by first casting one of the operands
>> to u32, then to u64, and thus avoid causing an integer overflow.
>
> Okay, thanks for the patch, but please let's not do this.
>
> Currently the highest possible port clock is 200 kHz, and 1000 times
> that fits into 31 bits. When we need to support higher clocks, we'll
> need to handle this. But not like this.
>
> That (u64)(u32) is just too unintuitive, and assumes the caller has
> already passed in something that has overflown. People are just going to
> pause there, and wonder what's going on.
>
> If we want to appease the static analyzer, I think a better approach
> would be to change the parameter to u64 clock_hz, and have the caller
> do:
>
> ret = skl_ddi_calculate_wrpll((u64)crtc_state->port_clock * 1000,
> i915->display.dpll.ref_clks.nssc,
> _params);
>
> BR,
> Jani.
>
First, I agree that using (u64)(u32) is confusing and not intuitive,
even if there are some similar examples in kernel code.
The reason why I thought I had to opt for it though is the following: I
was worried that if the int value of 'clock' in
skl_ddi_calculate_wrpll() is big enough (specifically, high bit is 1),
then after casting it to long or u64 in this case, the resulting value
of wider type will have all its ~32 upper bits also set to 1, per rules
of Integer Promotion. Changing the type from signed to unsigned, then to
bigger unsigned seems to mitigate *this* particular issue and I can't
come up with a more elegant solution at the moment. Correct me if I'm
wrong somewhere.
Also, while port clock may be able to fit its value timed 1000 into 31
bits, multiplying it by 5 to get AFE Clock value, as far as I can see,
*will* lead to overflow, as 2,000,000,000 * 5 won't fit into 32 bits.
To sum it up, with current max possible port clock values an integer
overflow can occur and changing 'clock' parameter from int to u64 may
lead to a different issue. If my understanding about integer promotion
is flawed, I'll gladly send v2 patch with your solution.
Regards,
Nikita
>
>>
>> Found by Linux Verification Center (linuxtesting.org) with static
>> analysis tool SVACE.
>>
>> Fixes: fe70b262e781 ("drm/i915: Move a bunch of stuff into rodata from the
>> stack")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Nikita Zhandarovich
>> ---
>> Fixes: tag is not entirely correct, as I can't properly identify the
>> origin with all the code movement. I opted out for using the most
>> recent topical commit instead.
>>
>> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> index 90998b037349..46d4dac6c491 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
>> @@ -1683,7 +1683,7 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
>> };
>> unsigned int dco, d, i;
>> unsigned int p0, p1, p2;
>> -u64 afe_clock = clock * 5; /* AFE Clock is 5x Pixel clock */
>> +u64 afe_clock = (u64)(u32)clock * 5; /* AFE Clock is 5x Pixel clock */
>>
>> for (d = 0; d < ARRAY_SIZE(dividers); d++) {
>> for (dco = 0; dco < ARRAY_SIZE(dco_central_freq); dco++) {
>
Re: [PATCH] drm/sched: Only start TDR in drm_sched_job_begin on first job
On Thu, Jul 25, 2024 at 09:42:08AM +0200, Christian König wrote: > Am 25.07.24 um 01:44 schrieb Matthew Brost: > > Only start in drm_sched_job_begin on first job being added to the > > pending list as if pending list non-empty the TDR has already been > > started. It is problematic to restart the TDR as it will extend TDR > > period for an already running job, potentially leading to dma-fence > > signaling for a very long period of with continous stream of jobs. > > Mhm, that should be unnecessary. drm_sched_start_timeout() should only start > the timeout, but never re-start it. > That function checks the pending list for not empty, so it indeed starts it. Which is the correct behavior for some of the callers, e.g. drm_sched_tdr_queue_imm, drm_sched_get_finished_job IMO best to fix this here. Also FWIW on Xe I wrote a test which submitted a new ending spinner, then submitted a job every second on the same queue in a loop and observed the spinner not get canceled for a long time. After this patch, the spinner correctly timed out after 5 second (our default TDR period). Matt > Could be that this isn't working properly. > > Regards, > Christian. > > > > > Cc: Christian König > > Signed-off-by: Matthew Brost > > --- > > drivers/gpu/drm/scheduler/sched_main.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c > > b/drivers/gpu/drm/scheduler/sched_main.c > > index 7e90c9f95611..feeeb9dbeb86 100644 > > --- a/drivers/gpu/drm/scheduler/sched_main.c > > +++ b/drivers/gpu/drm/scheduler/sched_main.c > > @@ -540,7 +540,8 @@ static void drm_sched_job_begin(struct drm_sched_job > > *s_job) > > spin_lock(>job_list_lock); > > list_add_tail(_job->list, >pending_list); > > - drm_sched_start_timeout(sched); > > + if (list_is_singular(>pending_list)) > > + drm_sched_start_timeout(sched); > > spin_unlock(>job_list_lock); > > } >
[PATCH v3 12/12] drm/xe/spi: add support for access mode
Check SPI access mode from GSC FW status registers
and overwrite access status read from SPI descriptor, if needed.
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/xe/regs/xe_gsc_regs.h | 5
drivers/gpu/drm/xe/xe_heci_gsc.c | 5 +---
drivers/gpu/drm/xe/xe_spi.c | 33 ++-
3 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/xe/regs/xe_gsc_regs.h
b/drivers/gpu/drm/xe/regs/xe_gsc_regs.h
index e2a925be137c..28c049e60e66 100644
--- a/drivers/gpu/drm/xe/regs/xe_gsc_regs.h
+++ b/drivers/gpu/drm/xe/regs/xe_gsc_regs.h
@@ -16,6 +16,11 @@
#define MTL_GSC_HECI1_BASE 0x00116000
#define MTL_GSC_HECI2_BASE 0x00117000
+#define DG1_GSC_HECI2_BASE 0x00259000
+#define PVC_GSC_HECI2_BASE 0x00285000
+#define DG2_GSC_HECI2_BASE 0x00374000
+
+
#define HECI_H_CSR(base) XE_REG((base) + 0x4)
#define HECI_H_CSR_IEREG_BIT(0)
#define HECI_H_CSR_ISREG_BIT(1)
diff --git a/drivers/gpu/drm/xe/xe_heci_gsc.c b/drivers/gpu/drm/xe/xe_heci_gsc.c
index 65b2e147c4b9..27734085164e 100644
--- a/drivers/gpu/drm/xe/xe_heci_gsc.c
+++ b/drivers/gpu/drm/xe/xe_heci_gsc.c
@@ -11,14 +11,11 @@
#include "xe_device_types.h"
#include "xe_drv.h"
#include "xe_heci_gsc.h"
+#include "regs/xe_gsc_regs.h"
#include "xe_platform_types.h"
#define GSC_BAR_LENGTH 0x0FFC
-#define DG1_GSC_HECI2_BASE 0x259000
-#define PVC_GSC_HECI2_BASE 0x285000
-#define DG2_GSC_HECI2_BASE 0x374000
-
static void heci_gsc_irq_mask(struct irq_data *d)
{
/* generic irq handling */
diff --git a/drivers/gpu/drm/xe/xe_spi.c b/drivers/gpu/drm/xe/xe_spi.c
index f8ad060f97f2..9019672bd464 100644
--- a/drivers/gpu/drm/xe/xe_spi.c
+++ b/drivers/gpu/drm/xe/xe_spi.c
@@ -5,7 +5,10 @@
#include
#include
+#include "xe_device.h"
#include "xe_device_types.h"
+#include "xe_mmio.h"
+#include "regs/xe_gsc_regs.h"
#include "xe_spi.h"
#define GEN12_GUNIT_SPI_BASE 0x00102040
@@ -23,6 +26,34 @@ static void xe_spi_release_dev(struct device *dev)
{
}
+static bool xe_spi_writeable_override(struct xe_device *xe)
+{
+ struct xe_gt *gt = xe_root_mmio_gt(xe);
+ struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
+ resource_size_t base;
+ bool writeable_override;
+
+ if (xe->info.platform == XE_BATTLEMAGE) {
+ base = DG2_GSC_HECI2_BASE;
+ } else if (xe->info.platform == XE_PVC) {
+ base = PVC_GSC_HECI2_BASE;
+ } else if (xe->info.platform == XE_DG2) {
+ base = DG2_GSC_HECI2_BASE;
+ } else if (xe->info.platform == XE_DG1) {
+ base = DG1_GSC_HECI2_BASE;
+ } else {
+ dev_err(>dev, "Unknown platform\n");
+ return true;
+ }
+
+ writeable_override =
+ !(xe_mmio_read32(gt, HECI_H_GS1(base)) &
+ HECI_FW_STATUS_2_SPI_ACCESS_MODE);
+ if (writeable_override)
+ dev_info(>dev, "SPI access overridden by jumper\n");
+ return writeable_override;
+}
+
void xe_spi_init(struct xe_device *xe)
{
struct intel_dg_spi_dev *spi = >spi;
@@ -33,7 +64,7 @@ void xe_spi_init(struct xe_device *xe)
if (!HAS_GSC_SPI(xe))
return;
- spi->writeable_override = false;
+ spi->writeable_override = xe_spi_writeable_override(xe);
spi->bar.parent = >resource[0];
spi->bar.start = GEN12_GUNIT_SPI_BASE + pdev->resource[0].start;
spi->bar.end = spi->bar.start + GEN12_GUNIT_SPI_SIZE - 1;
--
2.34.1
[PATCH v3 11/12] drm/xe/spi: add on-die spi device
Enable access to internal spi on DGFX with GSC/CSC devices
via a child device.
The spi child device is exposed via auxiliary bus.
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/xe_device.c | 3 ++
drivers/gpu/drm/xe/xe_device_types.h | 8 +++
drivers/gpu/drm/xe/xe_pci.c | 5 ++
drivers/gpu/drm/xe/xe_spi.c | 73
drivers/gpu/drm/xe/xe_spi.h | 15 ++
6 files changed, 105 insertions(+)
create mode 100644 drivers/gpu/drm/xe/xe_spi.c
create mode 100644 drivers/gpu/drm/xe/xe_spi.h
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 1ff9602a52f6..f98e26b81035 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -95,6 +95,7 @@ xe-y += xe_bb.o \
xe_ring_ops.o \
xe_sa.o \
xe_sched_job.o \
+ xe_spi.o \
xe_step.o \
xe_sync.o \
xe_tile.o \
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 1aba6f9eaa19..7b7aee91497e 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -47,6 +47,7 @@
#include "xe_pcode.h"
#include "xe_pm.h"
#include "xe_query.h"
+#include "xe_spi.h"
#include "xe_sriov.h"
#include "xe_tile.h"
#include "xe_ttm_stolen_mgr.h"
@@ -720,6 +721,7 @@ int xe_device_probe(struct xe_device *xe)
goto err_fini_gt;
}
+ xe_spi_init(xe);
xe_heci_gsc_init(xe);
err = xe_oa_init(xe);
@@ -788,6 +790,7 @@ void xe_device_remove(struct xe_device *xe)
xe_oa_fini(xe);
xe_heci_gsc_fini(xe);
+ xe_spi_fini(xe);
for_each_gt(gt, xe, id)
xe_gt_remove(gt);
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index 5b7292a9a66d..69bd4cbbc588 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -12,6 +12,8 @@
#include
#include
+#include
+
#include "xe_devcoredump_types.h"
#include "xe_heci_gsc.h"
#include "xe_gt_types.h"
@@ -45,6 +47,7 @@ struct xe_pat_ops;
#define IS_DGFX(xe) ((xe)->info.is_dgfx)
#define HAS_HECI_GSCFI(xe) ((xe)->info.has_heci_gscfi)
#define HAS_HECI_CSCFI(xe) ((xe)->info.has_heci_cscfi)
+#define HAS_GSC_SPI(xe) ((xe)->info.has_gsc_spi)
#define XE_VRAM_FLAGS_NEED64K BIT(0)
@@ -292,6 +295,8 @@ struct xe_device {
u8 has_heci_gscfi:1;
/** @info.has_heci_cscfi: device has heci cscfi */
u8 has_heci_cscfi:1;
+ /** @info.has_gsc_spi: device has gsc spi */
+ u8 has_gsc_spi:1;
/** @info.skip_guc_pc: Skip GuC based PM feature init */
u8 skip_guc_pc:1;
/** @info.has_atomic_enable_pte_bit: Device has atomic enable
PTE bit */
@@ -473,6 +478,9 @@ struct xe_device {
/** @oa: oa observation subsystem */
struct xe_oa oa;
+ /** @spi: discrete graphics spi */
+ struct intel_dg_spi_dev spi;
+
/** @needs_flr_on_fini: requests function-reset on fini */
bool needs_flr_on_fini;
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 3c4a3c91377a..c74c36ee7fa6 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -60,6 +60,7 @@ struct xe_device_desc {
u8 has_display:1;
u8 has_heci_gscfi:1;
u8 has_heci_cscfi:1;
+ u8 has_gsc_spi:1;
u8 has_llc:1;
u8 has_mmio_ext:1;
u8 has_sriov:1;
@@ -283,6 +284,7 @@ static const struct xe_device_desc dg1_desc = {
PLATFORM(DG1),
.has_display = true,
.has_heci_gscfi = 1,
+ .has_gsc_spi = 1,
.require_force_probe = true,
};
@@ -294,6 +296,7 @@ static const u16 dg2_g12_ids[] = { XE_DG2_G12_IDS(NOP), 0 };
DGFX_FEATURES, \
PLATFORM(DG2), \
.has_heci_gscfi = 1, \
+ .has_gsc_spi = 1, \
.subplatforms = (const struct xe_subplatform_desc[]) { \
{ XE_SUBPLATFORM_DG2_G10, "G10", dg2_g10_ids }, \
{ XE_SUBPLATFORM_DG2_G11, "G11", dg2_g11_ids }, \
@@ -325,6 +328,7 @@ static const __maybe_unused struct xe_device_desc pvc_desc
= {
PLATFORM(PVC),
.has_display = false,
.has_heci_gscfi = 1,
+ .has_gsc_spi = 1,
.require_force_probe = true,
};
@@ -609,6 +613,7 @@ static int xe_info_init_early(struct xe_device *xe,
xe->info.is_dgfx = desc->is_dgfx;
xe->info.has_heci_gscfi = desc->has_heci_gscfi;
xe->info.has_heci_cscfi = desc->has_heci_cscfi;
+ xe->info.has_gsc_spi = desc->has_gsc_spi;
xe->info.has_llc = desc->has_llc;
xe->info.has_mmio_ext = desc->has_mmio_ext;
xe->info.has_sriov = desc->has_sriov;
diff --git a/drivers/gpu/drm/xe/xe_spi.c b/drivers/gpu/drm/xe/xe_spi.c
new file mode 100644
index ..f8ad060f97f2
--- /dev/null
+++
[PATCH v3 10/12] drm/i915/spi: add support for access mode
Check SPI access mode from GSC FW status registers
and overwrite access status read from SPI descriptor, if needed.
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/spi/intel_spi.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
b/drivers/gpu/drm/i915/spi/intel_spi.c
index 8dd4065551e2..747e43313c6f 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -10,6 +10,7 @@
#include "spi/intel_spi.h"
#define GEN12_GUNIT_SPI_SIZE 0x80
+#define HECI_FW_STATUS_2_SPI_ACCESS_MODE BIT(3)
static const struct intel_dg_spi_region regions[INTEL_DG_SPI_REGIONS] = {
[0] = { .name = "DESCRIPTOR", },
@@ -22,6 +23,29 @@ static void i915_spi_release_dev(struct device *dev)
{
}
+static bool i915_spi_writeable_override(struct drm_i915_private *dev_priv)
+{
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
+ resource_size_t base;
+ bool writeable_override;
+
+ if (IS_DG1(dev_priv)) {
+ base = DG1_GSC_HECI2_BASE;
+ } else if (IS_DG2(dev_priv)) {
+ base = DG2_GSC_HECI2_BASE;
+ } else {
+ dev_err(>dev, "Unknown platform\n");
+ return true;
+ }
+
+ writeable_override =
+ !(intel_uncore_read(_priv->uncore, HECI_FWSTS(base, 2)) &
+ HECI_FW_STATUS_2_SPI_ACCESS_MODE);
+ if (writeable_override)
+ dev_info(>dev, "SPI access overridden by jumper\n");
+ return writeable_override;
+}
+
void intel_spi_init(struct drm_i915_private *dev_priv)
{
struct intel_dg_spi_dev *spi = _priv->spi;
@@ -33,6 +57,7 @@ void intel_spi_init(struct drm_i915_private *dev_priv)
if (!IS_DGFX(dev_priv))
return;
+ spi->writeable_override = i915_spi_writeable_override(dev_priv);
spi->bar.parent = >resource[0];
spi->bar.start = GEN12_GUNIT_SPI_BASE + pdev->resource[0].start;
spi->bar.end = spi->bar.start + GEN12_GUNIT_SPI_SIZE - 1;
--
2.34.1
[PATCH v3 09/12] drm/i915/spi: add intel_spi_region map
From: Tomas Winkler
Add the dGFX spi region map and convey it via auxiliary device
to the spi child device.
CC: Rodrigo Vivi
CC: Lucas De Marchi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/spi/intel_spi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
b/drivers/gpu/drm/i915/spi/intel_spi.c
index 17e4c7861ef5..8dd4065551e2 100644
--- a/drivers/gpu/drm/i915/spi/intel_spi.c
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -11,6 +11,13 @@
#define GEN12_GUNIT_SPI_SIZE 0x80
+static const struct intel_dg_spi_region regions[INTEL_DG_SPI_REGIONS] = {
+ [0] = { .name = "DESCRIPTOR", },
+ [2] = { .name = "GSC", },
+ [11] = { .name = "OptionROM", },
+ [12] = { .name = "DAM", },
+};
+
static void i915_spi_release_dev(struct device *dev)
{
}
@@ -31,6 +38,7 @@ void intel_spi_init(struct drm_i915_private *dev_priv)
spi->bar.end = spi->bar.start + GEN12_GUNIT_SPI_SIZE - 1;
spi->bar.flags = IORESOURCE_MEM;
spi->bar.desc = IORES_DESC_NONE;
+ spi->regions = regions;
aux_dev->name = "spi";
aux_dev->id = (pci_domain_nr(pdev->bus) << 16) |
--
2.34.1
[PATCH v3 08/12] drm/i915/spi: add spi device for discrete graphics
From: Tomas Winkler
Enable access to internal spi on DGFX devices via a child device.
The spi child device is exposed via auxiliary bus.
CC: Rodrigo Vivi
CC: Lucas De Marchi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/Makefile| 4 ++
drivers/gpu/drm/i915/i915_driver.c | 6 +++
drivers/gpu/drm/i915/i915_drv.h | 4 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/spi/intel_spi.c | 64
drivers/gpu/drm/i915/spi/intel_spi.h | 15 +++
6 files changed, 94 insertions(+)
create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c
create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c63fa2133ccb..02a9faf049a7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -211,6 +211,10 @@ i915-y += \
i915-y += \
gt/intel_gsc.o
+# graphics spi device (DGFX) support
+i915-y += \
+ spi/intel_spi.o
+
# graphics hardware monitoring (HWMON) support
i915-$(CONFIG_HWMON) += \
i915_hwmon.o
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 161b21eff694..49916a586dac 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,8 @@
#include "soc/intel_dram.h"
#include "soc/intel_gmch.h"
+#include "spi/intel_spi.h"
+
#include "i915_debugfs.h"
#include "i915_driver.h"
#include "i915_drm_client.h"
@@ -619,6 +621,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
/* Depends on sysfs having been initialized */
i915_perf_register(dev_priv);
+ intel_spi_init(dev_priv);
+
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
@@ -662,6 +666,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
i915_hwmon_unregister(dev_priv);
+ intel_spi_fini(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d1d21d433766..dd48fae4efe0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -34,6 +34,8 @@
#include
+#include
+
#include
#include "display/intel_display_limits.h"
@@ -315,6 +317,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct intel_dg_spi_dev spi;
+
struct i915_hwmon *hwmon;
struct intel_gt *gt[I915_MAX_GT];
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e4478194d11..50dc19c58666 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -323,6 +323,7 @@
#define DG2_GSC_HECI2_BASE 0x00374000
#define MTL_GSC_HECI1_BASE 0x00116000
#define MTL_GSC_HECI2_BASE 0x00117000
+#define GEN12_GUNIT_SPI_BASE 0x00102040
#define HECI_H_CSR(base) _MMIO((base) + 0x4)
#define HECI_H_CSR_IEREG_BIT(0)
diff --git a/drivers/gpu/drm/i915/spi/intel_spi.c
b/drivers/gpu/drm/i915/spi/intel_spi.c
new file mode 100644
index ..17e4c7861ef5
--- /dev/null
+++ b/drivers/gpu/drm/i915/spi/intel_spi.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2024, Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "spi/intel_spi.h"
+
+#define GEN12_GUNIT_SPI_SIZE 0x80
+
+static void i915_spi_release_dev(struct device *dev)
+{
+}
+
+void intel_spi_init(struct drm_i915_private *dev_priv)
+{
+ struct intel_dg_spi_dev *spi = _priv->spi;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
+ struct auxiliary_device *aux_dev = >aux_dev;
+ int ret;
+
+ /* Only the DGFX devices have internal SPI */
+ if (!IS_DGFX(dev_priv))
+ return;
+
+ spi->bar.parent = >resource[0];
+ spi->bar.start = GEN12_GUNIT_SPI_BASE + pdev->resource[0].start;
+ spi->bar.end = spi->bar.start + GEN12_GUNIT_SPI_SIZE - 1;
+ spi->bar.flags = IORESOURCE_MEM;
+ spi->bar.desc = IORES_DESC_NONE;
+
+ aux_dev->name = "spi";
+ aux_dev->id = (pci_domain_nr(pdev->bus) << 16) |
+ PCI_DEVID(pdev->bus->number, pdev->devfn);
+ aux_dev->dev.parent = >dev;
+ aux_dev->dev.release = i915_spi_release_dev;
+
+ ret = auxiliary_device_init(aux_dev);
+ if (ret) {
+ dev_err(>dev, "i915-spi aux init failed %d\n", ret);
+ return;
+ }
+
+ ret = auxiliary_device_add(aux_dev);
+ if (ret) {
+ dev_err(>dev, "i915-spi aux add failed %d\n", ret);
+ auxiliary_device_uninit(aux_dev);
+ return;
+ }
+}
+
+void intel_spi_fini(struct drm_i915_private *dev_priv)
+{
+ struct intel_dg_spi_dev *spi = _priv->spi;
+ struct pci_dev
[PATCH v3 07/12] spi: intel-dg: wake card on operations
Enable runtime PM in spi driver to notify graphics driver that
whole card should be kept awake while spi operations are
performed through this driver.
CC: Lucas De Marchi
Signed-off-by: Alexander Usyskin
---
drivers/spi/spi-intel-dg.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
index 534e99cb336d..9671c4ec01a9 100644
--- a/drivers/spi/spi-intel-dg.c
+++ b/drivers/spi/spi-intel-dg.c
@@ -12,11 +12,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#define INTEL_DG_SPI_RPM_TIMEOUT 500
+
struct intel_dg_spi {
struct kref refcnt;
struct mtd_info mtd;
@@ -471,6 +474,12 @@ static int intel_dg_spi_erase(struct mtd_info *mtd, struct
erase_info *info)
total_len = info->len;
addr = info->addr;
+ ret = pm_runtime_resume_and_get(mtd->dev.parent);
+ if (ret < 0) {
+ dev_err(>dev, "rpm: get failed %d\n", ret);
+ return ret;
+ }
+
mutex_lock(>lock);
while (total_len > 0) {
@@ -512,6 +521,8 @@ static int intel_dg_spi_erase(struct mtd_info *mtd, struct
erase_info *info)
out:
mutex_unlock(>lock);
+ pm_runtime_mark_last_busy(mtd->dev.parent);
+ pm_runtime_put_autosuspend(mtd->dev.parent);
return ret;
}
@@ -545,6 +556,12 @@ static int intel_dg_spi_read(struct mtd_info *mtd, loff_t
from, size_t len,
if (len > spi->regions[idx].size - from)
len = spi->regions[idx].size - from;
+ ret = pm_runtime_resume_and_get(mtd->dev.parent);
+ if (ret < 0) {
+ dev_err(>dev, "rpm: get failed %zd\n", ret);
+ return ret;
+ }
+
mutex_lock(>lock);
ret = spi_read(spi, region, from, len, buf);
@@ -557,6 +574,8 @@ static int intel_dg_spi_read(struct mtd_info *mtd, loff_t
from, size_t len,
*retlen = ret;
mutex_unlock(>lock);
+ pm_runtime_mark_last_busy(mtd->dev.parent);
+ pm_runtime_put_autosuspend(mtd->dev.parent);
return 0;
}
@@ -590,6 +609,12 @@ static int intel_dg_spi_write(struct mtd_info *mtd, loff_t
to, size_t len,
if (len > spi->regions[idx].size - to)
len = spi->regions[idx].size - to;
+ ret = pm_runtime_resume_and_get(mtd->dev.parent);
+ if (ret < 0) {
+ dev_err(>dev, "rpm: get failed %zd\n", ret);
+ return ret;
+ }
+
mutex_lock(>lock);
ret = spi_write(spi, region, to, len, buf);
@@ -602,6 +627,8 @@ static int intel_dg_spi_write(struct mtd_info *mtd, loff_t
to, size_t len,
*retlen = ret;
mutex_unlock(>lock);
+ pm_runtime_mark_last_busy(mtd->dev.parent);
+ pm_runtime_put_autosuspend(mtd->dev.parent);
return 0;
}
@@ -747,6 +774,17 @@ static int intel_dg_spi_probe(struct auxiliary_device
*aux_dev,
}
}
+ pm_runtime_enable(device);
+
+ pm_runtime_set_autosuspend_delay(device, INTEL_DG_SPI_RPM_TIMEOUT);
+ pm_runtime_use_autosuspend(device);
+
+ ret = pm_runtime_resume_and_get(device);
+ if (ret < 0) {
+ dev_err(device, "rpm: get failed %d\n", ret);
+ goto err_norpm;
+ }
+
spi->base = devm_ioremap_resource(device, >bar);
if (IS_ERR(spi->base)) {
dev_err(device, "mmio not mapped\n");
@@ -769,9 +807,13 @@ static int intel_dg_spi_probe(struct auxiliary_device
*aux_dev,
dev_set_drvdata(_dev->dev, spi);
+ pm_runtime_put(device);
return 0;
err:
+ pm_runtime_put(device);
+err_norpm:
+ pm_runtime_disable(device);
kref_put(>refcnt, intel_dg_spi_release);
return ret;
}
@@ -783,6 +825,8 @@ static void intel_dg_spi_remove(struct auxiliary_device
*aux_dev)
if (!spi)
return;
+ pm_runtime_disable(_dev->dev);
+
mtd_device_unregister(>mtd);
dev_set_drvdata(_dev->dev, NULL);
--
2.34.1
[PATCH v3 06/12] spi: intel-dg: align 64bit read and write
GSC SPI HW errors on quad access overlapping 1K border.
Align 64bit read and write to avoid readq/writeq over 1K border.
Signed-off-by: Alexander Usyskin
---
drivers/spi/spi-intel-dg.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
index dc4d6c573522..534e99cb336d 100644
--- a/drivers/spi/spi-intel-dg.c
+++ b/drivers/spi/spi-intel-dg.c
@@ -231,6 +231,24 @@ static ssize_t spi_write(struct intel_dg_spi *spi, u8
region,
len_s -= to_shift;
}
+ if (!IS_ALIGNED(to, sizeof(u64)) &&
+ ((to ^ (to + len_s)) & GENMASK(31, 10))) {
+ /*
+* Workaround reads/writes across 1k-aligned addresses
+* (start u32 before 1k, end u32 after)
+* as this fails on hardware.
+*/
+ u32 data;
+
+ memcpy(, [0], sizeof(u32));
+ spi_write32(spi, to, data);
+ if (spi_error(spi))
+ return -EIO;
+ buf += sizeof(u32);
+ to += sizeof(u32);
+ len_s -= sizeof(u32);
+ }
+
len8 = ALIGN_DOWN(len_s, sizeof(u64));
for (i = 0; i < len8; i += sizeof(u64)) {
u64 data;
@@ -289,6 +307,23 @@ static ssize_t spi_read(struct intel_dg_spi *spi, u8
region,
from += from_shift;
}
+ if (!IS_ALIGNED(from, sizeof(u64)) &&
+ ((from ^ (from + len_s)) & GENMASK(31, 10))) {
+ /*
+* Workaround reads/writes across 1k-aligned addresses
+* (start u32 before 1k, end u32 after)
+* as this fails on hardware.
+*/
+ u32 data = spi_read32(spi, from);
+
+ if (spi_error(spi))
+ return -EIO;
+ memcpy([0], , sizeof(data));
+ len_s -= sizeof(u32);
+ buf += sizeof(u32);
+ from += sizeof(u32);
+ }
+
len8 = ALIGN_DOWN(len_s, sizeof(u64));
for (i = 0; i < len8; i += sizeof(u64)) {
u64 data = spi_read64(spi, from + i);
--
2.34.1
[PATCH v3 05/12] spi: intel-dg: implement mtd access handlers
From: Tomas Winkler
Implement mtd read, erase, and write handlers.
For erase operation address and size should be 4K aligned.
For write operation address and size has to be 4bytes aligned.
CC: Rodrigo Vivi
CC: Lucas De Marchi
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Alexander Usyskin
---
drivers/spi/spi-intel-dg.c | 152 +++--
1 file changed, 147 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
index 2ffc2d61fdc8..dc4d6c573522 100644
--- a/drivers/spi/spi-intel-dg.c
+++ b/drivers/spi/spi-intel-dg.c
@@ -174,7 +174,6 @@ static int intel_dg_spi_is_valid(struct intel_dg_spi *spi)
return 0;
}
-__maybe_unused
static unsigned int spi_get_region(const struct intel_dg_spi *spi, loff_t from)
{
unsigned int i;
@@ -206,7 +205,6 @@ static ssize_t spi_rewrite_partial(struct intel_dg_spi
*spi, loff_t to,
return len;
}
-__maybe_unused
static ssize_t spi_write(struct intel_dg_spi *spi, u8 region,
loff_t to, size_t len, const unsigned char *buf)
{
@@ -265,7 +263,6 @@ static ssize_t spi_write(struct intel_dg_spi *spi, u8
region,
return len;
}
-__maybe_unused
static ssize_t spi_read(struct intel_dg_spi *spi, u8 region,
loff_t from, size_t len, unsigned char *buf)
{
@@ -324,7 +321,6 @@ static ssize_t spi_read(struct intel_dg_spi *spi, u8 region,
return len;
}
-__maybe_unused
static ssize_t
spi_erase(struct intel_dg_spi *spi, u8 region, loff_t from, u64 len, u64
*fail_addr)
{
@@ -413,18 +409,164 @@ static int intel_dg_spi_init(struct intel_dg_spi *spi,
struct device *device)
static int intel_dg_spi_erase(struct mtd_info *mtd, struct erase_info *info)
{
- return 0;
+ struct intel_dg_spi *spi;
+ unsigned int idx;
+ u8 region;
+ u64 addr;
+ ssize_t bytes;
+ loff_t from;
+ size_t len;
+ size_t total_len;
+ int ret = 0;
+
+ if (!mtd || !info)
+ return -EINVAL;
+
+ spi = mtd->priv;
+ if (WARN_ON(!spi))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(info->addr, SZ_4K) || !IS_ALIGNED(info->len, SZ_4K)) {
+ dev_err(>dev, "unaligned erase %llx %llx\n",
+ info->addr, info->len);
+ info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+ return -EINVAL;
+ }
+
+ total_len = info->len;
+ addr = info->addr;
+
+ mutex_lock(>lock);
+
+ while (total_len > 0) {
+ if (!IS_ALIGNED(addr, SZ_4K) || !IS_ALIGNED(total_len, SZ_4K)) {
+ dev_err(>dev, "unaligned erase %llx %zx\n", addr,
total_len);
+ info->fail_addr = addr;
+ ret = -ERANGE;
+ goto out;
+ }
+
+ idx = spi_get_region(spi, addr);
+ if (idx >= spi->nregions) {
+ dev_err(>dev, "out of range");
+ info->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
+ ret = -ERANGE;
+ goto out;
+ }
+
+ from = addr - spi->regions[idx].offset;
+ region = spi->regions[idx].id;
+ len = total_len;
+ if (len > spi->regions[idx].size - from)
+ len = spi->regions[idx].size - from;
+
+ dev_dbg(>dev, "erasing region[%d] %s from %llx len %zx\n",
+ region, spi->regions[idx].name, from, len);
+
+ bytes = spi_erase(spi, region, from, len, >fail_addr);
+ if (bytes < 0) {
+ dev_dbg(>dev, "erase failed with %zd\n", bytes);
+ info->fail_addr += spi->regions[idx].offset;
+ ret = bytes;
+ goto out;
+ }
+
+ addr += len;
+ total_len -= len;
+ }
+
+out:
+ mutex_unlock(>lock);
+ return ret;
}
static int intel_dg_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
+ struct intel_dg_spi *spi;
+ ssize_t ret;
+ unsigned int idx;
+ u8 region;
+
+ if (!mtd)
+ return -EINVAL;
+
+ spi = mtd->priv;
+ if (WARN_ON(!spi))
+ return -EINVAL;
+
+ idx = spi_get_region(spi, from);
+
+ dev_dbg(>dev, "reading region[%d] %s from %lld len %zd\n",
+ spi->regions[idx].id, spi->regions[idx].name, from, len);
+
+ if (idx >= spi->nregions) {
+ dev_err(>dev, "out of ragnge");
+ return -ERANGE;
+ }
+
+ from -= spi->regions[idx].offset;
+ region = spi->regions[idx].id;
+ if (len > spi->regions[idx].size - from)
+ len = spi->regions[idx].size - from;
+
+ mutex_lock(>lock);
+
+ ret =
[PATCH v3 04/12] spi: intel-dg: spi register with mtd
From: Tomas Winkler
Register the on-die spi device with the mtd subsystem.
Refcount spi object on _get and _put mtd callbacks.
CC: Rodrigo Vivi
CC: Lucas De Marchi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/spi/spi-intel-dg.c | 111 +
1 file changed, 111 insertions(+)
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
index 63c8292347e7..2ffc2d61fdc8 100644
--- a/drivers/spi/spi-intel-dg.c
+++ b/drivers/spi/spi-intel-dg.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -17,6 +19,8 @@
struct intel_dg_spi {
struct kref refcnt;
+ struct mtd_info mtd;
+ struct mutex lock; /* region access lock */
void __iomem *base;
size_t size;
unsigned int nregions;
@@ -407,6 +411,23 @@ static int intel_dg_spi_init(struct intel_dg_spi *spi,
struct device *device)
return n;
}
+static int intel_dg_spi_erase(struct mtd_info *mtd, struct erase_info *info)
+{
+ return 0;
+}
+
+static int intel_dg_spi_read(struct mtd_info *mtd, loff_t from, size_t len,
+size_t *retlen, u_char *buf)
+{
+ return 0;
+}
+
+static int intel_dg_spi_write(struct mtd_info *mtd, loff_t to, size_t len,
+ size_t *retlen, const u_char *buf)
+{
+ return 0;
+}
+
static void intel_dg_spi_release(struct kref *kref)
{
struct intel_dg_spi *spi = container_of(kref, struct intel_dg_spi,
refcnt);
@@ -415,9 +436,90 @@ static void intel_dg_spi_release(struct kref *kref)
pr_debug("freeing spi memory\n");
for (i = 0; i < spi->nregions; i++)
kfree(spi->regions[i].name);
+ mutex_destroy(>lock);
kfree(spi);
}
+static int intel_dg_spi_get_device(struct mtd_info *mtd)
+{
+ struct mtd_info *master;
+ struct intel_dg_spi *spi;
+
+ if (!mtd)
+ return -ENODEV;
+
+ master = mtd_get_master(mtd);
+ spi = master->priv;
+ if (WARN_ON(!spi))
+ return -EINVAL;
+ pr_debug("get spi %s %d\n", mtd->name, kref_read(>refcnt));
+ kref_get(>refcnt);
+
+ return 0;
+}
+
+static void intel_dg_spi_put_device(struct mtd_info *mtd)
+{
+ struct mtd_info *master;
+ struct intel_dg_spi *spi;
+
+ if (!mtd)
+ return;
+
+ master = mtd_get_master(mtd);
+ spi = master->priv;
+ if (WARN_ON(!spi))
+ return;
+ pr_debug("put spi %s %d\n", mtd->name, kref_read(>refcnt));
+ kref_put(>refcnt, intel_dg_spi_release);
+}
+
+static int intel_dg_spi_init_mtd(struct intel_dg_spi *spi, struct device
*device,
+unsigned int nparts, bool writeable_override)
+{
+ unsigned int i;
+ unsigned int n;
+ struct mtd_partition *parts = NULL;
+ int ret;
+
+ dev_dbg(device, "registering with mtd\n");
+
+ spi->mtd.owner = THIS_MODULE;
+ spi->mtd.dev.parent = device;
+ spi->mtd.flags = MTD_CAP_NORFLASH | MTD_WRITEABLE;
+ spi->mtd.type = MTD_DATAFLASH;
+ spi->mtd.priv = spi;
+ spi->mtd._write = intel_dg_spi_write;
+ spi->mtd._read = intel_dg_spi_read;
+ spi->mtd._erase = intel_dg_spi_erase;
+ spi->mtd._get_device = intel_dg_spi_get_device;
+ spi->mtd._put_device = intel_dg_spi_put_device;
+ spi->mtd.writesize = SZ_1; /* 1 byte granularity */
+ spi->mtd.erasesize = SZ_4K; /* 4K bytes granularity */
+ spi->mtd.size = spi->size;
+
+ parts = kcalloc(spi->nregions, sizeof(*parts), GFP_KERNEL);
+ if (!parts)
+ return -ENOMEM;
+
+ for (i = 0, n = 0; i < spi->nregions && n < nparts; i++) {
+ if (!spi->regions[i].is_readable)
+ continue;
+ parts[n].name = spi->regions[i].name;
+ parts[n].offset = spi->regions[i].offset;
+ parts[n].size = spi->regions[i].size;
+ if (!spi->regions[i].is_writable && !writeable_override)
+ parts[n].mask_flags = MTD_WRITEABLE;
+ n++;
+ }
+
+ ret = mtd_device_register(>mtd, parts, n);
+
+ kfree(parts);
+
+ return ret;
+}
+
static int intel_dg_spi_probe(struct auxiliary_device *aux_dev,
const struct auxiliary_device_id *aux_dev_id)
{
@@ -449,6 +551,7 @@ static int intel_dg_spi_probe(struct auxiliary_device
*aux_dev,
if (!spi)
return -ENOMEM;
+ mutex_init(>lock);
kref_init(>refcnt);
spi->nregions = nregions;
@@ -481,6 +584,12 @@ static int intel_dg_spi_probe(struct auxiliary_device
*aux_dev,
goto err;
}
+ ret = intel_dg_spi_init_mtd(spi, device, ret, ispi->writeable_override);
+ if (ret) {
+ dev_err(device, "failed init mtd %d\n", ret);
+ goto err;
+ }
+
[PATCH v3 03/12] spi: intel-dg: implement spi access functions
From: Tomas Winkler
Implement spi_read(), spi_erase() and spi_write() functions.
CC: Lucas De Marchi
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Alexander Usyskin
---
drivers/spi/spi-intel-dg.c | 199 +
1 file changed, 199 insertions(+)
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
index 1da8f527d47c..63c8292347e7 100644
--- a/drivers/spi/spi-intel-dg.c
+++ b/drivers/spi/spi-intel-dg.c
@@ -3,13 +3,16 @@
* Copyright(c) 2019-2024, Intel Corporation. All rights reserved.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
struct intel_dg_spi {
@@ -84,6 +87,33 @@ static inline u32 spi_read32(struct intel_dg_spi *spi, u32
address)
return ioread32(base + SPI_TRIGGER_REG);
}
+static inline u64 spi_read64(struct intel_dg_spi *spi, u32 address)
+{
+ void __iomem *base = spi->base;
+
+ iowrite32(address, base + SPI_ADDRESS_REG);
+
+ return readq(base + SPI_TRIGGER_REG);
+}
+
+static void spi_write32(struct intel_dg_spi *spi, u32 address, u32 data)
+{
+ void __iomem *base = spi->base;
+
+ iowrite32(address, base + SPI_ADDRESS_REG);
+
+ iowrite32(data, base + SPI_TRIGGER_REG);
+}
+
+static void spi_write64(struct intel_dg_spi *spi, u32 address, u64 data)
+{
+ void __iomem *base = spi->base;
+
+ iowrite32(address, base + SPI_ADDRESS_REG);
+
+ writeq(data, base + SPI_TRIGGER_REG);
+}
+
static int spi_get_access_map(struct intel_dg_spi *spi)
{
u32 flmap1;
@@ -140,6 +170,175 @@ static int intel_dg_spi_is_valid(struct intel_dg_spi *spi)
return 0;
}
+__maybe_unused
+static unsigned int spi_get_region(const struct intel_dg_spi *spi, loff_t from)
+{
+ unsigned int i;
+
+ for (i = 0; i < spi->nregions; i++) {
+ if ((spi->regions[i].offset + spi->regions[i].size - 1) > from
&&
+ spi->regions[i].offset <= from &&
+ spi->regions[i].size != 0)
+ break;
+ }
+
+ return i;
+}
+
+static ssize_t spi_rewrite_partial(struct intel_dg_spi *spi, loff_t to,
+ loff_t offset, size_t len, const u32 *newdata)
+{
+ u32 data = spi_read32(spi, to);
+
+ if (spi_error(spi))
+ return -EIO;
+
+ memcpy((u8 *) + offset, newdata, len);
+
+ spi_write32(spi, to, data);
+ if (spi_error(spi))
+ return -EIO;
+
+ return len;
+}
+
+__maybe_unused
+static ssize_t spi_write(struct intel_dg_spi *spi, u8 region,
+loff_t to, size_t len, const unsigned char *buf)
+{
+ size_t i;
+ size_t len8;
+ size_t len4;
+ size_t to4;
+ size_t to_shift;
+ size_t len_s = len;
+ ssize_t ret;
+
+ spi_set_region_id(spi, region);
+
+ to4 = ALIGN_DOWN(to, sizeof(u32));
+ to_shift = min(sizeof(u32) - ((size_t)to - to4), len);
+ if (to - to4) {
+ ret = spi_rewrite_partial(spi, to4, to - to4, to_shift,
+ (uint32_t *)[0]);
+ if (ret < 0)
+ return ret;
+
+ buf += to_shift;
+ to += to_shift;
+ len_s -= to_shift;
+ }
+
+ len8 = ALIGN_DOWN(len_s, sizeof(u64));
+ for (i = 0; i < len8; i += sizeof(u64)) {
+ u64 data;
+
+ memcpy(, [i], sizeof(u64));
+ spi_write64(spi, to + i, data);
+ if (spi_error(spi))
+ return -EIO;
+ }
+
+ len4 = len_s - len8;
+ if (len4 >= sizeof(u32)) {
+ u32 data;
+
+ memcpy(, [i], sizeof(u32));
+ spi_write32(spi, to + i, data);
+ if (spi_error(spi))
+ return -EIO;
+ i += sizeof(u32);
+ len4 -= sizeof(u32);
+ }
+
+ if (len4 > 0) {
+ ret = spi_rewrite_partial(spi, to + i, 0, len4,
+ (uint32_t *)[i]);
+ if (ret < 0)
+ return ret;
+ }
+
+ return len;
+}
+
+__maybe_unused
+static ssize_t spi_read(struct intel_dg_spi *spi, u8 region,
+ loff_t from, size_t len, unsigned char *buf)
+{
+ size_t i;
+ size_t len8;
+ size_t len4;
+ size_t from4;
+ size_t from_shift;
+ size_t len_s = len;
+
+ spi_set_region_id(spi, region);
+
+ from4 = ALIGN_DOWN(from, sizeof(u32));
+ from_shift = min(sizeof(u32) - ((size_t)from - from4), len);
+
+ if (from - from4) {
+ u32 data = spi_read32(spi, from4);
+
+ if (spi_error(spi))
+ return -EIO;
+ memcpy([0], (u8 *) + (from - from4), from_shift);
+ len_s -= from_shift;
+ buf
[PATCH v3 02/12] spi: intel-dg: implement region enumeration
From: Tomas Winkler
In intel-dg spi, there is no access to the spi controller,
the information is extracted from the descriptor region.
CC: Rodrigo Vivi
CC: Lucas De Marchi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/spi/spi-intel-dg.c | 190 +
1 file changed, 190 insertions(+)
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
index 7a00d222bb72..1da8f527d47c 100644
--- a/drivers/spi/spi-intel-dg.c
+++ b/drivers/spi/spi-intel-dg.c
@@ -17,14 +17,197 @@ struct intel_dg_spi {
void __iomem *base;
size_t size;
unsigned int nregions;
+ u32 access_map;
struct {
const char *name;
u8 id;
u64 offset;
u64 size;
+ unsigned int is_readable:1;
+ unsigned int is_writable:1;
} regions[];
};
+#define SPI_TRIGGER_REG 0x
+#define SPI_VALSIG_REG0x0010
+#define SPI_ADDRESS_REG 0x0040
+#define SPI_REGION_ID_REG 0x0044
+/*
+ * [15:0]-Erase size = 0x0010 4K 0x0080 32K 0x0100 64K
+ * [23:16]-Reserved
+ * [31:24]-Erase SPI RegionID
+ */
+#define SPI_ERASE_REG 0x0048
+#define SPI_ACCESS_ERROR_REG 0x0070
+#define SPI_ADDRESS_ERROR_REG 0x0074
+
+/* Flash Valid Signature */
+#define SPI_FLVALSIG 0x0FF0A55A
+
+#define SPI_MAP_ADDR_MASK 0x00FF
+#define SPI_MAP_ADDR_SHIFT0x0004
+
+#define REGION_ID_DESCRIPTOR 0
+/* Flash Region Base Address */
+#define FRBA 0x40
+/* Flash Region __n - Flash Descriptor Record */
+#define FLREG(__n) (FRBA + ((__n) * 4))
+/* Flash Map 1 Register */
+#define FLMAP1_REG 0x18
+#define FLMSTR4_OFFSET 0x00C
+
+#define SPI_ACCESS_ERROR_PCIE_MASK 0x7
+
+static inline void spi_set_region_id(struct intel_dg_spi *spi, u8 region)
+{
+ iowrite32((u32)region, spi->base + SPI_REGION_ID_REG);
+}
+
+static inline u32 spi_error(struct intel_dg_spi *spi)
+{
+ u32 reg = ioread32(spi->base + SPI_ACCESS_ERROR_REG) &
+ SPI_ACCESS_ERROR_PCIE_MASK;
+
+ /* reset error bits */
+ if (reg)
+ iowrite32(reg, spi->base + SPI_ACCESS_ERROR_REG);
+
+ return reg;
+}
+
+static inline u32 spi_read32(struct intel_dg_spi *spi, u32 address)
+{
+ void __iomem *base = spi->base;
+
+ iowrite32(address, base + SPI_ADDRESS_REG);
+
+ return ioread32(base + SPI_TRIGGER_REG);
+}
+
+static int spi_get_access_map(struct intel_dg_spi *spi)
+{
+ u32 flmap1;
+ u32 fmba;
+ u32 fmstr4;
+ u32 fmstr4_addr;
+
+ spi_set_region_id(spi, REGION_ID_DESCRIPTOR);
+
+ flmap1 = spi_read32(spi, FLMAP1_REG);
+ if (spi_error(spi))
+ return -EIO;
+ /* Get Flash Master Baser Address (FMBA) */
+ fmba = ((flmap1 & SPI_MAP_ADDR_MASK) << SPI_MAP_ADDR_SHIFT);
+ fmstr4_addr = fmba + FLMSTR4_OFFSET;
+
+ fmstr4 = spi_read32(spi, fmstr4_addr);
+ if (spi_error(spi))
+ return -EIO;
+
+ spi->access_map = fmstr4;
+ return 0;
+}
+
+static bool spi_region_readable(struct intel_dg_spi *spi, u8 region)
+{
+ if (region < 12)
+ return spi->access_map & (1 << (region + 8)); /* [19:8] */
+ else
+ return spi->access_map & (1 << (region - 12)); /* [3:0] */
+}
+
+static bool spi_region_writeable(struct intel_dg_spi *spi, u8 region)
+{
+ if (region < 12)
+ return spi->access_map & (1 << (region + 20)); /* [31:20] */
+ else
+ return spi->access_map & (1 << (region - 8)); /* [7:4] */
+}
+
+static int intel_dg_spi_is_valid(struct intel_dg_spi *spi)
+{
+ u32 is_valid;
+
+ spi_set_region_id(spi, REGION_ID_DESCRIPTOR);
+
+ is_valid = spi_read32(spi, SPI_VALSIG_REG);
+ if (spi_error(spi))
+ return -EIO;
+
+ if (is_valid != SPI_FLVALSIG)
+ return -ENODEV;
+
+ return 0;
+}
+
+static int intel_dg_spi_init(struct intel_dg_spi *spi, struct device *device)
+{
+ int ret;
+ unsigned int i, n;
+
+ /* clean error register, previous errors are ignored */
+ spi_error(spi);
+
+ ret = intel_dg_spi_is_valid(spi);
+ if (ret) {
+ dev_err(device, "The SPI is not valid %d\n", ret);
+ return ret;
+ }
+
+ if (spi_get_access_map(spi))
+ return -EIO;
+
+ for (i = 0, n = 0; i < spi->nregions; i++) {
+ u32 address, base, limit, region;
+ u8 id = spi->regions[i].id;
+
+ address = FLREG(id);
+ region = spi_read32(spi, address);
+
+ base = (region & 0x) << 12;
+ limit = (((region & 0x) >> 16) << 12) | 0xFFF;
+
+ dev_dbg(device, "[%d] %s: region: 0x%08X base: 0x%08x limit:
0x%08x\n",
+ id, spi->regions[i].name, region, base, limit);
+
+ if
[PATCH v3 01/12] spi: add driver for intel graphics on-die spi device
Add auxiliary driver for intel discrete graphics
on-die spi device.
CC: Rodrigo Vivi
CC: Lucas De Marchi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
MAINTAINERS | 7 ++
drivers/spi/Kconfig | 11 +++
drivers/spi/Makefile | 1 +
drivers/spi/spi-intel-dg.c | 142 +++
include/linux/intel_dg_spi_aux.h | 27 ++
5 files changed, 188 insertions(+)
create mode 100644 drivers/spi/spi-intel-dg.c
create mode 100644 include/linux/intel_dg_spi_aux.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 082483b40fac..90e06701f988 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11003,6 +11003,13 @@ L: linux-ker...@vger.kernel.org
S: Supported
F: arch/x86/include/asm/intel-family.h
+INTEL DISCRETE GRAPHIC SPI FLASH DRIVER
+M: Alexander Usyskin
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/spi/spi-intel-dg.c
+F: include/linux/intel_dg_spi_aux.h
+
INTEL DRM DISPLAY FOR XE AND I915 DRIVERS
M: Jani Nikula
M: Rodrigo Vivi
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a2c99ff33e0a..ad6e74ff3223 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -518,6 +518,17 @@ config SPI_INTEL_PLATFORM
To compile this driver as a module, choose M here: the module
will be called spi-intel-platform.
+config SPI_INTEL_DG
+ tristate "Intel Discrete Graphic SPI flash driver"
+ depends on AUXILIARY_BUS || COMPILE_TEST
+ depends on MTD
+ help
+ This enables support for Intel Discrete Graphic SPI
+ auxiliary device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called spi-intel-dg.
+
config SPI_JCORE
tristate "J-Core SPI Master"
depends on OF && (SUPERH || COMPILE_TEST)
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e694254dec04..3c48a086c0e0 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_SPI_INGENIC) += spi-ingenic.o
obj-$(CONFIG_SPI_INTEL)+= spi-intel.o
obj-$(CONFIG_SPI_INTEL_PCI)+= spi-intel-pci.o
obj-$(CONFIG_SPI_INTEL_PLATFORM) += spi-intel-platform.o
+obj-$(CONFIG_SPI_INTEL_DG) += spi-intel-dg.o
obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LJCA) += spi-ljca.o
diff --git a/drivers/spi/spi-intel-dg.c b/drivers/spi/spi-intel-dg.c
new file mode 100644
index ..7a00d222bb72
--- /dev/null
+++ b/drivers/spi/spi-intel-dg.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2019-2024, Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct intel_dg_spi {
+ struct kref refcnt;
+ void __iomem *base;
+ size_t size;
+ unsigned int nregions;
+ struct {
+ const char *name;
+ u8 id;
+ u64 offset;
+ u64 size;
+ } regions[];
+};
+
+static void intel_dg_spi_release(struct kref *kref)
+{
+ struct intel_dg_spi *spi = container_of(kref, struct intel_dg_spi,
refcnt);
+ int i;
+
+ pr_debug("freeing spi memory\n");
+ for (i = 0; i < spi->nregions; i++)
+ kfree(spi->regions[i].name);
+ kfree(spi);
+}
+
+static int intel_dg_spi_probe(struct auxiliary_device *aux_dev,
+ const struct auxiliary_device_id *aux_dev_id)
+{
+ struct intel_dg_spi_dev *ispi =
auxiliary_dev_to_intel_dg_spi_dev(aux_dev);
+ struct device *device;
+ struct intel_dg_spi *spi;
+ unsigned int nregions;
+ unsigned int i, n;
+ size_t size;
+ char *name;
+ size_t name_size;
+ int ret;
+
+ device = _dev->dev;
+
+ /* count available regions */
+ for (nregions = 0, i = 0; i < INTEL_DG_SPI_REGIONS; i++) {
+ if (ispi->regions[i].name)
+ nregions++;
+ }
+
+ if (!nregions) {
+ dev_err(device, "no regions defined\n");
+ return -ENODEV;
+ }
+
+ size = sizeof(*spi) + sizeof(spi->regions[0]) * nregions;
+ spi = kzalloc(size, GFP_KERNEL);
+ if (!spi)
+ return -ENOMEM;
+
+ kref_init(>refcnt);
+
+ spi->nregions = nregions;
+ for (n = 0, i = 0; i < INTEL_DG_SPI_REGIONS; i++) {
+ if (ispi->regions[i].name) {
+ name_size = strlen(dev_name(_dev->dev)) +
+ strlen(ispi->regions[i].name) + 2; /* for
point */
+ name = kzalloc(name_size, GFP_KERNEL);
+ if (!name)
+ continue;
+ snprintf(name, name_size, "%s.%s",
+
[PATCH v3 00/12] spi: add driver for Intel discrete graphics
Add driver for access to Intel discrete graphics card internal SPI device. Expose device on auxiliary bus by i915 and Xe drivers and provide spi driver to register this device with MTD framework. This is a rewrite of "drm/i915/spi: spi access for discrete graphics" series with connection to the Xe driver and splitting the spi driver part to separate module in spi subsystem. This series intended to be pushed through drm-xe-next. V3: rebase over drm-xe-next to enable CI run V2: fix review comments fix signatures order depend spi presence in Xe on special flag, as not all new discrete cards have such spi Alexander Usyskin (6): spi: add driver for intel graphics on-die spi device spi: intel-dg: align 64bit read and write spi: intel-dg: wake card on operations drm/i915/spi: add support for access mode drm/xe/spi: add on-die spi device drm/xe/spi: add support for access mode Tomas Winkler (6): spi: intel-dg: implement region enumeration spi: intel-dg: implement spi access functions spi: intel-dg: spi register with mtd spi: intel-dg: implement mtd access handlers drm/i915/spi: add spi device for discrete graphics drm/i915/spi: add intel_spi_region map MAINTAINERS | 7 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/i915_driver.c| 6 + drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/spi/intel_spi.c | 97 +++ drivers/gpu/drm/i915/spi/intel_spi.h | 15 + drivers/gpu/drm/xe/Makefile | 1 + drivers/gpu/drm/xe/regs/xe_gsc_regs.h | 5 + drivers/gpu/drm/xe/xe_device.c| 3 + drivers/gpu/drm/xe/xe_device_types.h | 8 + drivers/gpu/drm/xe/xe_heci_gsc.c | 5 +- drivers/gpu/drm/xe/xe_pci.c | 5 + drivers/gpu/drm/xe/xe_spi.c | 104 drivers/gpu/drm/xe/xe_spi.h | 15 + drivers/spi/Kconfig | 11 + drivers/spi/Makefile | 1 + drivers/spi/spi-intel-dg.c| 863 ++ include/linux/intel_dg_spi_aux.h | 27 + 19 files changed, 1178 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h create mode 100644 drivers/gpu/drm/xe/xe_spi.c create mode 100644 drivers/gpu/drm/xe/xe_spi.h create mode 100644 drivers/spi/spi-intel-dg.c create mode 100644 include/linux/intel_dg_spi_aux.h -- 2.34.1
Re: [PATCH 6/8] drm/ttm: revert "Export ttm_bo_get_unless_zero()"
On 7/23/24 2:17 PM, Christian König wrote:
This reverts commit 24dc64c1ba5c3ef0463d59fef6df09336754188d.
Shouldn't be needed by drivers any more.
Signed-off-by: Christian König
Reviewed-by: Matthew Brost
Technically, this series should be a v2, right? I also still think it would be
good to add the corresponding driver maintainers to the recipient list.
Anyway, for the TTM patches: Reviewed-by: Danilo Krummrich
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
drivers/gpu/drm/ttm/ttm_bo_internal.h | 48 +++
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 ++
drivers/gpu/drm/ttm/ttm_device.c | 1 +
include/drm/ttm/ttm_bo.h | 18 --
5 files changed, 52 insertions(+), 18 deletions(-)
create mode 100644 drivers/gpu/drm/ttm/ttm_bo_internal.h
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0131ec802066..fe4638ec0976 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -45,6 +45,7 @@
#include
#include "ttm_module.h"
+#include "ttm_bo_internal.h"
static void ttm_bo_mem_space_debug(struct ttm_buffer_object *bo,
struct ttm_placement *placement)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_internal.h
b/drivers/gpu/drm/ttm/ttm_bo_internal.h
new file mode 100644
index ..6a7305efd778
--- /dev/null
+++ b/drivers/gpu/drm/ttm/ttm_bo_internal.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+
+#ifndef _TTM_BO_INTERNAL_H_
+#define _TTM_BO_INTERNAL_H_
+
+#include
+
+/**
+ * ttm_bo_get_unless_zero - reference a struct ttm_buffer_object unless
+ * its refcount has already reached zero.
+ * @bo: The buffer object.
+ *
+ * Used to reference a TTM buffer object in lookups where the object is removed
+ * from the lookup structure during the destructor and for RCU lookups.
+ *
+ * Returns: @bo if the referencing was successful, NULL otherwise.
+ */
+static inline __must_check struct ttm_buffer_object *
+ttm_bo_get_unless_zero(struct ttm_buffer_object *bo)
+{
+ if (!kref_get_unless_zero(>kref))
+ return NULL;
+ return bo;
+}
+
+#endif
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 3c07f4712d5c..f7143384ef1c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -37,6 +37,8 @@
#include
+#include "ttm_bo_internal.h"
+
struct ttm_transfer_obj {
struct ttm_buffer_object base;
struct ttm_buffer_object *bo;
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index e7cc4954c1bc..2e7fa3a11dc0 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -36,6 +36,7 @@
#include
#include "ttm_module.h"
+#include "ttm_bo_internal.h"
/*
* ttm_global_mutex - protecting the global state
diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
index d1a732d56259..31ec7fd34eeb 100644
--- a/include/drm/ttm/ttm_bo.h
+++ b/include/drm/ttm/ttm_bo.h
@@ -239,24 +239,6 @@ static inline void ttm_bo_get(struct ttm_buffer_object *bo)
kref_get(>kref);
}
-/**
- * ttm_bo_get_unless_zero - reference a struct ttm_buffer_object unless
- * its refcount has already reached zero.
- * @bo: The buffer object.
- *
- * Used to reference a TTM buffer object in lookups where the object is removed
- * from the lookup structure during the destructor and for RCU lookups.
- *
- * Returns: @bo if the referencing was successful, NULL otherwise.
- */
-static inline __must_check struct ttm_buffer_object *
-ttm_bo_get_unless_zero(struct ttm_buffer_object *bo)
-{
- if (!kref_get_unless_zero(>kref))
- return NULL;
- return bo;
-}
-
/**
* ttm_bo_reserve:
*
Re: [PATCH] drm/test: use kunit action wrapper macro in the gem shmem test suite
On Tue, Jul 23, 2024 at 09:10:35PM +0200, Marco Pagani wrote:
> Replace deferred action function wrappers with equivalent ones defined
> using the macro introduced by commit 56778b49c9a2 ("kunit: Add a macro to
> wrap a deferred action function")
>
> Signed-off-by: Marco Pagani
Merged to drm-misc-next, thanks for your patch.
-Sima
> ---
> drivers/gpu/drm/tests/drm_gem_shmem_test.c | 27 ++
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c
> b/drivers/gpu/drm/tests/drm_gem_shmem_test.c
> index c3758faa1b83..f7f7d8b0f61f 100644
> --- a/drivers/gpu/drm/tests/drm_gem_shmem_test.c
> +++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c
> @@ -23,29 +23,16 @@
> #define TEST_BYTE0xae
>
> /*
> - * Wrappers to avoid an explicit type casting when passing action
> - * functions to kunit_add_action().
> + * Wrappers to avoid cast warnings when passing action functions
> + * directly to kunit_add_action().
> */
> -static void kfree_wrapper(void *ptr)
> -{
> - const void *obj = ptr;
> -
> - kfree(obj);
> -}
> -
> -static void sg_free_table_wrapper(void *ptr)
> -{
> - struct sg_table *sgt = ptr;
> +KUNIT_DEFINE_ACTION_WRAPPER(kfree_wrapper, kfree, const void *);
>
> - sg_free_table(sgt);
> -}
> -
> -static void drm_gem_shmem_free_wrapper(void *ptr)
> -{
> - struct drm_gem_shmem_object *shmem = ptr;
> +KUNIT_DEFINE_ACTION_WRAPPER(sg_free_table_wrapper, sg_free_table,
> + struct sg_table *);
>
> - drm_gem_shmem_free(shmem);
> -}
> +KUNIT_DEFINE_ACTION_WRAPPER(drm_gem_shmem_free_wrapper, drm_gem_shmem_free,
> + struct drm_gem_shmem_object *);
>
> /*
> * Test creating a shmem GEM object backed by shmem buffer. The test
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 6/8] drm/ttm: revert "Export ttm_bo_get_unless_zero()"
On Tue, Jul 23, 2024 at 02:17:48PM +0200, Christian König wrote:
> This reverts commit 24dc64c1ba5c3ef0463d59fef6df09336754188d.
>
> Shouldn't be needed by drivers any more.
>
> Signed-off-by: Christian König
> Reviewed-by: Matthew Brost
On the last 3 patches:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 1 +
> drivers/gpu/drm/ttm/ttm_bo_internal.h | 48 +++
> drivers/gpu/drm/ttm/ttm_bo_util.c | 2 ++
> drivers/gpu/drm/ttm/ttm_device.c | 1 +
> include/drm/ttm/ttm_bo.h | 18 --
> 5 files changed, 52 insertions(+), 18 deletions(-)
> create mode 100644 drivers/gpu/drm/ttm/ttm_bo_internal.h
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 0131ec802066..fe4638ec0976 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -45,6 +45,7 @@
> #include
>
> #include "ttm_module.h"
> +#include "ttm_bo_internal.h"
>
> static void ttm_bo_mem_space_debug(struct ttm_buffer_object *bo,
> struct ttm_placement *placement)
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_internal.h
> b/drivers/gpu/drm/ttm/ttm_bo_internal.h
> new file mode 100644
> index ..6a7305efd778
> --- /dev/null
> +++ b/drivers/gpu/drm/ttm/ttm_bo_internal.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright 2018 Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + *
> + */
> +
> +#ifndef _TTM_BO_INTERNAL_H_
> +#define _TTM_BO_INTERNAL_H_
> +
> +#include
> +
> +/**
> + * ttm_bo_get_unless_zero - reference a struct ttm_buffer_object unless
> + * its refcount has already reached zero.
> + * @bo: The buffer object.
> + *
> + * Used to reference a TTM buffer object in lookups where the object is
> removed
> + * from the lookup structure during the destructor and for RCU lookups.
> + *
> + * Returns: @bo if the referencing was successful, NULL otherwise.
> + */
> +static inline __must_check struct ttm_buffer_object *
> +ttm_bo_get_unless_zero(struct ttm_buffer_object *bo)
> +{
> + if (!kref_get_unless_zero(>kref))
> + return NULL;
> + return bo;
> +}
> +
> +#endif
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 3c07f4712d5c..f7143384ef1c 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -37,6 +37,8 @@
>
> #include
>
> +#include "ttm_bo_internal.h"
> +
> struct ttm_transfer_obj {
> struct ttm_buffer_object base;
> struct ttm_buffer_object *bo;
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index e7cc4954c1bc..2e7fa3a11dc0 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -36,6 +36,7 @@
> #include
>
> #include "ttm_module.h"
> +#include "ttm_bo_internal.h"
>
> /*
> * ttm_global_mutex - protecting the global state
> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
> index d1a732d56259..31ec7fd34eeb 100644
> --- a/include/drm/ttm/ttm_bo.h
> +++ b/include/drm/ttm/ttm_bo.h
> @@ -239,24 +239,6 @@ static inline void ttm_bo_get(struct ttm_buffer_object
> *bo)
> kref_get(>kref);
> }
>
> -/**
> - * ttm_bo_get_unless_zero - reference a struct ttm_buffer_object unless
> - * its refcount has already reached zero.
> - * @bo: The buffer object.
> - *
> - * Used to reference a TTM buffer object in lookups where the object is
> removed
> - * from the lookup structure during the destructor and for RCU lookups.
> - *
> - * Returns: @bo if the referencing was successful, NULL otherwise.
> - */
> -static inline __must_check struct ttm_buffer_object *
> -ttm_bo_get_unless_zero(struct ttm_buffer_object *bo)
> -{
> - if (!kref_get_unless_zero(>kref))
> - return NULL;
> - return bo;
> -}
> -
> /**
> *
Re: [PATCH 5/8] drm/vmwgfx: partially revert "Adapt validation code for reference-free lookups"
On Tue, Jul 23, 2024 at 02:17:47PM +0200, Christian König wrote:
> This reverts commit 64ad2abfe9a628ce79859d072704bd1ef7682044.
>
> To me it looks like this functionality was never actually used. At least
> I can't find any protection in vmw_bo_free().
Just to double-check I've done the audit of all callers, and they all look
like they're holding a full reference indeed. The somewhat annoying case
was vmw_sw_context->cur_query_bo because it seems to not be refcounted
itself. But that's either dev_priv->pinned_bo or
dev_priv->dummy_query_bo, both of which are refcounted, so we're good.
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Christian König
> Cc: Zack Rusin
> Cc: Broadcom internal kernel review list
>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> index e7625b3f71e0..e11837e484aa 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.c
> @@ -262,7 +262,8 @@ int vmw_validation_add_bo(struct vmw_validation_context
> *ctx,
> bo_node->hash.key);
> }
> val_buf = _node->base;
> - val_buf->bo = ttm_bo_get_unless_zero(>tbo);
> + vmw_bo_reference(vbo);
> + val_buf->bo = >tbo;
> if (!val_buf->bo)
> return -ESRCH;
> val_buf->num_shared = 0;
> @@ -656,7 +657,7 @@ void vmw_validation_unref_lists(struct
> vmw_validation_context *ctx)
> struct vmw_validation_res_node *val;
>
> list_for_each_entry(entry, >bo_list, base.head) {
> - ttm_bo_put(entry->base.bo);
> + drm_gem_object_put(>base.bo->base);
> entry->base.bo = NULL;
> }
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 4/8] drm/vmwgfx: use GEM references instead of TTMs
On Tue, Jul 23, 2024 at 02:17:46PM +0200, Christian König wrote:
> Instead of a TTM reference grab a GEM reference whenever necessary.
>
> Signed-off-by: Christian König
> Cc: Zack Rusin
> Cc: Broadcom internal kernel review list
>
There's a ttm_bo_put in vmwgfx_mob.c that you didn't convert, is there a
reason for that? And the mix of vmw_bo_(un)reference and
drm_gem_object_get/put in vmwgfx_resource.c is a bit confusing, I'd just
refcount the res->guest_memory_bo instead so that you can use the vmw_bo_
functions.
-Sima
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 19 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 +++---
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
> 9 files changed, 23 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index 00144632c600..3caaacb124ec 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -501,7 +501,7 @@ static int vmw_user_bo_synccpu_release(struct drm_file
> *filp,
> if (!(flags & drm_vmw_synccpu_allow_cs)) {
> atomic_dec(_bo->cpu_writers);
> }
> - vmw_user_bo_unref(_bo);
> + vmw_bo_unreference(_bo);
> }
>
> return ret;
> @@ -543,7 +543,7 @@ int vmw_user_bo_synccpu_ioctl(struct drm_device *dev,
> void *data,
> return ret;
>
> ret = vmw_user_bo_synccpu_grab(vbo, arg->flags);
> - vmw_user_bo_unref();
> + vmw_bo_unreference();
> if (unlikely(ret != 0)) {
> if (ret == -ERESTARTSYS || ret == -EBUSY)
> return -EBUSY;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> index f349642e6190..42a58d57409d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> @@ -188,30 +188,15 @@ static inline void vmw_bo_unreference(struct vmw_bo
> **buf)
>
> *buf = NULL;
> if (tmp_buf)
> - ttm_bo_put(_buf->tbo);
> + drm_gem_object_put(_buf->tbo.base);
> }
>
> static inline struct vmw_bo *vmw_bo_reference(struct vmw_bo *buf)
> {
> - ttm_bo_get(>tbo);
> + drm_gem_object_get(>tbo.base);
> return buf;
> }
>
> -static inline struct vmw_bo *vmw_user_bo_ref(struct vmw_bo *vbo)
> -{
> - drm_gem_object_get(>tbo.base);
> - return vbo;
> -}
> -
> -static inline void vmw_user_bo_unref(struct vmw_bo **buf)
> -{
> - struct vmw_bo *tmp_buf = *buf;
> -
> - *buf = NULL;
> - if (tmp_buf)
> - drm_gem_object_put(_buf->tbo.base);
> -}
> -
> static inline struct vmw_bo *to_vmw_bo(struct drm_gem_object *gobj)
> {
> return container_of((gobj), struct vmw_bo, tbo.base);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> index a7c07692262b..6b700ebd71b1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> @@ -502,7 +502,7 @@ static int vmw_cotable_resize(struct vmw_resource *res,
> size_t new_size)
>
> vmw_resource_mob_attach(res);
> /* Let go of the old mob. */
> - vmw_user_bo_unref(_buf);
> + vmw_bo_unreference(_buf);
> res->id = vcotbl->type;
>
> ret = dma_resv_reserve_fences(bo->base.resv, 1);
> @@ -521,7 +521,7 @@ static int vmw_cotable_resize(struct vmw_resource *res,
> size_t new_size)
> out_wait:
> ttm_bo_unpin(bo);
> ttm_bo_unreserve(bo);
> - vmw_user_bo_unref();
> + vmw_bo_unreference();
>
> out_done:
> MKS_STAT_TIME_POP(MKSSTAT_KERN_COTABLE_RESIZE);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 2e52d73eba48..be29b9ff8901 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -1166,7 +1166,7 @@ static int vmw_translate_mob_ptr(struct vmw_private
> *dev_priv,
> vmw_bo_placement_set(vmw_bo, VMW_BO_DOMAIN_MOB, VMW_BO_DOMAIN_MOB);
> ret = vmw_validation_add_bo(sw_context->ctx, vmw_bo);
> tmp_bo = vmw_bo;
> - vmw_user_bo_unref(_bo);
> + vmw_bo_unreference(_bo);
> if (unlikely(ret != 0))
> return ret;
>
> @@ -1223,7 +1223,7 @@ static int vmw_translate_guest_ptr(struct vmw_private
> *dev_priv,
>VMW_BO_DOMAIN_GMR | VMW_BO_DOMAIN_VRAM);
> ret = vmw_validation_add_bo(sw_context->ctx, vmw_bo);
> tmp_bo = vmw_bo;
> - vmw_user_bo_unref(_bo);
> +
