Re: [PATCH 3/7] drm/msm/a6xx: Add support for A640 speed binning
On 12/13/2022 5:54 AM, Konrad Dybcio wrote:
> Add support for matching QFPROM fuse values to get the correct speed bin
> on A640 (SM8150) GPUs.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 36c8fb699b56..2c1630f0c04c 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1877,6 +1877,16 @@ static u32 a619_get_speed_bin(u32 fuse)
> return UINT_MAX;
> }
>
> +static u32 a640_get_speed_bin(u32 fuse)
> +{
> + if (fuse == 0)
> + return 0;
> + else if (fuse == 1)
> + return 1;
> +
> + return UINT_MAX;
> +}
> +
> static u32 adreno_7c3_get_speed_bin(u32 fuse)
> {
> if (fuse == 0)
> @@ -1902,6 +1912,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct
> adreno_rev rev, u32 fuse)
> if (adreno_cmp_rev(ADRENO_REV(6, 3, 5, ANY_ID), rev))
> val = adreno_7c3_get_speed_bin(fuse);
>
> + if (adreno_cmp_rev(ADRENO_REV(6, 4, 0, ANY_ID), rev))
> + val = a640_get_speed_bin(fuse);
> +
> if (val == UINT_MAX) {
> DRM_DEV_ERROR(dev,
> "missing support for speed-bin: %u. Some OPPs may not
> be supported by hardware\n",
Reviewed-by: Akhil P Oommen
-Akhil.
[PATCH v2] drm/msm/hdmi: Fix the error handling path of msm_hdmi_dev_probe()
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi: move msm_hdmi_get_phy() to
msm_hdmi_dev_probe()")
Signed-off-by: Christophe JAILLET
Reviewed-by: Abhinav Kumar
---
Change in v2:
- Fix a typo in the prefix of the subject line[Abhinav Kumar]
- Add R-b tag[Abhinav Kumar]
v1:
https://lore.kernel.org/all/b3d9dac978f1e2e42a40ec61f58aa98c44c85dfd.1670741386.git.christophe.jail...@wanadoo.fr/
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 4d3fdc806bef..97372bb241d8 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -532,11 +532,19 @@ static int msm_hdmi_dev_probe(struct platform_device
*pdev)
ret = devm_pm_runtime_enable(>dev);
if (ret)
- return ret;
+ goto err_put_phy;
platform_set_drvdata(pdev, hdmi);
- return component_add(>dev, _hdmi_ops);
+ ret = component_add(>dev, _hdmi_ops);
+ if (ret)
+ goto err_put_phy;
+
+ return 0;
+
+err_put_phy:
+ msm_hdmi_put_phy(hdmi);
+ return ret;
}
static int msm_hdmi_dev_remove(struct platform_device *pdev)
--
2.34.1
Re: [PATCH] usb: gadget: aspeed_udc: Add check for dma_alloc_coherent
On Tue, Dec 13, 2022 at 10:51:19AM +0800, Jiasheng Jiang wrote:
> Add the check for the return value of dma_alloc_coherent
> in order to avoid NULL pointer dereference.
>
> Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
> Signed-off-by: Jiasheng Jiang
> ---
> drivers/usb/gadget/udc/aspeed_udc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/gadget/udc/aspeed_udc.c
> b/drivers/usb/gadget/udc/aspeed_udc.c
> index 01968e2167f9..6cf46562bb25 100644
> --- a/drivers/usb/gadget/udc/aspeed_udc.c
> +++ b/drivers/usb/gadget/udc/aspeed_udc.c
> @@ -1516,6 +1516,8 @@ static int ast_udc_probe(struct platform_device *pdev)
> AST_UDC_EP_DMA_SIZE *
> AST_UDC_NUM_ENDPOINTS,
> >ep0_buf_dma, GFP_KERNEL);
> + if (!udc->ep0_buf)
> + return -ENOMEM;
How did you test this? I ask as it is obviously not correct. Please
always test your patches before submitting them as adding new bugs when
claiming that you are fixing a problem is not good.
And how did you find this potential problem? What tool did you use and
why did you not follow the documentation for properly describing the
tool?
thanks,
greg k-h
Re: [PATCH 00/16] Enable Colorspace connector property in amdgpu
Thanks for this, Harry! I tested your series with https://github.com/Themaister/Granite + test-hdr with my KHR_display + HDR Mesa branch and it works great. The code also looks good -- I was already fairly familiar with it when I rebased it and debugged things previously. (Hence where my random commit comes from). Once the documentation comment is fixed in "[PATCH 07/16] drm/connector: Print connector colorspace in state debugfs" this series is Reviewed-By: Joshua Ashton - Joshie ✨ On 12/12/22 18:21, Harry Wentland wrote: This patchset enables the DP and HDMI infoframe properties in amdgpu. The first two patches are not completely related to the rest. The first patch allows for HDR_OUTPUT_METADATA with EOTFs that are unknown in the kernel. The second one prints a connector's max_bpc as part of the atomic state debugfs print. The following patches rework the connector colorspace code to 1) allow for easy printing of the colorspace in the drm_atomic state debugfs, and 2) allow drivers to specify the supported colorspaces on a connector. The rest of the patches deal with the Colorspace enablement in amdgpu. Since the Colorspace property didn't have an IGT test I added one to kms_hdr. The relevant patchset can be found on the IGT mailing list or on https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/hdr-colorimetry Since I don't have a DP and HDMI analyzer I could not test this end-to-end but someone will test it in the coming days. We'll refrain from merging this until we can confirm the DP/HDMI analyzer shows the correct infoframe. Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Harry Wentland (15): drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF drm/connector: print max_requested_bpc in state debugfs drm/connector: Drop COLORIMETRY_NO_DATA drm/connector: Convert DRM_MODE_COLORIMETRY to enum drm/connector: Pull out common create_colorspace_property code drm/connector: Allow drivers to pass list of supported colorspaces drm/connector: Print connector colorspace in state debugfs drm/amd/display: Always pass connector_state to stream validation drm/amd/display: Register Colorspace property for DP and HDMI drm/amd/display: Set colorspace for HDMI infoframe drm/amd/display: Send correct DP colorspace infopacket drm/amd/display: Add support for explicit BT601_YCC drm/amd/display: Add debugfs for testing output colorspace drm/amd/display: Add default case for output_color_space switch drm/amd/display: Don't restrict bpc to 8 bpc Joshua Ashton (1): drm/amd/display: Always set crtcinfo from create_stream_for_sink .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 86 ++--- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 ++ drivers/gpu/drm/display/drm_hdmi_helper.c | 8 +- drivers/gpu/drm/drm_atomic.c | 2 + drivers/gpu/drm/drm_connector.c | 181 ++ .../gpu/drm/i915/display/intel_connector.c| 4 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- include/drm/display/drm_dp.h | 2 +- include/drm/drm_connector.h | 57 +++--- 9 files changed, 261 insertions(+), 138 deletions(-) -- 2.38.1
[PATCH v2] drm/i915/hwconfig: Remove comment block
No functional modification involved.
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning: expecting
prototype for intel_guc_hwconfig_init(). Prototype was for guc_hwconfig_init()
instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3414
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Changes in v2:
-Remove the comment block.
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 4781fccc2687..5559d39881ee 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -102,12 +102,6 @@ static bool has_table(struct drm_i915_private *i915)
return false;
}
-/**
- * intel_guc_hwconfig_init - Initialize the HWConfig
- *
- * Retrieve the HWConfig table from the GuC and save it locally.
- * It can then be queried on demand by other users later on.
- */
static int guc_hwconfig_init(struct intel_gt *gt)
{
struct intel_hwconfig *hwconfig = >info.hwconfig;
--
2.20.1.7.g153144c
[PATCH v2] net: ksz884x: Remove some unused functions
These functions are defined in the ksz884x.c file, but not called
elsewhere, so delete these unused functions.
drivers/net/ethernet/micrel/ksz884x.c:2212:20: warning: unused function
'port_cfg_force_flow_ctrl'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3418
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Changes in v2:
-Delete more unused functions.
drivers/net/ethernet/micrel/ksz884x.c | 89 ---
1 file changed, 89 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ksz884x.c
b/drivers/net/ethernet/micrel/ksz884x.c
index e6acd1e7b263..5d6ed7a63e59 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -2209,102 +2209,13 @@ static inline void port_cfg_back_pressure(struct
ksz_hw *hw, int p, int set)
KS8842_PORT_CTRL_2_OFFSET, PORT_BACK_PRESSURE, set);
}
-static inline void port_cfg_force_flow_ctrl(struct ksz_hw *hw, int p, int set)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_FORCE_FLOW_CTRL, set);
-}
-
-static inline int port_chk_back_pressure(struct ksz_hw *hw, int p)
-{
- return port_chk(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_BACK_PRESSURE);
-}
-
-static inline int port_chk_force_flow_ctrl(struct ksz_hw *hw, int p)
-{
- return port_chk(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_FORCE_FLOW_CTRL);
-}
-
/* Spanning Tree */
-static inline void port_cfg_rx(struct ksz_hw *hw, int p, int set)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_RX_ENABLE, set);
-}
-
-static inline void port_cfg_tx(struct ksz_hw *hw, int p, int set)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_TX_ENABLE, set);
-}
-
static inline void sw_cfg_fast_aging(struct ksz_hw *hw, int set)
{
sw_cfg(hw, KS8842_SWITCH_CTRL_1_OFFSET, SWITCH_FAST_AGING, set);
}
-static inline void sw_flush_dyn_mac_table(struct ksz_hw *hw)
-{
- if (!(hw->overrides & FAST_AGING)) {
- sw_cfg_fast_aging(hw, 1);
- mdelay(1);
- sw_cfg_fast_aging(hw, 0);
- }
-}
-
-/* VLAN */
-
-static inline void port_cfg_ins_tag(struct ksz_hw *hw, int p, int insert)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_1_OFFSET, PORT_INSERT_TAG, insert);
-}
-
-static inline void port_cfg_rmv_tag(struct ksz_hw *hw, int p, int remove)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_1_OFFSET, PORT_REMOVE_TAG, remove);
-}
-
-static inline int port_chk_ins_tag(struct ksz_hw *hw, int p)
-{
- return port_chk(hw, p,
- KS8842_PORT_CTRL_1_OFFSET, PORT_INSERT_TAG);
-}
-
-static inline int port_chk_rmv_tag(struct ksz_hw *hw, int p)
-{
- return port_chk(hw, p,
- KS8842_PORT_CTRL_1_OFFSET, PORT_REMOVE_TAG);
-}
-
-static inline void port_cfg_dis_non_vid(struct ksz_hw *hw, int p, int set)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_DISCARD_NON_VID, set);
-}
-
-static inline void port_cfg_in_filter(struct ksz_hw *hw, int p, int set)
-{
- port_cfg(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_INGRESS_VLAN_FILTER, set);
-}
-
-static inline int port_chk_dis_non_vid(struct ksz_hw *hw, int p)
-{
- return port_chk(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_DISCARD_NON_VID);
-}
-
-static inline int port_chk_in_filter(struct ksz_hw *hw, int p)
-{
- return port_chk(hw, p,
- KS8842_PORT_CTRL_2_OFFSET, PORT_INGRESS_VLAN_FILTER);
-}
-
/* Mirroring */
static inline void port_cfg_mirror_sniffer(struct ksz_hw *hw, int p, int set)
--
2.20.1.7.g153144c
[PATCH] usb: gadget: aspeed_udc: Add check for dma_alloc_coherent
Add the check for the return value of dma_alloc_coherent
in order to avoid NULL pointer dereference.
Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
Signed-off-by: Jiasheng Jiang
---
drivers/usb/gadget/udc/aspeed_udc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/aspeed_udc.c
b/drivers/usb/gadget/udc/aspeed_udc.c
index 01968e2167f9..6cf46562bb25 100644
--- a/drivers/usb/gadget/udc/aspeed_udc.c
+++ b/drivers/usb/gadget/udc/aspeed_udc.c
@@ -1516,6 +1516,8 @@ static int ast_udc_probe(struct platform_device *pdev)
AST_UDC_EP_DMA_SIZE *
AST_UDC_NUM_ENDPOINTS,
>ep0_buf_dma, GFP_KERNEL);
+ if (!udc->ep0_buf)
+ return -ENOMEM;
udc->gadget.speed = USB_SPEED_UNKNOWN;
udc->gadget.max_speed = USB_SPEED_HIGH;
--
2.25.1
Re: [PATCH 2/2] drm/i915/guc: Look for a guilty context when an engine reset fails
On Tue, Nov 29, 2022 at 01:12:53PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
does (due to unknwon reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0a42f1807f52c..c82730804a1c4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4751,11 +4751,24 @@ static void reset_fail_worker_func(struct work_struct
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(>submission_state.lock, flags);
- if (likely(reset_fail_mask))
+ if (likely(reset_fail_mask)) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* GuC is toast at this point - it dead loops after sending the
failed
+* reset notification. So need to manually determine the guilty
context.
+* Note that it should be safe/reliable to do this here because
the GuC
+* is toast and will not be scheduling behind the KMD's back.
+*/
Is that defined by the kmd-GuC interface that following a failed reset notification, GuC
will always dead-loop OR not schedule anything (even on other engines) until KMD takes
some action? What action should KMD take?
Regards,
Umesh
+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
+ intel_guc_find_hung_context(engine);
+
intel_gt_handle_error(gt, reset_fail_mask,
I915_ERROR_CAPTURE,
"GuC failed to reset engine mask=0x%x\n",
reset_fail_mask);
+ }
}
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
--
2.37.3
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Allow error capture without a request
On Tue, Nov 29, 2022 at 01:12:52PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.
In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.
So update the error capture code to always record engine information
if an engine is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 55 +++
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64e..2ed1c84c9fab4 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct
intel_engine_coredump *ee)
}
static bool record_context(struct i915_gem_context_coredump *e,
- const struct i915_request *rq)
+ struct intel_context *ce)
{
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
rcu_read_lock();
- ctx = rcu_dereference(rq->context->gem_context);
+ ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
- e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
- e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+ e->total_runtime = intel_context_get_total_runtime_ns(ce);
+ e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
simulated = i915_gem_context_no_error_capture(ctx);
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs
*engine, gfp_t gfp, u32 dump_
return ee;
}
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+ struct intel_context *ce,
+ gfp_t gfp)
+{
+ struct intel_engine_capture_vma *vma = NULL;
+
+ ee->simulated |= record_context(>context, ce);
+ if (ee->simulated)
+ return NULL;
+
+ /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+ vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+ vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+ return vma;
+}
+
struct intel_engine_capture_vma *
intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
struct i915_request *rq,
gfp_t gfp)
{
- struct intel_engine_capture_vma *vma = NULL;
+ struct intel_engine_capture_vma *vma;
- ee->simulated |= record_context(>context, rq);
- if (ee->simulated)
+ vma = engine_coredump_add_context(ee, rq->context, gfp);
+ if (!vma)
return NULL;
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct
intel_engine_coredump *ee,
*/
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
- vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
- vma = capture_vma(vma, rq->context->state, "HW context", gfp);
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1608,8 +1628,11 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (!rq || !i915_request_started(rq))
- goto no_request_capture;
+ if (rq && !i915_request_started(rq)) {
+ drm_info(>gt->i915->drm, "Got hung context on %s
with no active request!\n",
+engine->name);
+ rq = NULL;
+ }
} else {
/*
* Getting here with GuC enabled means
Re: [Freedreno] [PATCH] drm/msm/hdm: Fix the error handling path of msm_hdmi_dev_probe()
On 12/12/2022 5:34 PM, Abhinav Kumar wrote:
On 12/10/2022 10:50 PM, Christophe JAILLET wrote:
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi: move msm_hdmi_get_phy() to
msm_hdmi_dev_probe()")
Signed-off-by: Christophe JAILLET
Reviewed-by: Abhinav Kumar
Actually, i missed one nit
In the subject line, it should be "drm/msm/hdmi"
The "i" is missing.
Please fix that and post it.
---
Not sure if the Fixes tag is correct. At least it is when the probe needs
to be fixed but the issue was maybe there elsewhere before.
Seems right to me.
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c
b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 4d3fdc806bef..97372bb241d8 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -532,11 +532,19 @@ static int msm_hdmi_dev_probe(struct
platform_device *pdev)
ret = devm_pm_runtime_enable(>dev);
if (ret)
- return ret;
+ goto err_put_phy;
platform_set_drvdata(pdev, hdmi);
- return component_add(>dev, _hdmi_ops);
+ ret = component_add(>dev, _hdmi_ops);
+ if (ret)
+ goto err_put_phy;
+
+ return 0;
+
+err_put_phy:
+ msm_hdmi_put_phy(hdmi);
+ return ret;
}
static int msm_hdmi_dev_remove(struct platform_device *pdev)
Re: [PATCH] drm/msm/hdm: Fix the error handling path of msm_hdmi_dev_probe()
On 12/10/2022 10:50 PM, Christophe JAILLET wrote:
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi: move msm_hdmi_get_phy() to
msm_hdmi_dev_probe()")
Signed-off-by: Christophe JAILLET
Reviewed-by: Abhinav Kumar
---
Not sure if the Fixes tag is correct. At least it is when the probe needs
to be fixed but the issue was maybe there elsewhere before.
Seems right to me.
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 4d3fdc806bef..97372bb241d8 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -532,11 +532,19 @@ static int msm_hdmi_dev_probe(struct platform_device
*pdev)
ret = devm_pm_runtime_enable(>dev);
if (ret)
- return ret;
+ goto err_put_phy;
platform_set_drvdata(pdev, hdmi);
- return component_add(>dev, _hdmi_ops);
+ ret = component_add(>dev, _hdmi_ops);
+ if (ret)
+ goto err_put_phy;
+
+ return 0;
+
+err_put_phy:
+ msm_hdmi_put_phy(hdmi);
+ return ret;
}
static int msm_hdmi_dev_remove(struct platform_device *pdev)
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 13 December 2022 02:41:55 GMT+03:00, Abhinav Kumar
wrote:
>Hi Dmitry
>
>On 12/12/2022 2:35 PM, Dmitry Baryshkov wrote:
>> On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh wrote:
>>>
>>>
>>> On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
On 09/12/2022 02:22, Kuogee Hsieh wrote:
>
> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>>>
>>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
> Add both data-lanes and link-frequencies property into endpoint
>
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lanes property
>
> Changes in v8:
> -- correct Bjorn mail address to kernel.org
>
> Changes in v10:
> -- add menu item to data-lanes and link-frequecnis
>
> Changes in v11:
> -- add endpoint property at port@1
>
> Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the
example validates against the schema?
>>>
>>> yes, but i run "make dt_binding_check
>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
>>> at mu v5.15 branch since
>>
>> I wouldn't ask you to post the log here. But I don't think that
>> either of the errors that I see here is related to 5.15 vs 6.1-rc.
>>
>> In fact after applying this patch against 5.15 I saw the expected
>> failure:
>>
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>> properties:required: ['port@0', 'port@1'] is not of type 'object',
>> 'boolean'
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>> properties: 'required' should not be valid under {'$ref':
>> '#/definitions/json-schema-prop-names'}
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>> ignoring, error in schema: properties: required
>>
>>>
>>> "make dt_binding_check" does not work at msm-next branch.
>>
>> I went ahead and just checked.
>>
>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
>> in msm-next and reports a single example-related warning in
>> msm-next-lumag. I pushed a patch to fix that warning (wich can
>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
>> that both these branches have consistent error-free display/msm
>> schemas.
>>
> I have clean msm-next branch (without my data-lines yaml patch
> applied) and run "make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
> then I saw below error messages.
>
> Have you run into this problem?
No.
>>>
>>> Did you do anything to fix "older dtschema instance"?
>>
>> I did not since I hadn't had such a problem. I can refer again to the
>> steps I provided you beforehand. The email was sent 6 days ago. No
>> answer from your side since that time.
>>
>>> I had run "pip3 install dtschema --upgrade" and still not work.
>>
>> Can you please post a full log of this command?
>>
>>>
>>> D you know how to fix this problem?
>>>
>>> Thanks,
>>>
>>> kuogee
>>>
>>> sort: -:2: disorder: 2022.1
>>> ERROR: dtschema minimum version is v2022.3
>>> make[2]: *** [check_dtschema_version] Error 1
>>> make[1]: *** [dt_binding_check] Error 2
>>> make: *** [__sub-make] Error 2
>>
>> Please add the output of:
>>
>> which dt-validate
>> dt-validate -V
>>
>> And also a full log of your failing kernel build.
>>
>>
>>
>>> I had run "pip3 install dtschema --upgrade" according Rob Herring response.
>>> but it still shows same problem.
>>> Please let know how can I fix this problem.
>>>
>
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/dtc/dtc.o
> HOSTCC scripts/dtc/flattree.o
> HOSTCC scripts/dtc/fstree.o
> HOSTCC scripts/dtc/data.o
> HOSTCC scripts/dtc/livetree.o
> HOSTCC scripts/dtc/treesource.o
> HOSTCC scripts/dtc/srcpos.o
> HOSTCC scripts/dtc/checks.o
> HOSTCC scripts/dtc/util.o
> LEX scripts/dtc/dtc-lexer.lex.c
> HOSTCC scripts/dtc/dtc-lexer.lex.o
> HOSTCC scripts/dtc/dtc-parser.tab.o
> HOSTLD scripts/dtc/dtc
> sort: -:2: disorder: 2022.1
> ERROR: dtschema minimum version is v2022.3
[PATCH 4/7] drm/msm/a6xx: Add support for A650 speed binning
Add support for matching QFPROM fuse values to get the correct speed bin
on A650 (SM8250) GPUs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 2c1630f0c04c..f139ec57c32d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1887,6 +1887,20 @@ static u32 a640_get_speed_bin(u32 fuse)
return UINT_MAX;
}
+static u32 a650_get_speed_bin(u32 fuse)
+{
+ if (fuse == 0)
+ return 0;
+ else if (fuse == 1)
+ return 1;
+ else if (fuse == 2)
+ return 2;
+ else if (fuse == 3)
+ return 3;
+
+ return UINT_MAX;
+}
+
static u32 adreno_7c3_get_speed_bin(u32 fuse)
{
if (fuse == 0)
@@ -1915,6 +1929,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct
adreno_rev rev, u32 fuse)
if (adreno_cmp_rev(ADRENO_REV(6, 4, 0, ANY_ID), rev))
val = a640_get_speed_bin(fuse);
+ if (adreno_cmp_rev(ADRENO_REV(6, 5, 0, ANY_ID), rev))
+ val = a650_get_speed_bin(fuse);
+
if (val == UINT_MAX) {
DRM_DEV_ERROR(dev,
"missing support for speed-bin: %u. Some OPPs may not
be supported by hardware\n",
--
2.39.0
[PATCH 3/7] drm/msm/a6xx: Add support for A640 speed binning
Add support for matching QFPROM fuse values to get the correct speed bin
on A640 (SM8150) GPUs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 36c8fb699b56..2c1630f0c04c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1877,6 +1877,16 @@ static u32 a619_get_speed_bin(u32 fuse)
return UINT_MAX;
}
+static u32 a640_get_speed_bin(u32 fuse)
+{
+ if (fuse == 0)
+ return 0;
+ else if (fuse == 1)
+ return 1;
+
+ return UINT_MAX;
+}
+
static u32 adreno_7c3_get_speed_bin(u32 fuse)
{
if (fuse == 0)
@@ -1902,6 +1912,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct
adreno_rev rev, u32 fuse)
if (adreno_cmp_rev(ADRENO_REV(6, 3, 5, ANY_ID), rev))
val = adreno_7c3_get_speed_bin(fuse);
+ if (adreno_cmp_rev(ADRENO_REV(6, 4, 0, ANY_ID), rev))
+ val = a640_get_speed_bin(fuse);
+
if (val == UINT_MAX) {
DRM_DEV_ERROR(dev,
"missing support for speed-bin: %u. Some OPPs may not
be supported by hardware\n",
--
2.39.0
linux-next: manual merge of the fbdev tree with the drm tree
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
drivers/video/fbdev/Kconfig
between commit:
c8a17756c425 ("drm/ofdrm: Add ofdrm for Open Firmware framebuffers")
from the drm tree and commit:
225e095bbd3a ("fbdev: offb: make offb driver tristate")
from the fbdev tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/video/fbdev/Kconfig
index 71019b167f8b,a529511f7f53..
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@@ -456,9 -453,8 +456,9 @@@ config FB_ATAR
chipset found in Ataris.
config FB_OF
- bool "Open Firmware frame buffer device support"
- depends on (FB = y) && PPC && (!PPC_PSERIES || PCI)
+ tristate "Open Firmware frame buffer device support"
+ depends on FB && PPC && (!PPC_PSERIES || PCI)
+ depends on !DRM_OFDRM
select APERTURE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
pgpo6ONEaWE1o.pgp
Description: OpenPGP digital signature
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
Hi Dmitry
On 12/12/2022 2:35 PM, Dmitry Baryshkov wrote:
On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh wrote:
On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
On 09/12/2022 02:22, Kuogee Hsieh wrote:
On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
On 09/12/2022 01:38, Kuogee Hsieh wrote:
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the
example validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
at mu v5.15 branch since
I wouldn't ask you to post the log here. But I don't think that
either of the errors that I see here is related to 5.15 vs 6.1-rc.
In fact after applying this patch against 5.15 I saw the expected
failure:
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties:required: ['port@0', 'port@1'] is not of type 'object',
'boolean'
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
ignoring, error in schema: properties: required
"make dt_binding_check" does not work at msm-next branch.
I went ahead and just checked.
`make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
in msm-next and reports a single example-related warning in
msm-next-lumag. I pushed a patch to fix that warning (wich can
hopefully be picked up by Abhinav into msm-fixes). So you can assume
that both these branches have consistent error-free display/msm
schemas.
I have clean msm-next branch (without my data-lines yaml patch
applied) and run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
then I saw below error messages.
Have you run into this problem?
No.
Did you do anything to fix "older dtschema instance"?
I did not since I hadn't had such a problem. I can refer again to the
steps I provided you beforehand. The email was sent 6 days ago. No
answer from your side since that time.
I had run "pip3 install dtschema --upgrade" and still not work.
Can you please post a full log of this command?
D you know how to fix this problem?
Thanks,
kuogee
sort: -:2: disorder: 2022.1
ERROR: dtschema minimum version is v2022.3
make[2]: *** [check_dtschema_version] Error 1
make[1]: *** [dt_binding_check] Error 2
make: *** [__sub-make] Error 2
Please add the output of:
which dt-validate
dt-validate -V
And also a full log of your failing kernel build.
I had run "pip3 install dtschema --upgrade" according Rob Herring response.
but it still shows same problem.
Please let know how can I fix this problem.
HOSTCC scripts/basic/fixdep
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
HOSTCC scripts/dtc/dtc-lexer.lex.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
sort: -:2: disorder: 2022.1
ERROR: dtschema minimum version is v2022.3
make[2]: *** [check_dtschema_version] Error 1
make[1]: *** [dt_binding_check] Error 2
make: *** [__sub-make] Error 2
This means that somewhere in your path you have an older dtschema
instance.
When you sent me a question regarding this error, I asked for the
additional info. You provided none. Instead you went on sending the
untested patch that doesn't work.
since i can not test it on msm-next so that I did test it at my v5-15
branch.
Wrong.
besides, i think i have to sent the whole series patches include this
one to address your new comments on other patch.
is this correct?
No. Please fix your system first, validate your patches and send them
afterwards. You can not expect others to do your job.
Just finished working with kuogee on this. This issue had been reported
by few others earlier (example
[PATCH v9 22/23] drm/i915/vm_bind: Properly build persistent map sg table
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
support requires this for page backed regions.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 120 +++-
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7f23adcfb253..d092a86123ae 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1328,6 +1328,120 @@ intel_partial_pages(const struct i915_gtt_view *view,
return ERR_PTR(ret);
}
+static unsigned int
+intel_copy_dma_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+ struct scatterlist *dst_sg, *src_sg;
+ unsigned int i, len, nents = 0;
+
+ dst_sg = dst_st->sgl;
+ for_each_sgtable_dma_sg(src_st, src_sg, i) {
+ if (sg_dma_len(src_sg) <= offset) {
+ offset -= sg_dma_len(src_sg);
+ continue;
+ }
+
+ nents++;
+ len = min(sg_dma_len(src_sg) - offset, length);
+ if (!dry_run) {
+ sg_dma_address(dst_sg) = sg_dma_address(src_sg) +
offset;
+ sg_dma_len(dst_sg) = len;
+ dst_sg = sg_next(dst_sg);
+ }
+
+ length -= len;
+ offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static unsigned int
+intel_copy_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+ struct scatterlist *dst_sg, *src_sg;
+ unsigned int i, len, nents = 0;
+
+ dst_sg = dst_st->sgl;
+ for_each_sgtable_sg(src_st, src_sg, i) {
+ if (src_sg->length <= offset) {
+ offset -= src_sg->length;
+ continue;
+ }
+
+ nents++;
+ len = min(src_sg->length - offset, length);
+ if (!dry_run) {
+ unsigned long pfn;
+
+ pfn = page_to_pfn(sg_page(src_sg)) + offset / PAGE_SIZE;
+ sg_set_page(dst_sg, pfn_to_page(pfn), len, 0);
+ dst_sg = sg_next(dst_sg);
+ }
+
+ length -= len;
+ offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static noinline struct sg_table *
+intel_persistent_partial_pages(const struct i915_gtt_view *view,
+ struct drm_i915_gem_object *obj)
+{
+ u64 offset = view->partial.offset << PAGE_SHIFT;
+ struct sg_table *st, *obj_st = obj->mm.pages;
+ u64 length = view->partial.size << PAGE_SHIFT;
+ struct scatterlist *sg;
+ unsigned int nents;
+ int ret = -ENOMEM;
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ goto err_st_alloc;
+
+ /* Get required sg_table size */
+ nents = intel_copy_dma_sg(obj_st, st, offset, length, true);
+ if (i915_gem_object_has_struct_page(obj)) {
+ unsigned int pg_nents;
+
+ pg_nents = intel_copy_sg(obj_st, st, offset, length, true);
+ if (nents < pg_nents)
+ nents = pg_nents;
+ }
+
+ ret = sg_alloc_table(st, nents, GFP_KERNEL);
+ if (ret)
+ goto err_sg_alloc;
+
+ /* Build sg_table for specified section */
+ intel_copy_dma_sg(obj_st, st, offset, length, false);
+ if (i915_gem_object_has_struct_page(obj))
+ intel_copy_sg(obj_st, st, offset, length, false);
+
+ /* Mark last sg */
+ sg = st->sgl;
+ while (sg_next(sg))
+ sg = sg_next(sg);
+ sg_mark_end(sg);
+
+ return st;
+
+err_sg_alloc:
+ kfree(st);
+err_st_alloc:
+ return ERR_PTR(ret);
+}
+
static int
__i915_vma_get_pages(struct i915_vma *vma)
{
@@ -1360,7 +1474,11 @@ __i915_vma_get_pages(struct i915_vma *vma)
break;
case I915_GTT_VIEW_PARTIAL:
- pages = intel_partial_pages(>gtt_view, vma->obj);
+ if (i915_vma_is_persistent(vma))
+ pages = intel_persistent_partial_pages(>gtt_view,
+ vma->obj);
+ else
+ pages = intel_partial_pages(>gtt_view, vma->obj);
break;
}
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 20/23] drm/i915/vm_bind: Render VM_BIND documentation
Update i915 documentation to include VM_BIND changes and render all VM_BIND related documentation. Reviewed-by: Matthew Auld Signed-off-by: Niranjana Vishwanathapura --- Documentation/gpu/i915.rst | 78 -- 1 file changed, 59 insertions(+), 19 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 60ea21734902..01429a8f0d6c 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -283,15 +283,18 @@ An Intel GPU has multiple engines. There are several engine types. The Intel GPU family is a family of integrated GPU's using Unified Memory Access. For having the GPU "do work", user space will feed the -GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` -or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will -instruct the GPU to perform work (for example rendering) and that work -needs memory from which to read and memory to which to write. All memory -is encapsulated within GEM buffer objects (usually created with the ioctl -`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU -to create will also list all GEM buffer objects that the batchbuffer reads -and/or writes. For implementation details of memory management see -`GEM BO Management Implementation Details`_. +GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`, +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` or `DRM_IOCTL_I915_GEM_EXECBUFFER3`. +Most such batchbuffers will instruct the GPU to perform work (for example +rendering) and that work needs memory from which to read and memory to +which to write. All memory is encapsulated within GEM buffer objects +(usually created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). In vm_bind mode +(see `VM_BIND mode`_), the batch buffer and all the GEM buffer objects that +it reads and/or writes should be bound with vm_bind ioctl before submitting +the batch buffer to GPU. In legacy (non-VM_BIND) mode, an ioctl providing a +batchbuffer for the GPU to create will also list all GEM buffer objects that +the batchbuffer reads and/or writes. For implementation details of memory +management see `GEM BO Management Implementation Details`_. The i915 driver allows user space to create a context via the ioctl `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit @@ -309,8 +312,9 @@ In addition to the ordering guarantees, the kernel will restore GPU state via HW context when commands are issued to a context, this saves user space the need to restore (most of atleast) the GPU state at the start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer -work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) -to identify what context to use with the command. +work can pass that ID (drm_i915_gem_execbuffer3::ctx_id, or in the lower +bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use +with the command. The GPU has its own memory management and address space. The kernel driver maintains the memory translation table for the GPU. For older @@ -318,14 +322,14 @@ GPUs (i.e. those before Gen8), there is a single global such translation table, a global Graphics Translation Table (GTT). For newer generation GPUs each context has its own translation table, called Per-Process Graphics Translation Table (PPGTT). Of important note, is that although -PPGTT is named per-process it is actually per context. When user space -submits a batchbuffer, the kernel walks the list of GEM buffer objects -used by the batchbuffer and guarantees that not only is the memory of -each such GEM buffer object resident but it is also present in the -(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT, -then it is given an address. Two consequences of this are: the kernel -needs to edit the batchbuffer submitted to write the correct value of -the GPU address when a GEM BO is assigned a GPU address and the kernel +PPGTT is named per-process it is actually per context. In legacy +(non-vm_bind) mode, when user space submits a batchbuffer, the kernel walks +the list of GEM buffer objects used by the batchbuffer and guarantees that +not only is the memory of each such GEM buffer object resident but it is +also present in the (PP)GTT. If the GEM buffer object is not yet placed in +the (PP)GTT, then it is given an address. Two consequences of this are: the +kernel needs to edit the batchbuffer submitted to write the correct value +of the GPU address when a GEM BO is assigned a GPU address and the kernel might evict a different GEM BO from the (PP)GTT to make address room for another GEM BO. Consequently, the ioctls submitting a batchbuffer for execution also include a list of all locations within buffers that @@ -407,6 +411,15 @@ objects, which has the goal to make space in gpu virtual address spaces. .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c :internal: +VM_BIND mode + +
[PATCH v9 18/23] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts
Only support vm_bind mode with non-recoverable contexts.
With new vm_bind mode with eb3 submission path, we need not
support older recoverable contexts.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fb4d2dab5053..9809c58316c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1617,6 +1617,12 @@ i915_gem_create_context(struct drm_i915_private *i915,
INIT_LIST_HEAD(>stale.engines);
if (pc->vm) {
+ /* Only non-recoverable contexts are allowed in vm_bind mode */
+ if (i915_gem_vm_is_vm_bind_mode(pc->vm) &&
+ (pc->user_flags & BIT(UCONTEXT_RECOVERABLE))) {
+ err = -EINVAL;
+ goto err_ctx;
+ }
vm = i915_vm_get(pc->vm);
} else if (HAS_FULL_PPGTT(i915)) {
struct i915_ppgtt *ppgtt;
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 19/23] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode
Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.
v2: update kernel-doc
v3: create vm->root_obj only upon I915_VM_CREATE_FLAGS_USE_VM_BIND
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 ++--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_getparam.c| 3 +++
include/uapi/drm/i915_drm.h | 26 -
6 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9809c58316c2..ba4aca5ff432 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1809,9 +1809,13 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev,
void *data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
- if (args->flags)
+ if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
+ if ((args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) &&
+ !HAS_VM_BIND(i915))
+ return -EOPNOTSUPP;
+
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
@@ -1824,15 +1828,32 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev,
void *data,
goto err_put;
}
+ if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) {
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ goto err_put;
+ }
+
+ ppgtt->vm.root_obj = obj;
+ }
+
err = xa_alloc(_priv->vm_xa, , >vm,
xa_limit_32b, GFP_KERNEL);
if (err)
- goto err_put;
+ goto err_root_obj_put;
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->vm_id = id;
return 0;
+err_root_obj_put:
+ if (ppgtt->vm.root_obj) {
+ i915_gem_object_put(ppgtt->vm.root_obj);
+ ppgtt->vm.root_obj = NULL;
+ }
err_put:
i915_vm_put(>vm);
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e8b41aa8f8c4..b53aef2853cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -150,8 +150,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device
*dev, void *data,
*/
static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
{
- /* No support to enable vm_bind mode yet */
- return false;
+ return !!vm->root_obj;
}
struct i915_address_space *
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7045b2114df6..2e4c9fabf3b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -179,6 +179,8 @@ int i915_vm_lock_objects(struct i915_address_space *vm,
void i915_address_space_fini(struct i915_address_space *vm)
{
drm_mm_takedown(>mm);
+ if (vm->root_obj)
+ i915_gem_object_put(vm->root_obj);
GEM_BUG_ON(!RB_EMPTY_ROOT(>va.rb_root));
mutex_destroy(>vm_bind_lock);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a4e9dc15b69..dff6a76805cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -967,6 +967,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_LMEMBAR_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
GRAPHICS_VER_FULL(i915) >= IP_VER(12,
70))
+#define HAS_VM_BIND(i915) (GRAPHICS_VER(i915) >= 12)
+
/* intel_device_info.c */
static inline struct intel_device_info *
mkwrite_device_info(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 61ef2d9cfa62..20c1bf904a65 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -178,6 +178,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_OA_TIMESTAMP_FREQUENCY:
value = i915_perf_oa_timestamp_frequency(i915);
break;
+ case I915_PARAM_VM_BIND_VERSION:
+ value = HAS_VM_BIND(i915);
+ break;
default:
drm_dbg(>drm, "Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h
[PATCH v9 15/23] drm/i915/vm_bind: Expose i915_request_await_bind()
Rename __i915_request_await_bind() as i915_request_await_bind()
and make it non-static as it will be used in execbuf3 ioctl path.
v2: add documentation
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 8 +---
drivers/gpu/drm/i915/i915_vma.h | 16
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7013b2936565..af3eb6ce68b0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1923,18 +1923,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(>obj->userfault_link);
}
-static int
-__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
-{
- return __i915_request_await_exclusive(rq, >active);
-}
-
static int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request
*rq)
{
int err;
/* Wait for the vma to be bound before we start! */
- err = __i915_request_await_bind(rq, vma);
+ err = i915_request_await_bind(rq, vma);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 1f25e45a6325..d6c05227fb04 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -55,6 +55,22 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma,
unsigned int flags);
#define __EXEC_OBJECT_NO_RESERVE BIT(31)
#define __EXEC_OBJECT_NO_REQUEST_AWAIT BIT(30)
+/**
+ * i915_request_await_bind() - Setup request to wait for a vma bind completion
+ * @rq: the request which should wait
+ * @vma: vma whose binding @rq should wait to complete
+ *
+ * Setup the request @rq to asynchronously wait for @vma bind to complete
+ * before starting execution.
+ *
+ * Returns 0 on success, error code on failure.
+ */
+static inline int
+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
+{
+ return __i915_request_await_exclusive(rq, >active);
+}
+
int __must_check _i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq,
struct dma_fence *fence,
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 14/23] drm/i915/vm_bind: Update i915_vma_verify_bind_complete()
Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.
v2: Fix fence leak
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_vma.c | 22 --
drivers/gpu/drm/i915/i915_vma.h | 1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6970e1022fee..7013b2936565 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -441,12 +441,25 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-static int i915_vma_verify_bind_complete(struct i915_vma *vma)
+/**
+ * i915_vma_verify_bind_complete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion
+ *
+ * As the fence reference is obtained under RCU, no locking is required by
+ * the caller.
+ *
+ * Returns: 0 if the vma bind is completed. Error code otherwise.
+ */
+int i915_vma_verify_bind_complete(struct i915_vma *vma)
{
- struct dma_fence *fence = i915_active_fence_get(>active.excl);
+ struct dma_fence *fence;
int err;
+ /* Ensure vma bind is initiated */
+ if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
+ return -EINVAL;
+
+ fence = i915_active_fence_get(>active.excl);
if (!fence)
return 0;
@@ -459,9 +472,6 @@ static int i915_vma_verify_bind_complete(struct i915_vma
*vma)
return err;
}
-#else
-#define i915_vma_verify_bind_complete(_vma) 0
-#endif
I915_SELFTEST_EXPORT void
i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index de1756e4f638..1f25e45a6325 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -487,6 +487,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
int i915_vma_wait_for_bind(struct i915_vma *vma);
int i915_vma_sync(struct i915_vma *vma);
+int i915_vma_verify_bind_complete(struct i915_vma *vma);
/**
* i915_vma_get_current_resource - Get the current resource of the vma
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 17/23] drm/i915/vm_bind: userptr dma-resv changes
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
v2: Do not double add vma to vm->userptr_invalidated_list
v3: Initialize vma->userptr_invalidated_link
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 84 ++-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 15
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
7 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 913b1f8bda9f..a1aee477e2df 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -20,6 +20,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_USERPTR_USED BIT_ULL(34)
#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -144,7 +145,22 @@ static void eb_scoop_unbound_vma_all(struct
i915_address_space *vm)
{
struct i915_vma *vma, *vn;
- /**
+#ifdef CONFIG_MMU_NOTIFIER
+ /*
+* Move all invalidated userptr vmas back into vm_bind_list so that
+* they are looked up and revalidated.
+*/
+ spin_lock(>userptr_invalidated_lock);
+ list_for_each_entry_safe(vma, vn, >userptr_invalidated_list,
+userptr_invalidated_link) {
+ list_del_init(>userptr_invalidated_link);
+ if (!list_empty(>vm_bind_link))
+ list_move_tail(>vm_bind_link, >vm_bind_list);
+ }
+ spin_unlock(>userptr_invalidated_lock);
+#endif
+
+ /*
* Move all unbound vmas back into vm_bind_list so that they are
* revalidated.
*/
@@ -157,10 +173,47 @@ static void eb_scoop_unbound_vma_all(struct
i915_address_space *vm)
spin_unlock(>vm_rebind_lock);
}
+static int eb_lookup_persistent_userptr_vmas(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *last_vma = NULL;
+ struct i915_vma *vma;
+ int err;
+
+ lockdep_assert_held(>vm_bind_lock);
+
+ list_for_each_entry(vma, >vm_bind_list, vm_bind_link) {
+ if (!i915_gem_object_is_userptr(vma->obj))
+ continue;
+
+ err = i915_gem_object_userptr_submit_init(vma->obj);
+ if (err)
+ return err;
+
+ /*
+* The above submit_init() call does the object unbind and
+* hence adds vma into vm_rebind_list. Remove it from that
+* list as it is already scooped for revalidation.
+*/
+ spin_lock(>vm_rebind_lock);
+ if (!list_empty(>vm_rebind_link))
+ list_del_init(>vm_rebind_link);
+ spin_unlock(>vm_rebind_lock);
+
+ last_vma = vma;
+ }
+
+ if (last_vma)
+ eb->args->flags |= __EXEC3_USERPTR_USED;
+
+ return 0;
+}
+
static int eb_lookup_vma_all(struct i915_execbuffer *eb)
{
struct i915_vma *vma;
unsigned int i;
+ int err = 0;
for (i = 0; i < eb->num_batches; i++) {
vma = eb_find_vma(eb->context->vm, eb->batch_addresses[i]);
@@ -172,6 +225,10 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
eb_scoop_unbound_vma_all(eb->context->vm);
+ err = eb_lookup_persistent_userptr_vmas(eb);
+ if (err)
+ return err;
+
return 0;
}
@@ -344,6 +401,29 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
}
}
+#ifdef CONFIG_MMU_NOTIFIER
+ /* Check for further userptr invalidations */
+ spin_lock(>userptr_invalidated_lock);
+ if (!list_empty(>userptr_invalidated_list))
+ err = -EAGAIN;
+ spin_unlock(>userptr_invalidated_lock);
+
+ if (!err && (eb->args->flags & __EXEC3_USERPTR_USED)) {
+ read_lock(>i915->mm.notifier_lock);
+ list_for_each_entry(vma, >vm_bind_list, vm_bind_link) {
+ if (!i915_gem_object_is_userptr(vma->obj))
+ continue;
+
+ err = i915_gem_object_userptr_submit_done(vma->obj);
+ if (err)
+ break;
+ }
+ read_unlock(>i915->mm.notifier_lock);
+ }
+#endif
+ if (unlikely(err))
+ goto err_skip;
+
[PATCH v9 12/23] drm/i915/vm_bind: Use common execbuf functions in execbuf path
Update the execbuf path to use common execbuf functions to
reduce code duplication with the newer execbuf3 path.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 513 ++
1 file changed, 39 insertions(+), 474 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6a7f0227f65f..8b49543f3265 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -28,6 +28,7 @@
#include "i915_file_private.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
#include "i915_gem_evict.h"
#include "i915_gem_ioctls.h"
#include "i915_reg.h"
@@ -236,13 +237,6 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
-struct eb_fence {
- struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
- struct dma_fence *dma_fence;
- u64 value;
- struct dma_fence_chain *chain_fence;
-};
-
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2452,164 +2446,29 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX] = VECS0
};
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct
intel_context *ce)
-{
- struct intel_ring *ring = ce->ring;
- struct intel_timeline *tl = ce->timeline;
- struct i915_request *rq;
-
- /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
- if (intel_ring_update_space(ring) >= PAGE_SIZE)
- return NULL;
-
- /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
- list_for_each_entry(rq, >requests, link) {
- if (rq->ring != ring)
- continue;
-
- if (__intel_ring_space(rq->postfix,
- ring->emit, ring->size) > ring->size / 2)
- break;
- }
- if (>link == >requests)
- return NULL; /* weird, we will check again later for real */
-
- return i915_request_get(rq);
-}
-
-static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context
*ce,
- bool throttle)
-{
- struct intel_timeline *tl;
- struct i915_request *rq = NULL;
-
- /*
-* Take a local wakeref for preparing to dispatch the execbuf as
-* we expect to access the hardware fairly frequently in the
-* process, and require the engine to be kept awake between accesses.
-* Upon dispatch, we acquire another prolonged wakeref that we hold
-* until the timeline is idle, which in turn releases the wakeref
-* taken on the engine, and the parent device.
-*/
- tl = intel_context_timeline_lock(ce);
- if (IS_ERR(tl))
- return PTR_ERR(tl);
-
- intel_context_enter(ce);
- if (throttle)
- rq = eb_throttle(eb, ce);
- intel_context_timeline_unlock(tl);
-
- if (rq) {
- bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
- long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
-
- if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
- timeout) < 0) {
- i915_request_put(rq);
-
- /*
-* Error path, cannot use intel_context_timeline_lock as
-* that is user interruptable and this clean up step
-* must be done.
-*/
- mutex_lock(>timeline->mutex);
- intel_context_exit(ce);
- mutex_unlock(>timeline->mutex);
-
- if (nonblock)
- return -EWOULDBLOCK;
- else
- return -EINTR;
- }
- i915_request_put(rq);
- }
-
- return 0;
-}
-
static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle)
{
- struct intel_context *ce = eb->context, *child;
int err;
- int i = 0, j = 0;
GEM_BUG_ON(eb->args->flags & __EXEC_ENGINE_PINNED);
- if (unlikely(intel_context_is_banned(ce)))
- return -EIO;
-
- /*
-* Pinning the contexts may generate requests in
[PATCH v9 05/23] drm/i915/vm_bind: Add support to create persistent vma
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing. ie., multiple
mappings (at different VA) point to the same gtt_view of object.
Skip vma_lookup for persistent vmas to support aliasing.
v2: Remove unused I915_VMA_PERSISTENT definition,
update validity check in i915_vma_compare(),
remove unwanted is_persistent check in release_references().
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_vma.c | 36 +--
drivers/gpu/drm/i915/i915_vma.h | 17 -
drivers/gpu/drm/i915/i915_vma_types.h | 6 +
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 79b2e19a299f..e43cbb5fa154 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -111,7 +111,8 @@ static void __i915_vma_retire(struct i915_active *ref)
static struct i915_vma *
vma_create(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
- const struct i915_gtt_view *view)
+ const struct i915_gtt_view *view,
+ bool skip_lookup_cache)
{
struct i915_vma *pos = ERR_PTR(-E2BIG);
struct i915_vma *vma;
@@ -198,6 +199,9 @@ vma_create(struct drm_i915_gem_object *obj,
__set_bit(I915_VMA_GGTT_BIT, __i915_vma_flags(vma));
}
+ if (skip_lookup_cache)
+ goto skip_rb_insert;
+
rb = NULL;
p = >vma.tree.rb_node;
while (*p) {
@@ -222,6 +226,7 @@ vma_create(struct drm_i915_gem_object *obj,
rb_link_node(>obj_node, rb, p);
rb_insert_color(>obj_node, >vma.tree);
+skip_rb_insert:
if (i915_vma_is_ggtt(vma))
/*
* We put the GGTT vma at the start of the vma-list, followed
@@ -301,7 +306,34 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
/* vma_create() will resolve the race if another creates the vma */
if (unlikely(!vma))
- vma = vma_create(obj, vm, view);
+ vma = vma_create(obj, vm, view, false);
+
+ GEM_BUG_ON(!IS_ERR(vma) && i915_vma_compare(vma, vm, view));
+ return vma;
+}
+
+/**
+ * i915_vma_create_persistent - create a persistent VMA
+ * @obj: parent drm_i915_gem_object to be mapped
+ * @vm: address space in which the mapping is located
+ * @view: additional mapping requirements
+ *
+ * Creates a persistent vma.
+ *
+ * Returns the vma, or an error pointer.
+ */
+struct i915_vma *
+i915_vma_create_persistent(struct drm_i915_gem_object *obj,
+ struct i915_address_space *vm,
+ const struct i915_gtt_view *view)
+{
+ struct i915_vma *vma;
+
+ GEM_BUG_ON(!kref_read(>ref));
+
+ vma = vma_create(obj, vm, view, true);
+ if (!IS_ERR(vma))
+ i915_vma_set_persistent(vma);
GEM_BUG_ON(!IS_ERR(vma) && i915_vma_compare(vma, vm, view));
return vma;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index ed5c9d682a1b..dd9951a41ff3 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -44,6 +44,10 @@ struct i915_vma *
i915_vma_instance(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
const struct i915_gtt_view *view);
+struct i915_vma *
+i915_vma_create_persistent(struct drm_i915_gem_object *obj,
+ struct i915_address_space *vm,
+ const struct i915_gtt_view *view);
void i915_vma_unpin_and_release(struct i915_vma **p_vma, unsigned int flags);
#define I915_VMA_RELEASE_MAP BIT(0)
@@ -185,6 +189,16 @@ static inline u32 i915_ggtt_pin_bias(struct i915_vma *vma)
return i915_vm_to_ggtt(vma->vm)->pin_bias;
}
+static inline bool i915_vma_is_persistent(const struct i915_vma *vma)
+{
+ return test_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
+}
+
+static inline void i915_vma_set_persistent(struct i915_vma *vma)
+{
+ set_bit(I915_VMA_PERSISTENT_BIT, __i915_vma_flags(vma));
+}
+
static inline struct i915_vma *i915_vma_get(struct i915_vma *vma)
{
i915_gem_object_get(vma->obj);
@@ -211,7 +225,8 @@ i915_vma_compare(struct i915_vma *vma,
{
ptrdiff_t cmp;
- GEM_BUG_ON(view && !i915_is_ggtt_or_dpt(vm));
+ GEM_BUG_ON(view && !(i915_is_ggtt_or_dpt(vm) ||
+i915_vma_is_persistent(vma)));
cmp = ptrdiff(vma->vm, vm);
if (cmp)
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h
b/drivers/gpu/drm/i915/i915_vma_types.h
index 77fda2244d16..be1cd76304cb 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -265,6
[PATCH v9 21/23] drm/i915/vm_bind: Async vm_unbind support
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
v3: Add force_unbind function variants
Reviewed-by: Matthew Auld
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 49 ++-
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 1cc0b8a4e0e7..78e7c0642c5f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index b27735eaaeb9..7f23adcfb253 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1746,7 +1748,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void __force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(>node))
return;
@@ -1760,10 +1762,26 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, >flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
+#define force_unbind(vma) __force_unbind((vma), false)
+
static void release_references(struct i915_vma *vma, struct intel_gt *gt,
bool vm_ddestroy)
{
@@ -1842,6 +1860,33 @@ void i915_vma_destroy(struct i915_vma *vma)
release_references(vma, gt, vm_ddestroy);
}
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(>vm->mutex);
+ /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+ if (async && i915_active_wait(>active))
+ async = false;
+
+ __force_unbind(vma, async);
+ list_del_init(>vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(>vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
void i915_vma_parked(struct intel_gt *gt)
{
struct i915_vma *vma, *next;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index d6c05227fb04..8033f5c96efc 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -319,6 +319,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3f27001a2c8d..b9167f950327 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3970,7 +3970,8 @@ struct drm_i915_gem_vm_bind {
* any error.
*
* VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
- * are not ordered.
+ * are not ordered. Furthermore, parts of the VM_UNBIND operation can be done
+ *
[PATCH v9 11/23] drm/i915/vm_bind: Abstract out common execbuf functions
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Abstract out the common execbuf functionalities into a
separate file where possible, thus allowing code sharing.
v2: Use drm_dbg instead of DRM_DEBUG
Reviewed-by: Andi Shyti
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile | 1 +
.../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++
.../drm/i915/gem/i915_gem_execbuffer_common.h | 76 ++
3 files changed, 748 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0bd7de1883fb..bf3aa6e97ddd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+ gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
new file mode 100644
index ..fb1364f08a61
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
@@ -0,0 +1,671 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_gt_pm.h"
+#include "gt/intel_ring.h"
+
+#include "i915_drv.h"
+#include "i915_gem_execbuffer_common.h"
+
+#define __EXEC_COMMON_FENCE_WAIT BIT(0)
+#define __EXEC_COMMON_FENCE_SIGNAL BIT(1)
+
+static struct i915_request *eb_throttle(struct intel_context *ce)
+{
+ struct intel_ring *ring = ce->ring;
+ struct intel_timeline *tl = ce->timeline;
+ struct i915_request *rq;
+
+ /*
+* Completely unscientific finger-in-the-air estimates for suitable
+* maximum user request size (to avoid blocking) and then backoff.
+*/
+ if (intel_ring_update_space(ring) >= PAGE_SIZE)
+ return NULL;
+
+ /*
+* Find a request that after waiting upon, there will be at least half
+* the ring available. The hysteresis allows us to compete for the
+* shared ring and should mean that we sleep less often prior to
+* claiming our resources, but not so long that the ring completely
+* drains before we can submit our next request.
+*/
+ list_for_each_entry(rq, >requests, link) {
+ if (rq->ring != ring)
+ continue;
+
+ if (__intel_ring_space(rq->postfix,
+ ring->emit, ring->size) > ring->size / 2)
+ break;
+ }
+ if (>link == >requests)
+ return NULL; /* weird, we will check again later for real */
+
+ return i915_request_get(rq);
+}
+
+static int eb_pin_timeline(struct intel_context *ce, bool throttle,
+ bool nonblock)
+{
+ struct intel_timeline *tl;
+ struct i915_request *rq = NULL;
+
+ /*
+* Take a local wakeref for preparing to dispatch the execbuf as
+* we expect to access the hardware fairly frequently in the
+* process, and require the engine to be kept awake between accesses.
+* Upon dispatch, we acquire another prolonged wakeref that we hold
+* until the timeline is idle, which in turn releases the wakeref
+* taken on the engine, and the parent device.
+*/
+ tl = intel_context_timeline_lock(ce);
+ if (IS_ERR(tl))
+ return PTR_ERR(tl);
+
+ intel_context_enter(ce);
+ if (throttle)
+ rq = eb_throttle(ce);
+ intel_context_timeline_unlock(tl);
+
+ if (rq) {
+ long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
+
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ timeout) < 0) {
+ i915_request_put(rq);
+
+ /*
+* Error path, cannot use intel_context_timeline_lock as
+* that is user interruptable and this clean up step
+* must be done.
+*/
+ mutex_lock(>timeline->mutex);
+ intel_context_exit(ce);
+ mutex_unlock(>timeline->mutex);
+
+ if (nonblock)
+ return -EWOULDBLOCK;
+ else
+ return -EINTR;
+ }
+ i915_request_put(rq);
+ }
+
+ return 0;
+}
+
+/**
+ * i915_eb_pin_engine() - Pin the engine
+ * @ce:
[PATCH v9 16/23] drm/i915/vm_bind: Handle persistent vmas in execbuf3
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
Individualize fences before adding to dma_resv obj.
v4: Fix bind completion check, use PIN_NOEVICT,
use proper lock while checking if vm_rebind_list is empty.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 215 +-
1 file changed, 214 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index 49045858a3e9..913b1f8bda9f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -3,6 +3,7 @@
* Copyright © 2022 Intel Corporation
*/
+#include
#include
#include
@@ -19,6 +20,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -42,7 +44,9 @@
* execlist. Hence, no support for implicit sync.
*
* The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
*
* The execbuf3 ioctl directly specifies the batch addresses instead of as
* object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -58,6 +62,13 @@
* So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
* vma lookup table, implicit sync, vma active reference tracking etc., are not
* applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
*/
/**
@@ -129,6 +140,23 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
}
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)
+{
+ struct i915_vma *vma, *vn;
+
+ /**
+* Move all unbound vmas back into vm_bind_list so that they are
+* revalidated.
+*/
+ spin_lock(>vm_rebind_lock);
+ list_for_each_entry_safe(vma, vn, >vm_rebind_list, vm_rebind_link) {
+ list_del_init(>vm_rebind_link);
+ if (!list_empty(>vm_bind_link))
+ list_move_tail(>vm_bind_link, >vm_bind_list);
+ }
+ spin_unlock(>vm_rebind_lock);
+}
+
static int eb_lookup_vma_all(struct i915_execbuffer *eb)
{
struct i915_vma *vma;
@@ -142,14 +170,108 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
eb->batches[i] = vma;
}
+ eb_scoop_unbound_vma_all(eb->context->vm);
+
+ return 0;
+}
+
+static int eb_lock_vma_all(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma;
+ int err;
+
+ err = i915_gem_object_lock(eb->context->vm->root_obj, >ww);
+ if (err)
+ return err;
+
+ list_for_each_entry(vma, >non_priv_vm_bind_list,
+ non_priv_vm_bind_link) {
+ err = i915_gem_object_lock(vma->obj, >ww);
+ if (err)
+ return err;
+ }
+
return 0;
}
+static void eb_release_persistent_vma_all(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ struct i915_vma *vma, *vn;
+
+ lockdep_assert_held(>vm_bind_lock);
+
+ if (!(eb->args->flags & __EXEC3_HAS_PIN))
+ return;
+
+ assert_object_held(vm->root_obj);
+
+ list_for_each_entry_safe(vma, vn, >vm_bind_list, vm_bind_link)
+ if (!i915_vma_verify_bind_complete(vma))
+ list_move_tail(>vm_bind_link, >vm_bound_list);
+
+ eb->args->flags &= ~__EXEC3_HAS_PIN;
+}
+
static void eb_release_vma_all(struct i915_execbuffer *eb)
{
+ eb_release_persistent_vma_all(eb);
eb_unpin_engine(eb);
}
+static int eb_reserve_fence_for_persistent_vma_all(struct i915_execbuffer *eb)
+{
+ struct i915_address_space *vm = eb->context->vm;
+ u64 num_fences = 1;
+ struct i915_vma *vma;
+ int ret;
+
+ /* Reserve enough slots to accommodate composite fences */
+ if
[PATCH v9 23/23] drm/i915/vm_bind: Support capture of persistent mappings
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling, thus not adding any
additional latency to the submission path.
A list of persistent vmas requiring capture is maintained
instead of a list of vma resources. This allows for no
additional handling around eviction.
v2: enable with CONFIG_DRM_I915_CAPTURE_ERROR, remove gfp
overwrite, add kernel-doc and expand commit message
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../gpu/drm/i915/gem/i915_gem_vm_bind_object.c | 13 +
drivers/gpu/drm/i915/gt/intel_gtt.c| 5 +
drivers/gpu/drm/i915/gt/intel_gtt.h| 7 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 18 +-
drivers/gpu/drm/i915/i915_vma.c| 4
drivers/gpu/drm/i915/i915_vma_types.h | 4
include/uapi/drm/i915_drm.h| 9 +++--
7 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 78e7c0642c5f..562a67a988f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -88,6 +88,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ mutex_lock(>vm->vm_capture_lock);
+ if (!list_empty(>vm_capture_link))
+ list_del_init(>vm_capture_link);
+ mutex_unlock(>vm->vm_capture_lock);
+#endif
spin_lock(>vm->vm_rebind_lock);
if (!list_empty(>vm_rebind_link))
list_del_init(>vm_rebind_link);
@@ -357,6 +363,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
continue;
}
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
+ mutex_lock(>vm_capture_lock);
+ list_add_tail(>vm_capture_link,
>vm_capture_list);
+ mutex_unlock(>vm_capture_lock);
+ }
+#endif
list_add_tail(>vm_bind_link, >vm_bound_list);
i915_vm_bind_it_insert(vma, >va);
if (!obj->priv_root)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2e4c9fabf3b8..103ca55222be 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -297,6 +297,11 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
spin_lock_init(>vm_rebind_lock);
spin_lock_init(>userptr_invalidated_lock);
INIT_LIST_HEAD(>userptr_invalidated_list);
+
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ INIT_LIST_HEAD(>vm_capture_list);
+ mutex_init(>vm_capture_lock);
+#endif
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 620b4e020a9f..7f69e1d4fb5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -281,6 +281,13 @@ struct i915_address_space {
/** @root_obj: root object for dma-resv sharing by private objects */
struct drm_i915_gem_object *root_obj;
+#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
+ /* @vm_capture_list: list of vm captures */
+ struct list_head vm_capture_list;
+ /* @vm_capture_lock: protects vm_capture_list */
+ struct mutex vm_capture_lock;
+#endif
+
/* Global GTT */
bool is_ggtt:1;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64..76b2834ce958 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1460,6 +1460,22 @@ capture_vma(struct intel_engine_capture_vma *next,
return next;
}
+static struct intel_engine_capture_vma *
+capture_user_vm(struct intel_engine_capture_vma *capture,
+ struct i915_address_space *vm, gfp_t gfp)
+{
+ struct i915_vma *vma;
+
+ mutex_lock(>vm_capture_lock);
+ /* vma->resource must be valid here as persistent vmas are bound */
+ list_for_each_entry(vma, >vm_capture_list, vm_capture_link)
+ capture = capture_vma_snapshot(capture, vma->resource,
+ gfp, "user");
+ mutex_unlock(>vm_capture_lock);
+
+ return capture;
+}
+
static struct intel_engine_capture_vma *
capture_user(struct intel_engine_capture_vma *capture,
const struct i915_request *rq,
@@ -1471,7 +1487,7 @@ capture_user(struct intel_engine_capture_vma *capture,
capture = capture_vma_snapshot(capture, c->vma_res, gfp,
[PATCH v9 07/23] drm/i915/vm_bind: Support for VM private BOs
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.
VM private BOs can be only mapped on specified VM and cannot be dmabuf
exported. Also, they are supported only in vm_bind mode.
v2: Pad struct drm_i915_gem_create_ext_vm_private for 64bit alignment,
add input validity checks.
v3: Create root_obj only for ppgtt.
v4: Fix releasing of obj->priv_root. Do not create vm->root_obj yet.
Allow vm private object creation only in vm_bind mode.
Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_create.c| 54 ++-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 +++
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6 +++
.../drm/i915/gem/i915_gem_vm_bind_object.c| 9
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 2 +
include/uapi/drm/i915_drm.h | 33
12 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b90901ad6866..fb4d2dab5053 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -83,6 +83,7 @@
#include "i915_file_private.h"
#include "i915_gem_context.h"
+#include "i915_gem_internal.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 86469710bd59..717403c79226 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
@@ -251,6 +252,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+ u32 vm_id;
};
static void repr_placements(char *buf, size_t size,
@@ -400,9 +402,32 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
return 0;
}
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+ struct drm_i915_gem_create_ext_vm_private ext;
+ struct create_ext *ext_data = data;
+
+ if (copy_from_user(, base, sizeof(ext)))
+ return -EFAULT;
+
+ /* Reserved fields must be 0 */
+ if (ext.rsvd)
+ return -EINVAL;
+
+ /* vm_id 0 is reserved */
+ if (!ext.vm_id)
+ return -ENOENT;
+
+ ext_data->vm_id = ext.vm_id;
+
+ return 0;
+}
+
static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+ [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
};
/**
@@ -418,6 +443,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+ struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
@@ -431,6 +457,17 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
if (ret)
return ret;
+ if (ext_data.vm_id) {
+ vm = i915_gem_vm_lookup(file->driver_priv, ext_data.vm_id);
+ if (unlikely(!vm))
+ return -ENOENT;
+
+ if (!i915_gem_vm_is_vm_bind_mode(vm)) {
+ ret = -EINVAL;
+ goto vm_put;
+ }
+ }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915, INTEL_MEMORY_SYSTEM);
@@ -457,8 +494,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void
*data,
ext_data.placements,
ext_data.n_placements,
ext_data.flags);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ if (IS_ERR(obj)) {
+ ret =
[PATCH v9 08/23] drm/i915/vm_bind: Add support to handle object evictions
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.
v2: Remove unused I915_VMA_PURGED definition.
v3: Properly handle __i915_vma_unbind_async() case.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 6
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 +++
drivers/gpu/drm/i915/i915_vma.c | 28 +++
drivers/gpu/drm/i915/i915_vma.h | 10 +++
drivers/gpu/drm/i915/i915_vma_types.h | 8 ++
6 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 4f9df4b756d2..dc738677466b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -86,6 +86,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
{
lockdep_assert_held(>vm->vm_bind_lock);
+ spin_lock(>vm->vm_rebind_lock);
+ if (!list_empty(>vm_rebind_link))
+ list_del_init(>vm_rebind_link);
+ i915_vma_set_purged(vma);
+ spin_unlock(>vm->vm_rebind_lock);
+
list_del_init(>vm_bind_link);
list_del_init(>non_priv_vm_bind_link);
i915_vm_bind_it_remove(vma, >vm->va);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 7ce0237d664f..4f91857dca46 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -291,6 +291,8 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
INIT_LIST_HEAD(>vm_bound_list);
mutex_init(>vm_bind_lock);
INIT_LIST_HEAD(>non_priv_vm_bind_list);
+ INIT_LIST_HEAD(>vm_rebind_list);
+ spin_lock_init(>vm_rebind_lock);
}
void *__px_vaddr(struct drm_i915_gem_object *p)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index cb87d0e925c7..dbe6792df3e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -266,6 +266,10 @@ struct i915_address_space {
struct list_head vm_bind_list;
/** @vm_bound_list: List of vm_binding completed */
struct list_head vm_bound_list;
+ /** @vm_rebind_list: list of vmas to be rebinded */
+ struct list_head vm_rebind_list;
+ /** @vm_rebind_lock: protects vm_rebound_list */
+ spinlock_t vm_rebind_lock;
/** @va: tree of persistent vmas */
struct rb_root_cached va;
/** @non_priv_vm_bind_list: list of non-private object mappings */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 30f0c0aca007..353203bd5685 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -243,6 +243,7 @@ vma_create(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(>vm_bind_link);
INIT_LIST_HEAD(>non_priv_vm_bind_link);
+ INIT_LIST_HEAD(>vm_rebind_link);
return vma;
err_unlock:
@@ -1716,6 +1717,14 @@ static void force_unbind(struct i915_vma *vma)
if (!drm_mm_node_allocated(>node))
return;
+ /*
+* Persistent vma should have been purged by now.
+* If not, issue a warning and purge it.
+*/
+ if (GEM_WARN_ON(i915_vma_is_persistent(vma) &&
+ !i915_vma_is_purged(vma)))
+ i915_vma_set_purged(vma);
+
atomic_and(~I915_VMA_PIN_MASK, >flags);
WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(>node));
@@ -2082,6 +2091,16 @@ int __i915_vma_unbind(struct i915_vma *vma)
__i915_vma_evict(vma, false);
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
+
+ if (i915_vma_is_persistent(vma)) {
+ spin_lock(>vm->vm_rebind_lock);
+ if (list_empty(>vm_rebind_link) &&
+ !i915_vma_is_purged(vma))
+ list_add_tail(>vm_rebind_link,
+ >vm->vm_rebind_list);
+ spin_unlock(>vm->vm_rebind_lock);
+ }
+
return 0;
}
@@ -2116,6 +2135,15 @@ static struct dma_fence *__i915_vma_unbind_async(struct
i915_vma *vma)
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
+ if (i915_vma_is_persistent(vma)) {
+ spin_lock(>vm->vm_rebind_lock);
+ if (list_empty(>vm_rebind_link) &&
+ !i915_vma_is_purged(vma))
+ list_add_tail(>vm_rebind_link,
+ >vm->vm_rebind_list);
+ spin_unlock(>vm->vm_rebind_lock);
+ }
+
return fence;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.h
[PATCH v9 02/23] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_sw_fence.c | 28 +---
drivers/gpu/drm/i915/i915_sw_fence.h | 23 +--
2 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index cc2a8821d22a..ae06d35db056 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -7,7 +7,6 @@
#include
#include
#include
-#include
#include "i915_sw_fence.h"
#include "i915_selftest.h"
@@ -569,11 +568,26 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
return ret;
}
-int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
- struct dma_resv *resv,
- bool write,
- unsigned long timeout,
- gfp_t gfp)
+/**
+ * __i915_sw_fence_await_reservation() - Setup a fence to wait on a dma-resv
+ * object with specified usage.
+ * @fence: the fence that needs to wait
+ * @resv: dma-resv object
+ * @usage: dma_resv_usage (See enum dma_resv_usage)
+ * @timeout: how long to wait in jiffies
+ * @gfp: allocation mode
+ *
+ * Setup the @fence to asynchronously wait on dma-resv object @resv for
+ * @usage to complete before signaling.
+ *
+ * Returns 0 if there is nothing to wait on, -ve error code upon error
+ * and >0 upon successfully setting up the wait.
+ */
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp)
{
struct dma_resv_iter cursor;
struct dma_fence *f;
@@ -582,7 +596,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
*fence,
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
- dma_resv_iter_begin(, resv, dma_resv_usage_rw(write));
+ dma_resv_iter_begin(, resv, usage);
dma_resv_for_each_fence_unlocked(, f) {
pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
gfp);
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
b/drivers/gpu/drm/i915/i915_sw_fence.h
index f752bfc7c6e1..9c4859dc4c0d 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -10,13 +10,13 @@
#define _I915_SW_FENCE_H_
#include
+#include
#include
#include
#include /* for NOTIFY_DONE */
#include
struct completion;
-struct dma_resv;
struct i915_sw_fence;
enum i915_sw_fence_notify {
@@ -89,11 +89,22 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
unsigned long timeout,
gfp_t gfp);
-int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
- struct dma_resv *resv,
- bool write,
- unsigned long timeout,
- gfp_t gfp);
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp);
+
+static inline int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ bool write,
+ unsigned long timeout,
+ gfp_t gfp)
+{
+ return __i915_sw_fence_await_reservation(fence, resv,
+dma_resv_usage_rw(write),
+timeout, gfp);
+}
bool i915_sw_fence_await(struct i915_sw_fence *fence);
void i915_sw_fence_complete(struct i915_sw_fence *fence);
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 06/23] drm/i915/vm_bind: Implement bind and unbind of object
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
v2: On older platforms ctx->vm is not set, check for it.
In vm_bind call, add vma to vm_bind_list.
Add more input validity checks.
Update some documentation.
v3: In vm_bind call, add vma to vm_bound_list as user can
request a fence and pass to execbuf3 as input fence.
Remove short term pinning with PIN_VALIDATE flag.
v4: Replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode().
v5: Ensure all reserved fields are 0, use PIN_NOEVICT.
v6: Add reserved fields to drm_i915_gem_vm_bind.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 5 +
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 26 ++
.../drm/i915/gem/i915_gem_vm_bind_object.c| 330 ++
drivers/gpu/drm/i915/gt/intel_gtt.c | 10 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +
drivers/gpu/drm/i915/i915_driver.c| 3 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
drivers/gpu/drm/i915/i915_vma_types.h | 14 +
include/uapi/drm/i915_drm.h | 105 ++
11 files changed, 519 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index dfa211451a1d..0bd7de1883fb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -168,6 +168,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+ gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 899fa8f1e0fe..e8b41aa8f8c4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,21 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+/**
+ * i915_gem_vm_is_vm_bind_mode() - Check if address space is in vm_bind mode
+ * @vm: the address space
+ *
+ * Returns:
+ * true: @vm is in vm_bind mode; allows only vm_bind method of binding.
+ * false: @vm is not in vm_bind mode; allows only legacy execbuff method
+ *of binding.
+ */
+static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
+{
+ /* No support to enable vm_bind mode yet */
+ return false;
+}
+
struct i915_address_space *
i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 192bb3f10733..6456f15448bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -785,6 +785,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
+ if (ctx->vm && i915_gem_vm_is_vm_bind_mode(ctx->vm)) {
+ i915_gem_context_put(ctx);
+ return -EOPNOTSUPP;
+ }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..5064aba9ab87
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
[PATCH v9 13/23] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.
Legacy features like relocations etc are not supported by execbuf3.
v2: Add more input validity checks.
v3: batch_address is a VA (not an array) if num_batches=1,
minor cleanup
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()
v5: Remove unwanted krealloc() and address other review comments.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 579 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 +
drivers/gpu/drm/i915/i915_driver.c| 1 +
include/uapi/drm/i915_drm.h | 61 ++
5 files changed, 644 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bf3aa6e97ddd..2aa63287f3a9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -152,6 +152,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+ gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..49045858a3e9
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,579 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+
+#include
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+ DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+ 22; \
+})
+#endif
+
+/**
+ * DOC: User command execution in vm_bind mode
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * @args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ * @fences: array of execbuf fences (See struct eb_fence)
+ * @num_fences: number of fences in @fences array
+ */
+struct i915_execbuffer {
+ struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer3 *args;
+
+
[PATCH v9 03/23] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 18 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 005a7f842784..86469710bd59 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -15,10 +15,18 @@
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region **placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Returns the largest of min_page_size of the @placements,
+ * or I915_GTT_PAGE_SIZE_4K if @n_placements is 0.
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +36,6 @@ static u32 object_max_page_size(struct intel_memory_region
**placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
- GEM_BUG_ON(!max_page_size);
return max_page_size;
}
@@ -99,7 +106,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements, n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3db53769864c..5455ca0eabe9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
}
void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region **placements,
+ unsigned int n_placements);
void i915_objects_module_exit(void);
int i915_objects_module_init(void);
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 09/23] drm/i915/vm_bind: Support persistent vma activeness tracking
Do not use i915_vma activeness tracking for persistent vmas.
As persistent vmas are part of working set for each execbuf
submission on that address space (VM), a persistent vma is
active if the VM active. As vm->root_obj->base.resv will be
updated for each submission on that VM, it correctly
represent whether the VM is active or not.
Add i915_vm_is_active() and i915_vm_sync() functions based
on vm->root_obj->base.resv with DMA_RESV_USAGE_BOOKKEEP
usage. dma-resv fence list will be updated with this usage
during each submission with this VM in the new execbuf3
ioctl path.
Update i915_vma_is_active(), i915_vma_sync() and the
__i915_vma_unbind_async() functions to properly handle
persistent vmas.
v2: Ensure lvalue of dma_resv_wait_timeout() call is long.
Reviewed-by: Andi Shyti
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +++
drivers/gpu/drm/i915/i915_vma.c | 28 +
drivers/gpu/drm/i915/i915_vma.h | 25 +-
4 files changed, 83 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7bd1861ddbdf..1d8506548d4a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -25,6 +25,45 @@
#include "i915_trace.h"
#include "i915_vgpu.h"
+/**
+ * i915_vm_sync() - Wait until address space is not in use
+ * @vm: address space
+ *
+ * Waits until all requests using the address space are complete.
+ *
+ * Returns: 0 if success, -ve err code upon failure
+ */
+int i915_vm_sync(struct i915_address_space *vm)
+{
+ long ret;
+
+ /* Wait for all requests under this vm to finish */
+ ret = dma_resv_wait_timeout(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP, false,
+ MAX_SCHEDULE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+ else if (ret > 0)
+ return 0;
+ else
+ return -ETIMEDOUT;
+}
+
+/**
+ * i915_vm_is_active() - Check if address space is being used
+ * @vm: address space
+ *
+ * Check if any request using the specified address space is
+ * active.
+ *
+ * Returns: true if address space is active, false otherwise.
+ */
+bool i915_vm_is_active(const struct i915_address_space *vm)
+{
+ return !dma_resv_test_signaled(vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP);
+}
+
int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object *obj,
struct sg_table *pages)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 243419783052..e62b52c74586 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -52,4 +52,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
#define PIN_OFFSET_MASKI915_GTT_PAGE_MASK
+int i915_vm_sync(struct i915_address_space *vm);
+bool i915_vm_is_active(const struct i915_address_space *vm);
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 353203bd5685..c9527f1fdab9 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -422,6 +422,24 @@ int i915_vma_wait_for_bind(struct i915_vma *vma)
return err;
}
+/**
+ * i915_vma_sync() - Wait for the vma to be idle
+ * @vma: vma to be tested
+ *
+ * Returns 0 on success and error code on failure
+ */
+int i915_vma_sync(struct i915_vma *vma)
+{
+ int ret;
+
+ /* Wait for the asynchronous bindings and pending GPU reads */
+ ret = i915_active_wait(>active);
+ if (ret || !i915_vma_is_persistent(vma) || i915_vma_is_purged(vma))
+ return ret;
+
+ return i915_vm_sync(vma->vm);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
static int i915_vma_verify_bind_complete(struct i915_vma *vma)
{
@@ -1917,6 +1935,8 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
int err;
assert_object_held(obj);
+ if (i915_vma_is_persistent(vma))
+ return -EINVAL;
GEM_BUG_ON(!vma->pages);
@@ -2131,6 +2151,14 @@ static struct dma_fence *__i915_vma_unbind_async(struct
i915_vma *vma)
return ERR_PTR(-EBUSY);
}
+ if (i915_vma_is_persistent(vma) &&
+ __i915_sw_fence_await_reservation(>resource->chain,
+ vma->vm->root_obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP,
+ i915_fence_timeout(vma->vm->i915),
+ GFP_NOWAIT | __GFP_NOWARN) < 0)
+ return ERR_PTR(-EBUSY);
+
fence = __i915_vma_evict(vma, true);
drm_mm_remove_node(>node); /* pairs with i915_vma_release() */
diff --git
[PATCH v9 04/23] drm/i915/vm_bind: Support partially mapped vma resource
As persistent vmas can be partialled mapped to an object, remove restriction which require vma resource sg table to be just pointer to object's sg table. Reviewed-by: Matthew Auld Signed-off-by: Niranjana Vishwanathapura --- drivers/gpu/drm/i915/i915_vma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 34f0e6c923c2..79b2e19a299f 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -2060,8 +2060,7 @@ static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma) if (!drm_mm_node_allocated(>node)) return NULL; - if (i915_vma_is_pinned(vma) || - >obj->mm.rsgt->table != vma->resource->bi.pages) + if (i915_vma_is_pinned(vma)) return ERR_PTR(-EAGAIN); /* -- 2.21.0.rc0.32.g243a4c7e27
[PATCH v9 10/23] drm/i915/vm_bind: Add out fence support
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
v4: Return error if I915_TIMELINE_FENCE_WAIT fence flag is set.
Wait for bind to complete iff I915_TIMELINE_FENCE_SIGNAL is
not specified.
v5: Ensure __I915_TIMELINE_FENCE_UNKNOWN_FLAGS are not set.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
.../drm/i915/gem/i915_gem_vm_bind_object.c| 98 ++-
drivers/gpu/drm/i915/i915_vma.c | 7 +-
drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
include/uapi/drm/i915_drm.h | 58 ++-
5 files changed, 165 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@
#include
+struct dma_fence;
struct drm_device;
struct drm_file;
struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void
*data,
void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence);
+
#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index dc738677466b..fd1d82ce99e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@
#include
+#include
+
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_vm_bind.h"
@@ -101,6 +103,77 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
bool release_obj)
i915_gem_object_put(vma->obj);
}
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+ struct drm_syncobj *syncobj;
+
+ syncobj = drm_syncobj_find(file, handle);
+ if (!syncobj) {
+ drm_dbg(>vm->i915->drm,
+ "Invalid syncobj handle provided\n");
+ return -ENOENT;
+ }
+
+ /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+ if (point) {
+ vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+ if (!vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_put(syncobj);
+ return -ENOMEM;
+ }
+ } else {
+ vma->vm_bind_fence.chain_fence = NULL;
+ }
+ vma->vm_bind_fence.syncobj = syncobj;
+ vma->vm_bind_fence.value = point;
+
+ return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+ if (!vma->vm_bind_fence.syncobj)
+ return;
+
+ drm_syncobj_put(vma->vm_bind_fence.syncobj);
+ dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+ vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+ struct dma_fence * const fence)
+{
+ struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+ if (!syncobj)
+ return;
+
+ if (vma->vm_bind_fence.chain_fence) {
+ drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+ /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+ vma->vm_bind_fence.chain_fence = NULL;
+ } else {
+ drm_syncobj_replace_fence(syncobj, fence);
+ }
+}
+
static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
struct drm_i915_gem_vm_unbind *va)
{
@@ -206,6 +279,11 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
*vm,
if (!va->length || !IS_ALIGNED(va->start, I915_GTT_PAGE_SIZE))
ret = -EINVAL;
+ /* In fences are not supported */
+ if ((va->fence.flags & I915_TIMELINE_FENCE_WAIT) ||
+ (va->fence.flags & __I915_TIMELINE_FENCE_UNKNOWN_FLAGS))
+ ret = -EINVAL;
+
obj = i915_gem_object_lookup(file, va->handle);
if (!obj)
return -ENOENT;
@@ -238,6 +316,13 @@ static int
[PATCH v9 01/23] drm/i915/vm_bind: Expose vm lookup function
Make i915_gem_vm_lookup() function non-static as it will be
used by the vm_bind feature.
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ++-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 46e71f62fcec..b90901ad6866 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -346,7 +346,16 @@ static int proto_context_register(struct
drm_i915_file_private *fpriv,
return ret;
}
-static struct i915_address_space *
+/**
+ * i915_gem_vm_lookup() - looks up for the VM reference given the vm id
+ * @file_priv: the private data associated with the user's file
+ * @id: the VM id
+ *
+ * Finds the VM reference associated to a specific id.
+ *
+ * Returns the VM pointer on success, NULL in case of failure.
+ */
+struct i915_address_space *
i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e5b0f66ea1fe..899fa8f1e0fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -139,6 +139,9 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev,
void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+struct i915_address_space *
+i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id);
+
struct i915_gem_context *
i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id);
--
2.21.0.rc0.32.g243a4c7e27
[PATCH v9 00/23] drm/i915/vm_bind: Add VM_BIND functionality
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer objects (BOs) or sections of a BOs at specified GPU virtual addresses on a specified address space (VM). Multiple mappings can map to the same physical pages of an object (aliasing). These mappings (also referred to as persistent mappings) will be persistent across multiple GPU submissions (execbuf calls) issued by the UMD, without user having to provide a list of all required mappings during each submission (as required by older execbuf mode). This patch series support VM_BIND version 1, as described by the param I915_PARAM_VM_BIND_VERSION. Add new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any execlist support and all the legacy support like relocations etc., are removed. NOTEs: * It is based on below VM_BIND design+uapi rfc. Documentation/gpu/rfc/i915_vm_bind.rst * The IGT RFC series is posted as, [PATCH i-g-t v9 0/19] vm_bind: Add VM_BIND validation support v2: Address various review comments v3: Address review comments and other fixes v4: Remove vm_unbind out fence uapi which is not supported yet, replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode() v5: Render kernel-doc, use PIN_NOEVICT, limit vm_bind support to non-recoverable faults v6: Rebased, minor fixes, add reserved fields to drm_i915_gem_vm_bind, add new patch for async vm_unbind support v7: Rebased, minor cleanups as per review feedback v8: Rebased, add capture support v9: Address capture support feedback from v8 Test-with: 20221212231254.2303-1-niranjana.vishwanathap...@intel.com Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (23): drm/i915/vm_bind: Expose vm lookup function drm/i915/vm_bind: Add __i915_sw_fence_await_reservation() drm/i915/vm_bind: Expose i915_gem_object_max_page_size() drm/i915/vm_bind: Support partially mapped vma resource drm/i915/vm_bind: Add support to create persistent vma drm/i915/vm_bind: Implement bind and unbind of object drm/i915/vm_bind: Support for VM private BOs drm/i915/vm_bind: Add support to handle object evictions drm/i915/vm_bind: Support persistent vma activeness tracking drm/i915/vm_bind: Add out fence support drm/i915/vm_bind: Abstract out common execbuf functions drm/i915/vm_bind: Use common execbuf functions in execbuf path drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl drm/i915/vm_bind: Update i915_vma_verify_bind_complete() drm/i915/vm_bind: Expose i915_request_await_bind() drm/i915/vm_bind: Handle persistent vmas in execbuf3 drm/i915/vm_bind: userptr dma-resv changes drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode drm/i915/vm_bind: Render VM_BIND documentation drm/i915/vm_bind: Async vm_unbind support drm/i915/vm_bind: Properly build persistent map sg table drm/i915/vm_bind: Support capture of persistent mappings Documentation/gpu/i915.rst| 78 +- drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +- drivers/gpu/drm/i915/gem/i915_gem_context.h | 17 + drivers/gpu/drm/i915/gem/i915_gem_create.c| 72 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 6 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 522 +-- .../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 872 ++ .../drm/i915/gem/i915_gem_execbuffer_common.c | 671 ++ .../drm/i915/gem/i915_gem_execbuffer_common.h | 76 ++ drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 3 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 + drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 19 + drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 30 + .../drm/i915/gem/i915_gem_vm_bind_object.c| 463 ++ drivers/gpu/drm/i915/gt/intel_gtt.c | 22 + drivers/gpu/drm/i915/gt/intel_gtt.h | 28 + drivers/gpu/drm/i915/i915_driver.c| 4 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + drivers/gpu/drm/i915/i915_gem_gtt.h | 3 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 18 +- drivers/gpu/drm/i915/i915_sw_fence.c | 28 +- drivers/gpu/drm/i915/i915_sw_fence.h | 23 +- drivers/gpu/drm/i915/i915_vma.c | 308 ++- drivers/gpu/drm/i915/i915_vma.h | 70 +- drivers/gpu/drm/i915/i915_vma_types.h | 43 + include/uapi/drm/i915_drm.h | 281 +- 31 files changed, 3205 insertions(+), 552 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c create mode 100644
Re: [PATCH] drm/i915/gt: Reset twice
Hi Rodrigo,
On Mon, Dec 12, 2022 at 11:55:10AM -0500, Rodrigo Vivi wrote:
> On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> > From: Chris Wilson
> >
> > After applying an engine reset, on some platforms like Jasperlake, we
> > occasionally detect that the engine state is not cleared until shortly
> > after the resume. As we try to resume the engine with volatile internal
> > state, the first request fails with a spurious CS event (it looks like
> > it reports a lite-restore to the hung context, instead of the expected
> > idle->active context switch).
> >
> > Signed-off-by: Chris Wilson
>
> There's a typo in the signature email I'm afraid...
oh yes, I forgot the 'C' :)
> Other than that, have we checked the possibility of using the
> driver-initiated-flr bit
> instead of this second loop? That should be the right way to guarantee
> everything is
> cleared on gen11+...
maybe I am misinterpreting it, but is FLR the same as resetting
hardware domains individually?
How am I supposed to use driver_initiated_flr() in this context?
Thanks,
Andi
> > Cc: sta...@vger.kernel.org
> > Cc: Mika Kuoppala
> > Signed-off-by: Andi Shyti
> > ---
> > drivers/gpu/drm/i915/gt/intel_reset.c | 34 ++-
> > 1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > index ffde89c5835a4..88dfc0c5316ff 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > @@ -268,6 +268,7 @@ static int ilk_do_reset(struct intel_gt *gt,
> > intel_engine_mask_t engine_mask,
> > static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
> > {
> > struct intel_uncore *uncore = gt->uncore;
> > + int loops = 2;
> > int err;
> >
> > /*
> > @@ -275,18 +276,39 @@ static int gen6_hw_domain_reset(struct intel_gt *gt,
> > u32 hw_domain_mask)
> > * for fifo space for the write or forcewake the chip for
> > * the read
> > */
> > - intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
> > + do {
> > + intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
> >
> > - /* Wait for the device to ack the reset requests */
> > - err = __intel_wait_for_register_fw(uncore,
> > - GEN6_GDRST, hw_domain_mask, 0,
> > - 500, 0,
> > - NULL);
> > + /*
> > +* Wait for the device to ack the reset requests.
> > +*
> > +* On some platforms, e.g. Jasperlake, we see see that the
> > +* engine register state is not cleared until shortly after
> > +* GDRST reports completion, causing a failure as we try
> > +* to immediately resume while the internal state is still
> > +* in flux. If we immediately repeat the reset, the second
> > +* reset appears to serialise with the first, and since
> > +* it is a no-op, the registers should retain their reset
> > +* value. However, there is still a concern that upon
> > +* leaving the second reset, the internal engine state
> > +* is still in flux and not ready for resuming.
> > +*/
> > + err = __intel_wait_for_register_fw(uncore, GEN6_GDRST,
> > + hw_domain_mask, 0,
> > + 2000, 0,
> > + NULL);
> > + } while (err == 0 && --loops);
> > if (err)
> > GT_TRACE(gt,
> > "Wait for 0x%08x engines reset failed\n",
> > hw_domain_mask);
> >
> > + /*
> > +* As we have observed that the engine state is still volatile
> > +* after GDRST is acked, impose a small delay to let everything settle.
> > +*/
> > + udelay(50);
> > +
> > return err;
> > }
> >
> > --
> > 2.38.1
> >
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh wrote:
>
>
> On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
> > On 09/12/2022 02:22, Kuogee Hsieh wrote:
> >>
> >> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
> >>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>
> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
> > On 09/12/2022 00:36, Kuogee Hsieh wrote:
> >> Add both data-lanes and link-frequencies property into endpoint
> >>
> >> Changes in v7:
> >> -- split yaml out of dtsi patch
> >> -- link-frequencies from link rate to symbol rate
> >> -- deprecation of old data-lanes property
> >>
> >> Changes in v8:
> >> -- correct Bjorn mail address to kernel.org
> >>
> >> Changes in v10:
> >> -- add menu item to data-lanes and link-frequecnis
> >>
> >> Changes in v11:
> >> -- add endpoint property at port@1
> >>
> >> Signed-off-by: Kuogee Hsieh `
> >
> > Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
> > property
> > .git/rebase-apply/patch:47: trailing whitespace.
> >
> > .git/rebase-apply/patch:51: trailing whitespace.
> >
> >
> > Also the dt_binding_check fails with an error for this schema. And
> > after fixing the error in the schema I faced an example validation
> > error. Did you check that the schema is correct and that the
> > example validates against the schema?
>
> yes, but i run "make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
> at mu v5.15 branch since
> >>>
> >>> I wouldn't ask you to post the log here. But I don't think that
> >>> either of the errors that I see here is related to 5.15 vs 6.1-rc.
> >>>
> >>> In fact after applying this patch against 5.15 I saw the expected
> >>> failure:
> >>>
> >>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> >>> properties:required: ['port@0', 'port@1'] is not of type 'object',
> >>> 'boolean'
> >>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> >>> properties: 'required' should not be valid under {'$ref':
> >>> '#/definitions/json-schema-prop-names'}
> >>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> >>> ignoring, error in schema: properties: required
> >>>
>
> "make dt_binding_check" does not work at msm-next branch.
> >>>
> >>> I went ahead and just checked.
> >>>
> >>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
> >>> in msm-next and reports a single example-related warning in
> >>> msm-next-lumag. I pushed a patch to fix that warning (wich can
> >>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
> >>> that both these branches have consistent error-free display/msm
> >>> schemas.
> >>>
> >> I have clean msm-next branch (without my data-lines yaml patch
> >> applied) and run "make dt_binding_check
> >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
> >> then I saw below error messages.
> >>
> >> Have you run into this problem?
> >
> > No.
>
> Did you do anything to fix "older dtschema instance"?
I did not since I hadn't had such a problem. I can refer again to the
steps I provided you beforehand. The email was sent 6 days ago. No
answer from your side since that time.
> I had run "pip3 install dtschema --upgrade" and still not work.
Can you please post a full log of this command?
>
> D you know how to fix this problem?
>
> Thanks,
>
> kuogee
>
> sort: -:2: disorder: 2022.1
> ERROR: dtschema minimum version is v2022.3
> make[2]: *** [check_dtschema_version] Error 1
> make[1]: *** [dt_binding_check] Error 2
> make: *** [__sub-make] Error 2
Please add the output of:
which dt-validate
dt-validate -V
And also a full log of your failing kernel build.
> I had run "pip3 install dtschema --upgrade" according Rob Herring response.
> but it still shows same problem.
> Please let know how can I fix this problem.
>
> >
> >>
> >>HOSTCC scripts/basic/fixdep
> >>HOSTCC scripts/dtc/dtc.o
> >>HOSTCC scripts/dtc/flattree.o
> >>HOSTCC scripts/dtc/fstree.o
> >>HOSTCC scripts/dtc/data.o
> >>HOSTCC scripts/dtc/livetree.o
> >>HOSTCC scripts/dtc/treesource.o
> >>HOSTCC scripts/dtc/srcpos.o
> >>HOSTCC scripts/dtc/checks.o
> >>HOSTCC scripts/dtc/util.o
> >>LEX scripts/dtc/dtc-lexer.lex.c
> >>HOSTCC scripts/dtc/dtc-lexer.lex.o
> >>HOSTCC scripts/dtc/dtc-parser.tab.o
> >>HOSTLD scripts/dtc/dtc
> >> sort: -:2: disorder: 2022.1
> >> ERROR: dtschema minimum version is v2022.3
> >> make[2]: *** [check_dtschema_version] Error 1
> >> make[1]: *** [dt_binding_check] Error 2
> >> make: *** [__sub-make] Error 2
> >
> > This means that somewhere in your path you have an older dtschema
> > instance.
> >
> > When you sent me a question regarding this error, I asked for the
> > additional info. You provided none. Instead you went on sending the
> >
[PATCH v11 3/3] drm: exynos: dsi: Restore proper bridge chain order
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
Reviewed-by: Marek Vasut
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes for v11:
- add bridge.pre_enable_prev_first
Changes for v10:
- collect Marek review tag
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..9d10a89d28f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1428,7 +1428,8 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
{
struct exynos_dsi *dsi = bridge_to_dsi(bridge);
- return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
+ return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
+flags);
}
static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
@@ -1474,7 +1475,10 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
drm_bridge_add(>bridge);
- drm_bridge_attach(encoder, >bridge, NULL, 0);
+ drm_bridge_attach(encoder, >bridge,
+ list_first_entry_or_null(>bridge_chain,
+ struct drm_bridge,
+ chain_node), 0);
/*
* This is a temporary solution and should be made by more generic way.
@@ -1709,6 +1713,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
dsi->bridge.funcs = _dsi_bridge_funcs;
dsi->bridge.of_node = dev->of_node;
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
+ dsi->bridge.pre_enable_prev_first = true;
ret = component_add(dev, _dsi_component_ops);
if (ret)
--
2.25.1
[PATCH v11 2/3] drm/bridge: tc358764: Enable pre_enable_prev_first flag
From: Marek Szyprowski Enable the drm bridge pre_enable_prev_first flag so that the previous bridge pre_enable should be called first before the pre_enable for the tc358764 bridge is called. This makes sure that the previous bridge should be initialized properly before the tc358764 bridge is powered up. Signed-off-by: Marek Szyprowski Signed-off-by: Jagan Teki --- Changes for v11, v10: - none drivers/gpu/drm/bridge/tc358764.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c index 53259c12d777..f85654f1b104 100644 --- a/drivers/gpu/drm/bridge/tc358764.c +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -369,6 +369,7 @@ static int tc358764_probe(struct mipi_dsi_device *dsi) ctx->bridge.funcs = _bridge_funcs; ctx->bridge.of_node = dev->of_node; + ctx->bridge.pre_enable_prev_first = true; drm_bridge_add(>bridge); -- 2.25.1
[PATCH v11 1/3] drm: panel: Enable prepare_prev_first flag for samsung-s6e panels
Enable the drm panel prepare_prev_first flag so-that the previous
controller should be prepared first before the prepare for the
panel is called.
samsung-s6e3ha2, samsung-s6e63j0x03 and samsung-s6e8aa0 are the
effected samsung-s6e panels for this change.
This makes sure that the previous controller, likely to be a DSI
host controller should be initialized to LP-11 before the panel
is powered up.
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes for v11, v10:
- none
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 1 +
drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 5c621b15e84c..1355b2c27932 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -731,6 +731,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
drm_panel_add(>panel);
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index e06fd35de814..3223a9d06a50 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -462,6 +462,7 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel, dev, _funcs,
DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
ctx->bl_dev = backlight_device_register("s6e63j0x03", dev, ctx,
_bl_ops, NULL);
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
index 54213beafaf5..362eb10f10ce 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
@@ -1018,6 +1018,7 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
drm_panel_add(>panel);
--
2.25.1
[PATCH v11 0/3] drm: exynos: dsi: Restore the bridge chain
Split the Exynos DSI bridge chain update patches from Samsung DSIM bridge driver for easy to apply. Changes for v11: - enable bridge.pre_enable_prev_first Changes for v10: - collect Marek.V Review tag Any inputs? Jagan. Jagan Teki (2): drm: panel: Enable prepare_prev_first flag for samsung-s6e panels drm: exynos: dsi: Restore proper bridge chain order Marek Szyprowski (1): drm/bridge: tc358764: Enable pre_enable_prev_first flag drivers/gpu/drm/bridge/tc358764.c| 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +++-- drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 1 + drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 + drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 1 + 5 files changed, 11 insertions(+), 2 deletions(-) -- 2.25.1
[PATCH 13/16] drm/amd/display: Add support for explicit BT601_YCC
We use this by default but if userspace passes this explicitly we should respect it. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++ 1 file changed, 6 insertions(+) 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 5b347f8f4193..768c0c8fada1 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5175,6 +5175,12 @@ get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing, color_space = COLOR_SPACE_YCBCR601; } break; + case DRM_MODE_COLORIMETRY_BT601_YCC: + if (dc_crtc_timing->flags.Y_ONLY) + color_space = COLOR_SPACE_YCBCR601_LIMITED; + else + color_space = COLOR_SPACE_YCBCR601; + break; case DRM_MODE_COLORIMETRY_BT709_YCC: if (dc_crtc_timing->flags.Y_ONLY) color_space = COLOR_SPACE_YCBCR709_LIMITED; -- 2.38.1
[PATCH 14/16] drm/amd/display: Add debugfs for testing output colorspace
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 461037a3dd75..d95d1c9f4805 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -935,6 +935,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m,
void *data)
}
DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
+/*
+ * Returns the current bpc for the crtc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
+ */
+static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
+ struct dm_crtc_state *dm_crtc_state = NULL;
+ int res = -ENODEV;
+
+ mutex_lock(>mode_config.mutex);
+ drm_modeset_lock(>mutex, NULL);
+ if (crtc->state == NULL)
+ goto unlock;
+
+ dm_crtc_state = to_dm_crtc_state(crtc->state);
+ if (dm_crtc_state->stream == NULL)
+ goto unlock;
+
+ switch (dm_crtc_state->stream->output_color_space) {
+ case COLOR_SPACE_SRGB:
+ seq_printf(m, "RGB");
+ break;
+ case COLOR_SPACE_YCBCR601:
+ case COLOR_SPACE_YCBCR601_LIMITED:
+ seq_printf(m, "BT601_YCC");
+ break;
+ case COLOR_SPACE_YCBCR709:
+ case COLOR_SPACE_YCBCR709_LIMITED:
+ seq_printf(m, "BT709_YCC");
+ break;
+ case COLOR_SPACE_ADOBERGB:
+ seq_printf(m, "opRGB");
+ break;
+ case COLOR_SPACE_2020_RGB_FULLRANGE:
+ seq_printf(m, "BT2020_RGB");
+ break;
+ case COLOR_SPACE_2020_YCBCR:
+ seq_printf(m, "BT2020_YCC");
+ break;
+ default:
+ goto unlock;
+ }
+ res = 0;
+
+unlock:
+ drm_modeset_unlock(>mutex);
+ mutex_unlock(>mode_config.mutex);
+
+ return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
+
+
/*
* Example usage:
* Disable dsc passthrough, i.e.,: have dsc decoding at converver, not
external RX
@@ -3326,6 +3381,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
#endif
debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
crtc, _current_bpc_fops);
+ debugfs_create_file("amdgpu_current_colorspace", 0644,
crtc->debugfs_entry,
+ crtc, _current_colorspace_fops);
}
/*
--
2.38.1
[PATCH 11/16] drm/amd/display: Send correct DP colorspace infopacket
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 310388219f8c..8cf5a44d1d15 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5147,21 +5147,21 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
}
static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+ const struct drm_connector_state *connector_state)
{
enum dc_color_space color_space = COLOR_SPACE_SRGB;
- switch (dc_crtc_timing->pixel_encoding) {
- case PIXEL_ENCODING_YCBCR422:
- case PIXEL_ENCODING_YCBCR444:
- case PIXEL_ENCODING_YCBCR420:
- {
+ switch (connector_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+ if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
+ color_space = COLOR_SPACE_SRGB;
/*
* 27030khz is the separation point between HDTV and SDTV
* according to HDMI spec, we use YCbCr709 and YCbCr601
* respectively
*/
- if (dc_crtc_timing->pix_clk_100hz > 270300) {
+ } else if (dc_crtc_timing->pix_clk_100hz > 270300) {
if (dc_crtc_timing->flags.Y_ONLY)
color_space =
COLOR_SPACE_YCBCR709_LIMITED;
@@ -5174,15 +5174,21 @@ get_output_color_space(const struct dc_crtc_timing
*dc_crtc_timing)
else
color_space = COLOR_SPACE_YCBCR601;
}
-
- }
- break;
- case PIXEL_ENCODING_RGB:
- color_space = COLOR_SPACE_SRGB;
break;
-
- default:
- WARN_ON(1);
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ if (dc_crtc_timing->flags.Y_ONLY)
+ color_space = COLOR_SPACE_YCBCR709_LIMITED;
+ else
+ color_space = COLOR_SPACE_YCBCR709;
+ break;
+ case DRM_MODE_COLORIMETRY_OPRGB:
+ color_space = COLOR_SPACE_ADOBERGB;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ color_space = COLOR_SPACE_2020_YCBCR;
break;
}
@@ -5311,7 +5317,7 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
- stream->output_color_space = get_output_color_space(timing_out);
+ stream->output_color_space = get_output_color_space(timing_out,
connector_state);
stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
--
2.38.1
[PATCH 16/16] drm/amd/display: Don't restrict bpc to 8 bpc
This will let us pass kms_hdr.bpc_switch. I don't see any good reasons why we still need to limit bpc to 8 bpc and doing so is problematic when we enable HDR. If I remember correctly there might have been some displays out there where the advertised link bandwidth was not large enough to drive the default timing at max bpc. This would leave to an atomic commit/check failure which should really be handled in compositors with some sort of fallback mechanism. If this somehow turns out to still be an issue I suggest we add a module parameter to allow users to limit the max_bpc to a desired value. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 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 d0c071000a5d..396e345f5d6b 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7115,7 +7115,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm, drm_connector_attach_max_bpc_property(>base, 8, 16); /* This defaults to the max in the range, but we want 8bpc for non-edp. */ - aconnector->base.state->max_bpc = (connector_type == DRM_MODE_CONNECTOR_eDP) ? 16 : 8; + aconnector->base.state->max_bpc = 16; aconnector->base.state->max_requested_bpc = aconnector->base.state->max_bpc; if (connector_type == DRM_MODE_CONNECTOR_eDP && -- 2.38.1
[PATCH 09/16] drm/amd/display: Register Colorspace property for DP and HDMI
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
1 file changed, 15 insertions(+)
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 74cb0e200d90..67def042e9b4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7019,6 +7019,12 @@ static int amdgpu_dm_connector_get_modes(struct
drm_connector *connector)
return amdgpu_dm_connector->num_modes;
}
+static const u32 supported_colorspaces =
+ BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
+
void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
struct amdgpu_dm_connector *aconnector,
int connector_type,
@@ -7096,6 +7102,15 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.abm_level_property, 0);
}
+ if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
+ if
(!drm_mode_create_hdmi_colorspace_property(>base,
supported_colorspaces))
+
drm_connector_attach_colorspace_property(>base);
+ } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector_type == DRM_MODE_CONNECTOR_eDP) {
+ if (!drm_mode_create_dp_colorspace_property(>base,
supported_colorspaces))
+
drm_connector_attach_colorspace_property(>base);
+ }
+
if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
--
2.38.1
[PATCH 15/16] drm/amd/display: Add default case for output_color_space switch
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 768c0c8fada1..d0c071000a5d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5153,7 +5153,29 @@ get_output_color_space(const struct dc_crtc_timing
*dc_crtc_timing,
enum dc_color_space color_space = COLOR_SPACE_SRGB;
switch (connector_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT601_YCC:
+ if (dc_crtc_timing->flags.Y_ONLY)
+ color_space = COLOR_SPACE_YCBCR601_LIMITED;
+ else
+ color_space = COLOR_SPACE_YCBCR601;
+ break;
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ if (dc_crtc_timing->flags.Y_ONLY)
+ color_space = COLOR_SPACE_YCBCR709_LIMITED;
+ else
+ color_space = COLOR_SPACE_YCBCR709;
+ break;
+ case DRM_MODE_COLORIMETRY_OPRGB:
+ color_space = COLOR_SPACE_ADOBERGB;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ color_space = COLOR_SPACE_2020_YCBCR;
+ break;
case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+ default:
if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
color_space = COLOR_SPACE_SRGB;
/*
@@ -5175,27 +5197,6 @@ get_output_color_space(const struct dc_crtc_timing
*dc_crtc_timing,
color_space = COLOR_SPACE_YCBCR601;
}
break;
- case DRM_MODE_COLORIMETRY_BT601_YCC:
- if (dc_crtc_timing->flags.Y_ONLY)
- color_space = COLOR_SPACE_YCBCR601_LIMITED;
- else
- color_space = COLOR_SPACE_YCBCR601;
- break;
- case DRM_MODE_COLORIMETRY_BT709_YCC:
- if (dc_crtc_timing->flags.Y_ONLY)
- color_space = COLOR_SPACE_YCBCR709_LIMITED;
- else
- color_space = COLOR_SPACE_YCBCR709;
- break;
- case DRM_MODE_COLORIMETRY_OPRGB:
- color_space = COLOR_SPACE_ADOBERGB;
- break;
- case DRM_MODE_COLORIMETRY_BT2020_RGB:
- color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
- break;
- case DRM_MODE_COLORIMETRY_BT2020_YCC:
- color_space = COLOR_SPACE_2020_YCBCR;
- break;
}
return color_space;
--
2.38.1
[PATCH 04/16] drm/connector: Convert DRM_MODE_COLORIMETRY to enum
This allows us to use strongly typed arguments.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
include/drm/display/drm_dp.h | 2 +-
include/drm/drm_connector.h | 47 ++--
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 4d0abe4c7ea9..b98697459f9c 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1615,7 +1615,7 @@ enum dp_pixelformat {
*
* This enum is used to indicate DP VSC SDP Colorimetry formats.
* It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
- * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
+ * DB18] and a name of enum member follows drm_colorimetry definition.
*
* @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
* ITU-R BT.601 colorimetry format
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 62c814241828..edef65388c29 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -371,28 +371,29 @@ enum drm_privacy_screen_status {
* a colorspace property which will be created and exposed to
* userspace.
*/
-
-/* For Default case, driver will set the colorspace */
-#define DRM_MODE_COLORIMETRY_DEFAULT 0
-/* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC1
-#define DRM_MODE_COLORIMETRY_BT709_YCC 2
-/* CEA 861 Extended Colorimetry Options */
-#define DRM_MODE_COLORIMETRY_XVYCC_601 3
-#define DRM_MODE_COLORIMETRY_XVYCC_709 4
-#define DRM_MODE_COLORIMETRY_SYCC_601 5
-#define DRM_MODE_COLORIMETRY_OPYCC_601 6
-#define DRM_MODE_COLORIMETRY_OPRGB 7
-#define DRM_MODE_COLORIMETRY_BT2020_CYCC 8
-#define DRM_MODE_COLORIMETRY_BT2020_RGB9
-#define DRM_MODE_COLORIMETRY_BT2020_YCC10
-/* Additional Colorimetry extension added as part of CTA 861.G */
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D6511
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER12
-/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED13
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT14
-#define DRM_MODE_COLORIMETRY_BT601_YCC 15
+enum drm_colorspace {
+ /* For Default case, driver will set the colorspace */
+ DRM_MODE_COLORIMETRY_DEFAULT,
+ /* CEA 861 Normal Colorimetry options */
+ DRM_MODE_COLORIMETRY_SMPTE_170M_YCC,
+ DRM_MODE_COLORIMETRY_BT709_YCC,
+ /* CEA 861 Extended Colorimetry Options */
+ DRM_MODE_COLORIMETRY_XVYCC_601,
+ DRM_MODE_COLORIMETRY_XVYCC_709,
+ DRM_MODE_COLORIMETRY_SYCC_601,
+ DRM_MODE_COLORIMETRY_OPYCC_601,
+ DRM_MODE_COLORIMETRY_OPRGB,
+ DRM_MODE_COLORIMETRY_BT2020_CYCC,
+ DRM_MODE_COLORIMETRY_BT2020_RGB,
+ DRM_MODE_COLORIMETRY_BT2020_YCC,
+ /* Additional Colorimetry extension added as part of CTA 861.G */
+ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65,
+ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER,
+ /* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry
Format */
+ DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED,
+ DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT,
+ DRM_MODE_COLORIMETRY_BT601_YCC,
+};
/**
* enum drm_bus_flags - bus_flags info for _display_info
@@ -825,7 +826,7 @@ struct drm_connector_state {
* colorspace change on Sink. This is most commonly used to switch
* to wider color gamuts like BT2020.
*/
- u32 colorspace;
+ enum drm_colorspace colorspace;
/**
* @writeback_job: Writeback job for writeback connectors
--
2.38.1
[PATCH 05/16] drm/connector: Pull out common create_colorspace_property code
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c | 54 -
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 61c29ce74b03..ddba0b9fcc17 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1971,33 +1971,44 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* drm_mode_create_dp_colorspace_property() is used for DP connector.
*/
-/**
- * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
- * @connector: connector to create the Colorspace property on.
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * HDMI connectors.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+static int drm_mode_create_colorspace_property(struct drm_connector *connector,
+ const struct drm_prop_enum_list
*colorspaces,
+ int size)
{
struct drm_device *dev = connector->dev;
if (connector->colorspace_property)
return 0;
+ if (!colorspaces)
+ return 0;
+
connector->colorspace_property =
drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-hdmi_colorspaces,
-ARRAY_SIZE(hdmi_colorspaces));
+ colorspaces,
+ size);
if (!connector->colorspace_property)
return -ENOMEM;
return 0;
}
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+{
+ return drm_mode_create_colorspace_property(connector,
+ hdmi_colorspaces,
+
ARRAY_SIZE(hdmi_colorspaces));
+}
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
/**
@@ -2012,20 +2023,9 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
*/
int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
{
- struct drm_device *dev = connector->dev;
-
- if (connector->colorspace_property)
- return 0;
-
- connector->colorspace_property =
- drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-dp_colorspaces,
-ARRAY_SIZE(dp_colorspaces));
-
- if (!connector->colorspace_property)
- return -ENOMEM;
-
- return 0;
+ return drm_mode_create_colorspace_property(connector,
+ dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
}
EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
--
2.38.1
[PATCH 10/16] drm/amd/display: Set colorspace for HDMI infoframe
Now that we have the HDMI colorimetry fill the corresponding
AVI infoframe info. Also signal "mode_changed" if colorimetry
changed.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 ++-
1 file changed, 10 insertions(+), 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 67def042e9b4..310388219f8c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5282,6 +5282,7 @@ static void fill_stream_properties_from_drm_display_mode(
if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) {
drm_hdmi_avi_infoframe_from_display_mode(_frame, (struct
drm_connector *)connector, mode_in);
timing_out->vic = avi_frame.video_code;
+ drm_hdmi_avi_infoframe_colorimetry(_frame, connector_state);
drm_hdmi_vendor_infoframe_from_display_mode(_frame, (struct
drm_connector *)connector, mode_in);
timing_out->hdmi_vic = hv_frame.vic;
}
@@ -6476,6 +6477,14 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
if (!crtc)
return 0;
+ if (new_con_state->colorspace != old_con_state->colorspace) {
+ new_crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(new_crtc_state))
+ return PTR_ERR(new_crtc_state);
+
+ new_crtc_state->mode_changed = true;
+ }
+
if (!drm_connector_atomic_hdr_metadata_equal(old_con_state,
new_con_state)) {
struct dc_info_packet hdr_infopacket;
@@ -6498,7 +6507,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
* set is permissible, however. So only force a
* modeset if we're entering or exiting HDR.
*/
- new_crtc_state->mode_changed =
+ new_crtc_state->mode_changed = new_crtc_state->mode_changed ||
!old_con_state->hdr_output_metadata ||
!new_con_state->hdr_output_metadata;
}
--
2.38.1
[PATCH 12/16] drm/amd/display: Always set crtcinfo from create_stream_for_sink
From: Joshua Ashton Given that we always pass dm_state into here now, this won't ever trigger anymore. This is needed for we will always fail mode validation with invalid clocks or link bandwidth errors. Signed-off-by: Joshua Ashton Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 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 8cf5a44d1d15..5b347f8f4193 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5855,7 +5855,7 @@ create_stream_for_sink(struct amdgpu_dm_connector *aconnector, if (recalculate_timing) drm_mode_set_crtcinfo(_mode, 0); - else if (!dm_state) + else drm_mode_set_crtcinfo(, 0); /* -- 2.38.1
[PATCH 08/16] drm/amd/display: Always pass connector_state to stream validation
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0f391a147354..74cb0e200d90 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5761,15 +5761,14 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
{
struct drm_display_mode *preferred_mode = NULL;
struct drm_connector *drm_connector;
- const struct drm_connector_state *con_state =
- dm_state ? _state->base : NULL;
+ const struct drm_connector_state *con_state = _state->base;
struct dc_stream_state *stream = NULL;
struct drm_display_mode mode;
struct drm_display_mode saved_mode;
struct drm_display_mode *freesync_mode = NULL;
bool native_mode_found = false;
bool recalculate_timing = false;
- bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
+ bool scale = dm_state->scaling != RMX_OFF;
int mode_refresh;
int preferred_refresh = 0;
enum color_transfer_func tf = TRANSFER_FUNC_UNKNOWN;
@@ -6381,7 +6380,9 @@ enum drm_mode_status
amdgpu_dm_connector_mode_valid(struct drm_connector *connec
goto fail;
}
- stream = create_validate_stream_for_sink(aconnector, mode, NULL, NULL);
+ stream = create_validate_stream_for_sink(aconnector, mode,
+
to_dm_connector_state(connector->state),
+NULL);
if (stream) {
dc_stream_release(stream);
result = MODE_OK;
--
2.38.1
[PATCH 07/16] drm/connector: Print connector colorspace in state debugfs
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_atomic.c| 1 +
drivers/gpu/drm/drm_connector.c | 15 +++
include/drm/drm_connector.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0dc5858a723..d6d04c4ccfc0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1071,6 +1071,7 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
"(null)");
drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware);
drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
+ drm_printf(p, "\tcolorspace=%s\n",
drm_get_colorspace_name(state->colorspace));
if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0df5db3e4fec..2305eddcd0d4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1031,6 +1031,21 @@ static const char * const colorspace_names[] = {
[DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
};
+/**
+ * drm_get_color_encoding_name - return a string for color encoding
+ * @encoding: color encoding to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace)
+{
+ if (WARN_ON(colorspace >= ARRAY_SIZE(colorspace_names)))
+ return "unknown";
+
+ return colorspace_names[colorspace];
+}
+
static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5825c6ab969b..545eb6eb456a 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1906,6 +1906,7 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter);
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
/**
* drm_for_each_connector_iter - connector_list iterator macro
--
2.38.1
[PATCH 06/16] drm/connector: Allow drivers to pass list of supported colorspaces
Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.
Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_connector.c | 140 +-
.../gpu/drm/i915/display/intel_connector.c| 4 +-
drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
include/drm/drm_connector.h | 8 +-
4 files changed, 83 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ddba0b9fcc17..0df5db3e4fec 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1012,64 +1012,57 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
drm_dp_subconnector_enum_list)
-static const struct drm_prop_enum_list hdmi_colorspaces[] = {
- /* For Default case, driver will set the colorspace */
- { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
- /* Standard Definition Colorimetry based on CEA 861 */
- { DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
- { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
- /* Standard Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
- /* High Definition Colorimetry based on IEC 61966-2-4 */
- { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
- /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
- { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 [33] */
- { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
- /* Colorimetry based on ITU-R BT.2020 */
- { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
- /* Added as part of Additional Colorimetry Extension in 861.G */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
+static const char * const colorspace_names[] = {
+ [DRM_MODE_COLORIMETRY_DEFAULT] = "Default",
+ [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = "SMPTE_170M_YCC",
+ [DRM_MODE_COLORIMETRY_BT709_YCC] = "BT709_YCC",
+ [DRM_MODE_COLORIMETRY_XVYCC_601] = "XVYCC_601",
+ [DRM_MODE_COLORIMETRY_XVYCC_709] = "XVYCC_709",
+ [DRM_MODE_COLORIMETRY_SYCC_601] = "SYCC_601",
+ [DRM_MODE_COLORIMETRY_OPYCC_601] = "opYCC_601",
+ [DRM_MODE_COLORIMETRY_OPRGB] = "opRGB",
+ [DRM_MODE_COLORIMETRY_BT2020_CYCC] = "BT2020_CYCC",
+ [DRM_MODE_COLORIMETRY_BT2020_RGB] = "BT2020_RGB",
+ [DRM_MODE_COLORIMETRY_BT2020_YCC] = "BT2020_YCC",
+ [DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65] = "P3_RGB_D65",
+ [DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER] = "P3_RGB_Theater",
+ [DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED] = "RGB_WIDE_FIXED",
+ [DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT] = "RGB_WIDE_FLOAT",
+ [DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
};
+static const u32 hdmi_colorspaces =
+ BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
+ BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
+ BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
+ BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
+ BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
+ BIT(DRM_MODE_COLORIMETRY_BT2020_YCC) |
+ BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
+ BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry
* Format Table 2-120
*/
-static const struct drm_prop_enum_list dp_colorspaces[] = {
- /* For Default case, driver will set the colorspace */
- { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
- { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
- /* Colorimetry based on scRGB (IEC 61966-2-2) */
- { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, "RGB_Wide_Gamut_Floating_Point"
},
- /* Colorimetry based on IEC 61966-2-5 */
- { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- /* Colorimetry based on SMPTE RP 431-2 */
- { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
[PATCH 03/16] drm/connector: Drop COLORIMETRY_NO_DATA
The value is the same as DEFAULT. The HDMI_COLORIMETRY_NO_DATA
makes sense for the infopacket but it's meaningless for the
connector colorspace. or, in otherwise, just means to go with
driver default.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/display/drm_hdmi_helper.c | 2 +-
include/drm/drm_connector.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
b/drivers/gpu/drm/display/drm_hdmi_helper.c
index faf5e9efa7d3..c1e6851b2606 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -103,7 +103,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER(C(3) | EC(7) | ACE(1))
static const u32 hdmi_colorimetry_val[] = {
- [DRM_MODE_COLORIMETRY_NO_DATA] = HDMI_COLORIMETRY_NO_DATA,
+ [DRM_MODE_COLORIMETRY_DEFAULT] = HDMI_COLORIMETRY_NO_DATA,
[DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = HDMI_COLORIMETRY_SMPTE_170M_YCC,
[DRM_MODE_COLORIMETRY_BT709_YCC] = HDMI_COLORIMETRY_BT709_YCC,
[DRM_MODE_COLORIMETRY_XVYCC_601] = HDMI_COLORIMETRY_XVYCC_601,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4d830fc55a3d..62c814241828 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -375,7 +375,6 @@ enum drm_privacy_screen_status {
/* For Default case, driver will set the colorspace */
#define DRM_MODE_COLORIMETRY_DEFAULT 0
/* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_NO_DATA 0
#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC1
#define DRM_MODE_COLORIMETRY_BT709_YCC 2
/* CEA 861 Extended Colorimetry Options */
--
2.38.1
[PATCH 01/16] drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
The EDID of an HDR display defines EOTFs that are supported
by the display and can be set in the HDR metadata infoframe.
Userspace is expected to read the EDID and set an appropriate
HDR_OUTPUT_METADATA.
In drm_parse_hdr_metadata_block the kernel reads the supported
EOTFs from the EDID and stores them in the
drm_connector->hdr_sink_metadata. While doing so it also
filters the EOTFs to the EOTFs the kernel knows about.
When an HDR_OUTPUT_METADATA is set it then checks to
make sure the EOTF is a supported EOTF. In cases where
the kernel doesn't know about a new EOTF this check will
fail, even if the EDID advertises support.
Since it is expected that userspace reads the EDID to understand
what the display supports it doesn't make sense for DRM to block
an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
understand.
This comes with the added benefit of future-proofing metadata
support. If the spec defines a new EOTF there is no need to
update DRM and an compositor can immediately make use of it.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/609
v2: Distinguish EOTFs defind in kernel and ones defined
in EDID in the commit description (Pekka)
v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved
to drm_hdmi_helper.c
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Acked-by: Pekka Paalanen
---
drivers/gpu/drm/display/drm_hdmi_helper.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
b/drivers/gpu/drm/display/drm_hdmi_helper.c
index 0264abe55278..faf5e9efa7d3 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -44,10 +44,8 @@ int drm_hdmi_infoframe_set_hdr_metadata(struct
hdmi_drm_infoframe *frame,
/* Sink EOTF is Bit map while infoframe is absolute values */
if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
- connector->hdr_sink_metadata.hdmi_type1.eotf)) {
- DRM_DEBUG_KMS("EOTF Not Supported\n");
- return -EINVAL;
- }
+ connector->hdr_sink_metadata.hdmi_type1.eotf))
+ DRM_DEBUG_KMS("Unknown EOTF %d\n",
hdr_metadata->hdmi_metadata_type1.eotf);
err = hdmi_drm_infoframe_init(frame);
if (err < 0)
--
2.38.1
[PATCH 02/16] drm/connector: print max_requested_bpc in state debugfs
This is useful to understand the bpc defaults and support of a driver. Signed-off-by: Harry Wentland Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org --- drivers/gpu/drm/drm_atomic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index f197f59f6d99..c0dc5858a723 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1070,6 +1070,7 @@ static void drm_atomic_connector_print_state(struct drm_printer *p, drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector->name); drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : "(null)"); drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware); + drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc); if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) if (state->writeback_job && state->writeback_job->fb) -- 2.38.1
[PATCH 00/16] Enable Colorspace connector property in amdgpu
This patchset enables the DP and HDMI infoframe properties in amdgpu. The first two patches are not completely related to the rest. The first patch allows for HDR_OUTPUT_METADATA with EOTFs that are unknown in the kernel. The second one prints a connector's max_bpc as part of the atomic state debugfs print. The following patches rework the connector colorspace code to 1) allow for easy printing of the colorspace in the drm_atomic state debugfs, and 2) allow drivers to specify the supported colorspaces on a connector. The rest of the patches deal with the Colorspace enablement in amdgpu. Since the Colorspace property didn't have an IGT test I added one to kms_hdr. The relevant patchset can be found on the IGT mailing list or on https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/hdr-colorimetry Since I don't have a DP and HDMI analyzer I could not test this end-to-end but someone will test it in the coming days. We'll refrain from merging this until we can confirm the DP/HDMI analyzer shows the correct infoframe. Cc: Pekka Paalanen Cc: Sebastian Wick Cc: vitaly.pros...@amd.com Cc: Uma Shankar Cc: Ville Syrjälä Cc: Joshua Ashton Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Harry Wentland (15): drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF drm/connector: print max_requested_bpc in state debugfs drm/connector: Drop COLORIMETRY_NO_DATA drm/connector: Convert DRM_MODE_COLORIMETRY to enum drm/connector: Pull out common create_colorspace_property code drm/connector: Allow drivers to pass list of supported colorspaces drm/connector: Print connector colorspace in state debugfs drm/amd/display: Always pass connector_state to stream validation drm/amd/display: Register Colorspace property for DP and HDMI drm/amd/display: Set colorspace for HDMI infoframe drm/amd/display: Send correct DP colorspace infopacket drm/amd/display: Add support for explicit BT601_YCC drm/amd/display: Add debugfs for testing output colorspace drm/amd/display: Add default case for output_color_space switch drm/amd/display: Don't restrict bpc to 8 bpc Joshua Ashton (1): drm/amd/display: Always set crtcinfo from create_stream_for_sink .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 86 ++--- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 ++ drivers/gpu/drm/display/drm_hdmi_helper.c | 8 +- drivers/gpu/drm/drm_atomic.c | 2 + drivers/gpu/drm/drm_connector.c | 181 ++ .../gpu/drm/i915/display/intel_connector.c| 4 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- include/drm/display/drm_dp.h | 2 +- include/drm/drm_connector.h | 57 +++--- 9 files changed, 261 insertions(+), 138 deletions(-) -- 2.38.1
Re: [PATCH v8 21/22] drm/i915/vm_bind: Properly build persistent map sg table
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
support requires this for page backed regions.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 120 +++-
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 1b9033865768..68a9ac77b4f2 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1298,6 +1298,120 @@ intel_partial_pages(const struct i915_gtt_view *view,
return ERR_PTR(ret);
}
+static unsigned int
+intel_copy_dma_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+ struct scatterlist *dst_sg, *src_sg;
+ unsigned int i, len, nents = 0;
+
+ dst_sg = dst_st->sgl;
+ for_each_sgtable_dma_sg(src_st, src_sg, i) {
+ if (sg_dma_len(src_sg) <= offset) {
+ offset -= sg_dma_len(src_sg);
+ continue;
+ }
+
+ nents++;
+ len = min(sg_dma_len(src_sg) - offset, length);
+ if (!dry_run) {
+ sg_dma_address(dst_sg) = sg_dma_address(src_sg) +
offset;
+ sg_dma_len(dst_sg) = len;
+ dst_sg = sg_next(dst_sg);
+ }
+
+ length -= len;
+ offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static unsigned int
+intel_copy_sg(struct sg_table *src_st, struct sg_table *dst_st,
+ u64 offset, u64 length, bool dry_run)
+{
+ struct scatterlist *dst_sg, *src_sg;
+ unsigned int i, len, nents = 0;
+
+ dst_sg = dst_st->sgl;
+ for_each_sgtable_sg(src_st, src_sg, i) {
+ if (src_sg->length <= offset) {
+ offset -= src_sg->length;
+ continue;
+ }
+
+ nents++;
+ len = min(src_sg->length - offset, length);
+ if (!dry_run) {
+ unsigned long pfn;
+
+ pfn = page_to_pfn(sg_page(src_sg)) + offset / PAGE_SIZE;
+ sg_set_page(dst_sg, pfn_to_page(pfn), len, 0);
+ dst_sg = sg_next(dst_sg);
+ }
+
+ length -= len;
+ offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static noinline struct sg_table *
+intel_persistent_partial_pages(const struct i915_gtt_view *view,
+ struct drm_i915_gem_object *obj)
+{
+ u64 offset = view->partial.offset << PAGE_SHIFT;
+ struct sg_table *st, *obj_st = obj->mm.pages;
+ u64 length = view->partial.size << PAGE_SHIFT;
+ struct scatterlist *sg;
+ unsigned int nents;
+ int ret = -ENOMEM;
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ goto err_st_alloc;
+
+ /* Get required sg_table size */
+ nents = intel_copy_dma_sg(obj_st, st, offset, length, true);
+ if (i915_gem_object_has_struct_page(obj)) {
+ unsigned int pg_nents;
+
+ pg_nents = intel_copy_sg(obj_st, st, offset, length, true);
+ if (nents < pg_nents)
+ nents = pg_nents;
+ }
+
+ ret = sg_alloc_table(st, nents, GFP_KERNEL);
+ if (ret)
+ goto err_sg_alloc;
+
+ /* Build sg_table for specified section */
+ intel_copy_dma_sg(obj_st, st, offset, length, false);
+ if (i915_gem_object_has_struct_page(obj))
+ intel_copy_sg(obj_st, st, offset, length, false);
+
+ /* Mark last sg */
+ sg = st->sgl;
+ while (sg_next(sg))
+ sg = sg_next(sg);
+ sg_mark_end(sg);
Do we need this bit? The nents is exactly orig_nents, and sg_alloc_table
will already mark the end for you.
Is it not possible to re-use remap_contiguous_pages() somehow? Also do
we need the dry_run bit if we use sg_trim()? Maybe something like:
dst = sg_alloc_table(partial.size);
remap_contigious_pages_sg(dst, src);
i915_sg_trim(dst);
dst->nents = 0;
sg = remap_contigious_pages_dma_sg(dst, src);
+
+ return st;
+
+err_sg_alloc:
+ kfree(st);
+err_st_alloc:
+ return ERR_PTR(ret);
+}
+
static int
__i915_vma_get_pages(struct i915_vma *vma)
{
@@ -1330,7 +1444,11 @@ __i915_vma_get_pages(struct i915_vma *vma)
break;
case I915_GTT_VIEW_PARTIAL:
- pages = intel_partial_pages(>gtt_view, vma->obj);
+ if (i915_vma_is_persistent(vma))
+
Re: [PATCH v11 2/5] dt-bindings: msm/dp: add data-lanes and link-frequencies property
On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
On 09/12/2022 02:22, Kuogee Hsieh wrote:
On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
On 09/12/2022 01:38, Kuogee Hsieh wrote:
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
On 09/12/2022 00:36, Kuogee Hsieh wrote:
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh `
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And
after fixing the error in the schema I faced an example validation
error. Did you check that the schema is correct and that the
example validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
at mu v5.15 branch since
I wouldn't ask you to post the log here. But I don't think that
either of the errors that I see here is related to 5.15 vs 6.1-rc.
In fact after applying this patch against 5.15 I saw the expected
failure:
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties:required: ['port@0', 'port@1'] is not of type 'object',
'boolean'
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
ignoring, error in schema: properties: required
"make dt_binding_check" does not work at msm-next branch.
I went ahead and just checked.
`make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
in msm-next and reports a single example-related warning in
msm-next-lumag. I pushed a patch to fix that warning (wich can
hopefully be picked up by Abhinav into msm-fixes). So you can assume
that both these branches have consistent error-free display/msm
schemas.
I have clean msm-next branch (without my data-lines yaml patch
applied) and run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
then I saw below error messages.
Have you run into this problem?
No.
Did you do anything to fix "older dtschema instance"?
I had run "pip3 install dtschema --upgrade" according Rob Herring response.
but it still shows same problem.
Please let know how can I fix this problem.
HOSTCC scripts/basic/fixdep
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
HOSTCC scripts/dtc/dtc-lexer.lex.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
sort: -:2: disorder: 2022.1
ERROR: dtschema minimum version is v2022.3
make[2]: *** [check_dtschema_version] Error 1
make[1]: *** [dt_binding_check] Error 2
make: *** [__sub-make] Error 2
This means that somewhere in your path you have an older dtschema
instance.
When you sent me a question regarding this error, I asked for the
additional info. You provided none. Instead you went on sending the
untested patch that doesn't work.
since i can not test it on msm-next so that I did test it at my v5-15
branch.
besides, i think i have to sent the whole series patches include this
one to address your new comments on other patch.
is this correct?
But I did not check trainiling whitespace this time.
---
.../bindings/display/msm/dp-controller.yaml | 27
++
1 file changed, 27 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
---
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+
Re: [PATCH v7 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support
On 12/9/2022 2:39 AM, Bjorn Andersson wrote:
> On Thu, Dec 08, 2022 at 08:54:39PM +0530, Akhil P Oommen wrote:
>> On 12/7/2022 9:16 PM, Ulf Hansson wrote:
>>> On Wed, 5 Oct 2022 at 11:08, Akhil P Oommen
>>> wrote:
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
>>> Would you mind extending this commit message, to allow us to better
>>> understand what part is really the consumer part.
>> Sure. I can do that.
>>> I was expecting the consumer part to be the GPU (adreno) driver, but I
>>> may have failed to understand correctly. It would be nice to see an
>>> example of a typical sequence, where the reset is being
>>> asserted/deasserted, from the consumer point of view. Would you mind
>>> explaining this a bit more?
>> https://elixir.bootlin.com/linux/v6.1-rc8/source/drivers/gpu/drm/msm/adreno/a6xx_gpu.c#L1309
>> You are correct. The consumer is adreno gpu driver. When there is a gpu
>> fault, these sequences are followed:
>> 1. drop pm_runtime_put() for gpu device which will drops its vote on 'cx'
>> genpd. line: 1306
>> 2. At this point, there could be vote from either smmu driver (smmu is under
>> same power domain too) or from other subsystems (tz/hyp).
> Can you confirm that this is happening completely independent of what
> the kernel does?
Yes, it is independent.
>
>> 3. So we call into gdsc driver through reset interface to poll the gdsc
>> register to ensure it collapsed at least once. Line: 1309
> I other words, if we engineered 1. such that it would wait in
> gdsc_disable() until the condition for 3. is reached, that should work
> for you? (Obviously depending on the ability for us to engineer this...)
Yes, it will work.
-Akhil.
>
> Regards,
> Bjorn
>
>> 4. Then we turn ON gpu. line:1314.
>>
>> -Akhil.
Signed-off-by: Akhil P Oommen
Reviewed-by: Dmitry Baryshkov
>>> Kind regards
>>> Uffe
>>>
---
(no changes since v3)
Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const'
(Krzysztof)
Changes in v2:
- Minor update to use the updated custom reset ops implementation
drivers/clk/qcom/gpucc-sc7280.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/qcom/gpucc-sc7280.c
b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..fece3f4 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,22 @@ static const struct regmap_config
gpu_cc_sc7280_regmap_config = {
.fast_io = true,
};
+static const struct qcom_reset_ops cx_gdsc_reset = {
+ .reset = gdsc_wait_for_collapse,
+};
+
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+ [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
+};
+
static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
.config = _cc_sc7280_regmap_config,
.clks = gpu_cc_sc7280_clocks,
.num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
.gdscs = gpu_cc_sc7180_gdscs,
.num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+ .resets = gpucc_sc7280_resets,
+ .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
};
static const struct of_device_id gpu_cc_sc7280_match_table[] = {
--
2.7.4
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On 12/12/2022 9:09 PM, Ulf Hansson wrote: > On Fri, 9 Dec 2022 at 18:36, Ulf Hansson wrote: >> On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote: >>> On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote: On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote: > On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote: >> On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson >> wrote: >>> On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: >>> @Ulf, Akhil has a power-domain for a piece of hardware which may be >>> voted active by multiple different subsystems (co-processors/execution >>> contexts) in the system. >>> >>> As such, during the powering down sequence we don't wait for the >>> power-domain to turn off. But in the event of an error, the recovery >>> mechanism relies on waiting for the hardware to settle in a powered off >>> state. >>> >>> The proposal here is to use the reset framework to wait for this state >>> to be reached, before continuing with the recovery mechanism in the >>> client driver. >> I tried to review the series (see my other replies), but I am not sure >> I fully understand the consumer part. >> >> More exactly, when and who is going to pull the reset and at what point? >> >>> Given our other discussions on quirky behavior, do you have any >>> input/suggestions on this? >>> Some clients like adreno gpu driver would like to ensure that its gdsc is collapsed at hardware during a gpu reset sequence. This is because it has a votable gdsc which could be ON due to a vote from another subsystem like tz, hyp etc or due to an internal hardware signal. To allow this, gpucc driver can expose an interface to the client driver using reset framework. Using this the client driver can trigger a polling within the gdsc driver. >>> @Akhil, this description is fairly generic. As we've reached the state >>> where the hardware has settled and we return to the client, what >>> prevents it from being powered up again? >>> >>> Or is it simply a question of it hitting the powered-off state, not >>> necessarily staying there? >> Okay, so it's indeed the GPU driver that is going to assert/de-assert >> the reset at some point. Right? >> >> That seems like a reasonable approach to me, even if it's a bit >> unclear under what conditions that could happen. >> > Generally the disable-path of the power-domain does not check that the > power-domain is actually turned off, because the status might indicate > that the hardware is voting for the power-domain to be on. Is there a good reason why the HW needs to vote too, when the GPU driver is already in control? Or perhaps that depends on the running use case? > As part of the recovery of the GPU after some fatal fault, the GPU > driver does something which will cause the hardware votes for the > power-domain to be let go, and then the driver does pm_runtime_put(). Okay. That "something", sounds like a device specific setting for the corresponding gdsc, right? So somehow the GPU driver needs to manage that setting, right? > But in this case the GPU driver wants to ensure that the power-domain is > actually powered down, before it does pm_runtime_get() again. To ensure > that the hardware lost its state... I see. > The proposal here is to use a reset to reach into the power-domain > provider and wait for the hardware to be turned off, before the GPU > driver attempts turning the power-domain on again. > > > In other words, there is no reset. This is a hack to make a normally > asynchronous pd.power_off() to be synchronous in this particular case. Alright, assuming I understood your clarifications above correctly (thanks!), I think I have got a much better picture now. Rather than abusing the reset interface, I think we should manage this through the genpd's power on/off notifiers (GENPD_NOTIFY_OFF). The GPU driver should register its corresponding device for them (dev_pm_genpd_add_notifier()). The trick however, is to make the behaviour of the power-domain for the gdsc (the genpd->power_off() callback) conditional on whether the HW is configured to vote or not. If the HW can vote, it should not poll for the state - and vice versa when the HW can't vote. >>> Per Akhil's description I misunderstood who the other voters are; but >>> either way it's not the same "HW configured" mechanism as the one we're >>> already discussing. >> Okay, so this is another thing then. >> >>> >>> But if we based on similar means could control if the power_off() ops >>> should be blocking, waiting for the status indication to show that the >>> hardware
Re: [PATCH] drm/bridge: anx7625: keep last configure timing
On Fri, 9 Dec 2022 11:04:18 +0800, Xin Ji wrote: > Sometimes kernel may resume back quickly after suspend, > and DRM not call .mode_set() to re-config > display timing before calling .atomic_enable(), bridge > driver with this patch to keep last configure timing. > > Applied, thanks! Repo: https://cgit.freedesktop.org/drm/drm-misc/ [1/1] drm/bridge: anx7625: keep last configure timing commit: 38c8389011e06f16b365799f2cd958536befc2e9 rob
Re: [PATCH] drm/i915/gt: Reset twice
On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> From: Chris Wilson
>
> After applying an engine reset, on some platforms like Jasperlake, we
> occasionally detect that the engine state is not cleared until shortly
> after the resume. As we try to resume the engine with volatile internal
> state, the first request fails with a spurious CS event (it looks like
> it reports a lite-restore to the hung context, instead of the expected
> idle->active context switch).
>
> Signed-off-by: Chris Wilson
There's a typo in the signature email I'm afraid...
Other than that, have we checked the possibility of using the
driver-initiated-flr bit
instead of this second loop? That should be the right way to guarantee
everything is
cleared on gen11+...
> Cc: sta...@vger.kernel.org
> Cc: Mika Kuoppala
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 34 ++-
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index ffde89c5835a4..88dfc0c5316ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -268,6 +268,7 @@ static int ilk_do_reset(struct intel_gt *gt,
> intel_engine_mask_t engine_mask,
> static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
> {
> struct intel_uncore *uncore = gt->uncore;
> + int loops = 2;
> int err;
>
> /*
> @@ -275,18 +276,39 @@ static int gen6_hw_domain_reset(struct intel_gt *gt,
> u32 hw_domain_mask)
>* for fifo space for the write or forcewake the chip for
>* the read
>*/
> - intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
> + do {
> + intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
>
> - /* Wait for the device to ack the reset requests */
> - err = __intel_wait_for_register_fw(uncore,
> -GEN6_GDRST, hw_domain_mask, 0,
> -500, 0,
> -NULL);
> + /*
> + * Wait for the device to ack the reset requests.
> + *
> + * On some platforms, e.g. Jasperlake, we see see that the
> + * engine register state is not cleared until shortly after
> + * GDRST reports completion, causing a failure as we try
> + * to immediately resume while the internal state is still
> + * in flux. If we immediately repeat the reset, the second
> + * reset appears to serialise with the first, and since
> + * it is a no-op, the registers should retain their reset
> + * value. However, there is still a concern that upon
> + * leaving the second reset, the internal engine state
> + * is still in flux and not ready for resuming.
> + */
> + err = __intel_wait_for_register_fw(uncore, GEN6_GDRST,
> +hw_domain_mask, 0,
> +2000, 0,
> +NULL);
> + } while (err == 0 && --loops);
> if (err)
> GT_TRACE(gt,
>"Wait for 0x%08x engines reset failed\n",
>hw_domain_mask);
>
> + /*
> + * As we have observed that the engine state is still volatile
> + * after GDRST is acked, impose a small delay to let everything settle.
> + */
> + udelay(50);
> +
> return err;
> }
>
> --
> 2.38.1
>
Re: [PATCH v2] drm/display: Add missing Adaptive Sync DPCD definitions
On 12/9/22 17:00, Sung Joon Kim wrote: > The missing DPCD defintions from DP2.0 spec is as follows: > > DOWNSPREAD_CTRL (107h): > FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (bit 6) > For sink devices that support Adaptive-Sync operation > and Panel Replay > > DPRX_FEATURE_ENUMERATION_LIST_CONT_1 (2214h): > ADAPTIVE_SYNC_SDP_SUPPORTED (bit 0) > Bit to check sink device has Adaptive-Sync capability > AS_SDP_FIRST_HALF_LINE_OR_3840_PIXEL_CYCLE_WINDOW_NOT_SUPPORTED (bit 1) > A sink device that clears this bit will generate VSync pulse > leading edge of the HDMI output on the line count at which > Adaptive-Sync SDP is received as long as source device transmits > Adaptive-Sync SDP either in first line or first 3840 pixel > cycles > of the line whichever occurs first. > VSC_EXT_SDP_FRAMEWORK_VERSION_1_SUPPORTED (bit 4) > Bit to check sink device has SDP framework version 1 capability You're missing your Signed-off-by. Make sure to add it before pushing. With that fixed this is: Reviewed-by: Harry Wentland Harry > --- > include/drm/display/drm_dp.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 4d0abe4c7ea9..1bd6f9af0b46 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -603,6 +603,7 @@ > > #define DP_DOWNSPREAD_CTRL 0x107 > # define DP_SPREAD_AMP_0_5 (1 << 4) > +# define DP_FIXED_VTOTAL_AS_SDP_EN_IN_PR_ACTIVE (1 << 6) > # define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) /* eDP */ > > #define DP_MAIN_LINK_CHANNEL_CODING_SET 0x108 > @@ -1105,6 +1106,11 @@ > # define DP_VSC_EXT_CEA_SDP_SUPPORTED(1 << 6) /* DP > 1.4 */ > # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP > 1.4 */ > > +#define DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1 0x2214 /* 2.0 E11 */ > +# define DP_ADAPTIVE_SYNC_SDP_SUPPORTED(1 << 0) > +# define DP_AS_SDP_FIRST_HALF_LINE_OR_3840_PIXEL_CYCLE_WINDOW_NOT_SUPPORTED > (1 << 1) > +# define DP_VSC_EXT_SDP_FRAMEWORK_VERSION_1_SUPPORTED (1 << 4) > + > #define DP_128B132B_SUPPORTED_LINK_RATES 0x2215 /* 2.0 */ > # define DP_UHBR10 (1 << 0) > # define DP_UHBR20 (1 << 1)
Re: [PATCH] drm/i915/hwconfig: Modify mismatched function name
On Mon, Dec 12, 2022 at 11:20:12AM +0800, Jiapeng Chong wrote: > No functional modification involved. > > drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:112: warning: expecting > prototype for intel_guc_hwconfig_init(). Prototype was for > guc_hwconfig_init() instead. > > Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3414 > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c > b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c > index 4781fccc2687..bdb20beb3e70 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c > @@ -103,7 +103,7 @@ static bool has_table(struct drm_i915_private *i915) > } > > /** > - * intel_guc_hwconfig_init - Initialize the HWConfig > + * guc_hwconfig_init - Initialize the HWConfig > * > * Retrieve the HWConfig table from the GuC and save it locally. > * It can then be queried on demand by other users later on. > -- The name chaged when the function become static. And we shouldn't be documenting internal static functions. So, could you please entirely remove this comment block instead of fixing the name? Thanks, Rodrigo. > 2.20.1.7.g153144c >
[PATCH] drm/i915/gt: Reset twice
From: Chris Wilson
After applying an engine reset, on some platforms like Jasperlake, we
occasionally detect that the engine state is not cleared until shortly
after the resume. As we try to resume the engine with volatile internal
state, the first request fails with a spurious CS event (it looks like
it reports a lite-restore to the hung context, instead of the expected
idle->active context switch).
Signed-off-by: Chris Wilson
Cc: sta...@vger.kernel.org
Cc: Mika Kuoppala
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_reset.c | 34 ++-
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ffde89c5835a4..88dfc0c5316ff 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -268,6 +268,7 @@ static int ilk_do_reset(struct intel_gt *gt,
intel_engine_mask_t engine_mask,
static int gen6_hw_domain_reset(struct intel_gt *gt, u32 hw_domain_mask)
{
struct intel_uncore *uncore = gt->uncore;
+ int loops = 2;
int err;
/*
@@ -275,18 +276,39 @@ static int gen6_hw_domain_reset(struct intel_gt *gt, u32
hw_domain_mask)
* for fifo space for the write or forcewake the chip for
* the read
*/
- intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
+ do {
+ intel_uncore_write_fw(uncore, GEN6_GDRST, hw_domain_mask);
- /* Wait for the device to ack the reset requests */
- err = __intel_wait_for_register_fw(uncore,
- GEN6_GDRST, hw_domain_mask, 0,
- 500, 0,
- NULL);
+ /*
+* Wait for the device to ack the reset requests.
+*
+* On some platforms, e.g. Jasperlake, we see see that the
+* engine register state is not cleared until shortly after
+* GDRST reports completion, causing a failure as we try
+* to immediately resume while the internal state is still
+* in flux. If we immediately repeat the reset, the second
+* reset appears to serialise with the first, and since
+* it is a no-op, the registers should retain their reset
+* value. However, there is still a concern that upon
+* leaving the second reset, the internal engine state
+* is still in flux and not ready for resuming.
+*/
+ err = __intel_wait_for_register_fw(uncore, GEN6_GDRST,
+ hw_domain_mask, 0,
+ 2000, 0,
+ NULL);
+ } while (err == 0 && --loops);
if (err)
GT_TRACE(gt,
"Wait for 0x%08x engines reset failed\n",
hw_domain_mask);
+ /*
+* As we have observed that the engine state is still volatile
+* after GDRST is acked, impose a small delay to let everything settle.
+*/
+ udelay(50);
+
return err;
}
--
2.38.1
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/12/22 05:21, Rijo Thomas wrote:
On 12/10/2022 2:31 AM, Tom Lendacky wrote:
On 12/6/22 06:30, Rijo Thomas wrote:
For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
ring buffer address sent by host to ASP must be a real physical
address and the pages must be physically contiguous.
In a virtualized environment though, when the driver is running in a
guest VM, the pages allocated by __get_free_pages() may not be
contiguous in the host (or machine) physical address space. Guests
will see a guest (or pseudo) physical address and not the actual host
(or machine) physical address. The TEE running on ASP cannot decipher
pseudo physical addresses. It needs host or machine physical address.
To resolve this problem, use DMA APIs for allocating buffers that must
be shared with TEE. This will ensure that the pages are contiguous in
host (or machine) address space. If the DMA handle is an IOVA,
translate it into a physical address before sending it to ASP.
This patch also exports two APIs (one for buffer allocation and
another to free the buffer). This API can be used by AMD-TEE driver to
share buffers with TEE.
Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
Cc: Tom Lendacky
Cc: sta...@vger.kernel.org
Signed-off-by: Rijo Thomas
Co-developed-by: Jeshwanth
Signed-off-by: Jeshwanth
Reviewed-by: Devaraj Rangasamy
---
drivers/crypto/ccp/psp-dev.c | 6 +-
drivers/crypto/ccp/tee-dev.c | 116 ++-
drivers/crypto/ccp/tee-dev.h | 9 +--
include/linux/psp-tee.h | 47 ++
4 files changed, 127 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac8442..2b86158d7435 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
goto e_err;
}
+ if (sp->set_psp_master_device)
+ sp->set_psp_master_device(sp);
+
This worries me a bit... if psp_init() fails, it may still be referenced as
the master device. What's the reason for moving it?
Hmm. Okay, I see your point.
In psp_tee_alloc_dmabuf(), we call psp_get_master_device(). Without above
change, psp_get_master_device() returns NULL.
I think in psp_dev_init(), we can add below error handling:
ret = psp_init(psp);
if (ret)
goto e_init;
...
e_init:
if (sp->clear_psp_master_device)
sp->clear_psp_master_device(sp);
Will this help address your concern?
Yes, that works.
ret = psp_init(psp);
if (ret)
goto e_irq;
- if (sp->set_psp_master_device)
- sp->set_psp_master_device(sp);
-
/* Enable interrupt */
iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be37..1631d9851e54 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -12,8 +12,9 @@
#include
#include
#include
+#include
+#include
#include
-#include
#include
#include "psp-dev.h"
@@ -21,25 +22,64 @@
static bool psp_dead;
+struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
It looks like both calls to this use the same gfp_t values, you can probably
eliminate from the call and just specify them in here.
Okay, I will remove gfp_t flag from the function argument.
+{
+ struct psp_device *psp = psp_get_master_device();
+ struct dma_buffer *dma_buf;
+ struct iommu_domain *dom;
+
+ if (!psp || !size)
+ return NULL;
+
+ dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
+ if (!dma_buf)
+ return NULL;
+
+ dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
+ if (!dma_buf->vaddr || !dma_buf->dma) {
I don't think you can have one of these be NULL without both being NULL, but I
guess it doesn't hurt to check.
Okay, we will keep both checks for now.
+ kfree(dma_buf);
+ return NULL;
+ }
+
+ dma_buf->size = size;
+ > + dom = iommu_get_domain_for_dev(psp->dev);
+ if (dom)
You need a nice comment above this all explaining that. I guess you're using
the presence of a domain to determine whether you're running on bare-metal vs
within a hypervisor? I'm not sure what will happen if the guest ever gets an
emulated IOMMU...
Sure we will add a comment.
We are not trying to determive bare-metal vs hypervisor here, but determine
whether DMA handle returned by dma_alloc_coherent() is an IOVA or not.
If the address is an IOVA, we convert IOVA to physical address using
iommu_iova_to_phys(). This was our intention.
Ok, but if a VM gets an emulated IOMMU and ends up with an IOVA, that IOVA
points to a GPA - and if the size is over a page, then you aren't
guaranteed to have contiguous physical memory.
Probably not a concern at the moment, but not sure about what happens in
the future.
Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface
On Fri, 9 Dec 2022 at 18:36, Ulf Hansson wrote: > > On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote: > > > > On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote: > > > On Wed, 7 Dec 2022 at 17:55, Bjorn Andersson wrote: > > > > > > > > On Wed, Dec 07, 2022 at 05:00:51PM +0100, Ulf Hansson wrote: > > > > > On Thu, 1 Dec 2022 at 23:57, Bjorn Andersson > > > > > wrote: > > > > > > > > > > > > On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > > > > > > > > > > > > > > > > > > > @Ulf, Akhil has a power-domain for a piece of hardware which may be > > > > > > voted active by multiple different subsystems > > > > > > (co-processors/execution > > > > > > contexts) in the system. > > > > > > > > > > > > As such, during the powering down sequence we don't wait for the > > > > > > power-domain to turn off. But in the event of an error, the recovery > > > > > > mechanism relies on waiting for the hardware to settle in a powered > > > > > > off > > > > > > state. > > > > > > > > > > > > The proposal here is to use the reset framework to wait for this > > > > > > state > > > > > > to be reached, before continuing with the recovery mechanism in the > > > > > > client driver. > > > > > > > > > > I tried to review the series (see my other replies), but I am not sure > > > > > I fully understand the consumer part. > > > > > > > > > > More exactly, when and who is going to pull the reset and at what > > > > > point? > > > > > > > > > > > > > > > > > Given our other discussions on quirky behavior, do you have any > > > > > > input/suggestions on this? > > > > > > > > > > > > > Some clients like adreno gpu driver would like to ensure that its > > > > > > > gdsc > > > > > > > is collapsed at hardware during a gpu reset sequence. This is > > > > > > > because it > > > > > > > has a votable gdsc which could be ON due to a vote from another > > > > > > > subsystem > > > > > > > like tz, hyp etc or due to an internal hardware signal. To allow > > > > > > > this, gpucc driver can expose an interface to the client driver > > > > > > > using > > > > > > > reset framework. Using this the client driver can trigger a > > > > > > > polling within > > > > > > > the gdsc driver. > > > > > > > > > > > > @Akhil, this description is fairly generic. As we've reached the > > > > > > state > > > > > > where the hardware has settled and we return to the client, what > > > > > > prevents it from being powered up again? > > > > > > > > > > > > Or is it simply a question of it hitting the powered-off state, not > > > > > > necessarily staying there? > > > > > > > > > > Okay, so it's indeed the GPU driver that is going to assert/de-assert > > > > > the reset at some point. Right? > > > > > > > > > > That seems like a reasonable approach to me, even if it's a bit > > > > > unclear under what conditions that could happen. > > > > > > > > > > > > > Generally the disable-path of the power-domain does not check that the > > > > power-domain is actually turned off, because the status might indicate > > > > that the hardware is voting for the power-domain to be on. > > > > > > Is there a good reason why the HW needs to vote too, when the GPU > > > driver is already in control? > > > > > > Or perhaps that depends on the running use case? > > > > > > > > > > > As part of the recovery of the GPU after some fatal fault, the GPU > > > > driver does something which will cause the hardware votes for the > > > > power-domain to be let go, and then the driver does pm_runtime_put(). > > > > > > Okay. That "something", sounds like a device specific setting for the > > > corresponding gdsc, right? > > > > > > So somehow the GPU driver needs to manage that setting, right? > > > > > > > > > > > But in this case the GPU driver wants to ensure that the power-domain is > > > > actually powered down, before it does pm_runtime_get() again. To ensure > > > > that the hardware lost its state... > > > > > > I see. > > > > > > > > > > > The proposal here is to use a reset to reach into the power-domain > > > > provider and wait for the hardware to be turned off, before the GPU > > > > driver attempts turning the power-domain on again. > > > > > > > > > > > > In other words, there is no reset. This is a hack to make a normally > > > > asynchronous pd.power_off() to be synchronous in this particular case. > > > > > > Alright, assuming I understood your clarifications above correctly > > > (thanks!), I think I have got a much better picture now. > > > > > > Rather than abusing the reset interface, I think we should manage this > > > through the genpd's power on/off notifiers (GENPD_NOTIFY_OFF). The GPU > > > driver should register its corresponding device for them > > > (dev_pm_genpd_add_notifier()). > > > > > > The trick however, is to make the behaviour of the power-domain for > > > the gdsc (the genpd->power_off() callback) conditional on whether the > > > HW is configured to vote or not. If the HW can vote, it should not > > > poll for
Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer
On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
wrote:
>
> On 12.12.2022 09:43, Marek Szyprowski wrote:
> > On 12.12.2022 09:32, Jagan Teki wrote:
> >> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
> >> wrote:
> >>> Hi Jagan,
> >>>
> >>> On 09.12.2022 16:23, Jagan Teki wrote:
> The existing drm panels and bridges in Exynos required host
> initialization during the first DSI command transfer even though
> the initialization was done before.
>
> This host reinitialization is handled via DSIM_STATE_REINITIALIZED
> flag and triggers from host transfer.
>
> Do this exclusively for Exynos.
>
> Initial logic is derived from Marek Szyprowski changes.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Jagan Teki
> ---
> Changes from v9:
> - derived from v8
> - added comments
>
> drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
> include/drm/bridge/samsung-dsim.h | 5 +++--
> 2 files changed, 17 insertions(+), 3 deletions(-)
> >>> The following chunk is missing compared to v8:
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> index 6e9ad955ebd3..6a9403cb92ae 100644
> >>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
> >>> *dsi, unsigned int flag)
> >>> return 0;
> >>>
> >>> samsung_dsim_reset(dsi);
> >>> - samsung_dsim_enable_irq(dsi);
> >>> +
> >>> + if (!(dsi->state & DSIM_STATE_INITIALIZED))
> >>> + samsung_dsim_enable_irq(dsi);
> >> Is this really required? does it make sure that the IRQ does not
> >> enable twice?
> >
> > That's what that check does. Without the 'if (!(dsi->state &
> > DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
> > from pre_enable, then from the first transfer), what leads to a
> > warning from irq core.
>
> I've just noticed that we also would need to clear the
> DSIM_STATE_REINITIALIZED flag in dsim_suspend.
>
> However I've found that a bit simpler patch would keep the current code
> flow for Exynos instead of this reinitialization hack. This can be
> applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
> init in pre_enable" patch:
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 0b2e52585485..acc95c61ae45 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1291,9 +1291,11 @@ static void samsung_dsim_atomic_pre_enable(struct
> drm_bridge *bridge,
>
> dsi->state |= DSIM_STATE_ENABLED;
>
> - ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> - if (ret)
> - return;
> + if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
> + ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
> + if (ret)
> + return;
> + }
Sorry, I don't understand this. Does it mean Exynos doesn't need to
init host in pre_enable? If I remember correctly even though the host
is initialized it has to reinitialize during the first transfer - This
is what the Exynos requirement is. Please correct or explain here.
Jagan.
Re: [PATCH v9 00/18] drm: bridge: Add Samsung MIPI DSIM bridge
Hi Jagan, On 09.12.2022 16:23, Jagan Teki wrote: > This series supports common bridge support for Samsung MIPI DSIM > which is used in Exynos and i.MX8MM SoC's. > > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. Well, I think I've managed to fix the remaining bits to keep it working on Exynos and have all the features added in meantime between v1..v9. I've posted my comments in the individual patches, but to make think easier to test, I've also pushed my changes to the github: https://github.com/mszyprow/linux/tree/v6.1-next-20221208-dsi-v9-fixed With that fixes, feel free to add: Tested-by: Marek Szyprowski to all common/Exynos related patches. > Changes for v9: > - rebase on drm-misc-next > - drop drm bridge attach fix for Exynos > - added prepare_prev_first flag > - added pre_enable_prev_first flag > - fix bridge chain order for exynos > - added fix for Exynos host init for first DSI transfer > - added MEDIA_BUS_FMT_FIXED > - return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt >list is unsupported. > - added MEDIA_BUS_FMT_YUYV10_1X20 > - added MEDIA_BUS_FMT_YUYV12_1X24 > > Changes for v8: > * fixed comment lines > * fixed commit messages > * fixed video mode bits > * collect Marek Ack > * fixed video mode bit names > * update input formats logic > * added imx8mplus support > > Changes for v7: > * fix the drm bridge attach chain for exynos drm dsi driver > * fix the hw_type checking logic > > Changes for v6: > * handle previous bridge for exynos dsi while attaching bridge > > Changes for v5: > * bridge changes to support multi-arch > * updated and clear commit messages > * add hw_type via plat data > * removed unneeded quirk > * rebased on linux-next > t > Changes for v4: > * include Inki Dae in MAINTAINERS > * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > * update init handling to ensure host init done on first cmd transfer > > Changes for v3: > * fix the mult-arch build > * fix dsi host init > * updated commit messages > > Changes for v2: > * fix bridge handling > * fix dsi host init > * correct the commit messages > > Tested in Engicam i.Core MX8M Mini SoM. > > Repo: > https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v9 > > v8: > https://lore.kernel.org/all/20221110183853.3678209-1-ja...@amarulasolutions.com/ > > Any inputs? > Jagan. > > Jagan Teki (16): >drm: panel: Enable prepare_prev_first flag for samsung-s6e panels >drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags >drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits >drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge >drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices >drm: bridge: samsung-dsim: Mark PHY as optional >drm: bridge: samsung-dsim: Add host init in pre_enable >drm: bridge: samsung-dsim: Init exynos host for first DSI transfer >drm: bridge: samsung-dsim: Add atomic_check >drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset >drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts >drm: bridge: samsung-dsim: Add input_bus_flags >dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support >drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support >dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support >drm: bridge: samsung-dsim: Add i.MX8M Plus support > > Marek Szyprowski (2): >drm/bridge: tc358764: Enable pre_enable_prev_first flag >drm: exynos: dsi: Restore proper bridge chain order > > .../bindings/display/exynos/exynos_dsim.txt |2 + > MAINTAINERS |9 + > drivers/gpu/drm/bridge/Kconfig| 12 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 1934 + > drivers/gpu/drm/bridge/tc358764.c |1 + > drivers/gpu/drm/exynos/Kconfig|1 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1769 +-- > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c |1 + > .../gpu/drm/panel/panel-samsung-s6e63j0x03.c |1 + > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c |1 + > include/drm/bridge/samsung-dsim.h | 116 + > 12 files changed, 2195 insertions(+), 1653 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c > create mode 100644 include/drm/bridge/samsung-dsim.h > Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v9 10/18] drm: bridge: samsung-dsim: Init exynos host for first DSI transfer
On 12.12.2022 09:43, Marek Szyprowski wrote:
> On 12.12.2022 09:32, Jagan Teki wrote:
>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>> wrote:
>>> Hi Jagan,
>>>
>>> On 09.12.2022 16:23, Jagan Teki wrote:
The existing drm panels and bridges in Exynos required host
initialization during the first DSI command transfer even though
the initialization was done before.
This host reinitialization is handled via DSIM_STATE_REINITIALIZED
flag and triggers from host transfer.
Do this exclusively for Exynos.
Initial logic is derived from Marek Szyprowski changes.
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes from v9:
- derived from v8
- added comments
drivers/gpu/drm/bridge/samsung-dsim.c | 15 ++-
include/drm/bridge/samsung-dsim.h | 5 +++--
2 files changed, 17 insertions(+), 3 deletions(-)
>>> The following chunk is missing compared to v8:
>>>
>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> index 6e9ad955ebd3..6a9403cb92ae 100644
>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>>> @@ -1315,7 +1315,9 @@ static int samsung_dsim_init(struct samsung_dsim
>>> *dsi, unsigned int flag)
>>> return 0;
>>>
>>> samsung_dsim_reset(dsi);
>>> - samsung_dsim_enable_irq(dsi);
>>> +
>>> + if (!(dsi->state & DSIM_STATE_INITIALIZED))
>>> + samsung_dsim_enable_irq(dsi);
>> Is this really required? does it make sure that the IRQ does not
>> enable twice?
>
> That's what that check does. Without the 'if (!(dsi->state &
> DSIM_STATE_INITIALIZED))' check, the irqs will be enabled twice (first
> from pre_enable, then from the first transfer), what leads to a
> warning from irq core.
I've just noticed that we also would need to clear the
DSIM_STATE_REINITIALIZED flag in dsim_suspend.
However I've found that a bit simpler patch would keep the current code
flow for Exynos instead of this reinitialization hack. This can be
applied on the "[PATCH v9 09/18] drm: bridge: samsung-dsim: Add host
init in pre_enable" patch:
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 0b2e52585485..acc95c61ae45 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1291,9 +1291,11 @@ static void samsung_dsim_atomic_pre_enable(struct
drm_bridge *bridge,
dsi->state |= DSIM_STATE_ENABLED;
- ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
- if (ret)
- return;
+ if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
+ ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
+ if (ret)
+ return;
+ }
}
static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
diff --git a/include/drm/bridge/samsung-dsim.h
b/include/drm/bridge/samsung-dsim.h
index b8132bf8e36f..b4e26de88b9e 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -30,6 +30,9 @@ enum samsung_dsim_type {
SAMSUNG_DSIM_TYPE_COUNT,
};
+#define samsung_dsim_hw_is_exynos(hw) ((hw) >=
SAMSUNG_DSIM_TYPE_EXYNOS3250 && \
+ (hw) <= SAMSUNG_DSIM_TYPE_EXYNOS5433)
+
struct samsung_dsim_transfer {
struct list_head list;
struct completion completed;
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH v9 03/18] drm: exynos: dsi: Restore proper bridge chain order
On 09.12.2022 16:23, Jagan Teki wrote:
> From: Marek Szyprowski
>
> Restore the proper bridge chain by finding the previous bridge
> in the chain instead of passing NULL.
>
> This establishes a proper bridge chain while attaching downstream
> bridges.
>
> v9, v4:
> * none
>
> v3:
> * new patch
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Jagan Teki
> ---
As we are resurrecting this patch, one more change is needed here:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e5b1540c4ae4..9d10a89d28f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1713,6 +1713,7 @@ static int exynos_dsi_probe(struct platform_device
*pdev)
dsi->bridge.funcs = _dsi_bridge_funcs;
dsi->bridge.of_node = dev->of_node;
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
+ dsi->bridge.pre_enable_prev_first = true;
ret = component_add(dev, _dsi_component_ops);
if (ret)
On Exynos5433 Exynos DSI is together with Exynos MIC in the bridge
chain: Decon -> MIC -> DSI -> Panel.
To ensure proper order of initialization we need to mark our bridge
driver also with the pre_enable_prev_first flag. This would also need to
be added to patch "[PATCH v9 06/18] drm: bridge: Generalize Exynos-DSI
driver into a Samsung DSIM bridge".
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index ec673223d6b7..e5b1540c4ae4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1428,7 +1428,8 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
> {
> struct exynos_dsi *dsi = bridge_to_dsi(bridge);
>
> - return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
> + return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
> + flags);
> }
>
> static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
> @@ -1474,7 +1475,10 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
> *host,
>
> drm_bridge_add(>bridge);
>
> - drm_bridge_attach(encoder, >bridge, NULL, 0);
> + drm_bridge_attach(encoder, >bridge,
> + list_first_entry_or_null(>bridge_chain,
> +struct drm_bridge,
> +chain_node), 0);
>
> /*
>* This is a temporary solution and should be made by more generic way.
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
[PATCH v10 2/2] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits
HSA/HBP/HFP/HSE mode bits in Processor Reference Manuals specify a naming conversion as 'disable mode bit' due to its bit definition, 0 = Enable and 1 = Disable. For HSE bit, the i.MX 8M Mini/Nano/Plus Applications Processor Reference Manual named this bit as 'HseDisableMode' but the bit definition is quite opposite like 0 = Disables transfer 1 = Enables transfer which clearly states that HSE is not a disable bit. HSE is named as per the manual even though it is not a disable bit however the driver logic for handling HSE is based on the MIPI_DSI_MODE_VIDEO_HSE flag itself. Cc: Nicolas Boichat Reviewed-by: Marek Vasut Signed-off-by: Jagan Teki --- Changes for v10: - add Marek V review tag Changes for v9: - new patch drivers/gpu/drm/exynos/exynos_drm_dsi.c | 33 +++-- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index 50a2a9ca88a9..b64bb6006b7d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -75,10 +75,27 @@ #define DSIM_MAIN_PIX_FORMAT_RGB565(0x4 << 12) #define DSIM_SUB_VC(((x) & 0x3) << 16) #define DSIM_MAIN_VC (((x) & 0x3) << 18) -#define DSIM_HSA_MODE (1 << 20) -#define DSIM_HBP_MODE (1 << 21) -#define DSIM_HFP_MODE (1 << 22) -#define DSIM_HSE_MODE (1 << 23) +#define DSIM_HSA_DISABLE_MODE (1 << 20) +#define DSIM_HBP_DISABLE_MODE (1 << 21) +#define DSIM_HFP_DISABLE_MODE (1 << 22) +/* + * The i.MX 8M Mini Applications Processor Reference Manual, + * Rev. 3, 11/2020 Page 4091 + * The i.MX 8M Nano Applications Processor Reference Manual, + * Rev. 2, 07/2022 Page 3058 + * The i.MX 8M Plus Applications Processor Reference Manual, + * Rev. 1, 06/2021 Page 5436 + * named this bit as 'HseDisableMode' but the bit definition + * is quite opposite like + * 0 = Disables transfer + * 1 = Enables transfer + * which clearly states that HSE is not a disable bit. + * + * This bit is named as per the manual even though it is not + * a disable bit however the driver logic for handling HSE + * is based on the MIPI_DSI_MODE_VIDEO_HSE flag itself. + */ +#define DSIM_HSE_DISABLE_MODE (1 << 23) #define DSIM_AUTO_MODE (1 << 24) #define DSIM_VIDEO_MODE(1 << 25) #define DSIM_BURST_MODE(1 << 26) @@ -804,13 +821,13 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi) if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT) reg |= DSIM_AUTO_MODE; if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE) - reg |= DSIM_HSE_MODE; + reg |= DSIM_HSE_DISABLE_MODE; if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP) - reg |= DSIM_HFP_MODE; + reg |= DSIM_HFP_DISABLE_MODE; if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP) - reg |= DSIM_HBP_MODE; + reg |= DSIM_HBP_DISABLE_MODE; if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA) - reg |= DSIM_HSA_MODE; + reg |= DSIM_HSA_DISABLE_MODE; } if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET) -- 2.25.1
[PATCH v10 1/2] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
0 = Enable and 1 = Disable.
The logic for checking these mode flags was correct before
the MIPI_DSI*_NO_* mode flag conversion.
This patch is trying to fix this MIPI_DSI*_NO_* mode flags handling
Exynos DSI host and update the mode_flags in relevant panel drivers.
Fixes: <0f3b68b66a6d> ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
features")
Reviewed-by: Marek Vasut
Reviewed-by: Nicolas Boichat
Reported-by: Sébastien Szymanski
Signed-off-by: Jagan Teki
---
Changes for v10:
- add Marek V review tag
- add panel driver fixes
Changes for v9:
- none
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 4 +++-
drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 ++-
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 2 --
4 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e5b1540c4ae4..50a2a9ca88a9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_AUTO_MODE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
reg |= DSIM_HSE_MODE;
- if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
reg |= DSIM_HFP_MODE;
- if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
reg |= DSIM_HBP_MODE;
- if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
reg |= DSIM_HSA_MODE;
}
- if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
+ if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
reg |= DSIM_EOT_DISABLE;
switch (dsi->format) {
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 1355b2c27932..39eef3dce7c9 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -692,7 +692,9 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS |
+ MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
+ MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
ctx->supplies[0].supply = "vdd3";
ctx->supplies[1].supply = "vci";
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index 3223a9d06a50..46d6f4a87bf7 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -446,7 +446,8 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 1;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO_NO_HFP |
+ MIPI_DSI_MODE_VIDEO_NO_HBP | MIPI_DSI_MODE_VIDEO_NO_HSA;
ctx->supplies[0].supply = "vdd3";
ctx->supplies[1].supply = "vci";
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
index 362eb10f10ce..c51d07ec1529 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
@@ -990,8 +990,6 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST
- | MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP
- | MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET
| MIPI_DSI_MODE_VSYNC_FLUSH | MIPI_DSI_MODE_VIDEO_AUTO_VERT;
ret = s6e8aa0_parse_dt(ctx);
--
2.25.1
[PATCH v10 2/3] drm/bridge: tc358764: Enable pre_enable_prev_first flag
From: Marek Szyprowski Enable the drm bridge pre_enable_prev_first flag so that the previous bridge pre_enable should be called first before the pre_enable for the tc358764 bridge is called. This makes sure that the previous bridge should be initialized properly before the tc358764 bridge is powered up. Signed-off-by: Marek Szyprowski Signed-off-by: Jagan Teki --- Changes for v10: - none drivers/gpu/drm/bridge/tc358764.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c index 53259c12d777..f85654f1b104 100644 --- a/drivers/gpu/drm/bridge/tc358764.c +++ b/drivers/gpu/drm/bridge/tc358764.c @@ -369,6 +369,7 @@ static int tc358764_probe(struct mipi_dsi_device *dsi) ctx->bridge.funcs = _bridge_funcs; ctx->bridge.of_node = dev->of_node; + ctx->bridge.pre_enable_prev_first = true; drm_bridge_add(>bridge); -- 2.25.1
[PATCH v10 3/3] drm: exynos: dsi: Restore proper bridge chain order
From: Marek Szyprowski
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
Reviewed-by: Marek Vasut
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes for v10:
- collect Marek review tag
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index ec673223d6b7..e5b1540c4ae4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1428,7 +1428,8 @@ static int exynos_dsi_attach(struct drm_bridge *bridge,
{
struct exynos_dsi *dsi = bridge_to_dsi(bridge);
- return drm_bridge_attach(bridge->encoder, dsi->out_bridge, NULL, flags);
+ return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
+flags);
}
static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
@@ -1474,7 +1475,10 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
drm_bridge_add(>bridge);
- drm_bridge_attach(encoder, >bridge, NULL, 0);
+ drm_bridge_attach(encoder, >bridge,
+ list_first_entry_or_null(>bridge_chain,
+ struct drm_bridge,
+ chain_node), 0);
/*
* This is a temporary solution and should be made by more generic way.
--
2.25.1
[PATCH v10 1/3] drm: panel: Enable prepare_prev_first flag for samsung-s6e panels
Enable the drm panel prepare_prev_first flag so-that the previous
controller should be prepared first before the prepare for the
panel is called.
samsung-s6e3ha2, samsung-s6e63j0x03 and samsung-s6e8aa0 are the
effected samsung-s6e panels for this change.
This makes sure that the previous controller, likely to be a DSI
host controller should be initialized to LP-11 before the panel
is powered up.
Signed-off-by: Marek Szyprowski
Signed-off-by: Jagan Teki
---
Changes for v10:
- none
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 1 +
drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 5c621b15e84c..1355b2c27932 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -731,6 +731,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
drm_panel_add(>panel);
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index e06fd35de814..3223a9d06a50 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -462,6 +462,7 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel, dev, _funcs,
DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
ctx->bl_dev = backlight_device_register("s6e63j0x03", dev, ctx,
_bl_ops, NULL);
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
index 54213beafaf5..362eb10f10ce 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
@@ -1018,6 +1018,7 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
drm_panel_init(>panel, dev, _drm_funcs,
DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
drm_panel_add(>panel);
--
2.25.1
[PATCH v10 0/3] drm: exynos: dsi: Restore the bridge chain
Split the Exynos DSI bridge chain update patches from Samsung DSIM bridge driver for easy to apply. Changes for v10: - collect Marek.V Review tag Any inputs? Jagan. Jagan Teki (1): drm: panel: Enable prepare_prev_first flag for samsung-s6e panels Marek Szyprowski (2): drm/bridge: tc358764: Enable pre_enable_prev_first flag drm: exynos: dsi: Restore proper bridge chain order drivers/gpu/drm/bridge/tc358764.c| 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++-- drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 1 + drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 + drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 1 + 5 files changed, 10 insertions(+), 2 deletions(-) -- 2.25.1
Re: [PATCH 1/5] Renaming weak prng invocations - prandom_bytes_state, prandom_u32_state
Please CC me on future revisions. As of 6.2, the prandom namespace is *only* for predictable randomness. There's no need to rename anything. So nack on this patch 1/5. With regards to the remaining patches in this series, if you want to move prandom_u32_state callers over to get_random_bytes() and get_random_u32(), that's fine from my perspective, but last I looked, there was much usage in places where being repeatable was actually the goal - test suites and such, where you want to be able to redo your tests with the same seed. So you'll have to look at each instance case by case and convince whoever maintains that code that they don't need predictability. However, if you do that, the right functions to use are get_random_bytes() and get_random_u32(). Jason
Re: [PATCH v9 04/18] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
On Mon, Dec 12, 2022 at 7:51 PM Marek Szyprowski
wrote:
>
> On 12.12.2022 10:03, Jagan Teki wrote:
> > On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
> > wrote:
> >> Hi Jagan,
> >>
> >> On 09.12.2022 16:23, Jagan Teki wrote:
> >>> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
> >>> 0 = Enable and 1 = Disable.
> >>>
> >>> The logic for checking these mode flags was correct before
> >>> the MIPI_DSI*_NO_* mode flag conversion.
> >>>
> >>> Fix the MIPI_DSI*_NO_* mode flags handling.
> >>>
> >>> Fixes: <0f3b68b66a6d> ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
> >>> features")
> >>> Reviewed-by: Nicolas Boichat
> >>> Reported-by: Sébastien Szymanski
> >>> Signed-off-by: Jagan Teki
> >>> ---
> >>> Changes for v9:
> >>> - none
> >>>
> >>>drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
> >>>1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> index e5b1540c4ae4..50a2a9ca88a9 100644
> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> @@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi
> >>> *dsi)
> >>>reg |= DSIM_AUTO_MODE;
> >>>if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
> >>>reg |= DSIM_HSE_MODE;
> >>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
> >>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
> >>>reg |= DSIM_HFP_MODE;
> >>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
> >>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
> >>>reg |= DSIM_HBP_MODE;
> >>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
> >>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
> >>>reg |= DSIM_HSA_MODE;
> >>>}
> >>>
> >>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
> >>> + if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
> >>>reg |= DSIM_EOT_DISABLE;
> >>>
> >>>switch (dsi->format) {
> >>
> >> Huh, this changes the logic in the driver! I've spent another half of
> >> the night trying to figure out why v8 and v9 doesn't work on all my
> >> Exynos boards with DSI panels again...
> >>
> >> Please drop this patch from this series. If you want to get the Exynos
> >> DSI -> Samsung DSIM conversion merged, please focus on the core patches
> >> and don't add more random 'fixes' to each new version.
> >>
> >> This change has to be discussed separately. The values written by the
> >> Exynos DSI driver to the registers ARE CORRECT and DSI panels work fine
> >> with such configuration. So either everything is correct, or these flags
> >> are reversed both in the Exynos DSI driver AND at least tested DSI
> >> panels (s6e8aa0, s6e3ha2, s6e63j0x03). I would need to check this in
> >> panel datasheets if I manage to get them.
> > This issue was reproduced as part of the series in v7 in i.MX8m
> > platform and reported by Sébastien Szymanski [1] and TRM matches the
> > fix as well.
> >
> > [1]
> > https://lore.kernel.org/all/4c9475d0-f76f-0c59-1208-6e5395496...@armadeus.com/
>
> Then please append the following changes to this patch to keep current
> code working:
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> index 1355b2c27932..2a33602372d9 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> @@ -692,7 +692,9 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
>
> dsi->lanes = 4;
> dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS;
> + dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS
> + | MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP
> + | MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>
> ctx->supplies[0].supply = "vdd3";
> ctx->supplies[1].supply = "vci";
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> index 3223a9d06a50..bb47dbfdd7ee 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
> @@ -446,7 +446,8 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
>
> dsi->lanes = 1;
> dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO_NO_HFP
> + | MIPI_DSI_MODE_VIDEO_NO_HBP | MIPI_DSI_MODE_VIDEO_NO_HSA;
>
> ctx->supplies[0].supply = "vdd3";
> ctx->supplies[1].supply = "vci";
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
>
Re: [PATCH v9 04/18] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
On 12.12.2022 10:03, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
> wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
>>> 0 = Enable and 1 = Disable.
>>>
>>> The logic for checking these mode flags was correct before
>>> the MIPI_DSI*_NO_* mode flag conversion.
>>>
>>> Fix the MIPI_DSI*_NO_* mode flags handling.
>>>
>>> Fixes: <0f3b68b66a6d> ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
>>> features")
>>> Reviewed-by: Nicolas Boichat
>>> Reported-by: Sébastien Szymanski
>>> Signed-off-by: Jagan Teki
>>> ---
>>> Changes for v9:
>>> - none
>>>
>>>drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
>>>1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index e5b1540c4ae4..50a2a9ca88a9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -805,15 +805,15 @@ static int exynos_dsi_init_link(struct exynos_dsi
>>> *dsi)
>>>reg |= DSIM_AUTO_MODE;
>>>if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
>>>reg |= DSIM_HSE_MODE;
>>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP))
>>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
>>>reg |= DSIM_HFP_MODE;
>>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP))
>>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
>>>reg |= DSIM_HBP_MODE;
>>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA))
>>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
>>>reg |= DSIM_HSA_MODE;
>>>}
>>>
>>> - if (!(dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
>>> + if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
>>>reg |= DSIM_EOT_DISABLE;
>>>
>>>switch (dsi->format) {
>>
>> Huh, this changes the logic in the driver! I've spent another half of
>> the night trying to figure out why v8 and v9 doesn't work on all my
>> Exynos boards with DSI panels again...
>>
>> Please drop this patch from this series. If you want to get the Exynos
>> DSI -> Samsung DSIM conversion merged, please focus on the core patches
>> and don't add more random 'fixes' to each new version.
>>
>> This change has to be discussed separately. The values written by the
>> Exynos DSI driver to the registers ARE CORRECT and DSI panels work fine
>> with such configuration. So either everything is correct, or these flags
>> are reversed both in the Exynos DSI driver AND at least tested DSI
>> panels (s6e8aa0, s6e3ha2, s6e63j0x03). I would need to check this in
>> panel datasheets if I manage to get them.
> This issue was reproduced as part of the series in v7 in i.MX8m
> platform and reported by Sébastien Szymanski [1] and TRM matches the
> fix as well.
>
> [1]
> https://lore.kernel.org/all/4c9475d0-f76f-0c59-1208-6e5395496...@armadeus.com/
Then please append the following changes to this patch to keep current
code working:
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 1355b2c27932..2a33602372d9 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -692,7 +692,9 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS
+ | MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP
+ | MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
ctx->supplies[0].supply = "vdd3";
ctx->supplies[1].supply = "vci";
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index 3223a9d06a50..bb47dbfdd7ee 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -446,7 +446,8 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 1;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO_NO_HFP
+ | MIPI_DSI_MODE_VIDEO_NO_HBP | MIPI_DSI_MODE_VIDEO_NO_HSA;
ctx->supplies[0].supply = "vdd3";
ctx->supplies[1].supply = "vci";
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
index 362eb10f10ce..c51d07ec1529 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
@@ -990,8 +990,6 @@ static int s6e8aa0_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add enable delay property
On 12/12/22 13:29, Frieder Schrempf wrote: On 12.12.22 10:23, Krzysztof Kozlowski wrote: On 12/12/2022 10:09, Frieder Schrempf wrote: This does seem like a hardware bug right there, can you double-check this with the hardware engineer ? Yep, checked with hardware engineer. An 470nF is attached, together with an open drain output and only the internal pull-up. So yes ~113ms rising time until 0.7 x VCC. I don't suppose you can have that capacitor reduced or better yet, some external pull up added, can you ? Actually our HW engineers have implemented a similar RC circuit to provide a hardware delay for the EN signal. I think this is due to a design note in the datasheet (see chapter 7.4.1) and therefore it's probably widely spread. If I read section 7.4.1 correctly, it would be enough to just add delay Ten=1ms instead of the capacitor, right? And that would be device-specific. But if one chooses the capacitor solution, it becomes now board specific. Yes, seems like that's the case. Can you still fix the board instead ? It would even save you on BOM.
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add enable delay property
On 12.12.22 10:23, Krzysztof Kozlowski wrote: > On 12/12/2022 10:09, Frieder Schrempf wrote: > This does seem like a hardware bug right there, can you double-check > this with the hardware engineer ? Yep, checked with hardware engineer. An 470nF is attached, together with an open drain output and only the internal pull-up. So yes ~113ms rising time until 0.7 x VCC. >>> >>> I don't suppose you can have that capacitor reduced or better yet, some >>> external pull up added, can you ? >> >> Actually our HW engineers have implemented a similar RC circuit to >> provide a hardware delay for the EN signal. I think this is due to a >> design note in the datasheet (see chapter 7.4.1) and therefore it's >> probably widely spread. > > If I read section 7.4.1 correctly, it would be enough to just add delay > Ten=1ms instead of the capacitor, right? And that would be > device-specific. But if one chooses the capacitor solution, it becomes > now board specific. Yes, seems like that's the case.
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add enable delay property
On Mon, Dec 12, 2022 at 12:49:26PM +0100, Frieder Schrempf wrote: > On 12.12.22 10:32, Laurent Pinchart wrote: > > On Mon, Dec 12, 2022 at 10:09:45AM +0100, Frieder Schrempf wrote: > >> On 09.12.22 15:49, Marek Vasut wrote: > >>> On 12/9/22 14:38, Alexander Stein wrote: > Am Freitag, 9. Dezember 2022, 13:43:02 CET schrieb Marek Vasut: > > On 12/9/22 13:21, Alexander Stein wrote: > >> Am Freitag, 9. Dezember 2022, 13:02:10 CET schrieb Marek Vasut: > >>> On 12/9/22 10:36, Alexander Stein wrote: > Am Freitag, 9. Dezember 2022, 10:07:45 CET schrieb Krzysztof > Kozlowski: > > On 09/12/2022 09:54, Alexander Stein wrote: > >> Am Freitag, 9. Dezember 2022, 09:39:49 CET schrieb Krzysztof > >> Kozlowski: > >>> On 09/12/2022 09:33, Alexander Stein wrote: > It takes some time until the enable GPIO has settled when > turning on. > This delay is platform specific and may be caused by e.g. voltage > shifts, capacitors etc. > > Signed-off-by: Alexander Stein > --- > > > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4 > > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > index 48a97bb3e2e0d..3f50d497cf8ac 100644 > --- > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > +++ > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > @@ -32,6 +32,10 @@ properties: > maxItems: 1 > description: GPIO specifier for bridge_en pin (active > high). > > + ti,enable-delay-us: > + default: 1 > + description: Enable time delay for enable-gpios > >>> > >>> Aren't you now mixing two separate delays? One for entire block (I > >>> would assume mostly fixed delay) and one depending on regulators > >>> (regulator-ramp-delay, regulator-enable-ramp-delay). Maybe you > >>> miss the > >>> second delays in your power supply? If so, the first one might be > >>> fixed > >>> and hard-coded in the driver? > >> > >> Apparently there are two different delays: reset time (t_reset) of > >> 10ms as > >> specified by datasheet. This is already ensured by a following > >> delay after > >> requesting enable_gpio as low and switching the GPIO to low in > >> disable > >> path. > >> > >> When enabling this GPIO it takes some time until it is valid on > >> the chip, > >> this is what this series is about. It's highly platform specific. > >> > >> Unfortunately this is completely unrelated to the vcc-supply > >> regulator. > >> This one has to be enabled before the enable GPIO can be enabled. > >> So > >> there is no regulator-ramp-delay. > > > > Your driver does one after another - regulator followed immediately > > by > > gpio - so this as well can be a delay from regulator (maybe not > > ramp but > > enable delay). > >>> > >>> The chip has two separate input pins: > >>> > >>> VCC -- power supply that's regulator > >>> EN -- reset line, that's GPIO > >>> > >>> Alexander is talking about EN line here. > >>> > But this will introduce a section which must not be interrupted or > delayed. > This is impossible as the enable gpio is attached to an i2c expander > in my > case. > > Given the following time chart: > vcc set EN > > enable GPIO PAD > > | |<-- t_raise -->| > | > | <-- t_vcc_gpio --> | | > | <-- t_enable_delay --> | > > t_raise is the time from changing the GPIO output at the expander > until > voltage on the EN (input) pad from the bridge has reached high > voltage > level. This is an electrical characteristic I can not change and > have to > take into account. > t_vcc_gpio is the time from enabling supply voltage to enabling the > bridge > (removing from reset). Minimum t_vcc_gpio is something which can be > addressed by the regulator and is no problem so far. But there is no > upper bound to it. >
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add enable delay property
On 12.12.22 10:32, Laurent Pinchart wrote: > On Mon, Dec 12, 2022 at 10:09:45AM +0100, Frieder Schrempf wrote: >> On 09.12.22 15:49, Marek Vasut wrote: >>> On 12/9/22 14:38, Alexander Stein wrote: Am Freitag, 9. Dezember 2022, 13:43:02 CET schrieb Marek Vasut: > On 12/9/22 13:21, Alexander Stein wrote: >> Am Freitag, 9. Dezember 2022, 13:02:10 CET schrieb Marek Vasut: >>> On 12/9/22 10:36, Alexander Stein wrote: Am Freitag, 9. Dezember 2022, 10:07:45 CET schrieb Krzysztof Kozlowski: > On 09/12/2022 09:54, Alexander Stein wrote: >> Am Freitag, 9. Dezember 2022, 09:39:49 CET schrieb Krzysztof >> Kozlowski: >>> On 09/12/2022 09:33, Alexander Stein wrote: It takes some time until the enable GPIO has settled when turning on. This delay is platform specific and may be caused by e.g. voltage shifts, capacitors etc. Signed-off-by: Alexander Stein --- .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 48a97bb3e2e0d..3f50d497cf8ac 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -32,6 +32,10 @@ properties: maxItems: 1 description: GPIO specifier for bridge_en pin (active high). + ti,enable-delay-us: + default: 1 + description: Enable time delay for enable-gpios >>> >>> Aren't you now mixing two separate delays? One for entire block (I >>> would assume mostly fixed delay) and one depending on regulators >>> (regulator-ramp-delay, regulator-enable-ramp-delay). Maybe you miss >>> the >>> second delays in your power supply? If so, the first one might be >>> fixed >>> and hard-coded in the driver? >> >> Apparently there are two different delays: reset time (t_reset) of >> 10ms as >> specified by datasheet. This is already ensured by a following delay >> after >> requesting enable_gpio as low and switching the GPIO to low in >> disable >> path. >> >> When enabling this GPIO it takes some time until it is valid on the >> chip, >> this is what this series is about. It's highly platform specific. >> >> Unfortunately this is completely unrelated to the vcc-supply >> regulator. >> This one has to be enabled before the enable GPIO can be enabled. So >> there is no regulator-ramp-delay. > > Your driver does one after another - regulator followed immediately by > gpio - so this as well can be a delay from regulator (maybe not ramp > but > enable delay). >>> >>> The chip has two separate input pins: >>> >>> VCC -- power supply that's regulator >>> EN -- reset line, that's GPIO >>> >>> Alexander is talking about EN line here. >>> But this will introduce a section which must not be interrupted or delayed. This is impossible as the enable gpio is attached to an i2c expander in my case. Given the following time chart: vcc set EN enable GPIO PAD | |<-- t_raise -->| | | <-- t_vcc_gpio --> | | | <-- t_enable_delay --> | t_raise is the time from changing the GPIO output at the expander until voltage on the EN (input) pad from the bridge has reached high voltage level. This is an electrical characteristic I can not change and have to take into account. t_vcc_gpio is the time from enabling supply voltage to enabling the bridge (removing from reset). Minimum t_vcc_gpio is something which can be addressed by the regulator and is no problem so far. But there is no upper bound to it. >>> >>> What exactly is your EN signal rise time (should be ns or so)? Can you >>> look at that with a scope , maybe even with relation to the VCC >>> regulator >>> ? >> >> I checked EN rise time using a scope, it's ~110ms. I not an expert in >> hardware but on the mainboard there is some capacitor attached to
RE: [v10] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
>-Original Message-
>From: Marijn Suijten
>Sent: Wednesday, December 7, 2022 7:39 PM
>To: Kalyan Thota (QUIC)
>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>ker...@vger.kernel.org; robdcl...@chromium.org; diand...@chromium.org;
>swb...@chromium.org; Vinod Polimera (QUIC) ;
>dmitry.barysh...@linaro.org; Abhinav Kumar (QUIC)
>
>Subject: Re: [v10] drm/msm/disp/dpu1: add support for dspp sub block flush in
>sc7280
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 2022-12-07 04:59:23, Kalyan Thota wrote:
>> Flush mechanism for DSPP blocks has changed in sc7280 family, it
>> allows individual sub blocks to be flushed in coordination with master
>> flush control.
>>
>> Representation: master_flush && (PCC_flush | IGC_flush .. etc )
>>
>> This change adds necessary support for the above design.
>>
>> Changes in v1:
>> - Few nits (Doug, Dmitry)
>> - Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
>>
>> Changes in v2:
>> - Move the address offset to flush macro (Dmitry)
>> - Seperate ops for the sub block flush (Dmitry)
>>
>> Changes in v3:
>> - Reuse the DPU_DSPP_xx enum instead of a new one (Dmitry)
>>
>> Changes in v4:
>> - Use shorter version for unsigned int (Stephen)
>>
>> Changes in v5:
>> - Spurious patch please ignore.
>>
>> Changes in v6:
>> - Add SOB tag (Doug, Dmitry)
>>
>> Changes in v7:
>> - Cache flush mask per dspp (Dmitry)
>> - Few nits (Marijn)
>>
>> Changes in v8:
>> - Few nits (Marijn)
>>
>> Changes in v9:
>> - use DSPP enum while accessing flush mask to make it readable
>> (Dmitry)
>> - Few nits (Dmitry)
>>
>> Changes in v10:
>> - fix white spaces in a seperate patch (Dmitry)
>>
>> Signed-off-by: Kalyan Thota
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 ++-
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 44
>--
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 5 ++-
>> 5 files changed, 55 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> index 601d687..4170fbe 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>> @@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct
>> drm_crtc *crtc)
>>
>> /* stage config flush mask */
>> ctl->ops.update_pending_flush_dspp(ctl,
>> - mixer[i].hw_dspp->idx);
>> + mixer[i].hw_dspp->idx, DPU_DSPP_PCC);
>> }
>> }
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>> index 27f029f..0eecb2f 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>> @@ -65,7 +65,10 @@
>> (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
>>
>> #define CTL_SC7280_MASK \
>> - (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
>BIT(DPU_CTL_VM_CFG))
>> + (BIT(DPU_CTL_ACTIVE_CFG) | \
>> + BIT(DPU_CTL_FETCH_ACTIVE) | \
>> + BIT(DPU_CTL_VM_CFG) | \
>> + BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
>>
>> #define MERGE_3D_SM8150_MASK (0)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> index 38aa38a..126ee37 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>> @@ -161,10 +161,12 @@ enum {
>> * DSPP sub-blocks
>> * @DPU_DSPP_PCC Panel color correction block
>> * @DPU_DSPP_GC Gamma correction block
>> + * @DPU_DSPP_IGC Inverse gamma correction block
>> */
>> enum {
>> DPU_DSPP_PCC = 0x1,
>> DPU_DSPP_GC,
>> + DPU_DSPP_IGC,
>> DPU_DSPP_MAX
>> };
>>
>> @@ -191,6 +193,7 @@ enum {
>> * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
>> * @DPU_CTL_FETCH_ACTIVE:Active CTL for fetch HW (SSPPs)
>> * @DPU_CTL_VM_CFG: CTL config to support multiple VMs
>> + * @DPU_CTL_DSPP_BLOCK_FLUSH CTL config to support dspp sub-block
>> + flush
>
>The above uses tabs, why does this use spaces?
>
>> * @DPU_CTL_MAX
>> */
>> enum {
>> @@ -198,6 +201,7 @@ enum {
>> DPU_CTL_ACTIVE_CFG,
>> DPU_CTL_FETCH_ACTIVE,
>> DPU_CTL_VM_CFG,
>> + DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
>> DPU_CTL_MAX
>> };
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>> index a35ecb6..e801be1 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
>> @@ -33,6 +33,7 @@
>> #define CTL_INTF_FLUSH0x110
>>
Re: [PATCH 1/1] crypto: ccp - Allocate TEE ring and cmd buffer using DMA APIs
On 12/10/2022 2:31 AM, Tom Lendacky wrote:
> On 12/6/22 06:30, Rijo Thomas wrote:
>> For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
>> ring buffer address sent by host to ASP must be a real physical
>> address and the pages must be physically contiguous.
>>
>> In a virtualized environment though, when the driver is running in a
>> guest VM, the pages allocated by __get_free_pages() may not be
>> contiguous in the host (or machine) physical address space. Guests
>> will see a guest (or pseudo) physical address and not the actual host
>> (or machine) physical address. The TEE running on ASP cannot decipher
>> pseudo physical addresses. It needs host or machine physical address.
>>
>> To resolve this problem, use DMA APIs for allocating buffers that must
>> be shared with TEE. This will ensure that the pages are contiguous in
>> host (or machine) address space. If the DMA handle is an IOVA,
>> translate it into a physical address before sending it to ASP.
>>
>> This patch also exports two APIs (one for buffer allocation and
>> another to free the buffer). This API can be used by AMD-TEE driver to
>> share buffers with TEE.
>>
>> Fixes: 33960acccfbd ("crypto: ccp - add TEE support for Raven Ridge")
>> Cc: Tom Lendacky
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Rijo Thomas
>> Co-developed-by: Jeshwanth
>> Signed-off-by: Jeshwanth
>> Reviewed-by: Devaraj Rangasamy
>> ---
>> drivers/crypto/ccp/psp-dev.c | 6 +-
>> drivers/crypto/ccp/tee-dev.c | 116 ++-
>> drivers/crypto/ccp/tee-dev.h | 9 +--
>> include/linux/psp-tee.h | 47 ++
>> 4 files changed, 127 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
>> index c9c741ac8442..2b86158d7435 100644
>> --- a/drivers/crypto/ccp/psp-dev.c
>> +++ b/drivers/crypto/ccp/psp-dev.c
>> @@ -161,13 +161,13 @@ int psp_dev_init(struct sp_device *sp)
>> goto e_err;
>> }
>> + if (sp->set_psp_master_device)
>> + sp->set_psp_master_device(sp);
>> +
>
> This worries me a bit... if psp_init() fails, it may still be referenced as
> the master device. What's the reason for moving it?
Hmm. Okay, I see your point.
In psp_tee_alloc_dmabuf(), we call psp_get_master_device(). Without above
change, psp_get_master_device() returns NULL.
I think in psp_dev_init(), we can add below error handling:
ret = psp_init(psp);
if (ret)
goto e_init;
...
e_init:
if (sp->clear_psp_master_device)
sp->clear_psp_master_device(sp);
Will this help address your concern?
>
>> ret = psp_init(psp);
>> if (ret)
>> goto e_irq;
>> - if (sp->set_psp_master_device)
>> - sp->set_psp_master_device(sp);
>> -
>> /* Enable interrupt */
>> iowrite32(-1, psp->io_regs + psp->vdata->inten_reg);
>> diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
>> index 5c9d47f3be37..1631d9851e54 100644
>> --- a/drivers/crypto/ccp/tee-dev.c
>> +++ b/drivers/crypto/ccp/tee-dev.c
>> @@ -12,8 +12,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> -#include
>> #include
>> #include "psp-dev.h"
>> @@ -21,25 +22,64 @@
>> static bool psp_dead;
>> +struct dma_buffer *psp_tee_alloc_dmabuf(unsigned long size, gfp_t gfp)
>
> It looks like both calls to this use the same gfp_t values, you can probably
> eliminate from the call and just specify them in here.
>
Okay, I will remove gfp_t flag from the function argument.
>> +{
>> + struct psp_device *psp = psp_get_master_device();
>> + struct dma_buffer *dma_buf;
>> + struct iommu_domain *dom;
>> +
>> + if (!psp || !size)
>> + return NULL;
>> +
>> + dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
>> + if (!dma_buf)
>> + return NULL;
>> +
>> + dma_buf->vaddr = dma_alloc_coherent(psp->dev, size, _buf->dma, gfp);
>> + if (!dma_buf->vaddr || !dma_buf->dma) {
>
> I don't think you can have one of these be NULL without both being NULL, but
> I guess it doesn't hurt to check.
>
Okay, we will keep both checks for now.
>> + kfree(dma_buf);
>> + return NULL;
>> + }
>> +
>> + dma_buf->size = size;
>> + > + dom = iommu_get_domain_for_dev(psp->dev);
>> + if (dom)
>
> You need a nice comment above this all explaining that. I guess you're using
> the presence of a domain to determine whether you're running on bare-metal vs
> within a hypervisor? I'm not sure what will happen if the guest ever gets an
> emulated IOMMU...
Sure we will add a comment.
We are not trying to determive bare-metal vs hypervisor here, but determine
whether DMA handle returned by dma_alloc_coherent() is an IOVA or not.
If the address is an IOVA, we convert IOVA to physical address using
iommu_iova_to_phys(). This was our intention.
>
>> + dma_buf->paddr = iommu_iova_to_phys(dom, dma_buf->dma);
>
> If
Re: Try to address the DMA-buf coherency problem
Am 12.12.22 um 04:00 schrieb Tomasz Figa: [SNIP] What we could do is to force all exporters to use begin/end_cpu_access() even on it's own buffers and look at all the importers when the access is completed. But that would increase the complexity of the handling in the exporter. I feel like they should be doing so anyway, because it often depends on the SoC integration whether the DMA can do cache snooping or not. Yeah, but wouldn't help without the exporter taking care of the importers needs of cache flushing. And that's exactly what we try hard to avoid because it creates code in every exporter which is never tested except for the case that you combine this exporter with an non coherent importer. That's a testing nightmare because then you everywhere has code which only in very few combinations of exporter and importer is actually used. Although arguably, there is a corner case today where if one uses dma_alloc_coherent() to get a buffer with a coherent CPU mapping for device X that is declared as cache-coherent, one also expects not to need to call begin/end_cpu_access(), but those would be needed if the buffer was to be imported by device Y that is not cache-coherent... Sounds like after all it's a mess. I guess your patches make it one step closer to something sensible, import would fail in such cases. Although arguably we should be able to still export from driver Y and import to driver X just fine if Y allocated the buffer as coherent - otherwise we would break existing users for whom things worked fine. Allocating the buffer as coherent won't help in this case because we actually do want CPU caching for performant access. It's just that some device needs a cache flush before it sees all the changes. As far as I can see without adding additional complexity to the exporter this can only be archived in two ways: 1. Switch the role of the exporter and importer. This way the device with the need for the cache flush is the exporter and in control of the operations on its buffers. 2. We use DMA-buf as neutral mediator. Since DMA-buf keeps track of who has mapped the buffers it inserts the appropriate dma_sync_*_for_device() calls. [SNIP] The best we can do is to reject combinations which won't work in the kernel and then userspace could react accordingly. The question is whether userspace is able to deal with it, given the limited amount of information it gets from the kernel. Sure, there is always the ultimate fallback of memcpy(), but in many cases that would be totally unusable due to severe performance impact. If we were to remove the existing extent of implicit handling from the kernel, I think we need to first give the userspace the information necessary to explicitly handle the fallback to the same extent. Good point. We also need to think about backwards compatibility. Simply removing the implicit fallback cases would probably break a lot of userspace, so an opt-in behavior is likely needed initially... Yes, I'm completely aware of that as well. We can't hard break userspace even if the previous approach didn't worked 100% correctly. That's essentially the reason why we have DMA-buf heaps. Those heaps expose system memory buffers with certain properties (size, CMA, DMA bit restrictions etc...) and also implement the callback functions for CPU cache maintenance. How do DMA-buf heaps change anything here? We already have CPU cache maintenance callbacks in the DMA-buf API - the begin/end_cpu_access() for CPU accesses and dmabuf_map/unmap_attachment() for device accesses (which arguably shouldn't actually do CPU cache maintenance, unless that's implied by how either of the involved DMA engines work). DMA-buf heaps are the neutral man in the middle. The implementation keeps track of all the attached importers and should make sure that the allocated memory fits the need of everyone. Additional to that calls to the cache DMA-api cache management functions are inserted whenever CPU access begins/ends. I think in current design, it only knows all the importers after the buffer is already allocated, so it doesn't necessarily have a way to handle the allocation constraints. Something would have to be done to get all the importers attached before the allocation actually takes place. That's already in place. See the attach and map callbacks. I'm just not sure if heaps fully implements it like this. The problem is that in this particular case the exporter provides the buffer as is, e.g. with dirty CPU caches. And the importer can't deal with that. Why does the exporter leave the buffer with dirty CPU caches? Because exporters always export the buffers as they would use it. And in this case that means writing with the CPU to it. Sorry for the question not being very clear. I meant: How do the CPU caches get dirty in that case? The exporter wrote to it. As far as I understand the exporter just copies things from A to B with memcpy to construct the
Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add DISPCC node
On 12 December 2022 13:23:50 GMT+03:00, Konrad Dybcio
wrote:
>
>
>On 12.12.2022 11:18, Dmitry Baryshkov wrote:
>>
>>
>> On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio
>> wrote:
>>> Years after the SoC support has been added, it's high time for it to
>>> get dispcc going. Add the node to ensure that.
>>>
>>> Signed-off-by: Konrad Dybcio
>>> ---
>>> arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
>>> 1 file changed, 26 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> index a0c57fb798d3..ff0439f4 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>> @@ -3579,6 +3579,32 @@ camnoc_virt: interconnect@ac0 {
>>> qcom,bcm-voters = <_bcm_voter>;
>>> };
>>>
>>> + dispcc: clock-controller@af0 {
>>> + compatible = "qcom,sm8150-dispcc";
>>> + reg = <0 0x0af0 0 0x1>;
>>> + clocks = < RPMH_CXO_CLK>,
>>> +<0>,
>>> +<0>,
>>> +<0>,
>>> +<0>,
>>> +<0>,
>>> +<0>;
>>> + clock-names = "bi_tcxo",
>>> + "dsi0_phy_pll_out_byteclk",
>>> + "dsi0_phy_pll_out_dsiclk",
>>> + "dsi1_phy_pll_out_byteclk",
>>> + "dsi1_phy_pll_out_dsiclk",
>>> + "dp_phy_pll_link_clk",
>>> + "dp_phy_pll_vco_div_clk";
>>> + #clock-cells = <1>;
>>> + #reset-cells = <1>;
>>> + #power-domain-cells = <1>;
>>> +
>>> + power-domains = < SM8150_MMCX>;
>>> + /* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
>>> + required-opps = <_opp_low_svs>;
>>
>> Is it required for the dispcc, for the DSI or for the dpu? We have stumbled
>> upon the similar issue when working on the 8350, see the latest Robert's
>> patchset.
>While I don't have any hard evidence, it seems like it is required for
>any "interesting" multimedia components, AFAIU even including video and
>camera clocks..
>
>Seems like it's a deep down dependency for a lot of things on this
>particular SoC (and likely also on newer ones, remember the initial
>mess with 8250 mmcx?)
Yes. I was questioning the opp level rather than the domain itself. Usually the
least possible mmcx level is enough to get dispcc going. Then the consumers
(via the PLLs) bump this requirement.
In this particular case the vendor dtsi (sm8150-regulator.dtsi) declares that
the minimum level for mmcx is low_svs. So, I think, you can drop the todo
completely.
>
>Konrad
>>
>>
>>> + };
>>> +
>>> pdc: interrupt-controller@b22 {
>>> compatible = "qcom,sm8150-pdc", "qcom,pdc";
>>> reg = <0 0x0b22 0 0x400>;
>>
--
With best wishes
Dmitry
Re: [PATCH 3/3] arm64: dts: qcom: sm8150: Wire up MDSS
On 2022-12-12 10:33:14, Konrad Dybcio wrote: > Add required nodes for MDSS and hook up provided clocks in DISPCC. > This setup is almost identical to 8[23]50. > > Signed-off-by: Konrad Dybcio Reviewed-by: Marijn Suijten On Sony Xperia 5: Tested-by: Marijn Suijten Note that this device uses a command-mode panel which requires (since DPU 5.0.0) the TE functionality to be moved from the PP into the INTF block. I will send patches for this shortly, to enable proper vsyncing and presentation _without_ tearing. Note^2: We are also working to correct Display Stream Compression to work on the Sony Xperia 1 (bigger brother of Xperia 5 with a 4k display) and newer Sony devices on newer (sm8[234]50) SoCs! - Marijn
Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add DISPCC node
On 12.12.2022 11:18, Dmitry Baryshkov wrote:
>
>
> On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio
> wrote:
>> Years after the SoC support has been added, it's high time for it to
>> get dispcc going. Add the node to ensure that.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> index a0c57fb798d3..ff0439f4 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> @@ -3579,6 +3579,32 @@ camnoc_virt: interconnect@ac0 {
>> qcom,bcm-voters = <_bcm_voter>;
>> };
>>
>> +dispcc: clock-controller@af0 {
>> +compatible = "qcom,sm8150-dispcc";
>> +reg = <0 0x0af0 0 0x1>;
>> +clocks = < RPMH_CXO_CLK>,
>> + <0>,
>> + <0>,
>> + <0>,
>> + <0>,
>> + <0>,
>> + <0>;
>> +clock-names = "bi_tcxo",
>> + "dsi0_phy_pll_out_byteclk",
>> + "dsi0_phy_pll_out_dsiclk",
>> + "dsi1_phy_pll_out_byteclk",
>> + "dsi1_phy_pll_out_dsiclk",
>> + "dp_phy_pll_link_clk",
>> + "dp_phy_pll_vco_div_clk";
>> +#clock-cells = <1>;
>> +#reset-cells = <1>;
>> +#power-domain-cells = <1>;
>> +
>> +power-domains = < SM8150_MMCX>;
>> +/* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
>> +required-opps = <_opp_low_svs>;
>
> Is it required for the dispcc, for the DSI or for the dpu? We have stumbled
> upon the similar issue when working on the 8350, see the latest Robert's
> patchset.
While I don't have any hard evidence, it seems like it is required for
any "interesting" multimedia components, AFAIU even including video and
camera clocks..
Seems like it's a deep down dependency for a lot of things on this
particular SoC (and likely also on newer ones, remember the initial
mess with 8250 mmcx?)
Konrad
>
>
>> +};
>> +
>> pdc: interrupt-controller@b22 {
>> compatible = "qcom,sm8150-pdc", "qcom,pdc";
>> reg = <0 0x0b22 0 0x400>;
>
[PATCH] drm/nouveau/kms/nv50- (gcc13): fix nv50_wndw_new_ prototype
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int,
const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of
'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct
drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum
nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)'
It can be barely visible, but the declaration says about the parameters
in the middle:
enum nv50_disp_interlock_type,
u32 interlock_data,
u32 heads,
While the definition states differently:
u32 heads,
enum nv50_disp_interlock_type interlock_type,
u32 interlock_data,
Unify/fix the declaration to match the definition.
Cc: Martin Liska
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE)
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index 591c852f326b..76a6ae5d5652 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -35,8 +35,9 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads,
+ enum nv50_disp_interlock_type, u32 interlock_data,
+ struct nv50_wndw **);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
struct nv50_wndw_atom *);
void nv50_wndw_flush_clr(struct nv50_wndw *, u32 *interlock, bool flush,
--
2.38.1
Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add DISPCC node
On 2022-12-12 10:33:13, Konrad Dybcio wrote:
> Years after the SoC support has been added, it's high time for it to
> get dispcc going. Add the node to ensure that.
>
> Signed-off-by: Konrad Dybcio
On Sony Xperia 5:
Tested-by: Marijn Suijten
Reviewed-by: Marijn Suijten
> ---
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> index a0c57fb798d3..ff0439f4 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -3579,6 +3579,32 @@ camnoc_virt: interconnect@ac0 {
> qcom,bcm-voters = <_bcm_voter>;
> };
>
> + dispcc: clock-controller@af0 {
> + compatible = "qcom,sm8150-dispcc";
> + reg = <0 0x0af0 0 0x1>;
> + clocks = < RPMH_CXO_CLK>,
> + <0>,
> + <0>,
> + <0>,
> + <0>,
> + <0>,
> + <0>;
> + clock-names = "bi_tcxo",
> + "dsi0_phy_pll_out_byteclk",
> + "dsi0_phy_pll_out_dsiclk",
> + "dsi1_phy_pll_out_byteclk",
> + "dsi1_phy_pll_out_dsiclk",
> + "dp_phy_pll_link_clk",
> + "dp_phy_pll_vco_div_clk";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> +
> + power-domains = < SM8150_MMCX>;
> + /* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
Is this still something we want to check/test? Do we need a reference
manual to be sure?
> + required-opps = <_opp_low_svs>;
> + };
> +
> pdc: interrupt-controller@b22 {
> compatible = "qcom,sm8150-pdc", "qcom,pdc";
> reg = <0 0x0b22 0 0x400>;
> --
> 2.38.1
>
Re: [PATCH 2/3] arm64: dts: qcom: sm8150: Add DISPCC node
On 12 December 2022 12:33:13 GMT+03:00, Konrad Dybcio
wrote:
>Years after the SoC support has been added, it's high time for it to
>get dispcc going. Add the node to ensure that.
>
>Signed-off-by: Konrad Dybcio
>---
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
> 1 file changed, 26 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>index a0c57fb798d3..ff0439f4 100644
>--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>@@ -3579,6 +3579,32 @@ camnoc_virt: interconnect@ac0 {
> qcom,bcm-voters = <_bcm_voter>;
> };
>
>+ dispcc: clock-controller@af0 {
>+ compatible = "qcom,sm8150-dispcc";
>+ reg = <0 0x0af0 0 0x1>;
>+ clocks = < RPMH_CXO_CLK>,
>+ <0>,
>+ <0>,
>+ <0>,
>+ <0>,
>+ <0>,
>+ <0>;
>+ clock-names = "bi_tcxo",
>+"dsi0_phy_pll_out_byteclk",
>+"dsi0_phy_pll_out_dsiclk",
>+"dsi1_phy_pll_out_byteclk",
>+"dsi1_phy_pll_out_dsiclk",
>+"dp_phy_pll_link_clk",
>+"dp_phy_pll_vco_div_clk";
>+ #clock-cells = <1>;
>+ #reset-cells = <1>;
>+ #power-domain-cells = <1>;
>+
>+ power-domains = < SM8150_MMCX>;
>+ /* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
>+ required-opps = <_opp_low_svs>;
Is it required for the dispcc, for the DSI or for the dpu? We have stumbled
upon the similar issue when working on the 8350, see the latest Robert's
patchset.
>+ };
>+
> pdc: interrupt-controller@b22 {
> compatible = "qcom,sm8150-pdc", "qcom,pdc";
> reg = <0 0x0b22 0 0x400>;
--
With best wishes
Dmitry
