Re: [PATCH 5/7] media: hantro: introduce hantro_g1.c for common API
On Fri, Mar 05, 2021 at 06:39:22PM +, Emil Velikov wrote: > From: Emil Velikov > > The Hantro G1 IRQ and reset handling it pretty standard. I was this > close to duplicating it, yet again, before reconsidering and refactoring > it to a separate file. > > Cc: Ezequiel Garcia > Cc: Philipp Zabel > Cc: linux-me...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Signed-off-by: Emil Velikov Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] media: hantro: imx: remove unused include
Hi Emil,
On Fri, Mar 05, 2021 at 06:39:21PM +, Emil Velikov wrote:
> From: Emil Velikov
>
> The current imx8 code does not use the jpeg encoder. Remove the
> unnecessary include.
>
> Cc: Ezequiel Garcia
> Cc: Philipp Zabel
> Cc: linux-me...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Emil Velikov
thank you, patches 2-4 could be tagged
Fixes: 8e4aaa687863 ("media: hantro: add initial i.MX8MQ support")
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
Hi, On 2021-02-05 17:38, Sai Prakash Ranjan wrote: On 2021-02-04 03:16, Will Deacon wrote: On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: On 2021-02-01 23:50, Jordan Crouse wrote: > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > > > On reflection, I'm a bit worried about exposing this because I think it > > > > > will > > > > > introduce a mismatched virtual alias with the CPU (we don't even have a > > > > > MAIR > > > > > set up for this memory type). Now, we also have that issue for the PTW, > > > > > but > > > > > since we always use cache maintenance (i.e. the streaming API) for > > > > > publishing the page-tables to a non-coheren walker, it works out. > > > > > However, > > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent > > > > > allocation, then they're potentially in for a nasty surprise due to the > > > > > mismatched outer-cacheability attributes. > > > > > > > > > > > > > Can't we add the syscached memory type similar to what is done on android? > > > > > > Maybe. How does the GPU driver map these things on the CPU side? > > > > Currently we use writecombine mappings for everything, although there > > are some cases that we'd like to use cached (but have not merged > > patches that would give userspace a way to flush/invalidate) > > > > LLC/system cache doesn't have a relationship with the CPU cache. Its > just a > little accelerator that sits on the connection from the GPU to DDR and > caches > accesses. The hint that Sai is suggesting is used to mark the buffers as > 'no-write-allocate' to prevent GPU write operations from being cached in > the LLC > which a) isn't interesting and b) takes up cache space for read > operations. > > Its easiest to think of the LLC as a bonus accelerator that has no cost > for > us to use outside of the unfortunate per buffer hint. > > We do have to worry about the CPU cache w.r.t I/O coherency (which is a > different hint) and in that case we have all of concerns that Will > identified. > For mismatched outer cacheability attributes which Will mentioned, I was referring to [1] in android kernel. I've lost track of the conversation here :/ When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped into the CPU and with what attributes? Rob said "writecombine for everything" -- does that mean ioremap_wc() / MEMREMAP_WC? Rob answered this. Finally, we need to be careful when we use the word "hint" as "allocation hint" has a specific meaning in the architecture, and if we only mismatch on those then we're actually ok. But I think IOMMU_LLC is more than just a hint, since it actually drives eviction policy (i.e. it enables writeback). Sorry for the pedantry, but I just want to make sure we're all talking about the same things! Sorry for the confusion which probably was caused by my mentioning of android, NWA(no write allocate) is an allocation hint which we can ignore for now as it is not introduced yet in upstream. Any chance of taking this forward? We do not want to miss out on small fps gain when the product gets released. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available
Currently we see only the MAX FRL BW from PCON before going for FRL. Also add the check if source control mode is supported by the PCON, before starting configuring PCON for FRL training. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2e90359ce21f..8e401d3fd29d 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2638,7 +2638,8 @@ void intel_dp_check_frl_training(struct intel_dp *intel_dp) struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); /* Always go for FRL training if supported */ - if (!intel_dp_is_hdmi_2_1_sink(intel_dp) || + if (!(intel_dp->dpcd[2] & DP_PCON_SOURCE_CTL_MODE) || + !intel_dp_is_hdmi_2_1_sink(intel_dp) || intel_dp->frl.is_trained) return; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/i915/display: Remove FRL related code from disable DP sequence for older platforms
Remove code for resetting frl related members from intel_disable_dp, as this is not applicable for older platforms. Signed-off-by: Ankit Nautiyal Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 85ec74ae952e..2e90359ce21f 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2386,8 +2386,6 @@ static void intel_disable_dp(struct intel_atomic_state *state, intel_edp_backlight_off(old_conn_state); intel_dp_set_power(intel_dp, DP_SET_POWER_D3); intel_pps_off(intel_dp); - intel_dp->frl.is_trained = false; - intel_dp->frl.trained_rate_gbps = 0; } static void g4x_disable_dp(struct intel_atomic_state *state, -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/dp_helper: Define options for FRL training for HDMI2.1 PCON
Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.
This patch:
-Add register masks for Sequential and Normal FRL training options.
-Fixes the drm_helpers for FRL Training configuration to use the
appropriate masks.
-Modifies the calls to the above drm_helpers in i915/intel_dp as per
the above change.
v2: Re-used the register masks for these options, instead of enum. (Ville)
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 24 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 10 --
include/drm/drm_dp_helper.h | 6 --
3 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eedbb48815b7..cb2f53e56685 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2635,14 +2635,16 @@ EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
* drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
* @aux: DisplayPort AUX channel
* @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
- * @concurrent_mode: true if concurrent mode or operation is required,
- * false otherwise.
+ * @frl_mode: FRL Training mode, it can be either Concurrent or Sequential.
+ * In Concurrent Mode, the FRL link bring up can be done along with
+ * DP Link training. In Sequential mode, the FRL link bring up is done prior to
+ * the DP Link training.
*
* Returns 0 if success, else returns negative error code.
*/
int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
- bool concurrent_mode)
+ u8 frl_mode)
{
int ret;
u8 buf;
@@ -2651,7 +2653,7 @@ int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux,
int max_frl_gbps,
if (ret < 0)
return ret;
- if (concurrent_mode)
+ if (frl_mode == DP_PCON_ENABLE_CONCURRENT_LINK)
buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
else
buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
@@ -2694,21 +2696,23 @@ EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
* drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
* @aux: DisplayPort AUX channel
* @max_frl_mask : Max FRL BW to be tried by the PCON with HDMI Sink
- * @extended_train_mode : true for Extended Mode, false for Normal Mode.
- * In Normal mode, the PCON tries each frl bw from the max_frl_mask starting
- * from min, and stops when link training is successful. In Extended mode, all
- * frl bw selected in the mask are trained by the PCON.
+ * @frl_type : FRL training type, can be Extended, or Normal.
+ * In Normal FRL training, the PCON tries each frl bw from the max_frl_mask
+ * starting from min, and stops when link training is successful. In Extended
+ * FRL training, all frl bw selected in the mask are trained by the PCON.
*
* Returns 0 if success, else returns negative error code.
*/
int drm_dp_pcon_frl_configure_2(struct drm_dp_aux *aux, int max_frl_mask,
- bool extended_train_mode)
+ u8 frl_type)
{
int ret;
u8 buf = max_frl_mask;
- if (extended_train_mode)
+ if (frl_type == DP_PCON_FRL_LINK_TRAIN_EXTENDED)
buf |= DP_PCON_FRL_LINK_TRAIN_EXTENDED;
+ else
+ buf &= ~DP_PCON_FRL_LINK_TRAIN_EXTENDED;
ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_2, buf);
if (ret < 0)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4f89e0de5dde..85ec74ae952e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2557,10 +2557,6 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
*intel_dp)
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
{
-#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
-#define PCON_CONCURRENT_MODE (1 > 0)
-#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
-#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
#define TIMEOUT_FRL_READY_MS 500
#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
@@ -2594,10 +2590,12 @@ static int intel_dp_pcon_start_frl_training(struct
intel_dp *intel_dp)
return -ETIMEDOUT;
max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
- ret = drm_dp_pcon_frl_configure_1(_dp->aux, max_frl_bw,
PCON_SEQUENTIAL_MODE);
+ ret = drm_dp_pcon_frl_configure_1(_dp->aux, max_frl_bw,
+ DP_PCON_ENABLE_SEQUENTIAL_LINK);
if (ret < 0)
return ret;
- ret = drm_dp_pcon_frl_configure_2(_dp->aux, max_frl_bw_mask,
PCON_NORMAL_TRAIN_MODE);
+ ret = drm_dp_pcon_frl_configure_2(_dp->aux, max_frl_bw_mask,
+
[PATCH v3 0/3] HDMI2.1 PCON Misc Fixes
Patch1: Tweaks the drm_helpers for PCON configuration. Patch2: Removes unwanted code not applicable for older platforms. Patch3: Fixes condition for starting FRL link training. rev3: Patch-1 from rev2 [Read PCON DSC ENC caps only for DPCD rev >= 1.4] is dropped as it mixes DPCD and DP revisions. Ankit Nautiyal (3): drm/dp_helper: Define options for FRL training for HDMI2.1 PCON drm/i915/display: Remove FRL related code from disable DP sequence for older platforms drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available drivers/gpu/drm/drm_dp_helper.c | 24 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 15 ++- include/drm/drm_dp_helper.h | 6 -- 3 files changed, 24 insertions(+), 21 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] i915/display/intel_dp: Read PCON DSC ENC caps only for DPCD rev >= 1.4
As I realized, this patch is mixing DPCD rev and DP version, need an appropriate check instead. As for the gitlab issue https://gitlab.freedesktop.org/drm/intel/-/issues/2868 this seems to be not due to a DPCD register not defined for an older sink. The DPCD read in that case should have been 0, instead of timeout. I will drop this patch for now, from the series and revisit it later. Thanks & Regards, Ankit On 2/8/2021 5:14 PM, Nautiyal, Ankit K wrote: On 2/8/2021 4:45 PM, Jani Nikula wrote: On Thu, 04 Feb 2021, Ankit Nautiyal wrote: DP-HDMI2.1 PCON has DSC encoder caps defined in registers 0x92-0x9E. Do not read the registers if DPCD rev < 1.4. Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2868 Please use Fixes: to reference commits that this patch fixes. Please use Closes: to reference issues that this patch fixes. No need to resend for this, can be fixed while applying, but please tell me the commit that introduced the problem. BR, Jani. Alright will take care. Please find below the commit that introduced this: b9d96dacdc3d983eae234b52401edb56dbceb764 Patch : drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder https://patchwork.freedesktop.org/patch/408779/ Thanks & Regards, Ankit Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 8c12d5375607..2b83f0f433a2 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2489,9 +2489,11 @@ static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp) struct drm_i915_private *i915 = dp_to_i915(intel_dp); /* Clear the cached register set to avoid using stale values */ - memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd)); + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14) + return; + if (drm_dp_dpcd_read(_dp->aux, DP_PCON_DSC_ENCODER, intel_dp->pcon_dsc_dpcd, sizeof(intel_dp->pcon_dsc_dpcd)) < 0) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Verify bo size can fit framebuffer size on init.
On Mon, Mar 8, 2021 at 4:36 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> To initialize the framebuffer, call drm_gem_fb_init_with_funcs which
> verifies that the BO size can fit the FB size by calculating the minimum
> expected size of each plane.
>
> The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
> and kms_addfb_basic.bo-too-small
>
> Tested on ChromeOS Zork by turning on the display and running a YT
> video.
>
> === Changes from v1 ===
> 1. Added new line under declarations.
> 2. Use C style comment.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Sean Paul
> Signed-off-by: Mark Yacoub
Applied. Thanks. FWIW, it would be nice to clean this up in general.
All of this fbdev stuff is pretty convoluted.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 68 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 8 +++
> 3 files changed, 65 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 48cb33e5b3826..afa5f8ad0f563 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -870,17 +870,62 @@ static int amdgpu_display_get_fb_info(const struct
> amdgpu_framebuffer *amdgpu_fb
> return r;
> }
>
> +int amdgpu_display_gem_fb_init(struct drm_device *dev,
> + struct amdgpu_framebuffer *rfb,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object *obj)
> +{
> + int ret;
> +
> + rfb->base.obj[0] = obj;
> + drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
> + ret = drm_framebuffer_init(dev, >base, _fb_funcs);
> + if (ret)
> + goto err;
> +
> + ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + drm_err(dev, "Failed to init gem fb: %d\n", ret);
> + rfb->base.obj[0] = NULL;
> + return ret;
> +}
> +
> +int amdgpu_display_gem_fb_verify_and_init(
> + struct drm_device *dev, struct amdgpu_framebuffer *rfb,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object *obj)
> +{
> + int ret;
> +
> + rfb->base.obj[0] = obj;
> +
> + /* Verify that bo size can fit the fb size. */
> + ret = drm_gem_fb_init_with_funcs(dev, >base, file_priv, mode_cmd,
> +_fb_funcs);
> + if (ret)
> + goto err;
> +
> + ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + drm_err(dev, "Failed to verify and init gem fb: %d\n", ret);
> + rfb->base.obj[0] = NULL;
> + return ret;
> +}
> +
> int amdgpu_display_framebuffer_init(struct drm_device *dev,
> struct amdgpu_framebuffer *rfb,
> const struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object *obj)
> {
> int ret, i;
> - rfb->base.obj[0] = obj;
> - drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
> - ret = drm_framebuffer_init(dev, >base, _fb_funcs);
> - if (ret)
> - goto fail;
>
> /*
> * This needs to happen before modifier conversion as that might
> change
> @@ -891,13 +936,13 @@ int amdgpu_display_framebuffer_init(struct drm_device
> *dev,
> drm_dbg_kms(dev, "Plane 0 and %d have different BOs:
> %u vs. %u\n",
> i, mode_cmd->handles[0],
> mode_cmd->handles[i]);
> ret = -EINVAL;
> - goto fail;
> + return ret;
> }
> }
>
> ret = amdgpu_display_get_fb_info(rfb, >tiling_flags,
> >tmz_surface);
> if (ret)
> - goto fail;
> + return ret;
>
> if (dev->mode_config.allow_fb_modifiers &&
> !(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
> @@ -905,7 +950,7 @@ int amdgpu_display_framebuffer_init(struct drm_device
> *dev,
> if (ret) {
> drm_dbg_kms(dev, "Failed to convert tiling flags
> 0x%llX to a modifier",
> rfb->tiling_flags);
> - goto fail;
> + return ret;
> }
> }
>
> @@ -915,10 +960,6 @@ int amdgpu_display_framebuffer_init(struct drm_device
> *dev,
> }
>
> return 0;
> -
> -fail:
> - rfb->base.obj[0] = NULL;
> - return ret;
> }
>
> struct drm_framebuffer *
> @@ -953,7 +994,8 @@ amdgpu_display_user_framebuffer_create(struct drm_device
> *dev,
>
[PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 10 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 6 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..7199eb833f66 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
#include
#include
#include
@@ -355,3 +359,9 @@ int kfd_iommu_add_perf_counters(struct kfd_topology_device
*kdev)
return 0;
}
+
+#else
+
+#warning "Moldular IOMMU-V2 is not usable by built-in KFD"
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..b25365fc2c4e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
#ifndef __KFD_IOMMU_H__
#define __KFD_IOMMU_H__
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
#define KFD_SUPPORT_IOMMU_V2
@@ -73,6 +75,6 @@ static inline int kfd_iommu_add_perf_counters(struct
kfd_topology_device *kdev)
return 0;
}
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */
+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
#endif /* __KFD_IOMMU_H__ */
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [variant b] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 2021-03-08 um 3:45 p.m. schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_bind_process_to_device':
> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_unbind_process':
> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_suspend':
> kfd_iommu.c:(.text+0x966): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
> `amd_iommu_free_device'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_resume':
> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
> `amd_iommu_bind_pasid'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
> `amd_iommu_free_device'
>
> Change the 'imply' to a weak dependency that still allows compiling
> in all other configurations but disallows the configuration that
> causes a link failure.
I don't like this solution. It hides the HSA_AMD option in menuconfig
and it's not intuitively obvious to someone configuring a kernel why
it's not available. They may not even notice that it's missing and then
wonder later, why KFD functionality is missing in their kernel.
What I'm trying to achieve is, that KFD can be compiled without
AMD-IOMMU-V2 support in this case. I just tested my version using
IS_REACHABLE. I'll reply with that patch in a moment.
Regards,
Felix
>
> Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
> conditional")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
> b/drivers/gpu/drm/amd/amdkfd/Kconfig
> index f02c938f75da..d01dba2af3bb 100644
> --- a/drivers/gpu/drm/amd/amdkfd/Kconfig
> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
> @@ -6,7 +6,7 @@
> config HSA_AMD
> bool "HSA kernel driver for AMD GPU devices"
> depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
> - imply AMD_IOMMU_V2 if X86_64
> + depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m
> select HMM_MIRROR
> select MMU_NOTIFIER
> select DRM_AMDGPU_USERPTR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/8] mm: Device exclusive memory access
On Tuesday, 9 March 2021 6:44:41 AM AEDT Ralph Campbell wrote: > > On 3/3/21 10:16 PM, Alistair Popple wrote: > > Some devices require exclusive write access to shared virtual > > memory (SVM) ranges to perform atomic operations on that memory. This > > requires CPU page tables to be updated to deny access whilst atomic > > operations are occurring. > > > > In order to do this introduce a new swap entry > > type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for > > exclusive access by a device all page table mappings for the particular > > range are replaced with device exclusive swap entries. This causes any > > CPU access to the page to result in a fault. > > > > Faults are resovled by replacing the faulting entry with the original > > mapping. This results in MMU notifiers being called which a driver uses > > to update access permissions such as revoking atomic access. After > > notifiers have been called the device will no longer have exclusive > > access to the region. > > > > Signed-off-by: Alistair Popple > > I see in the next two patches how make_device_exclusive_entry() and > check_device_exclusive_range() are used. This points out a similar > problem that migrate_vma_setup() had before I added the > mmu_notifier_range_init_migrate() helper to pass a cookie from > migrate_vma_setup() to the invalidation callback so the device driver > could ignore an invalidation callback triggered by the caller and thus > resulting in a deadlock or having to invalidate device PTEs that > wouldn't be migrating. > > I think you can eliminate the need for check_device_exclusive_range() in > the same way by adding a "void *" pointer to make_device_exclusive_entry() > and passing that through to try_to_protect(), setting rmap_walk_control rwc.arg > and then passing arg to mmu_notifier_range_init_migrate(). Thanks for the idea, I had missed there was already a way of passing a "void *" as part of mmu_notifier_range_init_migrate(). Agree that should allow a single pass without needing check_device_exclusive_range(). As Jason points out still need to check the GUP page is mapped at the expected address but that can be done as part of installing the exclusive swap entry in try_to_protect_one(). > Although, maybe it would be better to define a new > mmu_notifier_range_init_exclusive() and event type MMU_NOTIFY_EXCLUSIVE so > that a device driver can revoke atomic/exclusive access but keep read/write > access to other parts of the page. Agree, I don't think overloading mmu_notifier_range_init_migrate() with the exclusive usage is correct. Better to define a new helper. > I thought about how make_device_exclusive_entry() is similar to hmm_range_fault() > and whether it would be possible to add a new HMM_PFN_REQ_EXCLUSIVE flag but I > see that make_device_exclusive_entry() returns the pages locked and with an > additional get_page() reference. This doesn't fit well with the other > hmm_range_fault() entries being returned as a "snapshot" so having a different > API makes sense. I think it would be useful to add a HMM_PFN_EXCLUSIVE flag so > that snapshots of the page tables can at least report that a page is exclusively > being accessed by *some* device. Unfortunately, there is no pgmap pointer to be > able to tell which device has exclusive access (since any struct page could be > exclusively accessed, not just device private ones). I have also experimented with integrating this with HMM but it just didn't end up being a good fit for the reasons you mention. I also don't think adding HMM_PFN_EXCLUSIVE to read page table snapshots is that useful because there is no way to tell *which* device has exclusive access. So unless I've missed some particular usage for it now I think it can probably be added as a future improvement to HMM if/when it is needed. - Alistair ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> On Wed, 3 Mar 2021 12:44:33 -0800
> "Navare, Manasi" wrote:
>
> > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > > On Tue, 2 Mar 2021 12:41:32 -0800
> > > Manasi Navare wrote:
> > >
> > > > In case of a modeset where a mode gets split across mutiple CRTCs
> > > > in the driver specific implementation (bigjoiner in i915) we wrongly
> > > > count
> > > > the affected CRTCs based on the drm_crtc_mask and indicate the stolen
> > > > CRTC as
> > > > an affected CRTC in atomic_check_only().
> > > > This triggers a warning since affected CRTCs doent match requested CRTC.
> > > >
> > > > To fix this in such bigjoiner configurations, we should only
> > > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > > if it is just used internally in the driver to split the mode.
> > >
> > > Hi,
> > >
> > > I think that makes sense to me. Stealing CRTCs that are not currently
> > > used by the userspace (display server) should be ok, as long as that
> > > is completely invisible to userspace: meaning that it does not cause
> > > userspace to unexpectedly e.g. receive or miss per-crtc atomic
> > > completion events.
> >
> > Yes since we are only doing atomic_check_only() here, the stolen
>
> But the real not-test-only commit will follow if this test-only commit
> succeeds, and keeping the guarantees for the real commit are important.
Hmm well after the actual real commit, since the second crtc is stolen
even though it is not being used for the display output, it is
used for joiner so the uapi.enable will be true after the real commit.
so actually the assertion would fail in this case.
@Ville @Danvet any suggestions here in that case?
Manasi
>
> > crtc is completely invisible to the userspace and hence that is
> > indicated by uapi.enable which is not true for this stolen
> > crtc. However if allow modeset flag set, then it will do a full
> > modeset and indicate the uapi.enable for this stolen crtc as well
> > since that cannot be used for other modeset requested by userspace.
> >
> > >
> > > Can that also be asserted somehow, or does this already do that?
> >
> > Not clear what you want the assertion for? Could you elaborate
>
> As assertion that when the real atomic commit happens and then
> completion events are fired, they match exactly the affected crtcs mask.
>
> I understand this may be off-topic for this particular patch, but since
> we are discussing the topic, such checks would be really nice. I'm
> curious if such checks already exist.
>
>
> Thanks,
> pq
>
> >
> > Manasi
> >
> > >
> > >
> > > Thanks,
> > > pq
> > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Simon Ser
> > > > Cc: Pekka Paalanen
> > > > Cc: Daniel Stone
> > > > Cc: Daniel Vetter
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 6 --
> > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 5b4547e0f775..d7acd6bbd97e 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1358,8 +1358,10 @@ int drm_atomic_check_only(struct
> > > > drm_atomic_state *state)
> > > > }
> > > > }
> > > >
> > > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > > - affected_crtc |= drm_crtc_mask(crtc);
> > > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > > + if (new_crtc_state->enable)
> > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > + }
> > > >
> > > > /*
> > > > * For commits that allow modesets drivers can add other CRTCs
> > > > to the
> > >
> >
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/8] mm/rmap: Split migration into its own function
On Tuesday, 9 March 2021 5:58:12 AM AEDT Ralph Campbell wrote: > > On 3/3/21 10:16 PM, Alistair Popple wrote: > > Migration is currently implemented as a mode of operation for > > try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag > > or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE. > > > > However it does not have much in common with the rest of the unmap > > functionality of try_to_unmap_one() and thus splitting it into a > > separate function reduces the complexity of try_to_unmap_one() making it > > more readable. > > > > Several simplifications can also be made in try_to_migrate_one() based > > on the following observations: > > > > - All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK. > > - No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON. > > - No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH. > > > > TTU_SPLIT_FREEZE is a special case of migration used when splitting an > > anonymous page. This is most easily dealt with by calling the correct > > function from unmap_page() in mm/huge_memory.c - either > > try_to_migrate() for PageAnon or try_to_unmap(). > > > > Signed-off-by: Alistair Popple > > Reviewed-by: Christoph Hellwig > > Looks reasonable to me. I do worry a bit about code duplication. I was initially concerned about this when splitting try_to_unmap_one() up but most of the code paths ended up being pretty orthogonal and I think the clarity gained from separating them is worth a small amount of duplication. > At some point in the future, it might be discovered that other combinations > of TTU_XXX flags are needed in which case a careful check of try_to_migrate() > and try_to_unmap() will be needed. I wanted to keep the code as simple as possible by removing all dead code paths that that weren't in use today. I think this is likely to be more of an issue if new TTU_XXX flags are added as there are already explicit (and hopefully exhaustive) checks in try_to_migrate() and try_to_unmap() for unsupported combinations of existing flags. To avoid ending up in the same situation again I would rather not have more TTU_XXX flags added if at all possible though. > Reviewed-by: Ralph Campbell Thanks. - Alistair ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: panel/kingdisplay, kd035g6-54nt: Remove spi-cs-high
On Sun, 07 Mar 2021 19:28:29 +, Paul Cercueil wrote: > The NT39016 panel is a fun beast, even though the documentation states > that the CS line is active-low, it will work just fine if the CS line is > configured as active-high, but it won't work if the CS line is forced > low or forced high. > > Since it did actually work with the spi-cs-high property, this is not a > bugfix, but we should nonetheless remove that property from the example > to match the documentation. > > Signed-off-by: Paul Cercueil > --- > .../bindings/display/panel/kingdisplay,kd035g6-54nt.yaml | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
2021 X.Org Foundation Membership renewal ENDS on THURSDAY Mar 11
The nomination period for the 2021 X.Org Foundation Board of Directors Election closed yesterday and the election is rapidly approaching. We currently only see membership renewals for 59 people. If you have not renewed your membership please do so by Thursday, Mar 11 at https://members.x.org. The nominated candidates will be announced a week from yesterday. There were some hickups with our earlier emails and we realize some of you may have not received them. To ensure you receive this email we're BCCing any member that has been registered as a member in the last 2 years. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
https://bugzilla.kernel.org/show_bug.cgi?id=212107 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- The driver turns off the fans for acoustic reasons if the OEM enabled support for the feature in the vbios. They will still go on when the temperature gets high enough. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: Remove unnecessary conversion to bool
On Sun, Mar 7, 2021 at 10:14 PM Jiapeng Chong wrote: > > Fix the following coccicheck warnings: > > ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1600:40-45: WARNING: conversion > to bool not needed here. > > ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1598:40-45: WARNING: conversion > to bool not needed here. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong This patch was already applied. Alex > --- > drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > index 690a509..b39e7db 100644 > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > @@ -1595,9 +1595,9 @@ static int sdma_v5_2_set_clockgating_state(void *handle, > case CHIP_VANGOGH: > case CHIP_DIMGREY_CAVEFISH: > sdma_v5_2_update_medium_grain_clock_gating(adev, > - state == AMD_CG_STATE_GATE ? true : false); > + state == AMD_CG_STATE_GATE); > sdma_v5_2_update_medium_grain_light_sleep(adev, > - state == AMD_CG_STATE_GATE ? true : false); > + state == AMD_CG_STATE_GATE); > break; > default: > break; > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Remove unnecessary conversion to bool
On Sun, Mar 7, 2021 at 10:00 PM Jiapeng Chong wrote: > > Fix the following coccicheck warnings: > > ./drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:561:34-39: WARNING: > conversion to bool not needed here. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong This patch was already applied. Alex > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > index ae6484a..42a4177 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c > @@ -558,7 +558,7 @@ bool dal_ddc_service_query_ddc_data( > /* should not set mot (middle of transaction) to 0 > * if there are pending read payloads > */ > - payload.mot = read_size == 0 ? false : true; > + payload.mot = !(read_size == 0); > payload.length = write_size; > payload.data = write_buf; > > -- > 1.8.3.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 --- Comment #18 from Alex Deucher (alexdeuc...@gmail.com) --- The original issue reported here was fixed. If you are having other issues, please open new bugs. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: remove duplicate include in dcn21 and gpio
Applied. Thanks! Alex On Sat, Mar 6, 2021 at 6:05 AM wrote: > > From: Zhang Yunkai > > 'dce110_resource.h' included in 'dcn21_resource.c' is duplicated. > 'hw_gpio.h' included in 'hw_factory_dce110.c' is duplicated. > > Signed-off-by: Zhang Yunkai > --- > drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 - > .../gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c| 4 > 2 files changed, 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c > b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c > index 072f8c880924..8a6a965751e8 100644 > --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c > +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c > @@ -61,7 +61,6 @@ > #include "dcn21/dcn21_dccg.h" > #include "dcn21_hubbub.h" > #include "dcn10/dcn10_resource.h" > -#include "dce110/dce110_resource.h" > #include "dce/dce_panel_cntl.h" > > #include "dcn20/dcn20_dwb.h" > diff --git a/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c > b/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c > index 66e4841f41e4..ca335ea60412 100644 > --- a/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c > +++ b/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c > @@ -48,10 +48,6 @@ > #define REGI(reg_name, block, id)\ > mm ## block ## id ## _ ## reg_name > > -#include "../hw_gpio.h" > -#include "../hw_ddc.h" > -#include "../hw_hpd.h" > - > #include "reg_helper.h" > #include "../hpd_regs.h" > > -- > 2.25.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: remove duplicate include in amdgpu_dm.c
Applied. Thanks! Alex On Sat, Mar 6, 2021 at 5:48 AM wrote: > > From: Zhang Yunkai > > 'drm/drm_hdcp.h' included in 'amdgpu_dm.c' is duplicated. > It is also included in the 79th line. > > Signed-off-by: Zhang Yunkai > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - > 1 file changed, 1 deletion(-) > > 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 3e1fd1e7d09f..fee46fbcb0b7 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -44,7 +44,6 @@ > #include "amdgpu_dm.h" > #ifdef CONFIG_DRM_AMD_DC_HDCP > #include "amdgpu_dm_hdcp.h" > -#include > #endif > #include "amdgpu_pm.h" > > -- > 2.25.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/amdgpu: Verify bo size can fit framebuffer size on init.
From: Mark Yacoub
To initialize the framebuffer, call drm_gem_fb_init_with_funcs which
verifies that the BO size can fit the FB size by calculating the minimum
expected size of each plane.
The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
and kms_addfb_basic.bo-too-small
Tested on ChromeOS Zork by turning on the display and running a YT
video.
=== Changes from v1 ===
1. Added new line under declarations.
2. Use C style comment.
Cc: Alex Deucher
Cc: "Christian König"
Cc: Sean Paul
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 68 +
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 8 +++
3 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 48cb33e5b3826..afa5f8ad0f563 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -870,17 +870,62 @@ static int amdgpu_display_get_fb_info(const struct
amdgpu_framebuffer *amdgpu_fb
return r;
}
+int amdgpu_display_gem_fb_init(struct drm_device *dev,
+ struct amdgpu_framebuffer *rfb,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_object *obj)
+{
+ int ret;
+
+ rfb->base.obj[0] = obj;
+ drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
+ ret = drm_framebuffer_init(dev, >base, _fb_funcs);
+ if (ret)
+ goto err;
+
+ ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
+ if (ret)
+ goto err;
+
+ return 0;
+err:
+ drm_err(dev, "Failed to init gem fb: %d\n", ret);
+ rfb->base.obj[0] = NULL;
+ return ret;
+}
+
+int amdgpu_display_gem_fb_verify_and_init(
+ struct drm_device *dev, struct amdgpu_framebuffer *rfb,
+ struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_object *obj)
+{
+ int ret;
+
+ rfb->base.obj[0] = obj;
+
+ /* Verify that bo size can fit the fb size. */
+ ret = drm_gem_fb_init_with_funcs(dev, >base, file_priv, mode_cmd,
+_fb_funcs);
+ if (ret)
+ goto err;
+
+ ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
+ if (ret)
+ goto err;
+
+ return 0;
+err:
+ drm_err(dev, "Failed to verify and init gem fb: %d\n", ret);
+ rfb->base.obj[0] = NULL;
+ return ret;
+}
+
int amdgpu_display_framebuffer_init(struct drm_device *dev,
struct amdgpu_framebuffer *rfb,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj)
{
int ret, i;
- rfb->base.obj[0] = obj;
- drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
- ret = drm_framebuffer_init(dev, >base, _fb_funcs);
- if (ret)
- goto fail;
/*
* This needs to happen before modifier conversion as that might change
@@ -891,13 +936,13 @@ int amdgpu_display_framebuffer_init(struct drm_device
*dev,
drm_dbg_kms(dev, "Plane 0 and %d have different BOs: %u
vs. %u\n",
i, mode_cmd->handles[0],
mode_cmd->handles[i]);
ret = -EINVAL;
- goto fail;
+ return ret;
}
}
ret = amdgpu_display_get_fb_info(rfb, >tiling_flags,
>tmz_surface);
if (ret)
- goto fail;
+ return ret;
if (dev->mode_config.allow_fb_modifiers &&
!(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
@@ -905,7 +950,7 @@ int amdgpu_display_framebuffer_init(struct drm_device *dev,
if (ret) {
drm_dbg_kms(dev, "Failed to convert tiling flags 0x%llX
to a modifier",
rfb->tiling_flags);
- goto fail;
+ return ret;
}
}
@@ -915,10 +960,6 @@ int amdgpu_display_framebuffer_init(struct drm_device *dev,
}
return 0;
-
-fail:
- rfb->base.obj[0] = NULL;
- return ret;
}
struct drm_framebuffer *
@@ -953,7 +994,8 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-ENOMEM);
}
- ret = amdgpu_display_framebuffer_init(dev, amdgpu_fb, mode_cmd, obj);
+ ret = amdgpu_display_gem_fb_verify_and_init(dev, amdgpu_fb, file_priv,
+ mode_cmd, obj);
if (ret) {
kfree(amdgpu_fb);
drm_gem_object_put(obj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
Re: [PATCH] drm/amdgpu: Verify bo size can fit framebuffer size on init.
On Thu, Mar 4, 2021 at 2:15 PM Mark Yacoub wrote:
>
> From: Mark Yacoub
>
> To initialize the framebuffer, use drm_gem_fb_init_with_funcs which
> verifies that the BO size can fit the FB size by calculating the minimum
> expected size of each plane.
>
> The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
> and kms_addfb_basic.bo-too-small
>
> Tested on ChromeOS Zork by turning on the display and running a YT
> video.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Sean Paul
> Signed-off-by: Mark Yacoub
Thanks for the patch. Just a few minor comments below.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 66 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 8 +++
> 3 files changed, 62 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 48cb33e5b3826..554038e5bbf6a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -870,18 +870,59 @@ static int amdgpu_display_get_fb_info(const struct
> amdgpu_framebuffer *amdgpu_fb
> return r;
> }
>
> -int amdgpu_display_framebuffer_init(struct drm_device *dev,
> - struct amdgpu_framebuffer *rfb,
> - const struct drm_mode_fb_cmd2 *mode_cmd,
> - struct drm_gem_object *obj)
> +int amdgpu_display_gem_fb_init(struct drm_device *dev,
> + struct amdgpu_framebuffer *rfb,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object *obj)
> {
> - int ret, i;
> + int ret;
Please add a new line here.
> rfb->base.obj[0] = obj;
> drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
> ret = drm_framebuffer_init(dev, >base, _fb_funcs);
> if (ret)
> - goto fail;
> + goto err;
> +
> + ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + drm_err(dev, "Failed to init gem fb: %d\n", ret);
> + rfb->base.obj[0] = NULL;
> + return ret;
> +}
> +
> +int amdgpu_display_gem_fb_verify_and_init(
> + struct drm_device *dev, struct amdgpu_framebuffer *rfb,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object *obj)
> +{
> + int ret;
> + rfb->base.obj[0] = obj;
> + // Verify that bo size can fit the fb size.
Please change this to use C style comments.
> + ret = drm_gem_fb_init_with_funcs(dev, >base, file_priv, mode_cmd,
> +_fb_funcs);
> + if (ret)
> + goto err;
>
> + ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + drm_err(dev, "Failed to verify and init gem fb: %d\n", ret);
> + rfb->base.obj[0] = NULL;
> + return ret;
> +}
> +
> +int amdgpu_display_framebuffer_init(struct drm_device *dev,
> + struct amdgpu_framebuffer *rfb,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object *obj)
> +{
> + int ret, i;
New line here.
> /*
> * This needs to happen before modifier conversion as that might
> change
> * the number of planes.
> @@ -891,13 +932,13 @@ int amdgpu_display_framebuffer_init(struct drm_device
> *dev,
> drm_dbg_kms(dev, "Plane 0 and %d have different BOs:
> %u vs. %u\n",
> i, mode_cmd->handles[0],
> mode_cmd->handles[i]);
> ret = -EINVAL;
> - goto fail;
> + return ret;
> }
> }
>
> ret = amdgpu_display_get_fb_info(rfb, >tiling_flags,
> >tmz_surface);
> if (ret)
> - goto fail;
> + return ret;
>
> if (dev->mode_config.allow_fb_modifiers &&
> !(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
> @@ -905,7 +946,7 @@ int amdgpu_display_framebuffer_init(struct drm_device
> *dev,
> if (ret) {
> drm_dbg_kms(dev, "Failed to convert tiling flags
> 0x%llX to a modifier",
> rfb->tiling_flags);
> - goto fail;
> + return ret;
> }
> }
>
> @@ -915,10 +956,6 @@ int amdgpu_display_framebuffer_init(struct drm_device
> *dev,
> }
>
> return 0;
> -
> -fail:
> - rfb->base.obj[0] = NULL;
> - return ret;
> }
>
> struct drm_framebuffer *
> @@ -953,7
Re: [PATCH] gpu: drm: swsmu: fix error return code of smu_v11_0_set_allowed_mask()
Applied. Thanks!
Alex
On Thu, Mar 4, 2021 at 11:02 PM Quan, Evan wrote:
>
> [AMD Public Use]
>
> Thanks. Reviewed-by: Evan Quan
>
> -Original Message-
> From: Jia-Ju Bai
> Sent: Friday, March 5, 2021 11:54 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; airl...@linux.ie; dan...@ffwll.ch; Quan, Evan
> ; Zhang, Hawking ; Wang,
> Kevin(Yang) ; Gao, Likun
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; Jia-Ju Bai
> Subject: [PATCH] gpu: drm: swsmu: fix error return code of
> smu_v11_0_set_allowed_mask()
>
> When bitmap_empty() or feature->feature_num triggers an error, no error
> return code of smu_v11_0_set_allowed_mask() is assigned.
> To fix this bug, ret is assigned with -EINVAL as error return code.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
> index 90585461a56e..82731a932308 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
> @@ -747,8 +747,10 @@ int smu_v11_0_set_allowed_mask(struct smu_context *smu)
> int ret = 0;
> uint32_t feature_mask[2];
>
> - if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) ||
> feature->feature_num < 64)
> + if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) ||
> feature->feature_num < 64) {
> + ret = -EINVAL;
> goto failed;
> + }
>
> bitmap_copy((unsigned long *)feature_mask, feature->allowed, 64);
>
> --
> 2.17.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] locking/rwsem: Add down_write_interruptible and use it
vmwgfx has really ugly implemention of an interruptible lock trying to match rw sem semantics. By adding a small bit of code implementing down_write_interruptible to rwsem which already supported down_read_interruptible we can completely remove all of the custom code from vmwgfx. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: Martin Krastev Cc: Roland Scheidegger Cc: linux-ker...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Zack Rusin (2): locking/rwsem: Add down_write_interruptible drm/vmwgfx: Remove custom locking code drivers/gpu/drm/vmwgfx/Makefile | 2 +- drivers/gpu/drm/vmwgfx/ttm_lock.c | 194 drivers/gpu/drm/vmwgfx/ttm_lock.h | 218 -- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 24 +- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 57 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 32 ++- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 4 +- .../gpu/drm/vmwgfx/vmwgfx_simple_resource.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 16 +- include/linux/rwsem.h | 1 + kernel/locking/rwsem.c| 23 ++ 17 files changed, 98 insertions(+), 515 deletions(-) delete mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c delete mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Remove custom locking code
vmwgfx used a custom locking code to support semantics of a
interruptible rwsem. Now with down_(read|write)_interruptible
implemented in the rwsem we can completely remove the custom
locking code. It also allows us to remove the hacks we needed
to support proper waits for write resources before
hibernation.
Cc: Martin Krastev
Cc: Roland Scheidegger
Cc: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/ttm_lock.c | 194
drivers/gpu/drm/vmwgfx/ttm_lock.h | 218 --
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 24 +-
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 57 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 32 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 4 +-
.../gpu/drm/vmwgfx/vmwgfx_simple_resource.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 16 +-
15 files changed, 74 insertions(+), 515 deletions(-)
delete mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.c
delete mode 100644 drivers/gpu/drm/vmwgfx/ttm_lock.h
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index cc4cdca7176e..744a806918df 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -9,7 +9,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_cotable.o vmwgfx_so.o vmwgfx_binding.o vmwgfx_msg.o \
vmwgfx_simple_resource.o vmwgfx_va.o vmwgfx_blit.o \
vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
- ttm_object.o ttm_lock.o
+ ttm_object.o
vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/ttm_lock.c
b/drivers/gpu/drm/vmwgfx/ttm_lock.c
deleted file mode 100644
index 5971c72e6d10..
--- a/drivers/gpu/drm/vmwgfx/ttm_lock.c
+++ /dev/null
@@ -1,194 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 OR MIT */
-/**
- *
- * Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
- * All Rights Reserved.
- *
- * 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, sub license, 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 (including the
- * next paragraph) 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 NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS 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.
- *
- **/
-/*
- * Authors: Thomas Hellstrom
- */
-
-#include
-#include
-#include
-#include
-#include "ttm_lock.h"
-#include "ttm_object.h"
-
-#define TTM_WRITE_LOCK_PENDING(1 << 0)
-#define TTM_VT_LOCK_PENDING (1 << 1)
-#define TTM_SUSPEND_LOCK_PENDING (1 << 2)
-#define TTM_VT_LOCK (1 << 3)
-#define TTM_SUSPEND_LOCK (1 << 4)
-
-void ttm_lock_init(struct ttm_lock *lock)
-{
- spin_lock_init(>lock);
- init_waitqueue_head(>queue);
- lock->rw = 0;
- lock->flags = 0;
-}
-
-void ttm_read_unlock(struct ttm_lock *lock)
-{
- spin_lock(>lock);
- if (--lock->rw == 0)
- wake_up_all(>queue);
- spin_unlock(>lock);
-}
-
-static bool __ttm_read_lock(struct ttm_lock *lock)
-{
- bool locked = false;
-
- spin_lock(>lock);
- if (lock->rw >= 0 && lock->flags == 0) {
- ++lock->rw;
- locked = true;
- }
- spin_unlock(>lock);
- return locked;
-}
-
-int ttm_read_lock(struct ttm_lock *lock, bool interruptible)
-{
- int ret = 0;
-
- if (interruptible)
- ret = wait_event_interruptible(lock->queue,
-
[PATCH 1/2] locking/rwsem: Add down_write_interruptible
Add an interruptible version of down_write. It's the other
side of the already implemented down_read_interruptible.
It allows drivers which used custom locking code to
support interruptible rw semaphores to switch over
to rwsem.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
include/linux/rwsem.h | 1 +
kernel/locking/rwsem.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 4c715be48717..753ae2cb8677 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -135,6 +135,7 @@ extern int down_read_trylock(struct rw_semaphore *sem);
* lock for writing
*/
extern void down_write(struct rw_semaphore *sem);
+extern int __must_check down_write_interruptible(struct rw_semaphore *sem);
extern int __must_check down_write_killable(struct rw_semaphore *sem);
/*
diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
index abba5df50006..0eadd20347de 100644
--- a/kernel/locking/rwsem.c
+++ b/kernel/locking/rwsem.c
@@ -1270,6 +1270,11 @@ static inline void __down_write(struct rw_semaphore *sem)
__down_write_common(sem, TASK_UNINTERRUPTIBLE);
}
+static inline int __down_write_interruptible(struct rw_semaphore *sem)
+{
+ return __down_write_common(sem, TASK_INTERRUPTIBLE);
+}
+
static inline int __down_write_killable(struct rw_semaphore *sem)
{
return __down_write_common(sem, TASK_KILLABLE);
@@ -1408,6 +1413,24 @@ void __sched down_write(struct rw_semaphore *sem)
}
EXPORT_SYMBOL(down_write);
+/*
+ * interruptible lock for writing
+ */
+int __sched down_write_interruptible(struct rw_semaphore *sem)
+{
+ might_sleep();
+ rwsem_acquire(>dep_map, 0, 0, _RET_IP_);
+
+ if (LOCK_CONTENDED_RETURN(sem, __down_write_trylock,
+ __down_write_interruptible)) {
+ rwsem_release(>dep_map, _RET_IP_);
+ return -EINTR;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(down_write_interruptible);
+
/*
* lock for writing
*/
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [variant b] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Change the 'imply' to a weak dependency that still allows compiling
in all other configurations but disallows the configuration that
causes a link failure.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index f02c938f75da..d01dba2af3bb 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -6,7 +6,7 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
- imply AMD_IOMMU_V2 if X86_64
+ depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
Hi Parshuram, On Tue, Mar 02, 2021 at 12:53:50PM +, Parshuram Raju Thombare wrote: > Hi Laurent, > > >>> Is this a property of the hardware, that is, are there multiple versions > >>> of this IP core covered by the same compatible string that support HDCP > >>> 1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given > >>> system will offer ?[] > >> > >> MHDP hardware supports both HDCP 2.2 and 1.4. So, this is a way > >> to select the version of HDCP, system wish to support. > > > > Then I'm not sure this qualifies as a DT property, which should describe > > the system, not configure it. A way for userspace to configure this > > would be better. > > Since this is for source device, I am not sure how useful it is to allow > user to change HDCP version supported. I think doing it in DTS > gives more control over HDCP to system designer/integrator. But how would they do so ? What would be the rationale for selecting a particular version in DT ? I'm not thinking about giving control of this parameter to the end-user, but in the context of an embedded system, it may be useful to select which HDCP versions to offer based on different constraints at runtime. This really seems like a system configuration parameter to me, not a system description. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 9:12 PM Christian König wrote: > Am 08.03.21 um 21:02 schrieb Felix Kuehling: > > Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: > > I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid > > it, because it is only really needed for a small number of AMD APUs, and > > even there it is now optional for more recent ones. > > > > Is there a better way to avoid build failures without creating a hard > > dependency? > > What you need is the same trick we used for AGP on radeon/nouveau: > > depends on AMD_IOMMU_V2 || !AMD_IOMMU_V2 > > This way when AMD_IOMMU_V2 is build as a module DRM_AMDGPU will be build > as a module as well. When it is disabled completely we don't care. Note that this trick only works if you put it into the DRM_AMDGPU Kconfig option itself, since that decides if the driver is built-in or a loadable module. If HSA_AMD is disabled, that dependency is not really necessary. The version I suggested -- adding "depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m" to the HSA_AMD option -- might be slightly nicer since it lets you still build a kernel with DRM_AMDGPU=y and AMD_IOMMU_V2=m, but without the HSA_AMD. I can send a patch with either of those two options to replace my original patch. > >The documentation in > > Documentation/kbuild/kconfig-language.rst suggests using if > > (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function > > calls. I think more generally, we could guard all of kfd_iommu.c with > > > > #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) > > > > And use the same condition to define the stubs in kfd_iommu.h. This would fix the compile-time error, but it's also the one I'd least recommend out of all the options, because that causes the driver to silently not work as expected. This seems even worse than failing the build. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: display: bridge: Add Chipone ICN6211 bindings
On Thu, 04 Mar 2021 14:51:32 +0530, Jagan Teki wrote: > ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone. > > It has a flexible configuration of MIPI DSI signal input and > produces RGB565, RGB666, RGB888 output format. > > Add dt-bingings for it. > > Signed-off-by: Jagan Teki > --- > Changes for v4: > - fixed Laurent comments > - added regulators > - replace reset with EN > - fixed warnings pointed by Robert > Changes for v3: > - updated to new dt-bindings style > > .../display/bridge/chipone,icn6211.yaml | 99 +++ > MAINTAINERS | 5 + > 2 files changed, 104 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 08.03.21 um 21:02 schrieb Felix Kuehling: Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: The driver build should work without IOMMUv2. In amdkfd/Makefile, we have this condition: ifneq ($(CONFIG_AMD_IOMMU_V2),) AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o endif In amdkfd/kfd_iommu.h we define inline stubs of the functions that are causing your link-failures if IOMMU_V2 is not enabled: #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) ... function declarations ... #else ... stubs ... #endif Right, that is the problem I tried to explain in my patch description. Should we just drop the 'imply' then and add a proper dependency like this? depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m I can send a v2 after some testing if you prefer this version. No. My point is, there should not be a hard dependency. The build should work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not working for you. It looks like you're building kfd_iommu.o, which should not be happening when AMD_IOMMU_V2 is not enabled. The condition in amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with your kernel config. Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as a loadable module, while AMDGPU is configured as built-in. I'm sorry, I didn't read it carefully. And I thought "imply" was meant to fix exactly this kind of issue. I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid it, because it is only really needed for a small number of AMD APUs, and even there it is now optional for more recent ones. Is there a better way to avoid build failures without creating a hard dependency? What you need is the same trick we used for AGP on radeon/nouveau: depends on AMD_IOMMU_V2 || !AMD_IOMMU_V2 This way when AMD_IOMMU_V2 is build as a module DRM_AMDGPU will be build as a module as well. When it is disabled completely we don't care. Regards, Christian. The documentation in Documentation/kbuild/kconfig-language.rst suggests using if (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function calls. I think more generally, we could guard all of kfd_iommu.c with #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) And use the same condition to define the stubs in kfd_iommu.h. Regards, Felix The causes a link failure for the vmlinux file, because the linker cannot resolve addresses of loadable modules at compile time -- they have not been loaded yet. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: > On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: >> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: >>> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling >>> wrote: The driver build should work without IOMMUv2. In amdkfd/Makefile, we have this condition: ifneq ($(CONFIG_AMD_IOMMU_V2),) AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o endif In amdkfd/kfd_iommu.h we define inline stubs of the functions that are causing your link-failures if IOMMU_V2 is not enabled: #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) ... function declarations ... #else ... stubs ... #endif >>> Right, that is the problem I tried to explain in my patch description. >>> >>> Should we just drop the 'imply' then and add a proper dependency like this? >>> >>> depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) >>> depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m >>> >>> I can send a v2 after some testing if you prefer this version. >> No. My point is, there should not be a hard dependency. The build should >> work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not >> working for you. It looks like you're building kfd_iommu.o, which should >> not be happening when AMD_IOMMU_V2 is not enabled. The condition in >> amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with >> your kernel config. > Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as > a loadable module, while AMDGPU is configured as built-in. I'm sorry, I didn't read it carefully. And I thought "imply" was meant to fix exactly this kind of issue. I don't want to create a hard dependency on AMD_IOMMU_V2 if I can avoid it, because it is only really needed for a small number of AMD APUs, and even there it is now optional for more recent ones. Is there a better way to avoid build failures without creating a hard dependency? The documentation in Documentation/kbuild/kconfig-language.rst suggests using if (IS_REACHABLE(CONFIG_AMD_IOMMU_V2)) to guard those problematic function calls. I think more generally, we could guard all of kfd_iommu.c with #if IS_REACHABLE(CONFIG_AMD_IOMMU_V2) And use the same condition to define the stubs in kfd_iommu.h. Regards, Felix > > The causes a link failure for the vmlinux file, because the linker cannot > resolve addresses of loadable modules at compile time -- they have > not been loaded yet. > > Arnd > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/8] mm: Device exclusive memory access
On 3/3/21 10:16 PM, Alistair Popple wrote: Some devices require exclusive write access to shared virtual memory (SVM) ranges to perform atomic operations on that memory. This requires CPU page tables to be updated to deny access whilst atomic operations are occurring. In order to do this introduce a new swap entry type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for exclusive access by a device all page table mappings for the particular range are replaced with device exclusive swap entries. This causes any CPU access to the page to result in a fault. Faults are resovled by replacing the faulting entry with the original mapping. This results in MMU notifiers being called which a driver uses to update access permissions such as revoking atomic access. After notifiers have been called the device will no longer have exclusive access to the region. Signed-off-by: Alistair Popple I see in the next two patches how make_device_exclusive_entry() and check_device_exclusive_range() are used. This points out a similar problem that migrate_vma_setup() had before I added the mmu_notifier_range_init_migrate() helper to pass a cookie from migrate_vma_setup() to the invalidation callback so the device driver could ignore an invalidation callback triggered by the caller and thus resulting in a deadlock or having to invalidate device PTEs that wouldn't be migrating. I think you can eliminate the need for check_device_exclusive_range() in the same way by adding a "void *" pointer to make_device_exclusive_entry() and passing that through to try_to_protect(), setting rmap_walk_control rwc.arg and then passing arg to mmu_notifier_range_init_migrate(). Although, maybe it would be better to define a new mmu_notifier_range_init_exclusive() and event type MMU_NOTIFY_EXCLUSIVE so that a device driver can revoke atomic/exclusive access but keep read/write access to other parts of the page. I thought about how make_device_exclusive_entry() is similar to hmm_range_fault() and whether it would be possible to add a new HMM_PFN_REQ_EXCLUSIVE flag but I see that make_device_exclusive_entry() returns the pages locked and with an additional get_page() reference. This doesn't fit well with the other hmm_range_fault() entries being returned as a "snapshot" so having a different API makes sense. I think it would be useful to add a HMM_PFN_EXCLUSIVE flag so that snapshots of the page tables can at least report that a page is exclusively being accessed by *some* device. Unfortunately, there is no pgmap pointer to be able to tell which device has exclusive access (since any struct page could be exclusively accessed, not just device private ones). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212077] AMD GPU discrete card memory at highest frequency even while not in use
https://bugzilla.kernel.org/show_bug.cgi?id=212077 Bat Malin (bat_ma...@abv.bg) changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|PATCH_ALREADY_AVAILABLE |--- --- Comment #4 from Bat Malin (bat_ma...@abv.bg) --- Issue not fixed in kernel 5.11.4 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: > > Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: > > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling > > wrote: > >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we > >> have this condition: > >> > >> ifneq ($(CONFIG_AMD_IOMMU_V2),) > >> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o > >> endif > >> > >> In amdkfd/kfd_iommu.h we define inline stubs of the functions that are > >> causing your link-failures if IOMMU_V2 is not enabled: > >> > >> #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) > >> ... function declarations ... > >> #else > >> ... stubs ... > >> #endif > > Right, that is the problem I tried to explain in my patch description. > > > > Should we just drop the 'imply' then and add a proper dependency like this? > > > > depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) > > depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m > > > > I can send a v2 after some testing if you prefer this version. > > No. My point is, there should not be a hard dependency. The build should > work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not > working for you. It looks like you're building kfd_iommu.o, which should > not be happening when AMD_IOMMU_V2 is not enabled. The condition in > amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with > your kernel config. Again, as I explained in the changelog text, AMD_IOMMU_V2 configured as a loadable module, while AMDGPU is configured as built-in. The causes a link failure for the vmlinux file, because the linker cannot resolve addresses of loadable modules at compile time -- they have not been loaded yet. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gem: add checks of drm_gem_object->funcs
On Mon, Mar 1, 2021 at 5:25 AM Christian König
wrote:
>
>
>
> Am 01.03.21 um 11:04 schrieb Daniel Vetter:
> > On Mon, Mar 1, 2021 at 10:56 AM Thomas Zimmermann
> > wrote:
> >> (cc'ing amd devs)
> >>
> >> Hi
> >>
> >> Am 28.02.21 um 17:10 schrieb Pavel Turinský:
> >>> The checks were removed in commit d693def4fd1c ("drm: Remove obsolete GEM
> >>> and PRIME callbacks from struct drm_driver") and can lead to following
> >>> kernel oops:
> >> Thanks for reporting. All drivers are supposed to set the funcs pointer
> >> in their GEM objects. This looks like a radeon bug. Adding the AMD devs.
> > Looks like we're setting obj->funcs only in radeon_gem_object_create,
> > but should set it in radeon_bo_create instead so it catches internal
> > functions too. I think this was missed in
> >
> > commit ce77038fdae385f947757a37573d90f2e83f0271
> > Author: Gerd Hoffmann
> > Date: Mon Aug 5 16:01:06 2019 +0200
> >
> > drm/radeon: use embedded gem object
>
> Maybe the same problem we had for amdgpu that the function pointer
> wasn't set for imported DMA-bufs?
Should be fixed here:
https://patchwork.freedesktop.org/patch/423250/
Alex
>
> Regards,
> Christian.
>
> >
> > Adding Gerd.
> > -Daniel
> >
> >> Best regards
> >> Thomas
> >>
> >>> [ 139.449098] BUG: kernel NULL pointer dereference, address:
> >>> 0008
> >>> [ 139.449110] #PF: supervisor read access in kernel mode
> >>> [ 139.449113] #PF: error_code(0x) - not-present page
> >>> [ 139.449116] PGD 0 P4D 0
> >>> [ 139.449121] Oops: [#1] PREEMPT SMP PTI
> >>> [ 139.449126] CPU: 4 PID: 1181 Comm: Xorg Not tainted 5.11.2LEdoian #2
> >>> [ 139.449130] Hardware name: Gigabyte Technology Co., Ltd. To be filled
> >>> by O.E.M./Z77-DS3H, BIOS F4 04/25/2012
> >>> [ 139.449133] RIP: 0010:drm_gem_handle_create_tail+0xcb/0x190 [drm]
> >>> [ 139.449185] Code: 00 48 89 ef e8 06 b4 49 f7 45 85 e4 78 77 48 8d 6b
> >>> 18 4c 89 ee 48 89 ef e8 c2 f5 00 00 89 c2 85 c0 75 3e 48 8b 83 40 01 00
> >>> 00 <48> 8b 40 0
> >>> 8 48 85 c0 74 0f 4c 89 ee 48 89 df e8 71 5d 87 f7 85 c0
> >>> [ 139.449190] RSP: 0018:be21c194bd28 EFLAGS: 00010246
> >>> [ 139.449194] RAX: RBX: 9da9b3caf078 RCX:
> >>>
> >>> [ 139.449197] RDX: RSI: c039b893 RDI:
> >>>
> >>> [ 139.449199] RBP: 9da9b3caf090 R08: 0040 R09:
> >>> 9da983b911c0
> >>> [ 139.449202] R10: 9da984749e00 R11: 9da9859bfc38 R12:
> >>> 0007
> >>> [ 139.449204] R13: 9da9859bfc00 R14: 9da9859bfc50 R15:
> >>> 9da9859bfc38
> >>> [ 139.449207] FS: 7f6332a56900() GS:9daea7b0()
> >>> knlGS:
> >>> [ 139.449211] CS: 0010 DS: ES: CR0: 80050033
> >>> [ 139.449214] CR2: 0008 CR3: 0001319b8005 CR4:
> >>> 001706e0
> >>> [ 139.449217] Call Trace:
> >>> [ 139.449224] drm_gem_prime_fd_to_handle+0xff/0x1d0 [drm]
> >>> [ 139.449274] ? drm_prime_destroy_file_private+0x20/0x20 [drm]
> >>> [ 139.449323] drm_ioctl_kernel+0xac/0xf0 [drm]
> >>> [ 139.449363] drm_ioctl+0x20f/0x3b0 [drm]
> >>> [ 139.449403] ? drm_prime_destroy_file_private+0x20/0x20 [drm]
> >>> [ 139.449454] radeon_drm_ioctl+0x49/0x80 [radeon]
> >>> [ 139.449500] __x64_sys_ioctl+0x84/0xc0
> >>> [ 139.449507] do_syscall_64+0x33/0x40
> >>> [ 139.449514] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> [ 139.449522] RIP: 0033:0x7f63330fbe6b
> >>> [ 139.449526] Code: ff ff ff 85 c0 79 8b 49 c7 c4 ff ff ff ff 5b 5d 4c
> >>> 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f
> >>> 05 <48> 3d 01 f
> >>> 0 ff ff 73 01 c3 48 8b 0d d5 af 0c 00 f7 d8 64 89 01 48
> >>> [ 139.449529] RSP: 002b:7fff1e9c4438 EFLAGS: 0246 ORIG_RAX:
> >>> 0010
> >>> [ 139.449534] RAX: ffda RBX: 7fff1e9c447c RCX:
> >>> 7f63330fbe6b
> >>> [ 139.449537] RDX: 7fff1e9c447c RSI: c00c642e RDI:
> >>> 0012
> >>> [ 139.449539] RBP: c00c642e R08: 7fff1e9c4520 R09:
> >>> 7f63331c7a60
> >>> [ 139.449542] R10: 7f6329fb9ab0 R11: 0246 R12:
> >>> 55f69810ad40
> >>> [ 139.449544] R13: 0012 R14: 0010 R15:
> >>> 7fff1e9c4c20
> >>> [ 139.449549] Modules linked in: 8021q garp mrp bridge stp llc
> >>> nls_iso8859_1 vfat fat fuse btrfs blake2b_generic xor raid6_pq libcrc32c
> >>> crypto_user tun i2c_de
> >>> v it87 hwmon_vid snd_seq snd_hda_codec_realtek snd_hda_codec_generic
> >>> ledtrig_audio sg snd_hda_codec_hdmi virtio_balloon snd_hda_intel
> >>> virtio_console snd_intel_
> >>> dspcfg soundwire_intel virtio_pci soundwire_generic_allocation
> >>> soundwire_cadence virtio_blk snd_hda_codec intel_rapl_msr btusb
> >>> intel_rapl_common virtio_net btr
> >>> tl net_failover uvcvideo snd_usb_audio snd_hda_core btbcm
> >>> x86_pkg_temp_thermal failover soundwire_bus btintel intel_powerclamp
> >>> snd_soc_core
[Bug 212137] kernel NULL pointer dereference, black screen when using two graphics cards
https://bugzilla.kernel.org/show_bug.cgi?id=212137 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- Should be fixed with this patch: https://patchwork.freedesktop.org/patch/423250/ -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we >> have this condition: >> >> ifneq ($(CONFIG_AMD_IOMMU_V2),) >> AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o >> endif >> >> In amdkfd/kfd_iommu.h we define inline stubs of the functions that are >> causing your link-failures if IOMMU_V2 is not enabled: >> >> #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) >> ... function declarations ... >> #else >> ... stubs ... >> #endif > Right, that is the problem I tried to explain in my patch description. > > Should we just drop the 'imply' then and add a proper dependency like this? > > depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) > depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m > > I can send a v2 after some testing if you prefer this version. No. My point is, there should not be a hard dependency. The build should work without CONFIG_AMD_IOMMU_V2. I don't understand why it's not working for you. It looks like you're building kfd_iommu.o, which should not be happening when AMD_IOMMU_V2 is not enabled. The condition in amdkfd/Makefile should make sure that kfd_iommu.o doesn't get built with your kernel config. Regards, Felix > > Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: > > The driver build should work without IOMMUv2. In amdkfd/Makefile, we > have this condition: > > ifneq ($(CONFIG_AMD_IOMMU_V2),) > AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o > endif > > In amdkfd/kfd_iommu.h we define inline stubs of the functions that are > causing your link-failures if IOMMU_V2 is not enabled: > > #if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2) > ... function declarations ... > #else > ... stubs ... > #endif Right, that is the problem I tried to explain in my patch description. Should we just drop the 'imply' then and add a proper dependency like this? depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64) depends on AMD_IOMMU_V2=y || DRM_AMDGPU=m I can send a v2 after some testing if you prefer this version. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 4/6] dt-bindings: display: ti: ti, omap5-dss.txt: add cec clock
On Tue, 02 Mar 2021 17:24:01 +0100, Hans Verkuil wrote: > The cec clock is required as well in order to support HDMI CEC, > document this. > > Signed-off-by: Hans Verkuil > --- > Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/8] mm/rmap: Split migration into its own function
On 3/3/21 10:16 PM, Alistair Popple wrote: Migration is currently implemented as a mode of operation for try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE. However it does not have much in common with the rest of the unmap functionality of try_to_unmap_one() and thus splitting it into a separate function reduces the complexity of try_to_unmap_one() making it more readable. Several simplifications can also be made in try_to_migrate_one() based on the following observations: - All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK. - No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON. - No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH. TTU_SPLIT_FREEZE is a special case of migration used when splitting an anonymous page. This is most easily dealt with by calling the correct function from unmap_page() in mm/huge_memory.c - either try_to_migrate() for PageAnon or try_to_unmap(). Signed-off-by: Alistair Popple Reviewed-by: Christoph Hellwig Looks reasonable to me. I do worry a bit about code duplication. At some point in the future, it might be discovered that other combinations of TTU_XXX flags are needed in which case a careful check of try_to_migrate() and try_to_unmap() will be needed. Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
On 3/3/21 10:16 PM, Alistair Popple wrote: The behaviour of try_to_unmap_one() is difficult to follow because it performs different operations based on a fairly large set of flags used in different combinations. TTU_MUNLOCK is one such flag. However it is exclusively used by try_to_munlock() which specifies no other flags. Therefore rather than overload try_to_unmap_one() with unrelated behaviour split this out into it's own function and remove the flag. Signed-off-by: Alistair Popple Looks good to me. Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/8] mm/swapops: Rework swap entry manipulation code
On 3/3/21 10:16 PM, Alistair Popple wrote: Both migration and device private pages use special swap entries that are manipluated by a range of inline functions. The arguments to these are somewhat inconsitent so rework them to remove flag type arguments and to make the arguments similar for both read and write entry creation. Signed-off-by: Alistair Popple Reviewed-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe Looks good to me too. Reviewed-by: Ralph Campbell ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/8] mm: Remove special swap entry functions
On 3/3/21 10:16 PM, Alistair Popple wrote:
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
Looks OK to me.
Reviewed-by: Ralph Campbell
---
v4:
* Added pfn_swap_entry_to_page()
* Reinstated check that migration entries point to locked pages
* Removed #define swapcache_prepare which isn't needed for CONFIG_SWAP=0
builds
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23 +-
include/linux/swap.h| 4 +--
include/linux/swapops.h | 69 ++---
mm/hmm.c| 5 ++-
mm/huge_memory.c| 4 +--
mm/memcontrol.c | 2 +-
mm/memory.c | 10 +++---
mm/migrate.c| 6 ++--
mm/page_vma_mapped.c| 6 ++--
10 files changed, 50 insertions(+), 81 deletions(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 18205f851c24..aae001096c46 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -691,7 +691,7 @@ static void ptep_zap_swap_entry(struct mm_struct *mm,
swp_entry_t entry)
if (!non_swap_entry(entry))
dec_mm_counter(mm, MM_SWAPENTS);
else if (is_migration_entry(entry)) {
- struct page *page = migration_entry_to_page(entry);
+ struct page *page = pfn_swap_entry_to_page(entry));
dec_mm_counter(mm, mm_counter(page));
}
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 602e3a52884d..7c75af0fc423 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -514,10 +514,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
} else {
mss->swap_pss += (u64)PAGE_SIZE << PSS_SHIFT;
}
- } else if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ } else if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
} else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
&& pte_none(*pte))) {
page = xa_load(>vm_file->f_mapping->i_pages,
@@ -549,7 +547,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
swp_entry_t entry = pmd_to_swp_entry(*pmd);
if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
if (IS_ERR_OR_NULL(page))
return;
@@ -691,10 +689,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long
hmask,
} else if (is_swap_pte(*pte)) {
swp_entry_t swpent = pte_to_swp_entry(*pte);
- if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
}
if (page) {
int mapcount = page_mapcount(page);
@@ -1382,11 +1378,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct
pagemapread *pm,
frame = swp_type(entry) |
(swp_offset(entry) << MAX_SWAPFILES_SHIFT);
flags |= PM_SWAP;
- if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
-
- if (is_device_private_entry(entry))
- page = device_private_entry_to_page(entry);
+ if (is_pfn_swap_entry(entry))
+ page = pfn_swap_entry_to_page(entry);
}
if (page && !PageAnon(page))
@@ -1443,7 +1436,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long
addr, unsigned long end,
if (pmd_swp_soft_dirty(pmd))
flags |= PM_SOFT_DIRTY;
VM_BUG_ON(!is_pmd_migration_entry(pmd));
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
#endif
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 596bc2f4d9b0..57a7690966a4 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -519,8 +519,8 @@ static inline void show_swap_cache_info(void)
{
}
-#define free_swap_and_cache(e) ({(is_migration_entry(e) || is_device_private_entry(e));})
-#define swapcache_prepare(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
+/* used to sanity check ptes in zap_pte_range
Re: [PATCH v7 3/3] drm: Add GUD USB Display driver
Den 05.03.2021 17.31, skrev Noralf Trønnes:
> This adds a USB display driver with the intention that it can be
> used with future USB interfaced low end displays/adapters. The Linux
> gadget device driver will serve as the canonical device implementation.
>
> diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
> +static int gud_probe(struct usb_interface *intf, const struct usb_device_id
> *id)
> +{
> + num_formats_dev = ret;
> + for (i = 0; i < num_formats_dev; i++) {
> + const struct drm_format_info *info;
> + size_t fmt_buf_size;
> + u32 format;
> +
> + format = gud_to_fourcc(formats_dev[i]);
> + if (!format) {
> + drm_dbg(drm, "Unsupported format: 0x%02x\n",
> formats_dev[i]);
> + continue;
> + }
> +
> + if (format == GUD_DRM_FORMAT_R1)
> + info = _drm_format_r1;
> + else if (format == GUD_DRM_FORMAT_RGB111)
> + info = _drm_format_rgb111;
> + else
> + info = drm_format_info(format);
> +
> + switch (format) {
> + case GUD_DRM_FORMAT_R1:
> + fallthrough;
> + case GUD_DRM_FORMAT_RGB111:
> + xrgb_emulation_format = info;
> + break;
> + case DRM_FORMAT_RGB565:
> + rgb565_supported = true;
> + if (!xrgb_emulation_format)
> + xrgb_emulation_format = info;
> + break;
> + case DRM_FORMAT_XRGB:
> + xrgb_supported = true;
> + break;
> + };
> +
> + fmt_buf_size = drm_format_info_min_pitch(info, 0,
> drm->mode_config.max_width) *
> +drm->mode_config.max_height;
> + max_buffer_size = max(max_buffer_size, fmt_buf_size);
> +
> + if (format == GUD_DRM_FORMAT_R1)
This line should be:
if (format == GUD_DRM_FORMAT_R1 || format ==
GUD_DRM_FORMAT_RGB111)
There's also a bug in the format conversion functions that shows up on
transfers with widths that are not pixels per byte aligned. I've fixed
R1, I'll look at RGB111 tomorrow.
Noralf.
> + continue; /* Internal not for userspace */
> +
> + formats[num_formats++] = format;
> + }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212137] kernel NULL pointer dereference, black screen when using two graphics cards
https://bugzilla.kernel.org/show_bug.cgi?id=212137 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Likely the same issue as this: https://www.spinics.net/lists/amd-gfx/msg59207.html -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212137] kernel NULL pointer dereference, black screen when using two graphics cards
https://bugzilla.kernel.org/show_bug.cgi?id=212137 --- Comment #1 from Dennis Foster (m...@dennisfoster.us) --- Created attachment 295743 --> https://bugzilla.kernel.org/attachment.cgi?id=295743=edit systemd journal -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212137] New: kernel NULL pointer dereference, black screen when using two graphics cards
https://bugzilla.kernel.org/show_bug.cgi?id=212137 Bug ID: 212137 Summary: kernel NULL pointer dereference, black screen when using two graphics cards Product: Drivers Version: 2.5 Kernel Version: 5.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: m...@dennisfoster.us Regression: No Created attachment 295741 --> https://bugzilla.kernel.org/attachment.cgi?id=295741=edit lspci -vvv On linux v5.11 and above (up to 5.11.4) I cannot longer boot the system (GNOME/Wayland) using two graphics cards. It gets stuck with black screen with no response to keyboard/mouse. In systemd journal there are some messages about kernel bug: Mar 08 11:54:05 homeserver kernel: BUG: kernel NULL pointer dereference, address: 0008 Mar 08 11:54:05 homeserver kernel: #PF: supervisor read access in kernel mode Mar 08 11:54:05 homeserver kernel: #PF: error_code(0x) - not-present page Mar 08 11:54:05 homeserver kernel: PGD 0 P4D 0 Mar 08 11:54:05 homeserver kernel: Oops: [#1] PREEMPT SMP NOPTI Mar 08 11:54:05 homeserver kernel: CPU: 6 PID: 608 Comm: gnome-shell Tainted: G OE 5.11.4-arch1-1 #1 Mar 08 11:54:05 homeserver kernel: Hardware name: Gigabyte Technology Co., Ltd. A320M-S2H/A320M-S2H-CF, BIOS F2 11/03/2020 Mar 08 11:54:05 homeserver kernel: RIP: 0010:drm_gem_handle_create_tail+0xcb/0x190 [drm] Mar 08 11:54:05 homeserver kernel: Code: 00 48 89 df e8 c6 20 59 f4 45 85 e4 78 77 48 8d 5d 18 4c 89 ee 48 89 df e8 42 fe 00 00 89 c2 85 c0 75 3e 48 8b 85 40 01 00 00 <48> 8b 40 08 48 85 c0 74 0f 4c 89 ee 48 89 ef e8 81 8b 91 f4 85 c0 Mar 08 11:54:05 homeserver kernel: RSP: 0018:b7a7c16bfd30 EFLAGS: 00010246 Mar 08 11:54:05 homeserver kernel: RAX: RBX: a0eabe065090 RCX: 0001 Everything works perfectly fine using current LTS v5.10.21. I am using Radeon RX 470 as a primary card, and the older ATI FirePro 2270 as a secondary one in order to provide two extra monitor outputs. I've attached my lspci output as well as full systemd log. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
On Mon, Mar 01, 2021 at 12:22:26PM +0100, Parshuram Thombare wrote:
> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
> This binding is not used in any upstreamed DTS yet, so changing
> index of property 'j721e-intg' should not affect anything.
TI folks might disagree, but weren't Cc'ed.
>
> Signed-off-by: Parshuram Thombare
> ---
> .../display/bridge/cdns,mhdp8546.yaml | 29 ---
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> index 63427878715e..5fdadadaac16 100644
> --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
> @@ -17,21 +17,24 @@ properties:
>- ti,j721e-mhdp8546
>
>reg:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- description:
>Register block of mhdptx apb registers up to PHY mapped area
> (AUX_CONFIG_P).
>The AUX and PMA registers are not part of this range, they are
> instead
>included in the associated PHY.
> + - description:
> + Register block of mhdptx sapb registers.
>- description:
>Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
>
>reg-names:
> -minItems: 1
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
> items:
>- const: mhdptx
> + - const: mhdptx-sapb
>- const: j721e-intg
>
>clocks:
> @@ -53,6 +56,11 @@ properties:
>power-domains:
> maxItems: 1
>
> + hdcp-config:
> +maxItems: 1
> +description:
> + HDCP version supported. Bit [0]:HDCP2.2 [1]:HDCP1.4.
2.2 is not backwards compatible with 1.4? What's the setting if not
present? Maybe just a 'disable 2.2 boolean' if that's the non-common
case.
In any case, it needs a type and constraints on the values.
> +
>interrupts:
> maxItems: 1
>
> @@ -98,15 +106,15 @@ allOf:
> then:
>properties:
> reg:
> - minItems: 2
> + minItems: 3
> reg-names:
> - minItems: 2
> + minItems: 3
> else:
>properties:
> reg:
> - maxItems: 1
> + maxItems: 2
> reg-names:
> - maxItems: 1
> + maxItems: 2
>
> required:
>- compatible
> @@ -129,8 +137,9 @@ examples:
>
> mhdp: dp-bridge@f0fb00 {
> compatible = "cdns,mhdp8546";
> -reg = <0xf0 0xfb00 0x0 0x100>;
> -reg-names = "mhdptx";
> +reg = <0xf0 0xfb00 0x0 0x100>,
> + <0x0 0x4f48000 0x0 0x74>;
> +reg-names = "mhdptx", "mhdptx-sapb";
> clocks = <_clock>;
> phys = <_phy>;
> phy-names = "dpphy";
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: meson_drv add shutdown function
Artem Lapkin writes: > Problem: random stucks on reboot stage about 1/20 stuck/reboots > // debug kernel log > [4.496660] reboot: kernel restart prepare CMD:(null) > [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller: > shutdown begin > [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller: > shutdown domain 0:VPU... > ...STUCK... > > Solution: add shutdown function to meson_drm driver > // debug kernel log > [5.231896] reboot: kernel restart prepare CMD:(null) > [5.246135] [drm:meson_drv_shutdown] > ... > [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller: > shutdown begin > [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller: > shutdown domain 0:VPU... > [5.338331] reboot: Restarting system > [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null) > bl31 reboot reason: 0xd > bl31 reboot reason: 0x0 > system cmd 1. > ...REBOOT... > > Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots > and Odroid boards, WeTek Play2 (GXBB) > > Tested-by: Christian Hewitt > Signed-off-by: Artem Lapkin Acked-by: Kevin Hilman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: leds: backlight: qcom-wled: Add PMI8994 compatible
On Sun, 28 Feb 2021 13:41:04 +0100, Konrad Dybcio wrote: > Document the newly added PMI8994 compatible. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128
On Thu, Mar 04, 2021 at 08:52:41PM -0500, Lyude Paul wrote:
> While Kepler does technically support 256x256 cursors, it turns out that
> Kepler actually has some additional requirements for scanout surfaces that
> we're not enforcing correctly, which aren't present on Maxwell and later.
> Cursor surfaces must always use small pages (4K), and overlay surfaces must
> always use large pages (128K).
>
> Fixing this correctly though will take a bit more work: as we'll need to
> add some code in prepare_fb() to move cursor FBs in large pages to small
> pages, and vice-versa for overlay FBs. So until we have the time to do
> that, just limit cursor surfaces to 128x128 - a size small enough to always
> default to small pages.
>
> This means small ovlys are still broken on Kepler, but it is extremely
> unlikely anyone cares about those anyway :).
>
> Signed-off-by: Lyude Paul
> Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to
> userspace")
> Cc: # v5.11+
I was experiencing problems with the mouse cursor on my system in v5.11
and after a bisect to help me search the web I found my way to this
patch, which fixed the problem for me.
Mine is an Armv8 system but there is nothing particularly exotic from a
graphics card or software point of view: Debian bullseye/wayland
(gnome-shell 3.38.3, mesa-20.3.4) running on a GT-710.
However FWIW:
Tested-by: Daniel Thompson
Daniel.
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 196612addfd6..1c9c0cdf85db 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2693,9 +2693,20 @@ nv50_display_create(struct drm_device *dev)
> else
> nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
>
> - if (disp->disp->object.oclass >= GK104_DISP) {
> + /* FIXME: 256x256 cursors are supported on Kepler, however unlike
> Maxwell and later
> + * generations Kepler requires that we use small pages (4K) for cursor
> scanout surfaces. The
> + * proper fix for this is to teach nouveau to migrate fbs being used
> for the cursor plane to
> + * small page allocations in prepare_fb(). When this is implemented, we
> should also force
> + * large pages (128K) for ovly fbs in order to fix Kepler ovlys.
> + * But until then, just limit cursors to 128x128 - which is small
> enough to avoid ever using
> + * large pages.
> + */
> + if (disp->disp->object.oclass >= GM107_DISP) {
> dev->mode_config.cursor_width = 256;
> dev->mode_config.cursor_height = 256;
> + } else if (disp->disp->object.oclass >= GK104_DISP) {
> + dev->mode_config.cursor_width = 128;
> + dev->mode_config.cursor_height = 128;
> } else {
> dev->mode_config.cursor_width = 64;
> dev->mode_config.cursor_height = 64;
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
The driver build should work without IOMMUv2. In amdkfd/Makefile, we
have this condition:
ifneq ($(CONFIG_AMD_IOMMU_V2),)
AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
endif
In amdkfd/kfd_iommu.h we define inline stubs of the functions that are
causing your link-failures if IOMMU_V2 is not enabled:
#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
... function declarations ...
#else
... stubs ...
#endif
Regards,
Felix
Am 2021-03-08 um 10:33 a.m. schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_bind_process_to_device':
> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_unbind_process':
> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_suspend':
> kfd_iommu.c:(.text+0x966): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
> `amd_iommu_free_device'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
> `kfd_iommu_resume':
> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
> `amd_iommu_bind_pasid'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
> `amd_iommu_free_device'
>
> Use a stronger 'select' instead.
>
> Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
> conditional")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/amdkfd/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
> b/drivers/gpu/drm/amd/amdkfd/Kconfig
> index f02c938f75da..91f85dfb7ba6 100644
> --- a/drivers/gpu/drm/amd/amdkfd/Kconfig
> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
> @@ -5,8 +5,9 @@
>
> config HSA_AMD
> bool "HSA kernel driver for AMD GPU devices"
> - depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
> - imply AMD_IOMMU_V2 if X86_64
> + depends on DRM_AMDGPU && ((X86_64 && IOMMU_SUPPORT && ACPI) || ARM64 ||
> PPC64)
> + select AMD_IOMMU if X86_64
> + select AMD_IOMMU_V2 if X86_64
> select HMM_MIRROR
> select MMU_NOTIFIER
> select DRM_AMDGPU_USERPTR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] media: hantro: imx: remove unused include
On Mon, 8 Mar 2021 at 13:57, Philipp Zabel wrote:
>
> Hi Emil,
>
> On Fri, Mar 05, 2021 at 06:39:21PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The current imx8 code does not use the jpeg encoder. Remove the
> > unnecessary include.
> >
> > Cc: Ezequiel Garcia
> > Cc: Philipp Zabel
> > Cc: linux-me...@vger.kernel.org
> > Cc: linux-rockc...@lists.infradead.org
> > Signed-off-by: Emil Velikov
>
> thank you, patches 2-4 could be tagged
>
> Fixes: 8e4aaa687863 ("media: hantro: add initial i.MX8MQ support")
> Reviewed-by: Philipp Zabel
>
Much appreciated. Will add all the tags for v2.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2
From: Arnd Bergmann
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use a stronger 'select' instead.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
b/drivers/gpu/drm/amd/amdkfd/Kconfig
index f02c938f75da..91f85dfb7ba6 100644
--- a/drivers/gpu/drm/amd/amdkfd/Kconfig
+++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
@@ -5,8 +5,9 @@
config HSA_AMD
bool "HSA kernel driver for AMD GPU devices"
- depends on DRM_AMDGPU && (X86_64 || ARM64 || PPC64)
- imply AMD_IOMMU_V2 if X86_64
+ depends on DRM_AMDGPU && ((X86_64 && IOMMU_SUPPORT && ACPI) || ARM64 ||
PPC64)
+ select AMD_IOMMU if X86_64
+ select AMD_IOMMU_V2 if X86_64
select HMM_MIRROR
select MMU_NOTIFIER
select DRM_AMDGPU_USERPTR
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/stm: dsi: Avoid printing errors for -EPROBE_DEFER
Applied on drm-misc-next.
Many thanks Raphaël & Yannick for your patch.
Note: I have updated the "From:" field to yannick.fer...@foss.st.com for more
consistency.
Philippe :-)
De : Yannick FERTRE - foss
Envoyé : lundi 8 mars 2021 10:10
À : Raphael GALLAIS-POU - foss; Yannick FERTRE; Philippe CORNU; Benjamin
Gaignard; Vincent ABRIOU; Sam Ravnborg; Joe Perches
Cc : David Airlie; Daniel Vetter; Maxime Coquelin; Alexandre TORGUE;
dri-devel@lists.freedesktop.org; linux-st...@st-md-mailman.stormreply.com;
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Philippe
CORNU - foss; Raphael GALLAIS-POU; Alexandre TORGUE - foss
Objet : Re: [PATCH 1/2] drm/stm: dsi: Avoid printing errors for -EPROBE_DEFER
Tested-by: Yannick Fertre
On 2/22/21 10:22 AM, Raphael GALLAIS-POU - foss wrote:
> From: Yannick Fertre
>
> Don't print error when probe deferred error is returned.
>
> Signed-off-by: Raphael Gallais-Pou
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 2e1f2664495d..8399d337589d 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -363,8 +363,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> *pdev)
>dsi->vdd_supply = devm_regulator_get(dev, "phy-dsi");
>if (IS_ERR(dsi->vdd_supply)) {
>ret = PTR_ERR(dsi->vdd_supply);
> - if (ret != -EPROBE_DEFER)
> - DRM_ERROR("Failed to request regulator: %d\n", ret);
> + dev_err_probe(dev, ret, "Failed to request regulator\n");
>return ret;
>}
>
> @@ -377,9 +376,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> *pdev)
>dsi->pllref_clk = devm_clk_get(dev, "ref");
>if (IS_ERR(dsi->pllref_clk)) {
>ret = PTR_ERR(dsi->pllref_clk);
> - if (ret != -EPROBE_DEFER)
> - DRM_ERROR("Unable to get pll reference clock: %d\n",
> - ret);
> + dev_err_probe(dev, ret, "Unable to get pll reference clock\n");
>goto err_clk_get;
>}
>
> @@ -419,7 +416,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> *pdev)
>dsi->dsi = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
>if (IS_ERR(dsi->dsi)) {
>ret = PTR_ERR(dsi->dsi);
> - DRM_ERROR("Failed to initialize mipi dsi host: %d\n", ret);
> + dev_err_probe(dev, ret, "Failed to initialize mipi dsi host\n");
>goto err_dsi_probe;
>}
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 1/2] drm/tegra: dc: Support memory bandwidth management
06.03.2021 02:02, Michał Mirosław пишет: > On Fri, Mar 05, 2021 at 12:45:51AM +0300, Dmitry Osipenko wrote: >> 04.03.2021 02:08, Michał Mirosław пишет: >>> On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote: Display controller (DC) performs isochronous memory transfers, and thus, has a requirement for a minimum memory bandwidth that shall be fulfilled, otherwise framebuffer data can't be fetched fast enough and this results in a DC's data-FIFO underflow that follows by a visual corruption. > [...] + /* + * Horizontal downscale takes extra bandwidth which roughly depends + * on the scaled width. + */ + if (src_w > dst_w) + mul = (src_w - dst_w) * bpp / 2048 + 1; + else + mul = 1; >>> >>> Does it really need more bandwidth to scale down? Does it read the same >>> data multiple times just to throw it away? >> The hardware isn't optimized for downscale, it indeed takes more >> bandwidth. You'll witness a severe underflow of plane's memory FIFO >> buffer on trying to downscale 1080p plane to 50x50. > [...] > > In your example, does it really need 16x the bandwidth compared to > no scaling case? The naive way to implement downscaling would be to read > all the pixels and only take every N-th. Maybe the problem is that in > downscaling mode the latency requirements are tighter? Why would bandwidth > required be proportional to a difference between the widths (instead e.g. > to src/dst or dst*cacheline_size)? Seems you're right, it's actually not the bandwidth. Recently I added memory client statistics gathering support to grate-kernel for Tegra20 and it shows that the consumed bandwidth is actually lower when plane is downscaled. So it should be the latency, which depends on memory frequency, and thus, on bandwidth. I'll try to improve comment to the code in the next version, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock
Hi, On Sat, Mar 06, 2021 at 11:56:45AM -0800, Rob Herring wrote: > On Tue, Feb 23, 2021 at 02:26:57AM +0100, Sebastian Reichel wrote: > > On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote: > > > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > > > > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > > > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > > > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > > > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > > > > the clock is disabled and all i.MX6 functionality depending on > > > > > the 32 KHz clock has undefined behaviour. On systems using hardware > > > > > watchdog it seems to likely trigger a lot earlier than configured. > > > > > > > > > > The proper solution would be to describe this dependency in DT, > > > > > but that will result in a deadlock. The kernel will see, that > > > > > i.MX6 system clock needs the RTC clock and do probe deferral. > > > > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > > > > CKIL clock and thus the RTC's clock will not be probed. So from > > > > > the kernel's perspective this is a chicken-and-egg problem. > > > > > > > > > > > > > Reading the previous paragraph, I was going to suggest describing the > > > > dependency and wondering whether this would cause a circular dependency. > > > > I guess this will keep being an issue for clocks on an I2C or SPI bus... > > > > Yes, it is a circular dependency on this particular system on > > module. It only works because the RTC enables the clock by > > default. The i.MX6 CKIL is expected to be always enabled. > > I think you should describe the circular clocking and then provide a way > to break the dependency. This is very much not trivial. The clock is required during early initialization of the i.MX. At this point we are far from probing I2C drivers and without the I2C driver the clock is not registered. The current i.MX code expects the system clocks to be fixed clocks, since they must be enabled before any code is executed (incl. bootloader) and must never be disabled. From a HW design point of view it does not make sense to have a SW controllable clock for it, since it just adds extra cost. I believe for QMX6 it is only SW controllable, because that avoids the need for an extra crystal. So how is the clock framework supposed to know, that it can ignore the clock during registration? I see the following options: 1. My solution is the simplest one. Keep i.MX clock code the same (it assumes a fixed-clock being used for CKIL) and avoid registering RTC clock. This basically means the RTC is considered to be a fixed-clock on this system, which is what the HW designers seemed to have in mind (vendor kernel for the QMX6 is old enough (4.9.x) to not to have CLK feature in the RTC driver. Vendor U-Boot also does not touch the RTC. Booting mainline kernel once bricks QMX6 boards until RTC battery is removed, so one could actually argue addition of the CLK feature in 1373e77b4f10 (4.13) is a regression). Currently Qualcomm device uses "protected-clocks" for FW controlled clocks where Linux would crash the system by trying to access them. IMHO the RTC is similar, since disabling or modifying its frequency on QMX6 results in undefined behaviour and possibly system crash. 2. Make i.MX clock code use the RTC as CKIL clock provider, but ignore it somehow. I see three sub-options: 2.1. Add a property 'boot-enabled' to the RTC node, so that the clock framework is aware of clock being enabled. This can be used to satisfy clock dependencies somehow. 2.2. The RTC device is not probed without I2C bus, but the driver could also register a fake clock purely based on DT information by adding some early init hook and take over the clock once the I2C part is being probed. I think this is a bad idea regarding maintainability of the driver. Also for systems not using the RTC clock, the early clock registration is basically wrong: If the kernel disables the RTC it will stay disabled across boots if the RTC has a backup battery. Basically we cannot imply anything from the RTC compatible value alone. 2.3 The i.MX core code could request CKIL with some flag, that it's fine to have an unresolvable clock and just expect it to be boot-enabled. The rationale would be, that CKIL must be always-enabled. > It's a somewhat common issue. It is? This only works, because one can treat the RTC's clock output like a fixed clock by not messing around with it. -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/4] PM / devfreq: lima: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14 +-
drivers/gpu/drm/lima/lima_devfreq.h | 2 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..86aea1bdc4f4 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -7,7 +7,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -84,17 +83,13 @@ static struct devfreq_dev_profile lima_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = lima_devfreq_target,
.get_dev_status = lima_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
void lima_devfreq_fini(struct lima_device *ldev)
{
struct lima_devfreq *devfreq = >devfreq;
- if (devfreq->cooling) {
- devfreq_cooling_unregister(devfreq->cooling);
- devfreq->cooling = NULL;
- }
-
if (devfreq->devfreq) {
devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
@@ -110,7 +105,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
int lima_devfreq_init(struct lima_device *ldev)
{
- struct thermal_cooling_device *cooling;
struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
@@ -173,12 +167,6 @@ int lima_devfreq_init(struct lima_device *ldev)
ldevfreq->devfreq = devfreq;
- cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
- if (IS_ERR(cooling))
- dev_info(dev, "Failed to register cooling device\n");
- else
- ldevfreq->cooling = cooling;
-
return 0;
err_fini:
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..c43a2069e5d3 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -9,7 +9,6 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
struct lima_device;
@@ -17,7 +16,6 @@ struct lima_devfreq {
struct devfreq *devfreq;
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
ktime_t busy_time;
ktime_t idle_time;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/4] PM / devfreq: panfrost: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..4d96edf1bc54 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -3,7 +3,6 @@
#include
#include
-#include
#include
#include
@@ -80,6 +79,7 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = panfrost_devfreq_target,
.get_dev_status = panfrost_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
int panfrost_devfreq_init(struct panfrost_device *pfdev)
@@ -90,7 +90,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct opp_table *opp_table;
- struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
@@ -139,12 +138,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdevfreq->devfreq = devfreq;
- cooling = devfreq_cooling_em_register(devfreq, NULL);
- if (IS_ERR(cooling))
- DRM_DEV_INFO(dev, "Failed to register cooling device\n");
- else
- pfdevfreq->cooling = cooling;
-
return 0;
err_fini:
@@ -156,11 +149,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
- if (pfdevfreq->cooling) {
- devfreq_cooling_unregister(pfdevfreq->cooling);
- pfdevfreq->cooling = NULL;
- }
-
if (pfdevfreq->opp_of_table_added) {
dev_pm_opp_of_remove_table(>pdev->dev);
pfdevfreq->opp_of_table_added = false;
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..470f5c974703 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -9,14 +9,11 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
-
struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
bool opp_of_table_added;
ktime_t busy_time;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/4] PM / devfreq: msm: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12 +---
drivers/gpu/drm/msm/msm_gpu.h | 2 --
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ab7c167b0623..eade94271a60 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
@@ -82,6 +81,7 @@ static struct devfreq_dev_profile msm_devfreq_profile = {
.target = msm_devfreq_target,
.get_dev_status = msm_devfreq_get_dev_status,
.get_cur_freq = msm_devfreq_get_cur_freq,
+ .is_cooling_device = true,
};
static void msm_devfreq_init(struct msm_gpu *gpu)
@@ -112,14 +112,6 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
}
devfreq_suspend_device(gpu->devfreq.devfreq);
-
- gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
- gpu->devfreq.devfreq);
- if (IS_ERR(gpu->cooling)) {
- DRM_DEV_ERROR(>pdev->dev,
- "Couldn't register GPU cooling device\n");
- gpu->cooling = NULL;
- }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -1056,6 +1048,4 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
if (gpu->worker) {
kthread_destroy_worker(gpu->worker);
}
-
- devfreq_cooling_unregister(gpu->cooling);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index d7cd02cd2109..93419368bac8 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -155,8 +155,6 @@ struct msm_gpu {
struct msm_gpu_state *crashstate;
/* True if the hardware supports expanded apriv (a650 and newer) */
bool hw_apriv;
-
- struct thermal_cooling_device *cooling;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/uapi: document kernel capabilities
Document all of the DRM_CAP_* defines.
v2 (Pekka):
- Describe what the bit depth is
- Expand on preferred dumb buffer memory access patterns
- Explain what a PRIME buffer is
- Mention DRM_IOCTL_PRIME_FD_TO_HANDLE and DRM_IOCTL_PRIME_HANDLE_TO_FD
- Explicitly reference CLOCK_REALTIME and CLOCK_MONOTONIC
- Make it clear DRM_CAP_CRTC_IN_VBLANK_EVENT applies to both DRM_EVENT_VBLANK
and DRM_EVENT_FLIP_COMPLETE
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 112 +++--
1 file changed, 108 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 0827037c5484..79e9c9d5e7a9 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -625,30 +625,134 @@ struct drm_gem_open {
__u64 size;
};
+/**
+ * DRM_CAP_DUMB_BUFFER
+ *
+ * If set to 1, the driver supports creating dumb buffers via the
+ * _IOCTL_MODE_CREATE_DUMB ioctl.
+ */
#define DRM_CAP_DUMB_BUFFER0x1
+/**
+ * DRM_CAP_VBLANK_HIGH_CRTC
+ *
+ * If set to 1, the kernel supports specifying a CRTC index in the high bits of
+ * _wait_vblank_request.type.
+ */
#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+/**
+ * DRM_CAP_DUMB_PREFERRED_DEPTH
+ *
+ * The preferred bit depth for dumb buffers.
+ *
+ * The bit depth is the number of bits used to indicate the color of a single
+ * pixel excluding any padding. This is different from the number of bits per
+ * pixel. For instance, XRGB has a bit depth of 24 but has 32 bits per
+ * pixel.
+ */
#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+/**
+ * DRM_CAP_DUMB_PREFER_SHADOW
+ *
+ * If set to 1, the driver prefers userspace to render to a shadow buffer
+ * instead of directly rendering to a dumb buffer. For best speed, userspace
+ * should do streaming ordered memory copies into the dumb buffer and never
+ * read from it.
+ */
#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+/**
+ * DRM_CAP_PRIME
+ *
+ * Bitfield of supported PRIME sharing capabilities. See _PRIME_CAP_IMPORT
+ * and _PRIME_CAP_EXPORT.
+ *
+ * PRIME buffers are exposed as dma-buf file descriptors. See
+ * Documentation/gpu/drm-mm.rst, section "PRIME Buffer Sharing".
+ */
#define DRM_CAP_PRIME 0x5
+/**
+ * DRM_PRIME_CAP_IMPORT
+ *
+ * If this bit is set in _CAP_PRIME, the driver supports importing PRIME
+ * buffers via the _IOCTL_PRIME_FD_TO_HANDLE ioctl.
+ */
#define DRM_PRIME_CAP_IMPORT 0x1
+/**
+ * DRM_PRIME_CAP_EXPORT
+ *
+ * If this bit is set in _CAP_PRIME, the driver supports exporting PRIME
+ * buffers via the _IOCTL_PRIME_HANDLE_TO_FD ioctl.
+ */
#define DRM_PRIME_CAP_EXPORT 0x2
+/**
+ * DRM_CAP_TIMESTAMP_MONOTONIC
+ *
+ * If set to 0, the kernel will report timestamps with ``CLOCK_REALTIME`` in
+ * struct drm_event_vblank. If set to 1, the kernel will report timestamps with
+ * ``CLOCK_MONOTONIC``. See ``clock_gettime(2)`` for the definition of these
+ * clocks.
+ */
#define DRM_CAP_TIMESTAMP_MONOTONIC0x6
+/**
+ * DRM_CAP_ASYNC_PAGE_FLIP
+ *
+ * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC.
+ */
#define DRM_CAP_ASYNC_PAGE_FLIP0x7
-/*
- * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid widthxheight
- * combination for the hardware cursor. The intention is that a hardware
- * agnostic userspace can query a cursor plane size to use.
+/**
+ * DRM_CAP_CURSOR_WIDTH
+ *
+ * The ``CURSOR_WIDTH`` and ``CURSOR_HEIGHT`` capabilities return a valid
+ * width x height combination for the hardware cursor. The intention is that a
+ * hardware agnostic userspace can query a cursor plane size to use.
*
* Note that the cross-driver contract is to merely return a valid size;
* drivers are free to attach another meaning on top, eg. i915 returns the
* maximum plane size.
*/
#define DRM_CAP_CURSOR_WIDTH 0x8
+/**
+ * DRM_CAP_CURSOR_HEIGHT
+ *
+ * See _CAP_CURSOR_WIDTH.
+ */
#define DRM_CAP_CURSOR_HEIGHT 0x9
+/**
+ * DRM_CAP_ADDFB2_MODIFIERS
+ *
+ * If set to 1, the driver supports supplying modifiers in the
+ * _IOCTL_MODE_ADDFB2 ioctl.
+ */
#define DRM_CAP_ADDFB2_MODIFIERS 0x10
+/**
+ * DRM_CAP_PAGE_FLIP_TARGET
+ *
+ * If set to 1, the driver supports the _MODE_PAGE_FLIP_TARGET_ABSOLUTE and
+ * _MODE_PAGE_FLIP_TARGET_RELATIVE flags in
+ * _mode_crtc_page_flip_target.flags for the _IOCTL_MODE_PAGE_FLIP
+ * ioctl.
+ */
#define DRM_CAP_PAGE_FLIP_TARGET 0x11
+/**
+ * DRM_CAP_CRTC_IN_VBLANK_EVENT
+ *
+ * If set to 1, the kernel supports reporting the CRTC ID in
+ * _event_vblank.crtc_id for the _EVENT_VBLANK and
+ * _EVENT_FLIP_COMPLETE events.
+ */
#define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
+/**
+ * DRM_CAP_SYNCOBJ
+ *
+ * If set to 1, the driver supports sync objects. See
+ * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
+ */
#define DRM_CAP_SYNCOBJ0x13
+/**
+ * DRM_CAP_SYNCOBJ_TIMELINE
+ *
+ * If set to 1, the driver supports timeline operations on sync
Re: [PATCH] drm/uapi: document kernel capabilities
On Monday, March 8th, 2021 at 9:20 AM, Pekka Paalanen wrote: > > > > +/** > > > > + * DRM_CAP_CRTC_IN_VBLANK_EVENT > > > > + * > > > > + * If set to 1, the kernel supports reporting the CRTC ID in > > > > + * _event_vblank.crtc_id. > > > > > > Does this not apply also to the pageflip / atomic completion event? > > > > Both DRM_EVENT_VBLANK and DRM_EVENT_FLIP_COMPLETE use the struct > > drm_event_vblank, so yes. I'll mention these two events explicitly. > > They do? Seems like I have been spoiled by the libdrm API that uses > drmEventContext with different callbacks for these things. Yeah, see drmHandleEvent [1] in libdrm. [1]: https://gitlab.freedesktop.org/mesa/drm/-/blob/7d6a1759900ffde0a7aac2fa0cbd7c2bf4989476/xf86drmMode.c#L922 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
Lontium LT8912B is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reported-by: kernel test robot
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912b.c | 836 +++
4 files changed, 852 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912b.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 719f633c8a28..072dea9c43ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10466,6 +10466,7 @@ LONTIUM LT8912B MIPI TO HDMI BRIDGE
M: Adrien Grassein
S: Maintained
F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
+F: drivers/gpu/drm/bridge/lontium-lt8912b.c
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3..f2c5ec75d2f5 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,20 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT8912B
+ tristate "Lontium LT8912B DSI/HDMI bridge"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT8912B DSI to HDMI bridge
+ chip driver.
+ Please say Y if you have such hardware.
+
+ Say M here if you want to support this hardware as a module.
+ The module will be named "lontium-lt8912b".
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d..756ce401aad3 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
new file mode 100644
index ..82501fe2e408
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -0,0 +1,836 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define I2C_MAIN 0
+#define I2C_ADDR_MAIN 0x48
+
+#define I2C_CEC_DSI 1
+#define I2C_ADDR_CEC_DSI 0x49
+
+#define I2C_MAX_IDX 2
+
+#define HPD_WORK_DELAY_MS 1000
+
+struct lt8912 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_client *i2c_client[I2C_MAX_IDX];
+ struct regmap *regmap[I2C_MAX_IDX];
+
+ struct device_node *host_node;
+ struct drm_bridge *hdmi_port;
+
+ struct mipi_dsi_device *dsi;
+
+ struct gpio_desc *gp_reset;
+
+ struct videomode mode;
+
+ u8 data_lanes;
+ bool is_power_on;
+ bool is_attached;
+
+ enum drm_connector_status cable_status;
+ struct workqueue_struct *workq;
+ struct delayed_work lt8912_check_hpd_work_id;
+};
+
+static int lt8912_write_init_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ /* Digital clock en*/
+ {0x08, 0xff},
+ {0x09, 0xff},
+ {0x0a, 0xff},
+ {0x0b, 0x7c},
+ {0x0c, 0xff},
+ {0x42, 0x04},
+
+ /*Tx Analog*/
+ {0x31, 0xb1},
+ {0x32, 0xb1},
+ {0x33, 0x0e},
+ {0x37, 0x00},
+ {0x38, 0x22},
+ {0x60, 0x82},
+
+ /*Cbus Analog*/
+ {0x39, 0x45},
+ {0x3a, 0x00},
+ {0x3b, 0x00},
+
+ /*HDMI Pll Analog*/
+ {0x44, 0x31},
+ {0x55, 0x44},
+ {0x57, 0x01},
+ {0x5a, 0x02},
+
+ /*MIPI Analog*/
+ {0x3e, 0xd6},
+ {0x3f, 0xd4},
+ {0x41, 0x3c},
+ {0xB2, 0x00},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq,
ARRAY_SIZE(seq));
+}
+
+static int lt8912_write_mipi_basic_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ {0x12, 0x04},
+ {0x14, 0x00},
+ {0x15, 0x00},
+ {0x1a, 0x03},
+ {0x1b, 0x03},
+ };
+
+ return
[PATCH v7 1/2] dt-bindings: display: bridge: Add documentation for LT8912B
Lontium LT8912B is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
Reviewed-by: Rob Herring
---
.../display/bridge/lontium,lt8912b.yaml | 102 ++
MAINTAINERS | 5 +
2 files changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
new file mode 100644
index ..735d0233a7d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912b.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT8912B MIPI to HDMI Bridge
+
+maintainers:
+ - Adrien Grassein
+
+description: |
+ The LT8912B is a bridge device which convert DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt8912b
+
+ reg:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Primary MIPI port for MIPI input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes: true
+
+required:
+ - data-lanes
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ HDMI port, should be connected to a node compatible with the
+ hdmi-connector binding.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@48 {
+compatible = "lontium,lt8912b";
+reg = <0x48>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+
+hdmi_out_in: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <_dsi_out>;
+};
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+};
+ };
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 9095d182deaf..719f633c8a28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10462,6 +10462,11 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: drivers/hid/hid-lg-g15.c
+LONTIUM LT8912B MIPI TO HDMI BRIDGE
+M: Adrien Grassein
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
M: Sreekanth Reddy
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/2] Add support of Lontium lt8912 MIPI to HDMI bridge
Hi, this patch set adds the support of the Lontium lt8912 MIPI to HDMI bridge in the kernel. It's only support the video part, not the audio part yet since I don't have the datasheet of this component. I get the current i2c configuration from Digi and Boundary drivers. Developed using the DB_DSIHD board from BoundaryDevices. Update in v2 - Use standard data-lanes instead of a custom prop; - Use hdmi-connector node. Update in v3 - Fix indentation; - Implement missing bridge functions; - Add some comments. Update in v4 - Fix bridge ops; - Fix i2c error detection. Update in v5 - Fix lt8912 name (lt8912b instead of lt8912); - Implement HPD via a workaround. In fact I don't have the datasheet of this component yet so I can't say if the configuration of the registers is correct or if I have an HW issue on my board. So, I choose to implement a fake version of HPD using a workqueue and polling the status regularly. Update in v6 - Fix a warning found by "kernel test robot" Update in v7 - Fix HPD logic (via an HW emulation); - HPD from chip is still not working. Thanks, Adrien Grassein (2): dt-bindings: display: bridge: Add documentation for LT8912B drm/bridge: Introduce LT8912B DSI to HDMI bridge .../display/bridge/lontium,lt8912b.yaml | 102 +++ MAINTAINERS | 6 + drivers/gpu/drm/bridge/Kconfig| 14 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/lontium-lt8912b.c | 836 ++ 5 files changed, 959 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912b.c -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Linux-stm32] [PATCH] drm/stm: ltdc: Use simple encoder
Applied on drm-misc-next.
Many thanks Jagan for your patch and many thanks Thomas & Yannick for your
reviews & tests.
Philippe :-)
De : Linux-stm32 de la part
de Yannick FERTRE - foss
Envoyé : jeudi 4 mars 2021 09:49
À : Thomas Zimmermann; Jagan Teki; Yannick FERTRE; Philippe CORNU; Benjamin
Gaignard; Vincent ABRIOU
Cc : dri-devel@lists.freedesktop.org; linux-amar...@amarulasolutions.com;
linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-st...@st-md-mailman.stormreply.com
Objet : Re: [Linux-stm32] [PATCH] drm/stm: ltdc: Use simple encoder
Hi Thomas,
I wait a few days before merging it.
Thank you for your help.
Best regards
Yannick
On 3/4/21 9:21 AM, Thomas Zimmermann wrote:
> Hi,
>
> shall I merge this patch?
>
> Am 02.03.21 um 18:57 schrieb Jagan Teki:
>> STM ltdc driver uses an empty implementation for its encoder.
>> Replace the code with the generic simple encoder.
>>
>> Signed-off-by: Jagan Teki
>> ---
>> drivers/gpu/drm/stm/ltdc.c | 12 ++--
>> 1 file changed, 2 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 7812094f93d6..aeeb43524ca0 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -31,6 +31,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> @@ -1020,14 +1021,6 @@ static int ltdc_crtc_init(struct drm_device
>> *ddev, struct drm_crtc *crtc)
>> return ret;
>> }
>> -/*
>> - * DRM_ENCODER
>> - */
>> -
>> -static const struct drm_encoder_funcs ltdc_encoder_funcs = {
>> -.destroy = drm_encoder_cleanup,
>> -};
>> -
>> static void ltdc_encoder_disable(struct drm_encoder *encoder)
>> {
>> struct drm_device *ddev = encoder->dev;
>> @@ -1088,8 +1081,7 @@ static int ltdc_encoder_init(struct drm_device
>> *ddev, struct drm_bridge *bridge)
>> encoder->possible_crtcs = CRTC_MASK;
>> encoder->possible_clones = 0;/* No cloning support */
>> -drm_encoder_init(ddev, encoder, _encoder_funcs,
>> - DRM_MODE_ENCODER_DPI, NULL);
>> +drm_simple_encoder_init(ddev, encoder, DRM_MODE_ENCODER_DPI);
>> drm_encoder_helper_add(encoder, _encoder_helper_funcs);
>>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
Linux-stm32 mailing list
linux-st...@st-md-mailman.stormreply.com
https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/14] drm/bridge: imx: Add LDB driver helper support
Hi Robert,
On Thu, 2021-03-04 at 11:27 +0800, Liu Ying wrote:
> Hi Robert,
>
> On Wed, 2021-03-03 at 16:34 +0100, Robert Foss wrote:
> > On Wed, 3 Mar 2021 at 08:23, Liu Ying wrote:
> > > Hi Robert,
> > >
> > > On Tue, 2021-03-02 at 15:22 +0100, Robert Foss wrote:
> > > > Hey Liu,
> > > >
> > > > Thanks for submitting this patch.
> > >
> > > Thanks for reviewing this patch.
> > >
> > > > On Thu, 18 Feb 2021 at 04:59, Liu Ying wrote:
> > > > > This patch adds a helper to support LDB drm bridge drivers for
> > > > > i.MX SoCs. Helper functions exported from this driver should
> > > > > implement common logics for all LDB modules embedded in i.MX SoCs.
> > > > >
> > > > > Signed-off-by: Liu Ying
> > > > > ---
> > > > > v3->v4:
> > > > > * No change.
> > > > >
> > > > > v2->v3:
> > > > > * Call syscon_node_to_regmap() to get regmap instead of
> > > > > syscon_regmap_lookup_by_phandle().
> > > > >
> > > > > v1->v2:
> > > > > * No change.
> > > > >
> > > > > drivers/gpu/drm/bridge/imx/Kconfig | 8 +
> > > > > drivers/gpu/drm/bridge/imx/Makefile | 1 +
> > > > > drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 248
> > > > >
> > > > > include/drm/bridge/imx_ldb_helper.h | 98 +++
> > > > > 4 files changed, 355 insertions(+)
> > > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> > > > > create mode 100644 include/drm/bridge/imx_ldb_helper.h
> > > > >
> > > > > diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> > > > > b/drivers/gpu/drm/bridge/imx/Kconfig
> > > > > index 1ea1ce7..23e24fd 100644
> > > > > --- a/drivers/gpu/drm/bridge/imx/Kconfig
> > > > > +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> > > > > @@ -1,3 +1,11 @@
> > > > > +config DRM_IMX_LVDS_BRIDGE_HELPER
> > > > > + tristate "Freescale i.MX LVDS display bridge helper"
> > > > > + depends on OF
> > > > > + select DRM_PANEL_BRIDGE
> > > > > + help
> > > > > + Helper to support Freescale i.MX LVDS Display Bridge(LDB).
> > > > > + This bridge is embedded in a SoC.
> > > > > +
> > > > > config DRM_IMX8QXP_PIXEL_COMBINER
> > > > > tristate "Freescale i.MX8QM/QXP pixel combiner"
> > > > > depends on OF
> > > > > diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> > > > > b/drivers/gpu/drm/bridge/imx/Makefile
> > > > > index e74dd64..902b703 100644
> > > > > --- a/drivers/gpu/drm/bridge/imx/Makefile
> > > > > +++ b/drivers/gpu/drm/bridge/imx/Makefile
> > > > > @@ -1,3 +1,4 @@
> > > > > +obj-$(CONFIG_DRM_IMX_LVDS_BRIDGE_HELPER) += imx-ldb-helper.o
> > > > > obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> > > > > obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> > > > > obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> > > > > diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> > > > > b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> > > > > new file mode 100644
> > > > > index ..94d7f9e
> > > > > --- /dev/null
> > > > > +++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> > > > > @@ -0,0 +1,248 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > +/*
> > > > > + * Copyright (C) 2012 Sascha Hauer, Pengutronix
> > > > > + * Copyright 2019,2020 NXP
> > > > > + */
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
> > > > > +{
> > > > > + return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(ldb_channel_is_single_link);
> > > > > +
> > > > > +bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
> > > > > +{
> > > > > + return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS
> > > > > ||
> > > > > + ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(ldb_channel_is_split_link);
> > > > > +
> > > > > +int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
> > > > > + struct drm_bridge_state
> > > > > *bridge_state,
> > > > > + struct drm_crtc_state *crtc_state,
> > > > > + struct drm_connector_state
> > > > > *conn_state)
> > > > > +{
> > > > > + struct ldb_channel *ldb_ch = bridge->driver_private;
> > > > > +
> > > > > + ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
> > > > > + ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(ldb_bridge_atomic_check_helper);
> > > > > +
> > > > > +void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
> > > > > + const struct drm_display_mode *mode,
> > > > > + const
Re: [PATCH v4 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding
Hi Rob,
On Fri, 2021-03-05 at 16:42 -0600, Rob Herring wrote:
> On Thu, Feb 18, 2021 at 11:41:49AM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).
> >
> > Signed-off-by: Liu Ying
> > ---
> > v3->v4:
> > * Add 'fsl,sc-resource' property. (Rob)
> >
> > v2->v3:
> > * Drop 'fsl,syscon' property. (Rob)
> > * Mention the CSR module controls PXL2DPI.
> >
> > v1->v2:
> > * Use graph schema. (Laurent)
> >
> > .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 108
> > +
> > 1 file changed, 108 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> > new file mode 100644
> > index ..e4e77fa
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> > @@ -0,0 +1,108 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbridge%2Ffsl%2Cimx8qxp-pxl2dpi.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7Ca37ec67ba3274bcea5c408d8e027f69b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637505809544037562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=UN2IQps7q5vK6uNG8fQTn1Klgn0cVyuYnUeqxrjCWHo%3Dreserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7Ca37ec67ba3274bcea5c408d8e027f69b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637505809544037562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=cvJVL3Fp1hwbjj1jO1YAozKdZATt5DJ78E7vGT%2F25Oc%3Dreserved=0
> > +
> > +title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
> > +
> > +maintainers:
> > + - Liu Ying
> > +
> > +description: |
> > + The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
> > + interfaces the pixel link 36-bit data output and the DSI controller’s
> > + MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
> > + used in LVDS mode, to remap the pixel color codings between those
> > modules.
> > + This module is purely combinatorial.
> > +
> > + The i.MX8qxp PXL2DPI is controlled by Control and Status Registers(CSR)
> > module.
> > + The CSR module, as a system controller, contains the PXL2DPI's
> > configuration
> > + register.
>
> So this node should be a child of the CSR. Ideally, this schema is also
> referenced from the CSR's schema (and if that doesn't exist, it should
> be there first).
I can add a patch to introduce a schema for the CSR in this series,
just prior to this patch. Do you think if that will be fine?
Thanks,
Liu Ying
>
> > +
> > +properties:
> > + compatible:
> > +const: fsl,imx8qxp-pxl2dpi
> > +
> > + fsl,sc-resource:
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +description: The SCU resource ID associated with this PXL2DPI instance.
> > +
> > + power-domains:
> > +maxItems: 1
> > +
> > + fsl,companion-pxl2dpi:
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +description: |
> > + A phandle which points to companion PXL2DPI which is used by
> > downstream
> > + LVDS Display Bridge(LDB) in split mode.
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: The PXL2DPI input port node from pixel link.
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: The PXL2DPI output port node to downstream bridge.
> > +
> > +required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - fsl,sc-resource
> > + - power-domains
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +pxl2dpi {
> > +compatible = "fsl,imx8qxp-pxl2dpi";
> > +fsl,sc-resource = ;
> > +power-domains = < IMX_SC_R_MIPI_0>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <0>;
> > +
> > +mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
> > +reg = <0>;
> > +remote-endpoint =
> > <_pixel_link0_mipi_lvds_0_pxl2dpi>;
> > +};
> > +
> > +mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
> > + reg = <1>;
> > +
Re: [PATCH v5 3/4] PM / devfreq: panfrost: Use devfreq cooling device registration
On 08/03/2021 09:16, Daniel Lezcano wrote:
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..4d96edf1bc54 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -3,7 +3,6 @@
#include
#include
-#include
#include
#include
@@ -80,6 +79,7 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = panfrost_devfreq_target,
.get_dev_status = panfrost_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
int panfrost_devfreq_init(struct panfrost_device *pfdev)
@@ -90,7 +90,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct opp_table *opp_table;
- struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
@@ -139,12 +138,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdevfreq->devfreq = devfreq;
- cooling = devfreq_cooling_em_register(devfreq, NULL);
- if (IS_ERR(cooling))
- DRM_DEV_INFO(dev, "Failed to register cooling device\n");
- else
- pfdevfreq->cooling = cooling;
-
return 0;
err_fini:
@@ -156,11 +149,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
- if (pfdevfreq->cooling) {
- devfreq_cooling_unregister(pfdevfreq->cooling);
- pfdevfreq->cooling = NULL;
- }
-
if (pfdevfreq->opp_of_table_added) {
dev_pm_opp_of_remove_table(>pdev->dev);
pfdevfreq->opp_of_table_added = false;
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..470f5c974703 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -9,14 +9,11 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
-
struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
bool opp_of_table_added;
ktime_t busy_time;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: i915: fix error return code of igt_buddy_alloc_smoke()
On 2021/3/8 17:18, Chris Wilson wrote: Quoting Jia-Ju Bai (2021-03-08 08:59:52) When i915_random_order() returns NULL to order, no error return code of igt_buddy_alloc_smoke() is assigned. To fix this bug, err is assigned with -EINVAL in this case. It would not be EINVAL since that is used for a reference failure, but in this case the idea was to return 0 as no testing was done and the ENOMEM was raised before testing began i.e. not an internal and unexpected driver allocation failure. -Chris Okay, thanks for your reply :) Best wishes, Jia-Ju Bai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Fri, 05 Mar 2021, Roland Scheidegger wrote: > The vmwgfx ones look all good to me, so for > 23-53: Reviewed-by: Roland Scheidegger > That said, they were already signed off by Zack, so not sure what > happened here. Yes, they were accepted at one point, then dropped without a reason. Since I rebased onto the latest -next, I had to pluck them back out of a previous one. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: i915: fix error return code of igt_buddy_alloc_smoke()
Quoting Jia-Ju Bai (2021-03-08 08:59:52) > When i915_random_order() returns NULL to order, no error return code of > igt_buddy_alloc_smoke() is assigned. > To fix this bug, err is assigned with -EINVAL in this case. It would not be EINVAL since that is used for a reference failure, but in this case the idea was to return 0 as no testing was done and the ENOMEM was raised before testing began i.e. not an internal and unexpected driver allocation failure. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/4] PM / devfreq: lima: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14 +-
drivers/gpu/drm/lima/lima_devfreq.h | 2 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..86aea1bdc4f4 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -7,7 +7,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -84,17 +83,13 @@ static struct devfreq_dev_profile lima_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = lima_devfreq_target,
.get_dev_status = lima_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
void lima_devfreq_fini(struct lima_device *ldev)
{
struct lima_devfreq *devfreq = >devfreq;
- if (devfreq->cooling) {
- devfreq_cooling_unregister(devfreq->cooling);
- devfreq->cooling = NULL;
- }
-
if (devfreq->devfreq) {
devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
@@ -110,7 +105,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
int lima_devfreq_init(struct lima_device *ldev)
{
- struct thermal_cooling_device *cooling;
struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
@@ -173,12 +167,6 @@ int lima_devfreq_init(struct lima_device *ldev)
ldevfreq->devfreq = devfreq;
- cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
- if (IS_ERR(cooling))
- dev_info(dev, "Failed to register cooling device\n");
- else
- ldevfreq->cooling = cooling;
-
return 0;
err_fini:
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..c43a2069e5d3 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -9,7 +9,6 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
struct lima_device;
@@ -17,7 +16,6 @@ struct lima_devfreq {
struct devfreq *devfreq;
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
ktime_t busy_time;
ktime_t idle_time;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/4] PM / devfreq: panfrost: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..4d96edf1bc54 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -3,7 +3,6 @@
#include
#include
-#include
#include
#include
@@ -80,6 +79,7 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = panfrost_devfreq_target,
.get_dev_status = panfrost_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
int panfrost_devfreq_init(struct panfrost_device *pfdev)
@@ -90,7 +90,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct opp_table *opp_table;
- struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
@@ -139,12 +138,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdevfreq->devfreq = devfreq;
- cooling = devfreq_cooling_em_register(devfreq, NULL);
- if (IS_ERR(cooling))
- DRM_DEV_INFO(dev, "Failed to register cooling device\n");
- else
- pfdevfreq->cooling = cooling;
-
return 0;
err_fini:
@@ -156,11 +149,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
- if (pfdevfreq->cooling) {
- devfreq_cooling_unregister(pfdevfreq->cooling);
- pfdevfreq->cooling = NULL;
- }
-
if (pfdevfreq->opp_of_table_added) {
dev_pm_opp_of_remove_table(>pdev->dev);
pfdevfreq->opp_of_table_added = false;
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..470f5c974703 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -9,14 +9,11 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
-
struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
bool opp_of_table_added;
ktime_t busy_time;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/4] PM / devfreq: msm: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12 +---
drivers/gpu/drm/msm/msm_gpu.h | 2 --
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ab7c167b0623..eade94271a60 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
@@ -82,6 +81,7 @@ static struct devfreq_dev_profile msm_devfreq_profile = {
.target = msm_devfreq_target,
.get_dev_status = msm_devfreq_get_dev_status,
.get_cur_freq = msm_devfreq_get_cur_freq,
+ .is_cooling_device = true,
};
static void msm_devfreq_init(struct msm_gpu *gpu)
@@ -112,14 +112,6 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
}
devfreq_suspend_device(gpu->devfreq.devfreq);
-
- gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
- gpu->devfreq.devfreq);
- if (IS_ERR(gpu->cooling)) {
- DRM_DEV_ERROR(>pdev->dev,
- "Couldn't register GPU cooling device\n");
- gpu->cooling = NULL;
- }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -1056,6 +1048,4 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
if (gpu->worker) {
kthread_destroy_worker(gpu->worker);
}
-
- devfreq_cooling_unregister(gpu->cooling);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index d7cd02cd2109..93419368bac8 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -155,8 +155,6 @@ struct msm_gpu {
struct msm_gpu_state *crashstate;
/* True if the hardware supports expanded apriv (a650 and newer) */
bool hw_apriv;
-
- struct thermal_cooling_device *cooling;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: i915: fix error return code of igt_threaded_blt()
Quoting Jia-Ju Bai (2021-03-08 09:07:22) > When kcalloc() returns NULL to tsk or thread, no error code of > igt_threaded_blt() is returned. > To fix this bug, -ENOMEM is returned as error code. Because we decided to skip the test if it could not be run due to insufficient memory, as opposed to an internal allocation failure from the driver. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/stm: dsi: Use dev_ based logging
Tested-by: Yannick Fertre
On 2/22/21 10:23 AM, Raphael GALLAIS-POU - foss wrote:
From: Yannick Fertre
Standardize on the dev_ based logging.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 49 ++-
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 8399d337589d..a7226bb3d0e8 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -76,6 +76,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
@@ -110,7 +111,8 @@ static inline void dsi_update_bits(struct dw_mipi_dsi_stm
*dsi, u32 reg,
dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
}
-static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
+static enum dsi_color dsi_color_from_mipi(struct dw_mipi_dsi_stm *dsi,
+ enum mipi_dsi_pixel_format fmt)
{
switch (fmt) {
case MIPI_DSI_FMT_RGB888:
@@ -122,7 +124,7 @@ static enum dsi_color dsi_color_from_mipi(enum
mipi_dsi_pixel_format fmt)
case MIPI_DSI_FMT_RGB565:
return DSI_RGB565_CONF1;
default:
- DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
+ dev_dbg(dsi->dev, "MIPI color invalid, so we use rgb888\n");
}
return DSI_RGB888;
}
@@ -205,14 +207,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
@@ -221,7 +223,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Enable the DSI wrapper */
dsi_set(dsi, DSI_WCR, WCR_DSIEN);
@@ -231,7 +233,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Disable the DSI wrapper */
dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
@@ -267,11 +269,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
- DRM_WARN("Warning max phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning max phy mbps is used\n");
}
if (pll_out_khz < dsi->lane_min_kbps) {
pll_out_khz = dsi->lane_min_kbps;
- DRM_WARN("Warning min phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning min phy mbps is used\n");
}
/* Compute best pll parameters */
@@ -281,7 +283,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
, , );
if (ret)
- DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+ dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
params\n");
/* Get the adjusted pll out value */
pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
@@ -299,13 +301,12 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
/* Select the color coding */
dsi_update_bits(dsi, DSI_WCFGR, WCFGR_COLMUX,
- dsi_color_from_mipi(format) << 1);
+ dsi_color_from_mipi(dsi, format) << 1);
*lane_mbps = pll_out_khz / 1000;
- DRM_DEBUG_DRIVER("pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
-pll_in_khz, pll_out_khz, *lane_mbps);
-
+ dev_dbg(dsi->dev, "pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
+ pll_in_khz, pll_out_khz, *lane_mbps);
return 0;
}
@@ -352,11 +353,13 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
if (!dsi)
return -ENOMEM;
+ dsi->dev = dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dsi->base = devm_ioremap_resource(dev, res);
Re: [PATCH 1/2] drm/stm: dsi: Avoid printing errors for -EPROBE_DEFER
Tested-by: Yannick Fertre
On 2/22/21 10:22 AM, Raphael GALLAIS-POU - foss wrote:
From: Yannick Fertre
Don't print error when probe deferred error is returned.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 2e1f2664495d..8399d337589d 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -363,8 +363,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
dsi->vdd_supply = devm_regulator_get(dev, "phy-dsi");
if (IS_ERR(dsi->vdd_supply)) {
ret = PTR_ERR(dsi->vdd_supply);
- if (ret != -EPROBE_DEFER)
- DRM_ERROR("Failed to request regulator: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to request regulator\n");
return ret;
}
@@ -377,9 +376,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
dsi->pllref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(dsi->pllref_clk)) {
ret = PTR_ERR(dsi->pllref_clk);
- if (ret != -EPROBE_DEFER)
- DRM_ERROR("Unable to get pll reference clock: %d\n",
- ret);
+ dev_err_probe(dev, ret, "Unable to get pll reference clock\n");
goto err_clk_get;
}
@@ -419,7 +416,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
dsi->dsi = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
if (IS_ERR(dsi->dsi)) {
ret = PTR_ERR(dsi->dsi);
- DRM_ERROR("Failed to initialize mipi dsi host: %d\n", ret);
+ dev_err_probe(dev, ret, "Failed to initialize mipi dsi host\n");
goto err_dsi_probe;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: i915: fix error return code of igt_threaded_blt()
When kcalloc() returns NULL to tsk or thread, no error code of
igt_threaded_blt() is returned.
To fix this bug, -ENOMEM is returned as error code.
Fixes: 0e99f939f08f ("drm/i915/selftests/blt: add some kthreads into the mix")
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
index 23b6e11bbc3e..b54ba8a1fcec 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
@@ -471,11 +471,13 @@ static int igt_threaded_blt(struct intel_engine_cs
*engine,
tsk = kcalloc(n_cpus, sizeof(struct task_struct *), GFP_KERNEL);
if (!tsk)
- return 0;
+ return -ENOMEM;
thread = kcalloc(n_cpus, sizeof(struct igt_thread_arg), GFP_KERNEL);
- if (!thread)
+ if (!thread) {
+ err = -ENOMEM;
goto out_tsk;
+ }
thread[0].file = mock_file(engine->i915);
if (IS_ERR(thread[0].file)) {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
https://bugzilla.kernel.org/show_bug.cgi?id=212107 Martin (martin...@gmx.com) changed: What|Removed |Added Severity|normal |blocking -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
https://bugzilla.kernel.org/show_bug.cgi?id=212107 --- Comment #3 from Martin (martin...@gmx.com) --- (In reply to Dieter Nützel from comment #2) > It could be the ZeroCore thing, which has finally landed with 5.11. > Please verify, that your gfx fans stopped with 5.11 and running with all > kernels below 5.11. Bloody hell, you're right. On 5.11.4 the fan on gpu stops completely, even though sensors claim it's spinning. I suppose I'm lucky I didn't fry my gpu ._. How is that even possible? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: meson_drv add shutdown function
On 02/03/2021 05:22, Artem Lapkin wrote:
> Problem: random stucks on reboot stage about 1/20 stuck/reboots
> // debug kernel log
> [4.496660] reboot: kernel restart prepare CMD:(null)
> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown begin
> [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown domain 0:VPU...
> ...STUCK...
>
> Solution: add shutdown function to meson_drm driver
> // debug kernel log
> [5.231896] reboot: kernel restart prepare CMD:(null)
> [5.246135] [drm:meson_drv_shutdown]
> ...
> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown begin
> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown domain 0:VPU...
> [5.338331] reboot: Restarting system
> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
> bl31 reboot reason: 0xd
> bl31 reboot reason: 0x0
> system cmd 1.
> ...REBOOT...
>
> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
> and Odroid boards, WeTek Play2 (GXBB)
>
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
> Tested-by: Christian Hewitt
> Signed-off-by: Artem Lapkin
>
> ---
> drivers/gpu/drm/meson/meson_drv.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 42c5d3246..693bb1293 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device
> *pdev,
> return count;
> }
>
> +static void meson_drv_shutdown(struct platform_device *pdev)
> +{
> + struct meson_drm *priv = dev_get_drvdata(>dev);
> + struct drm_device *drm = priv->drm;
> +
> + DRM_DEBUG_DRIVER("\n");
> + drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> +}
> +
> static int meson_drv_probe(struct platform_device *pdev)
> {
> struct component_match *match = NULL;
> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>
> static struct platform_driver meson_drm_platform_driver = {
> .probe = meson_drv_probe,
> + .shutdown = meson_drv_shutdown,
> .driver = {
> .name = "meson-drm",
> .of_match_table = dt_match,
>
Acked-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: i915: fix error return code of igt_buddy_alloc_smoke()
When i915_random_order() returns NULL to order, no error return code of
igt_buddy_alloc_smoke() is assigned.
To fix this bug, err is assigned with -EINVAL in this case.
Fixes: 1fe3818d17c9 ("drm/i915/selftests: try to rein in alloc_smoke")
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/i915/selftests/i915_buddy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_buddy.c
b/drivers/gpu/drm/i915/selftests/i915_buddy.c
index 632b912b0bc9..cf9b551b77e1 100644
--- a/drivers/gpu/drm/i915/selftests/i915_buddy.c
+++ b/drivers/gpu/drm/i915/selftests/i915_buddy.c
@@ -318,8 +318,10 @@ static int igt_buddy_alloc_smoke(void *arg)
}
order = i915_random_order(mm.max_order + 1, );
- if (!order)
+ if (!order) {
+ err = -EINVAL;
goto out_fini;
+ }
for (i = 0; i <= mm.max_order; ++i) {
struct i915_buddy_block *block;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add option to mmap GEM buffers cached
Hi Paul, having individual functions for each mode only makes sense if the decision is at compile time. But in patch 5, you're working around your earlier design by introducing in-driver helpers that select the correct CMA function. In SHMEM helpers we have the flag map_wc in the GEM structure that selects the pages caching mode (wc vs uncached). I think CMA should use this design as well. Have a map_noncoherent flag in the CMA GEM object and set it from the driver's implementation of gem_create_object. And in the long run, we could try to consolidate all drivers/helpers mapping flags in struct drm_gem_object. Best regards Thomas Am 07.03.21 um 21:28 schrieb Paul Cercueil: Rework of my previous patchset which added support for GEM buffers backed by non-coherent memory to the ingenic-drm driver. Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on some Ingenic SoCs, where even simple blits (e.g. memcpy) are about three times faster using this method. For the record, the previous patchset was accepted for 5.10 then had to be reverted, as it conflicted with some changes made to the DMA API. This new patchset is pretty different as it adds the functionality to the DRM core. The first three patches add variants to existing functions but with the "non-coherent memory" twist, exported as GPL symbols. The fourth patch adds a function to be used with the damage helpers. Finally, the last patch adds support for non-coherent GEM buffers to the ingenic-drm driver. The functionality is enabled through a module parameter, and is disabled by default. Cheers, -Paul Paul Cercueil (5): drm: Add and export function drm_gem_cma_create_noncoherent drm: Add and export function drm_gem_cma_dumb_create_noncoherent drm: Add and export function drm_gem_cma_mmap_noncoherent drm: Add and export function drm_gem_cma_sync_data drm/ingenic: Add option to alloc cached GEM buffers drivers/gpu/drm/drm_gem_cma_helper.c | 223 +++--- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 49 - drivers/gpu/drm/ingenic/ingenic-drm.h | 4 + drivers/gpu/drm/ingenic/ingenic-ipu.c | 14 +- include/drm/drm_gem_cma_helper.h | 13 ++ 5 files changed, 273 insertions(+), 30 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/nouveau/device: use snprintf() to replace strncpy() to avoid NUL-terminated string loss
Following warning is found when using W=1 to build kernel: In function ‘nvkm_udevice_info’, inlined from ‘nvkm_udevice_mthd’ at drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:195:10: drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:164:2: warning: ‘strncpy’ specified bound 16 equals destination size [-Wstringop-truncation] 164 | strncpy(args->v0.chip, device->chip->name, sizeof(args->v0.chip)); drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:165:2: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation] 165 | strncpy(args->v0.name, device->name, sizeof(args->v0.name)); The reason of this warning is strncpy() does not guarantee that the destination buffer will be NUL terminated. If the length of source string is bigger than number we set by third input parameter, only a part of characters is copied to the destination, and no NUL-terminated string is automatically added. There are some potential risks. So use snprintf() to replace strncpy(). Signed-off-by: Luo Jiaxing --- drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c index fea9d8f..4bf65bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c @@ -161,8 +161,8 @@ nvkm_udevice_info(struct nvkm_udevice *udev, void *data, u32 size) if (imem && args->v0.ram_size > 0) args->v0.ram_user = args->v0.ram_user - imem->reserved; - strncpy(args->v0.chip, device->chip->name, sizeof(args->v0.chip)); - strncpy(args->v0.name, device->name, sizeof(args->v0.name)); + snprintf(args->v0.chip, sizeof(args->v0.chip), "%s", device->chip->name); + snprintf(args->v0.name, sizeof(args->v0.name), "%s", device->name); return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/uapi: document kernel capabilities
On Sat, 06 Mar 2021 10:56:49 + Simon Ser wrote: > On Friday, March 5th, 2021 at 9:28 AM, Pekka Paalanen > wrote: > > > > +/** > > > + * DRM_CAP_DUMB_PREFERRED_DEPTH > > > + * > > > + * The preferred depth (in bits) for dumb buffers. > > > > this is literally depth, not bits per pixel, right? > > "Depth" is pretty ambiguous [1]. Maybe we should be more explicit here and say > that it's the number of bits used to indicate the color of a single pixel? And > maybe add a note that it's different from bits per pixel? Yes, indeed. I was already assuming the meaning of "depth" in drmModeAddFB(). > [1]: https://en.wikipedia.org/wiki/Color_depth > > > > +/** > > > + * DRM_CAP_PRIME > > > + * > > > + * Bitfield of supported PRIME sharing capabilities. See > > > _PRIME_CAP_IMPORT > > > + * and _PRIME_CAP_EXPORT. > > > + */ > > > #define DRM_CAP_PRIME0x5 > > > +/** > > > + * DRM_PRIME_CAP_IMPORT > > > + * > > > + * If this bit is set in _CAP_PRIME, the driver supports importing > > > PRIME > > > + * buffers. > > > > What are PRIME buffers? > > Will add something like: > > PRIME buffers are exposed as dma-buf file descriptors. See > Documentation/gpu/drm-mm.rst, section "PRIME Buffer Sharing". Sounds good. > > > + */ > > > #define DRM_PRIME_CAP_IMPORT0x1 > > > +/** > > > + * DRM_PRIME_CAP_EXPORT > > > + * > > > + * If this bit is set in _CAP_PRIME, the driver supports exporting > > > PRIME > > > + * buffers. > > > > What's the export API? HandleToFD()? > > Yes. Will add a note about it. Same for import. Cool. > > > +/** > > > + * DRM_CAP_CRTC_IN_VBLANK_EVENT > > > + * > > > + * If set to 1, the kernel supports reporting the CRTC ID in > > > + * _event_vblank.crtc_id. > > > > Does this not apply also to the pageflip / atomic completion event? > > Both DRM_EVENT_VBLANK and DRM_EVENT_FLIP_COMPLETE use the struct > drm_event_vblank, so yes. I'll mention these two events explicitly. They do? Seems like I have been spoiled by the libdrm API that uses drmEventContext with different callbacks for these things. Thanks, pq pgpJwPyFAG3vE.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 Andreas (icedragon...@web.de) changed: What|Removed |Added Kernel Version|5.11.3 |5.11.4 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] docs: gpu: fix typo
R-b me. Pushed, thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] docs: gpu: fix typo
Signed-off-by: Jianhui Zhao --- Documentation/gpu/todo.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 40ccac61137e..b7f1acb355f5 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -700,7 +700,7 @@ Outside DRM Convert fbdev drivers to DRM -There are plenty of fbdev drivers for older hardware. Some hwardware has +There are plenty of fbdev drivers for older hardware. Some hardware has become obsolete, but some still provides good(-enough) framebuffers. The drivers that are still useful should be converted to DRM and afterwards removed from fbdev. -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/ingenic: Add option to alloc cached GEM buffers
On Sun, 7 Mar 2021 20:28:35 + Paul Cercueil wrote:
> With the module parameter ingenic-drm.cached_gem_buffers, it is possible
> to specify that we want GEM buffers backed by non-coherent memory.
>
> This dramatically speeds up software rendering on Ingenic SoCs, even for
> tasks where write-combine memory should in theory be faster (e.g. simple
> blits).
Wondering if it is due to the tricks at [1].
If so, is dma_alloc_noncoherent() necessary in this patchset?
Christoph can you give us a concise lesson on noncoherency covering at least
noncoherent device, noncoherent memory(used in this work), no coherent
caching(in [1]), their links to speedup, and the thumb rule to handle
noncoherency in workdays. It feels toe curling every time I see noncoherence
going downtown with speedup hand in hand.
[1] Subject: [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos API
https://lore.kernel.org/lkml/20210301085236.947011-7-...@lst.de/#t
>
> Leave it disabled by default, since it is specific to one use-case
> (software rendering).
>
> v2: Rework code to work with new DRM APIs regarding plane states
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 49 ++-
> drivers/gpu/drm/ingenic/ingenic-drm.h | 4 ++
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 14 ++-
> 3 files changed, 63 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index d60e1eefc9d1..ba1ac0fcda74 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -23,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -99,6 +101,11 @@ struct ingenic_drm {
> struct notifier_block clock_nb;
> };
>
> +static bool ingenic_drm_cached_gem_buf;
> +module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool,
> 0400);
> +MODULE_PARM_DESC(cached_gem_buffers,
> + "Enable fully cached GEM buffers [default=false]");
> +
> static bool ingenic_drm_writeable_reg(struct device *dev, unsigned int reg)
> {
> switch (reg) {
> @@ -410,6 +417,8 @@ static int ingenic_drm_plane_atomic_check(struct
> drm_plane *plane,
>old_plane_state->fb->format->format !=
> new_plane_state->fb->format->format))
> crtc_state->mode_changed = true;
>
> + drm_atomic_helper_check_plane_damage(state, new_plane_state);
> +
> return 0;
> }
>
> @@ -541,10 +550,20 @@ static void ingenic_drm_update_palette(struct
> ingenic_drm *priv,
> }
> }
>
> +void ingenic_drm_sync_data(struct device *dev,
> +struct drm_plane_state *old_state,
> +struct drm_plane_state *state)
> +{
> + if (ingenic_drm_cached_gem_buf)
> + drm_gem_cma_sync_data(dev, old_state, state);
> +}
> +
> static void ingenic_drm_plane_atomic_update(struct drm_plane *plane,
> struct drm_atomic_state *state)
> {
> struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
> + struct drm_plane_state *oldstate = drm_atomic_get_old_plane_state(state,
> +
> plane);
> struct drm_plane_state *newstate = drm_atomic_get_new_plane_state(state,
>
> plane);
> struct drm_crtc_state *crtc_state;
> @@ -554,6 +573,8 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> u32 fourcc;
>
> if (newstate && newstate->fb) {
> + ingenic_drm_sync_data(priv->dev, oldstate, newstate);
> +
> crtc_state = newstate->crtc->state;
>
> addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
> @@ -743,6 +764,26 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
> *crtc)
> regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
> }
>
> +static struct drm_framebuffer *
> +ingenic_drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + if (ingenic_drm_cached_gem_buf)
> + return drm_gem_fb_create_with_dirty(dev, file, mode_cmd);
> +
> + return drm_gem_fb_create(dev, file, mode_cmd);
> +}
> +
> +static int ingenic_drm_gem_cma_dumb_create(struct drm_file *file_priv,
> +struct drm_device *drm,
> +struct drm_mode_create_dumb *args)
> +{
> + if (ingenic_drm_cached_gem_buf)
> + return drm_gem_cma_dumb_create_noncoherent(file_priv, drm,
> args);
> +
> + return drm_gem_cma_dumb_create(file_priv, drm, args);
> +}
> +
>
