Re: [PATCH 1/3] drm/i915/guc: Fix missing ecodes
Reviewed-by: Alan Previn
On Thu, 2023-02-02 at 17:10 -0800, Harrison, John C wrote:
> From: John Harrison
>
> Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
> number that is meant to distinguish similar seeming bugs with
> different underlying signatures. It is a combination of two ring state
> registers. Unfortunately, the register state being used is only valid
> in execlist mode. In GuC mode, the register state exists in a separate
> list of arbitrary register address/value pairs rather than the named
> entry structure. So, search through that list to find the two exciting
> registers and copy them over to the structure's named members.
>
> v2: if else if instead of if if (Alan)
>
> Signed-off-by: John Harrison
> Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
> Cc: Alan Previn
> Cc: Umesh Nerlige Ramappa
> Cc: Lucas De Marchi
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Aravind Iddamsetty
> Cc: Michael Cheng
> Cc: Matthew Brost
> Cc: Bruce Chang
> Cc: Daniele Ceraolo Spurio
> Cc: Matthew Auld
> ---
>
alan:snip
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Clean up of register capture search
I see you are inferring that a guc-id of zero can be valid.
I am guessing that might have contributed to some lost captures?
Thanks for catching this.
Reviewed-by: Alan Previn
On Thu, 2023-02-02 at 17:10 -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The comparison in the search for a matching register capture node was
> not the most readable. So remove two redundant terms and re-format to
> keep each term on a single line, and only one term per line.
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 710999d7189ee..87b080dd6bead 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -1627,9 +1627,8 @@ void intel_guc_capture_get_matching_node(struct
> intel_gt *gt,
> list_for_each_entry_safe(n, ntmp, &guc->capture->outlist, link) {
> if (n->eng_inst ==
> GUC_ID_TO_ENGINE_INSTANCE(ee->engine->guc_id) &&
> n->eng_class ==
> GUC_ID_TO_ENGINE_CLASS(ee->engine->guc_id) &&
> - n->guc_id && n->guc_id == ce->guc_id.id &&
> - (n->lrca & CTX_GTT_ADDRESS_MASK) && (n->lrca &
> CTX_GTT_ADDRESS_MASK) ==
> - (ce->lrc.lrca & CTX_GTT_ADDRESS_MASK)) {
> + n->guc_id == ce->guc_id.id &&
> + (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca &
> CTX_GTT_ADDRESS_MASK)) {
> list_del(&n->link);
> ee->guc_capture_node = n;
> ee->guc_capture = guc->capture;
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/3/23 19:34, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: On 2/3/23 11:00, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: On 2/3/23 10:19, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: On 2/3/23 07:59, Sebastian Wick wrote: On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: Userspace has no way of controlling or knowing the pixel encoding currently, so there is no way for it to ever get the right values here. That applies to a lot of the other values as well (they are explicitly RGB or YCC). The idea was that this property sets the infoframe/MSA/SDP value exactly, and other properties should be added to for use userspace to control the pixel encoding/colorspace conversion(if desired, or userspace just makes sure to directly feed in correct kind of data). I'm all for getting userspace control over pixel encoding but even then the kernel always knows which pixel encoding is selected and which InfoFrame has to be sent. Is there a reason why userspace would want to control the variant explicitly to the wrong value? I've asked this before but haven't seen an answer: Is there an existing upstream userspace project that makes use of this property (other than what Joshua is working on in gamescope right now)? That would help us understand the intent better. The intent was to control the infoframe colorimetry bits, nothing more. No idea what real userspace there was, if any. Controlling the infoframe alone isn't useful at all unless you can guarantee the wire encoding, which we cannot do. I don't think giving userspace explicit control over the exact infoframe values is the right thing to do. +1 Only userspace knows what kind of data it's stuffing into the pixels (and/or how it configures the csc units/etc.) to generate them. Yes, but userspace doesn't control or know whether we drive RGB or YCbCr on the wire. In fact, in some cases our driver needs to fallback to YCbCr420 for bandwidth reasons. There is currently no way for userspace to know that and I don't think it makes sense. People want that control as well for whatever reason. We've been asked to allow YCbCr 4:4:4 output many times. The automagic 4:2:0 fallback I think is rather fundementally incompatible with fancy color management. How would we even know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 that stuff is just always BT.709 limited range, no questions asked. That's what the Colorspace property *should* be determining here. That's what we have it set up to do in SteamOS/my tree right now. We use what we're telling the display, i.e., the value in the colorspace property. That way we know whether to use a BT.2020 or BT.709 matrix. And given how these things have gone in the past I think that is likey to bite someone at in the future. Also not what this property was meant to do nor does on any other driver AFAIK. I don't see how it's fundamentally incompatible with fancy color management stuff. If we start forbidding drivers from falling back to YCbCr (whether 4:4:4 or 4:2:0) we will break existing behavior on amdgpu and will see bug reports. The compositors could deal with that if/when they start doing the full color management stuff. The current stuff only really works when the kernel is allowed to do whatever it wants. So I think if userspace wants real color management it's going to have to set up the whole pipeline. And for that we need at least one new property to control the RGB->YCbCr conversion (or to explicitly avoid it). I mentioned this in my commit description, we absolutely should offer fine control here eventually. I don't think we need to solve that problem here though. And given that the proposed patch just swept all the non-BT.2020 issues under the rug makes me think no one has actually come up with any kind of consistent plan for anything else really. Does anyone actually use the non-BT.2020 colorspace stuff? No idea if anyone is using any of it. It's a bit hard to do right now outside the full passthrough case since we have no properties to control how the hardware will convert stuff. No, every userspace knows that encoding of the output buffer before going to the wire format is RGB. It's the only way you can have planes alpha-blend, or mix and match RGB and NV12, etc. Anyways, sounds like what you're basically proposing is getting rid of this property and starting from scratch. Hmm. I guess one option would be to add that property to control the output encoding, but include a few extra "automagic" values to it which would retain the kernel's freedom to select whether to do the RGB->YCbCr conversion or not. enum output_encod
[PATCH] drm/i915/pxp: limit drm-errors or warning on firmware API failures
MESA driver is creating protected context on every driver handle
creation to query caps bits for app. So when running CI tests,
they are observing hundreds of drm_errors when enabling PXP
in .config but using SOC fusing or BIOS configuration that cannot
support PXP sessions.
The fixes tag referenced below was to resolve a related issue
where we wanted to silence error messages, but that case was due
to outdated IFWI (firmware) that definitely needed an upgrade and
was, at that point, considered a one-off case as opposed to today's
realization that default CI was enabling PXP in kernel config for
all testing.
So with this patch, let's strike a balance between issues that is
critical but are root-caused from HW/platform gaps (louder drm-warn
but just ONCE) vs other cases where it could also come from session
state machine (which cannot be a WARN_ONCE since it can be triggered
due to runtime operation events).
Let's use helpers for these so as more functions are added in future
features / HW (or as FW designers continue to bless upstreaming of
the error codes and meanings), we only need to update the helpers.
NOTE: Don't completely remove FW errors (via drm_debug) or else cusomer
apps that really needs to know that content protection failed won't
be aware of it.
Fixes: b762787bf767 ("drm/i915/pxp: Use drm_dbg if arb session failed due to fw
version")
Signed-off-by: Alan Previn
---
.../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 73 +++
3 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index ae9b151b7cb7..6f6541d5e49a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -18,6 +18,9 @@
enum pxp_status {
PXP_STATUS_SUCCESS = 0x0,
PXP_STATUS_ERROR_API_VERSION = 0x1002,
+ PXP_STATUS_NOT_READY = 0x100e,
+ PXP_STATUS_PLATFCONFIG_KF1_NOVERIF = 0x101a,
+ PXP_STATUS_PLATFCONFIG_KF1_BAD = 0x101f,
PXP_STATUS_OP_NOT_PERMITTED = 0x4013
};
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 448cacb0465d..7de849cb6c47 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -74,7 +74,7 @@ static int pxp_create_arb_session(struct intel_pxp *pxp)
ret = pxp_wait_for_session_state(pxp, ARB_SESSION, true);
if (ret) {
- drm_err(>->i915->drm, "arb session failed to go in play\n");
+ drm_dbg(>->i915->drm, "arb session failed to go in play\n");
return ret;
}
drm_dbg(>->i915->drm, "PXP ARB session is alive\n");
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d9d248b48093..2d3bcff93da3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -19,6 +19,37 @@
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
+static bool
+is_fw_err_platform_config(u32 type)
+{
+ switch (type) {
+ case PXP_STATUS_ERROR_API_VERSION:
+ case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
+ case PXP_STATUS_PLATFCONFIG_KF1_BAD:
+ return true;
+ default:
+ break;
+ }
+ return false;
+}
+
+static const char *
+fw_err_to_string(u32 type)
+{
+ switch (type) {
+ case PXP_STATUS_ERROR_API_VERSION:
+ return "ERR_API_VERSION";
+ case PXP_STATUS_NOT_READY:
+ return "ERR_NOT_READY";
+ case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
+ case PXP_STATUS_PLATFCONFIG_KF1_BAD:
+ return "ERR_PLATFORM_CONFIG";
+ default:
+ break;
+ }
+ return NULL;
+}
+
static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
void *msg_in, u32 msg_in_size,
void *msg_out, u32 msg_out_max_size,
@@ -307,15 +338,21 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
&msg_out, sizeof(msg_out),
NULL);
- if (ret)
- drm_err(&i915->drm, "Failed to send tee msg ret=[%d]\n", ret);
- else if (msg_out.header.status == PXP_STATUS_ERROR_API_VERSION)
- drm_dbg(&i915->drm, "PXP firmware version unsupported,
requested: "
- "CMD-ID-[0x%08x] on API-Ver-[0x%08x]\n",
- msg_in.header.command_id, msg_in.header.api_version);
- else if (msg_out.header.status != 0x0)
- drm_warn(&i915->drm, "PXP firmware failed arb session init
request ret=[0x%08x]\n",
-msg_out.header.status);
+ if (ret) {
Re: [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
On 2/3/2023 8:10 PM, Dmitry Baryshkov wrote: On 04/02/2023 04:43, Abhinav Kumar wrote: On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote: On 04/02/2023 01:35, Abhinav Kumar wrote: On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote: Downstream driver uses dpu->caps->smart_dma_rev to update sspp->cap->features with the bit corresponding to the supported SmartDMA version. Upstream driver does not do this, resulting in SSPP subdriver not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP feature bits to dpu hw catalog. While reviewing this patch, I had a first hand experience of how we are reusing SSPP bitmasks for so many chipsets but I think overall you got them right here :) Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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 cf053e8f081e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,13 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -42,6 +45,7 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other chipsets like 8250, 8450, 8550. At the moment, for visual validation of this series, I only have sc7180/sc7280. We are leaving the rest for CI. Was that an intentional approach? If so, we will need tested-by tags from folks having 8350/8450/8550/sc8280x,qcm2290? I am only owning the visual validation on sc7280 atm. I'm not quite sure what is your intent here. Are there any SoCs after 845 that do not have SmartDMA 2.5? Or do you propose to enable SmartDMA only for the chipsets that we can visually test? That sounds strange. Yes I was thinking to enable smartDMA at the moment on chipsets which we can validate visually that display comes up. But I am not sure if thats entirely practical. But the intent was I just want to make sure basic display does come up with smartDMA enabled if we are enabling it for all chipsets. I don't think it is practical or logical. We don't require validating other changes on all possible chipsets, so what is so different with this one? Thats because with smartDMA if the programming of stages goes wrong we could potentially just see a blank screen. Its not about other changes, this change in particular controls enabling a feature. But thats just my thought. I am not going to request to ensure this or block this for this. You can still have my Reviewed-by: Abhinav Kumar But think of the validations that have to be done before we merge it.
Re: [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
On 04/02/2023 04:43, Abhinav Kumar wrote: On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote: On 04/02/2023 01:35, Abhinav Kumar wrote: On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote: Downstream driver uses dpu->caps->smart_dma_rev to update sspp->cap->features with the bit corresponding to the supported SmartDMA version. Upstream driver does not do this, resulting in SSPP subdriver not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP feature bits to dpu hw catalog. While reviewing this patch, I had a first hand experience of how we are reusing SSPP bitmasks for so many chipsets but I think overall you got them right here :) Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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 cf053e8f081e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,13 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -42,6 +45,7 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other chipsets like 8250, 8450, 8550. At the moment, for visual validation of this series, I only have sc7180/sc7280. We are leaving the rest for CI. Was that an intentional approach? If so, we will need tested-by tags from folks having 8350/8450/8550/sc8280x,qcm2290? I am only owning the visual validation on sc7280 atm. I'm not quite sure what is your intent here. Are there any SoCs after 845 that do not have SmartDMA 2.5? Or do you propose to enable SmartDMA only for the chipsets that we can visually test? That sounds strange. Yes I was thinking to enable smartDMA at the moment on chipsets which we can validate visually that display comes up. But I am not sure if thats entirely practical. But the intent was I just want to make sure basic display does come up with smartDMA enabled if we are enabling it for all chipsets. I don't think it is practical or logical. We don't require validating other changes on all possible chipsets, so what is so different with this one? -- With best wishes Dmitry
[PATCH] drm/amd/amdgpu: add complete header search path
The path for the "mod_info_packet.h" header file is
incomplete, so add its location to the header search path
in the amdgpu Makefile.
See on ARCH=alpha (275 times in one build).
In file included from ../drivers/gpu/drm/amd/amdgpu/amdgpu.h:90,
from ../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:43:
../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:62:10: fatal
error: mod_info_packet.h: No such file or directory
62 | #include "mod_info_packet.h"
| ^~~
compilation terminated.
Fixes: 5b49da02ddbe ("drm/amd/display: Enable Freesync over PCon")
Signed-off-by: Randy Dunlap
Cc: Signed-off-by: Sung Joon Kim
Cc: Alex Deucher
Cc: Christian König
Cc: "Pan, Xinhui"
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/Makefile |1 +
1 file changed, 1 insertion(+)
diff -- a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -34,6 +34,7 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/
-I$(FULL_AMD_PATH)/acp/include \
-I$(FULL_AMD_DISPLAY_PATH) \
-I$(FULL_AMD_DISPLAY_PATH)/include \
+ -I$(FULL_AMD_DISPLAY_PATH)/modules/inc \
-I$(FULL_AMD_DISPLAY_PATH)/dc \
-I$(FULL_AMD_DISPLAY_PATH)/amdgpu_dm \
-I$(FULL_AMD_PATH)/amdkfd
Re: [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote: On 04/02/2023 01:35, Abhinav Kumar wrote: On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote: Downstream driver uses dpu->caps->smart_dma_rev to update sspp->cap->features with the bit corresponding to the supported SmartDMA version. Upstream driver does not do this, resulting in SSPP subdriver not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP feature bits to dpu hw catalog. While reviewing this patch, I had a first hand experience of how we are reusing SSPP bitmasks for so many chipsets but I think overall you got them right here :) Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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 cf053e8f081e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,13 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -42,6 +45,7 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other chipsets like 8250, 8450, 8550. At the moment, for visual validation of this series, I only have sc7180/sc7280. We are leaving the rest for CI. Was that an intentional approach? If so, we will need tested-by tags from folks having 8350/8450/8550/sc8280x,qcm2290? I am only owning the visual validation on sc7280 atm. I'm not quite sure what is your intent here. Are there any SoCs after 845 that do not have SmartDMA 2.5? Or do you propose to enable SmartDMA only for the chipsets that we can visually test? That sounds strange. Yes I was thinking to enable smartDMA at the moment on chipsets which we can validate visually that display comes up. But I am not sure if thats entirely practical. But the intent was I just want to make sure basic display does come up with smartDMA enabled if we are enabling it for all chipsets.
Re: [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
On 04/02/2023 01:35, Abhinav Kumar wrote: On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote: Downstream driver uses dpu->caps->smart_dma_rev to update sspp->cap->features with the bit corresponding to the supported SmartDMA version. Upstream driver does not do this, resulting in SSPP subdriver not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP feature bits to dpu hw catalog. While reviewing this patch, I had a first hand experience of how we are reusing SSPP bitmasks for so many chipsets but I think overall you got them right here :) Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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 cf053e8f081e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,13 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -42,6 +45,7 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other chipsets like 8250, 8450, 8550. At the moment, for visual validation of this series, I only have sc7180/sc7280. We are leaving the rest for CI. Was that an intentional approach? If so, we will need tested-by tags from folks having 8350/8450/8550/sc8280x,qcm2290? I am only owning the visual validation on sc7280 atm. I'm not quite sure what is your intent here. Are there any SoCs after 845 that do not have SmartDMA 2.5? Or do you propose to enable SmartDMA only for the chipsets that we can visually test? That sounds strange. -- With best wishes Dmitry
Re: [PATCH 2/3] drm/scheduler: Fix elapsed_ns kernel-doc error
On 2/3/23 18:27, Lucas Stach wrote: > Thanks, I've added this to the etnaviv tree. > > Since the commit is only in -next and not a non-rebase tree yet, I > might be tempted to squash the fix into the offending commit. What > would be the right way to credit you for the fix in that case? > On SoB area, you can add: [Bagas: Append missing colon to @elapsed_ns] Signed-off-by: Bagas Sanjaya Thanks. -- An old man doll... just what I always wanted! - Clara
Re: [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote: Downstream driver uses dpu->caps->smart_dma_rev to update sspp->cap->features with the bit corresponding to the supported SmartDMA version. Upstream driver does not do this, resulting in SSPP subdriver not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP feature bits to dpu hw catalog. While reviewing this patch, I had a first hand experience of how we are reusing SSPP bitmasks for so many chipsets but I think overall you got them right here :) Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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 cf053e8f081e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,13 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -42,6 +45,7 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other chipsets like 8250, 8450, 8550. At the moment, for visual validation of this series, I only have sc7180/sc7280. We are leaving the rest for CI. Was that an intentional approach? If so, we will need tested-by tags from folks having 8350/8450/8550/sc8280x,qcm2290? I am only owning the visual validation on sc7280 atm.
Re: [PATCH v3 17/27] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format
On 04/02/2023 01:07, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
Nothing wrong with the change as such but why is this needed?
I looked through tne next patches in the series briefly and unless I am
missing something, I am not able to see how this rewrite is helping or
needed for the remaining patches.
Having a separate pipe argument eases adding support for r_pipe. After
all these changes only upper level functions access pstate->pipe. Then
it becomes natural to do:
dpu_plane_do_something(plane->pipe);
if (plane->r_pipe)
dpu_plane_do_something(plane->r_pipe);
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
1 file changed, 47 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5aabf9694a53..ee261a591d45 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -128,19 +128,18 @@ static struct dpu_kms *_dpu_plane_get_kms(struct
drm_plane *plane)
/**
* _dpu_plane_calc_bw - calculate bandwidth required for a plane
* @plane: Pointer to drm plane.
- * @fb: Pointer to framebuffer associated with the given plane
+ * @fmt: Pointer to source buffer format
* @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated bandwidth in the plane state.
* BW Equation: src_w * src_h * bpp * fps * (v_total / v_dest)
* Prefill BW Equation: line src bytes * line_time
*/
static void _dpu_plane_calc_bw(struct drm_plane *plane,
- struct drm_framebuffer *fb,
+ const struct dpu_format *fmt,
struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane_state *pstate;
struct drm_display_mode *mode;
- const struct dpu_format *fmt = NULL;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
int src_width, src_height, dst_height, fps;
u64 plane_prefill_bw;
@@ -152,8 +151,6 @@ static void _dpu_plane_calc_bw(struct drm_plane
*plane,
pstate = to_dpu_plane_state(plane->state);
mode = &plane->state->crtc->mode;
- fmt = dpu_get_dpu_format_ext(fb->format->format, fb->modifier);
-
src_width = drm_rect_width(&pipe_cfg->src_rect);
src_height = drm_rect_height(&pipe_cfg->src_rect);
dst_height = drm_rect_height(&pipe_cfg->dst_rect);
@@ -217,25 +214,25 @@ static void _dpu_plane_calc_clk(struct drm_plane
*plane, struct dpu_hw_sspp_cfg
/**
* _dpu_plane_calc_fill_level - calculate fill level of the given
source format
* @plane: Pointer to drm plane
+ * @pipe: Pointer to software pipe
* @fmt: Pointer to source buffer format
* @src_width: width of source buffer
* Return: fill level corresponding to the source buffer/format or 0
if error
*/
static int _dpu_plane_calc_fill_level(struct drm_plane *plane,
+ struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt, u32 src_width)
{
struct dpu_plane *pdpu;
- struct dpu_plane_state *pstate;
u32 fixed_buff_size;
u32 total_fl;
- if (!fmt || !plane->state || !src_width || !fmt->bpp) {
+ if (!fmt || !pipe || !src_width || !fmt->bpp) {
DPU_ERROR("invalid arguments\n");
return 0;
}
pdpu = to_dpu_plane(plane);
- pstate = to_dpu_plane_state(plane->state);
fixed_buff_size = pdpu->catalog->caps->pixel_ram_size;
/* FIXME: in multirect case account for the src_width of all the
planes */
@@ -251,7 +248,7 @@ static int _dpu_plane_calc_fill_level(struct
drm_plane *plane,
((src_width + 32) * fmt->bpp);
}
} else {
- if (pstate->pipe.multirect_mode ==
DPU_SSPP_MULTIRECT_PARALLEL) {
+ if (pipe->multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL) {
total_fl = (fixed_buff_size / 2) * 2 /
((src_width + 32) * fmt->bpp);
} else {
@@ -261,7 +258,7 @@ static int _dpu_plane_calc_fill_level(struct
drm_plane *plane,
}
DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s w:%u fl:%u\n",
- pdpu->pipe - SSPP_VIG0,
+ pipe->sspp->idx - SSPP_VIG0,
(char *)&fmt->base.pixel_format,
src_width, total_fl);
@@ -271,25 +268,22 @@ static int _dpu_plane_calc_fill_level(struct
drm_plane *plane,
/**
* _dpu_plane_set_qos_lut - set QoS LUT of the given plane
* @plane: Pointer to drm plane
- * @fb: Pointer to framebuffer associated with the given
plane
+ * @pipe: Pointer to software pipe
+ * @fmt: Pointer to source buffer format
* @pipe_cfg: Pointer to pipe configuration
*/
static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
- struct drm_framebuffer *fb, struct dpu_hw_sspp_cfg *pipe_cfg)
+
[PATCH] Revert "fbdev: Remove conflicting devices on PCI bus"
From: Bjorn Helgaas
This reverts commit 145eed48de278007f646b908fd70ac59d24ed81a.
Zeno Davatz reported that 145eed48de27 ("fbdev: Remove conflicting devices
on PCI bus") caused a console hang. The machine was actually still usable
via ssh, etc., but there was no activity on the console.
Reverting 145eed48de27 for the nvidiafb on that system fixed the problem.
Revert 145eed48de27 ("fbdev: Remove conflicting devices on PCI bus") since
we don't know what caused the problem.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=216859
Reported-by: Zeno Davatz
Tested-by: Zeno Davatz
Signed-off-by: Bjorn Helgaas
Cc: Helge Deller
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/video/fbdev/arkfb.c | 5 -
drivers/video/fbdev/asiliantfb.c | 5 -
drivers/video/fbdev/aty/aty128fb.c | 5 -
drivers/video/fbdev/aty/atyfb_base.c | 7 +--
drivers/video/fbdev/carminefb.c | 5 -
drivers/video/fbdev/chipsfb.c| 7 +--
drivers/video/fbdev/cirrusfb.c | 5 -
drivers/video/fbdev/cyber2000fb.c| 5 -
drivers/video/fbdev/geode/gx1fb_core.c | 5 -
drivers/video/fbdev/geode/gxfb_core.c| 5 -
drivers/video/fbdev/geode/lxfb_core.c| 5 -
drivers/video/fbdev/gxt4500.c| 5 -
drivers/video/fbdev/i740fb.c | 5 -
drivers/video/fbdev/i810/i810_main.c | 5 -
drivers/video/fbdev/imsttfb.c| 8 +---
drivers/video/fbdev/intelfb/intelfbdrv.c | 5 -
drivers/video/fbdev/kyro/fbdev.c | 5 -
drivers/video/fbdev/matrox/matroxfb_base.c | 5 -
drivers/video/fbdev/mb862xx/mb862xxfbdrv.c | 5 -
drivers/video/fbdev/neofb.c | 5 -
drivers/video/fbdev/nvidia/nvidia.c | 7 +--
drivers/video/fbdev/pm2fb.c | 5 -
drivers/video/fbdev/pm3fb.c | 5 -
drivers/video/fbdev/pvr2fb.c | 5 -
drivers/video/fbdev/riva/fbdev.c | 5 -
drivers/video/fbdev/s3fb.c | 5 -
drivers/video/fbdev/savage/savagefb_driver.c | 5 -
drivers/video/fbdev/sis/sis_main.c | 5 -
drivers/video/fbdev/skeletonfb.c | 8
drivers/video/fbdev/sm712fb.c| 5 -
drivers/video/fbdev/sstfb.c | 5 -
drivers/video/fbdev/sunxvr2500.c | 5 -
drivers/video/fbdev/sunxvr500.c | 5 -
drivers/video/fbdev/tdfxfb.c | 5 -
drivers/video/fbdev/tgafb.c | 7 ---
drivers/video/fbdev/tridentfb.c | 5 -
drivers/video/fbdev/vermilion/vermilion.c| 7 +--
drivers/video/fbdev/via/via-core.c | 5 -
drivers/video/fbdev/vt8623fb.c | 5 -
39 files changed, 5 insertions(+), 206 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index 60a96fdb5dd8..41b9117c55bb 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -11,7 +11,6 @@
* Code is based on s3fb
*/
-#include
#include
#include
#include
@@ -949,10 +948,6 @@ static int ark_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
int rc;
u8 regval;
- rc = aperture_remove_conflicting_pci_devices(dev, "arkfb");
- if (rc < 0)
- return rc;
-
/* Ignore secondary VGA device because there is no VGA arbitration */
if (! svga_primary_device(dev)) {
dev_info(&(dev->dev), "ignoring secondary device\n");
diff --git a/drivers/video/fbdev/asiliantfb.c b/drivers/video/fbdev/asiliantfb.c
index 8383468f5577..4a98383eb274 100644
--- a/drivers/video/fbdev/asiliantfb.c
+++ b/drivers/video/fbdev/asiliantfb.c
@@ -29,7 +29,6 @@
* more details.
*/
-#include
#include
#include
#include
@@ -546,10 +545,6 @@ static int asiliantfb_pci_init(struct pci_dev *dp,
struct fb_info *p;
int err;
- err = aperture_remove_conflicting_pci_devices(dp, "asiliantfb");
- if (err)
- return err;
-
if ((dp->resource[0].flags & IORESOURCE_MEM) == 0)
return -ENODEV;
addr = pci_resource_start(dp, 0);
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index dd31b9d7d337..a5cb33feaf4a 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -47,7 +47,6 @@
*/
-#include
#include
#include
#include
@@ -2056,10 +2055,6 @@ static int aty128_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
void __iomem *bios = NULL;
#endif
- err = aperture_remove_conflicting_pci_devices(pdev, "aty128fb");
- if (err)
- return err;
-
/* Enable device
Re: [PATCH v3 17/27] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
Nothing wrong with the change as such but why is this needed?
I looked through tne next patches in the series briefly and unless I am
missing something, I am not able to see how this rewrite is helping or
needed for the remaining patches.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
1 file changed, 47 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5aabf9694a53..ee261a591d45 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -128,19 +128,18 @@ static struct dpu_kms *_dpu_plane_get_kms(struct
drm_plane *plane)
/**
* _dpu_plane_calc_bw - calculate bandwidth required for a plane
* @plane: Pointer to drm plane.
- * @fb: Pointer to framebuffer associated with the given plane
+ * @fmt: Pointer to source buffer format
* @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated bandwidth in the plane state.
* BW Equation: src_w * src_h * bpp * fps * (v_total / v_dest)
* Prefill BW Equation: line src bytes * line_time
*/
static void _dpu_plane_calc_bw(struct drm_plane *plane,
- struct drm_framebuffer *fb,
+ const struct dpu_format *fmt,
struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane_state *pstate;
struct drm_display_mode *mode;
- const struct dpu_format *fmt = NULL;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
int src_width, src_height, dst_height, fps;
u64 plane_prefill_bw;
@@ -152,8 +151,6 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
pstate = to_dpu_plane_state(plane->state);
mode = &plane->state->crtc->mode;
- fmt = dpu_get_dpu_format_ext(fb->format->format, fb->modifier);
-
src_width = drm_rect_width(&pipe_cfg->src_rect);
src_height = drm_rect_height(&pipe_cfg->src_rect);
dst_height = drm_rect_height(&pipe_cfg->dst_rect);
@@ -217,25 +214,25 @@ static void _dpu_plane_calc_clk(struct drm_plane *plane,
struct dpu_hw_sspp_cfg
/**
* _dpu_plane_calc_fill_level - calculate fill level of the given source
format
* @plane:Pointer to drm plane
+ * @pipe: Pointer to software pipe
* @fmt: Pointer to source buffer format
* @src_width:width of source buffer
* Return: fill level corresponding to the source buffer/format or 0 if error
*/
static int _dpu_plane_calc_fill_level(struct drm_plane *plane,
+ struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt, u32 src_width)
{
struct dpu_plane *pdpu;
- struct dpu_plane_state *pstate;
u32 fixed_buff_size;
u32 total_fl;
- if (!fmt || !plane->state || !src_width || !fmt->bpp) {
+ if (!fmt || !pipe || !src_width || !fmt->bpp) {
DPU_ERROR("invalid arguments\n");
return 0;
}
pdpu = to_dpu_plane(plane);
- pstate = to_dpu_plane_state(plane->state);
fixed_buff_size = pdpu->catalog->caps->pixel_ram_size;
/* FIXME: in multirect case account for the src_width of all the planes */
@@ -251,7 +248,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
((src_width + 32) * fmt->bpp);
}
} else {
- if (pstate->pipe.multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL)
{
+ if (pipe->multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL) {
total_fl = (fixed_buff_size / 2) * 2 /
((src_width + 32) * fmt->bpp);
} else {
@@ -261,7 +258,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
}
DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s w:%u fl:%u\n",
- pdpu->pipe - SSPP_VIG0,
+ pipe->sspp->idx - SSPP_VIG0,
(char *)&fmt->base.pixel_format,
src_width, total_fl);
@@ -271,25 +268,22 @@ static int _dpu_plane_calc_fill_level(struct drm_plane *plane,
/**
* _dpu_plane_set_qos_lut - set QoS LUT of the given plane
* @plane:Pointer to drm plane
- * @fb:Pointer to framebuffer associated with the
given plane
+ * @pipe: Pointer to software pipe
+ * @fmt: Pointer to source buffer format
* @pipe_cfg: Pointer to pipe configuration
*/
static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
- struct drm_framebuffer *fb, struct dpu_hw_sspp_cfg *pipe_cfg)
+ struct dpu_sw_pipe *pipe,
+ const struct dpu_fo
Re: [PATCH v3 16/27] drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check()
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index bd09bb319a58..73e1a8c69ef0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1132,11 +1132,9 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
const struct drm_plane_state *pstate;
struct drm_plane *plane;
- struct drm_display_mode *mode;
int rc = 0;
- struct drm_rect crtc_rect = { 0 };
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
if (!crtc_state->enable || !crtc_state->active) {
@@ -1147,7 +1145,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
- mode = &crtc_state->adjusted_mode;
DRM_DEBUG_ATOMIC("%s: check\n", dpu_crtc->name);
/* force a full mode set if active state changed */
@@ -1157,13 +1154,9 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
if (cstate->num_mixers)
_dpu_crtc_setup_lm_bounds(crtc, crtc_state);
- crtc_rect.x2 = mode->hdisplay;
- crtc_rect.y2 = mode->vdisplay;
-
/* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
- struct drm_rect dst, clip = crtc_rect;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1176,15 +1169,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
continue;
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
-
- dst = drm_plane_state_dest(pstate);
- if (!drm_rect_intersect(&clip, &dst)) {
- DPU_ERROR("invalid vertical/horizontal destination\n");
- DPU_ERROR("display: " DRM_RECT_FMT " plane: "
- DRM_RECT_FMT "\n", DRM_RECT_ARG(&crtc_rect),
- DRM_RECT_ARG(&dst));
- return -E2BIG;
- }
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
Re: [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 --
3 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b485234eefb2..bd09bb319a58 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,7 +1129,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc
*crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
- struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1161,11 +1160,10 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
- /* get plane state for all drm planes associated with crtc state */
+ /* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate,
crtc_state) {
struct dpu_plane_state *dpu_pstate =
to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1179,8 +1177,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc
*crtc,
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
- dpu_plane_clear_multirect(pstate);
-
dst = drm_plane_state_dest(pstate);
if (!drm_rect_intersect(&clip, &dst)) {
DPU_ERROR("invalid vertical/horizontal destination\n");
@@ -1189,18 +1185,6 @@ static int dpu_crtc_atomic_check(struct
drm_crtc *crtc,
DRM_RECT_ARG(&dst));
return -E2BIG;
}
-
- /* verify stage setting before using it */
- stage = DPU_STAGE_0 + pstate->normalized_zpos;
- if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
- DPU_ERROR("> %d plane stages assigned\n",
- dpu_kms->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
- return -EINVAL;
- }
-
- to_dpu_plane_state(pstate)->stage = stage;
- DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
-
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 1b3033b15bfa..5aabf9694a53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -733,14 +733,6 @@ static int _dpu_plane_color_fill(struct dpu_plane
*pdpu,
return 0;
}
-void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state)
-{
- struct dpu_plane_state *pstate = to_dpu_plane_state(drm_state);
-
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-}
-
int dpu_plane_validate_multirect_v2(struct
dpu_multirect_plane_states *plane)
{
struct dpu_plane_state *pstate[R_MAX];
@@ -994,6 +986,16 @@ static int dpu_plane_atomic_check(struct
drm_plane *plane,
if (!new_plane_state->visible)
return 0;
+ pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
+ pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+
But I am not sure if clearing the multirect belongs here and now I want
to clarify one thing about
https://patchwork.freedesktop.org/patch/521354/?series=99909&rev=4 which
was R-bed in the v1 and carried fwd since then.
So prior to that change, we were only clearing the multirects of the
planes that were staged to the crtc and we were getting those from the
crtc state. But now we are clearing the multirect of all the planes.
Dont we have to keep that in the crtc_atomic_check() since we do that on
all the planes attached to a certain CRTC.
In that case shouldnt we keep this in the crtc_atomic_check() and bring
back pipe_staged[] without the multirect and source split cases ofcourse.
What for? In other words, what would be the difference?
+ pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
+ if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
+ DPU_ERROR("> %d plane stages assigned\n",
+ pdpu->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
+ return -EINVAL;
+ }
+
I agree that this check belongs to the plane_atomic_check().
src.x1 = new_plane_state->src_x >> 16;
src.y1 = new_plane_state->src_y >> 16;
src.x2 = src.x1 + (new_
Re: [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 --
3 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b485234eefb2..bd09bb319a58 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,7 +1129,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
- struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1161,11 +1160,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
- /* get plane state for all drm planes associated with crtc state */
+ /* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1179,8 +1177,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
- dpu_plane_clear_multirect(pstate);
-
dst = drm_plane_state_dest(pstate);
if (!drm_rect_intersect(&clip, &dst)) {
DPU_ERROR("invalid vertical/horizontal destination\n");
@@ -1189,18 +1185,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
DRM_RECT_ARG(&dst));
return -E2BIG;
}
-
- /* verify stage setting before using it */
- stage = DPU_STAGE_0 + pstate->normalized_zpos;
- if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
- DPU_ERROR("> %d plane stages assigned\n",
-
dpu_kms->catalog->caps->max_mixer_blendstages - DPU_STAGE_0);
- return -EINVAL;
- }
-
- to_dpu_plane_state(pstate)->stage = stage;
- DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
-
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 1b3033b15bfa..5aabf9694a53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -733,14 +733,6 @@ static int _dpu_plane_color_fill(struct dpu_plane *pdpu,
return 0;
}
-void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state)
-{
- struct dpu_plane_state *pstate = to_dpu_plane_state(drm_state);
-
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-}
-
int dpu_plane_validate_multirect_v2(struct dpu_multirect_plane_states *plane)
{
struct dpu_plane_state *pstate[R_MAX];
@@ -994,6 +986,16 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->visible)
return 0;
+ pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
+ pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+
But I am not sure if clearing the multirect belongs here and now I want
to clarify one thing about
https://patchwork.freedesktop.org/patch/521354/?series=99909&rev=4 which
was R-bed in the v1 and carried fwd since then.
So prior to that change, we were only clearing the multirects of the
planes that were staged to the crtc and we were getting those from the
crtc state. But now we are clearing the multirect of all the planes.
Dont we have to keep that in the crtc_atomic_check() since we do that on
all the planes attached to a certain CRTC.
In that case shouldnt we keep this in the crtc_atomic_check() and bring
back pipe_staged[] without the multirect and source split cases ofcourse.
+ pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
+ if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
+ DPU_ERROR("> %d plane stages assigned\n",
+ pdpu->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
+ return -EINVAL;
+ }
+
I agree that this check
[pull] amdgpu drm-next-6.3
Hi Dave, Daniel,
More stuff for 6.3. Mostly bug fixes.
The following changes since commit aebd8f0c6f8280ba35bc989f4a9ea47469d3589a:
Merge v6.2-rc6 into drm-next (2023-01-31 12:23:23 +0100)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-next-6.3-2023-02-03
for you to fetch changes up to 69ed0c5d44d72051b13e65384e9d9354c45d5e14:
Revert "drm/amd/display: disable S/G display on DCN 3.1.4" (2023-02-03
15:42:42 -0500)
amd-drm-next-6.3-2023-02-03:
amdgpu:
- PCI hotplug fixes
- Allow S0ix without BIOS support
- GC11 fixes
- DCN 3.2.x fixes
- Enable freesync over PCon
- DSC fix
- DCN 3.1.4 fixes
- NBIO 4.3 fix
- Misc code cleanups and spelling fixes
- Temporarily disable S/G on DCN 2.1 and 3.1.2/3
- Fix and re-enable S/G on DCN 3.1.4
- Re-enable the AGP aperture on GMC 11.x
Alex Deucher (6):
drm/amd/display: Properly handle additional cases where DCN is not
supported
drm/amd/display: disable S/G display on DCN 2.1.0
drm/amd/display: disable S/G display on DCN 3.1.2/3
drm/amd/display: properly handling AGP aperture in vm setup
Revert "Revert "drm/amdgpu/gmc11: enable AGP aperture""
Revert "drm/amd/display: disable S/G display on DCN 3.1.4"
Aric Cyr (2):
drm/amd/display: Revert "avoid disable otg when dig was disabled"
drm/amd/display: 3.2.221
Daniel Miess (3):
drm/amd/display: Correct bw_params population
drm/amd/display: Add missing brackets in calculation
drm/amd/display: Adjust downscaling limits for dcn314
Evan Quan (1):
drm/amdgpu: enable HDP SD for gfx 11.0.3
Fangzhi Zuo (1):
drm/amd/display: Add Debug Log for MST and PCON
George Shen (1):
drm/amd/display: Unassign does_plane_fit_in_mall function from dcn3.2
Graham Sider (1):
drm/amdgpu: update wave data type to 3 for gfx11
Guilherme G. Piccoli (1):
drm/amd/display: Trivial swizzle-related code clean-ups
Hersen Wu (1):
drm/amd/display: fix linux dp link lost handled only one time
Jonathan Neuschäfer (1):
drm/amdgpu: Fix a typo ("boradcast")
Leon Huang (1):
drm/amd/display: Fix only one ABM pipe enabled under ODM combined case
Mario Limonciello (2):
drm/amd: Allow s0ix without BIOS support
drm/amd: Fix initialization for nbio 4.3.0
Mustapha Ghaddar (1):
drm/amd/display: Add Function declaration in dc_link
Nicholas Kazlauskas (2):
drm/amd/display: Fix Z8 support configurations
drm/amd/display: Reset DMUB mailbox SW state after HW reset
Samson Tam (1):
drm/amd/display: fix MALL size hardcoded for DCN321
Sung Joon Kim (1):
drm/amd/display: Enable Freesync over PCon
Tim Huang (1):
drm/amd/pm: drop unneeded dpm features disablement for SMU 13.0.4/11
Tom Rix (2):
drm/amd/display: reduce else-if to else in dcn10_blank_pixel_data()
drm/amd/display: reduce else-if to else in dcn32_calculate_dlg_params()
Vitaly Prosyak (2):
Revert "drm/amdgpu: TA unload messages are not actually sent to psp when
amdgpu is uninstalled"
drm/amdgpu: always sending PSP messages LOAD_ASD and UNLOAD_TA
Vladimir Stempen (1):
drm/amd/display: fix FCLK pstate change underflow
Wenjing Liu (1):
drm/amd/display: add rc_params_override option in dc_dsc_config
Yifan Zha (1):
drm/amdgpu: Remove writing GRBM_GFX_CNTL in RLCG interface under SRIOV
Yiqing Yao (1):
drm/amdgpu: Enable vclk dclk node for gc11.0.3
ye xingchen (1):
drm/amdgpu/display: remove duplicate include header in files
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 16 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 -
drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 +-
drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c | 7 +-
drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c| 7 +-
drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c | 6 +-
drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c | 8 +-
drivers/gpu/drm/amd/amdgpu/soc21.c | 3 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 130 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 67 ++-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 45 ++-
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 12 ++
.../amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 31 +++--
.../amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 26 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
drivers/gpu/drm/amd/display/dc/dc.h
Re: [PATCH v3 14/27] drm/msm/dpu: don't use unsupported blend stages
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index c1579d6f5060..b485234eefb2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,6 +1129,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
+ struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1164,7 +1165,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int z_pos;
+ int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1189,17 +1190,16 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
return -E2BIG;
}
- z_pos = pstate->normalized_zpos;
-
- /* verify z_pos setting before using it */
- if (z_pos >= DPU_STAGE_MAX - DPU_STAGE_0) {
+ /* verify stage setting before using it */
+ stage = DPU_STAGE_0 + pstate->normalized_zpos;
+ if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
DPU_ERROR("> %d plane stages assigned\n",
- DPU_STAGE_MAX - DPU_STAGE_0);
+
dpu_kms->catalog->caps->max_mixer_blendstages - DPU_STAGE_0);
return -EINVAL;
}
- to_dpu_plane_state(pstate)->stage = z_pos + DPU_STAGE_0;
- DRM_DEBUG_ATOMIC("%s: zpos %d\n", dpu_crtc->name, z_pos);
+ to_dpu_plane_state(pstate)->stage = stage;
+ DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
}
Re: [PATCH v3 11/27] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
Now with the prev change, this is
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4c05f4b5e050..fbfb39a7a229 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -451,7 +451,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe
*pipe,
{
struct dpu_hw_sspp *ctx = pipe->sspp;
struct dpu_hw_blk_reg_map *c;
- u32 src_size, src_xy, dst_size, dst_xy, ystride0, ystride1;
+ u32 src_size, src_xy, dst_size, dst_xy;
u32 src_size_off, src_xy_off, out_size_off, out_xy_off;
u32 idx;
@@ -482,44 +482,18 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe *pipe,
dst_size = (drm_rect_height(&cfg->dst_rect) << 16) |
drm_rect_width(&cfg->dst_rect);
- if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
- ystride0 = (cfg->layout.plane_pitch[0]) |
- (cfg->layout.plane_pitch[1] << 16);
- ystride1 = (cfg->layout.plane_pitch[2]) |
- (cfg->layout.plane_pitch[3] << 16);
- } else {
- ystride0 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE0 + idx);
- ystride1 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE1 + idx);
-
- if (pipe->multirect_index == DPU_SSPP_RECT_0) {
- ystride0 = (ystride0 & 0x) |
- (cfg->layout.plane_pitch[0] & 0x);
- ystride1 = (ystride1 & 0x)|
- (cfg->layout.plane_pitch[2] & 0x);
- } else {
- ystride0 = (ystride0 & 0x) |
- ((cfg->layout.plane_pitch[0] << 16) &
-0x);
- ystride1 = (ystride1 & 0x) |
- ((cfg->layout.plane_pitch[2] << 16) &
-0x);
- }
- }
-
/* rectangle register programming */
DPU_REG_WRITE(c, src_size_off + idx, src_size);
DPU_REG_WRITE(c, src_xy_off + idx, src_xy);
DPU_REG_WRITE(c, out_size_off + idx, dst_size);
DPU_REG_WRITE(c, out_xy_off + idx, dst_xy);
-
- DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE0 + idx, ystride0);
- DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,
struct dpu_hw_sspp_cfg *cfg)
{
struct dpu_hw_sspp *ctx = pipe->sspp;
+ u32 ystride0, ystride1;
int i;
u32 idx;
@@ -541,6 +515,33 @@ static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,
DPU_REG_WRITE(&ctx->hw, SSPP_SRC3_ADDR + idx,
cfg->layout.plane_addr[2]);
}
+
+ if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
+ ystride0 = (cfg->layout.plane_pitch[0]) |
+ (cfg->layout.plane_pitch[1] << 16);
+ ystride1 = (cfg->layout.plane_pitch[2]) |
+ (cfg->layout.plane_pitch[3] << 16);
+ } else {
+ ystride0 = DPU_REG_READ(&ctx->hw, SSPP_SRC_YSTRIDE0 + idx);
+ ystride1 = DPU_REG_READ(&ctx->hw, SSPP_SRC_YSTRIDE1 + idx);
+
+ if (pipe->multirect_index == DPU_SSPP_RECT_0) {
+ ystride0 = (ystride0 & 0x) |
+ (cfg->layout.plane_pitch[0] & 0x);
+ ystride1 = (ystride1 & 0x)|
+ (cfg->layout.plane_pitch[2] & 0x);
+ } else {
+ ystride0 = (ystride0 & 0x) |
+ ((cfg->layout.plane_pitch[0] << 16) &
+0x);
+ ystride1 = (ystride1 & 0x) |
+ ((cfg->layout.plane_pitch[2] << 16) &
+0x);
+ }
+ }
+
+ DPU_REG_WRITE(&ctx->hw, SSPP_SRC_YSTRIDE0 + idx, ystride0);
+ DPU_REG_WRITE(&ctx->hw, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
Re: [PATCH v3 10/27] drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Signed-off-by: Dmitry Baryshkov
I am yet to confirm with HW team if programming 0 stride and 0 address
is absolutely needed for solid fill or not.
Ideally, in solid fill mode these should just be ignored by the HW.
But this change and the next wont break anything. Should just be a no-op
for HW.
Hence,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index abf499275242..4c05f4b5e050 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -563,11 +563,16 @@ static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
static void dpu_hw_sspp_setup_solidfill(struct dpu_sw_pipe *pipe, u32 color)
{
struct dpu_hw_sspp *ctx = pipe->sspp;
+ struct dpu_hw_sspp_cfg cfg;
u32 idx;
if (_sspp_subblk_offset(ctx, DPU_SSPP_SRC, &idx))
return;
+ /* cleanup source addresses */
+ memset(&cfg, 0, sizeof(cfg));
+ ctx->ops.setup_sourceaddress(pipe, &cfg);
+
if (pipe->multirect_index == DPU_SSPP_RECT_SOLO ||
pipe->multirect_index == DPU_SSPP_RECT_0)
DPU_REG_WRITE(&ctx->hw, SSPP_SRC_CONSTANT_COLOR + idx, color);
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/3/23 14:34, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote: >> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote: >>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: On 2/3/23 11:00, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: >> >> >> On 2/3/23 10:19, Ville Syrjälä wrote: >>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: On 2/3/23 07:59, Sebastian Wick wrote: > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > wrote: >> >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: >>> Userspace has no way of controlling or knowing the pixel encoding >>> currently, so there is no way for it to ever get the right values >>> here. >> >> That applies to a lot of the other values as well (they are >> explicitly RGB or YCC). The idea was that this property sets the >> infoframe/MSA/SDP value exactly, and other properties should be >> added to for use userspace to control the pixel encoding/colorspace >> conversion(if desired, or userspace just makes sure to >> directly feed in correct kind of data). > > I'm all for getting userspace control over pixel encoding but even > then the kernel always knows which pixel encoding is selected and > which InfoFrame has to be sent. Is there a reason why userspace would > want to control the variant explicitly to the wrong value? > I've asked this before but haven't seen an answer: Is there an existing upstream userspace project that makes use of this property (other than what Joshua is working on in gamescope right now)? That would help us understand the intent better. >>> >>> The intent was to control the infoframe colorimetry bits, >>> nothing more. No idea what real userspace there was, if any. >>> I don't think giving userspace explicit control over the exact infoframe values is the right thing to do. >>> >>> Only userspace knows what kind of data it's stuffing into >>> the pixels (and/or how it configures the csc units/etc.) to >>> generate them. >>> >> >> Yes, but userspace doesn't control or know whether we drive >> RGB or YCbCr on the wire. In fact, in some cases our driver >> needs to fallback to YCbCr420 for bandwidth reasons. There >> is currently no way for userspace to know that and I don't >> think it makes sense. > > People want that control as well for whatever reason. We've > been asked to allow YCbCr 4:4:4 output many times. > > The automagic 4:2:0 fallback I think is rather fundementally > incompatible with fancy color management. How would we even > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 > that stuff is just always BT.709 limited range, no questions > asked. > We use what we're telling the display, i.e., the value in the colorspace property. That way we know whether to use a BT.2020 or BT.709 matrix. >>> >>> And given how these things have gone in the past I think >>> that is likey to bite someone at in the future. Also not >>> what this property was meant to do nor does on any other >>> driver AFAIK. >>> I don't see how it's fundamentally incompatible with fancy color management stuff. If we start forbidding drivers from falling back to YCbCr (whether 4:4:4 or 4:2:0) we will break existing behavior on amdgpu and will see bug reports. >>> >>> The compositors could deal with that if/when they start doing >>> the full color management stuff. The current stuff only really >>> works when the kernel is allowed to do whatever it wants. >>> > So I think if userspace wants real color management it's > going to have to set up the whole pipeline. And for that > we need at least one new property to control the RGB->YCbCr > conversion (or to explicitly avoid it). > > And given that the proposed patch just swept all the > non-BT.2020 issues under the rug makes me think no > one has actually come up with any kind of consistent > plan for anything else really. > Does anyone actually use the non-BT.2020 colorspace stuff? >>> >>> No idea if anyone is using any of it. It's a bit hard to do >>> right now outside the full passthrough case since we have no >>> properties to control how the hardware will convert stuff. >>> >>> Anyways, sounds like what you're basically proposing is >>> getting rid of this property and starting from scratch. >> >> Hmm. I guess one option would be to add that property to >> control the output encoding, but include a few extra >> "automagic" values to it which would retain the kernel's >> f
Re: [PATCH v3 09/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
LGTM now,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4d3ca8532563..abf499275242 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -419,19 +419,18 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_sspp *ctx,
}
static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
- struct dpu_hw_sspp_cfg *sspp,
- void *scaler_cfg)
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format)
{
u32 idx;
- struct dpu_hw_scaler3_cfg *scaler3_cfg = scaler_cfg;
- if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx) || !sspp
+ if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx)
|| !scaler3_cfg)
return;
dpu_hw_setup_scaler3(&ctx->hw, scaler3_cfg, idx,
ctx->cap->sblk->scaler_blk.version,
- sspp->layout.format);
+ format);
}
static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 8d566ad1877e..5e9b07090a21 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -317,13 +317,12 @@ struct dpu_hw_sspp_ops {
/**
* setup_scaler - setup scaler
-* @ctx: Pointer to pipe context
-* @pipe_cfg: Pointer to pipe configuration
-* @scaler_cfg: Pointer to scaler configuration
+* @scaler3_cfg: Pointer to scaler configuration
+* @format: pixel format parameters
*/
void (*setup_scaler)(struct dpu_hw_sspp *ctx,
- struct dpu_hw_sspp_cfg *pipe_cfg,
- void *scaler_cfg);
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format);
/**
* get_scaler_ver - get scaler h/w version
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 8f1767619d06..4f5c44d78332 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -677,8 +677,8 @@ static void _dpu_plane_setup_scaler(struct dpu_sw_pipe
*pipe,
if (pipe_hw->ops.setup_scaler &&
pipe->multirect_index != DPU_SSPP_RECT_1)
pipe_hw->ops.setup_scaler(pipe_hw,
- pipe_cfg,
- &scaler3_cfg);
+ &scaler3_cfg,
+ fmt);
}
/**
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: > > > > > > > > > On 2/3/23 11:00, Ville Syrjälä wrote: > > > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > >> > > > >> > > > >> On 2/3/23 10:19, Ville Syrjälä wrote: > > > >>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > > > > > > > On 2/3/23 07:59, Sebastian Wick wrote: > > > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > > > wrote: > > > >> > > > >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > > >>> Userspace has no way of controlling or knowing the pixel encoding > > > >>> currently, so there is no way for it to ever get the right values > > > >>> here. > > > >> > > > >> That applies to a lot of the other values as well (they are > > > >> explicitly RGB or YCC). The idea was that this property sets the > > > >> infoframe/MSA/SDP value exactly, and other properties should be > > > >> added to for use userspace to control the pixel encoding/colorspace > > > >> conversion(if desired, or userspace just makes sure to > > > >> directly feed in correct kind of data). > > > > > > > > I'm all for getting userspace control over pixel encoding but even > > > > then the kernel always knows which pixel encoding is selected and > > > > which InfoFrame has to be sent. Is there a reason why userspace > > > > would > > > > want to control the variant explicitly to the wrong value? > > > > > > > > > > I've asked this before but haven't seen an answer: Is there an > > > existing > > > upstream userspace project that makes use of this property (other > > > than > > > what Joshua is working on in gamescope right now)? That would help us > > > understand the intent better. > > > >>> > > > >>> The intent was to control the infoframe colorimetry bits, > > > >>> nothing more. No idea what real userspace there was, if any. > > > >>> > > > > > > I don't think giving userspace explicit control over the exact > > > infoframe > > > values is the right thing to do. > > > >>> > > > >>> Only userspace knows what kind of data it's stuffing into > > > >>> the pixels (and/or how it configures the csc units/etc.) to > > > >>> generate them. > > > >>> > > > >> > > > >> Yes, but userspace doesn't control or know whether we drive > > > >> RGB or YCbCr on the wire. In fact, in some cases our driver > > > >> needs to fallback to YCbCr420 for bandwidth reasons. There > > > >> is currently no way for userspace to know that and I don't > > > >> think it makes sense. > > > > > > > > People want that control as well for whatever reason. We've > > > > been asked to allow YCbCr 4:4:4 output many times. > > > > > > > > The automagic 4:2:0 fallback I think is rather fundementally > > > > incompatible with fancy color management. How would we even > > > > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 > > > > that stuff is just always BT.709 limited range, no questions > > > > asked. > > > > > > > > > > We use what we're telling the display, i.e., the value in the > > > colorspace property. That way we know whether to use a BT.2020 > > > or BT.709 matrix. > > > > And given how these things have gone in the past I think > > that is likey to bite someone at in the future. Also not > > what this property was meant to do nor does on any other > > driver AFAIK. > > > > > I don't see how it's fundamentally incompatible with fancy > > > color management stuff. > > > > > > If we start forbidding drivers from falling back to YCbCr > > > (whether 4:4:4 or 4:2:0) we will break existing behavior on > > > amdgpu and will see bug reports. > > > > The compositors could deal with that if/when they start doing > > the full color management stuff. The current stuff only really > > works when the kernel is allowed to do whatever it wants. > > > > > > > > > So I think if userspace wants real color management it's > > > > going to have to set up the whole pipeline. And for that > > > > we need at least one new property to control the RGB->YCbCr > > > > conversion (or to explicitly avoid it). > > > > > > > > And given that the proposed patch just swept all the > > > > non-BT.2020 issues under the rug makes me think no > > > > one has actually come up with any kind of consistent > > > > plan for anything else really. > > > > > > > > > > Does anyone actually use the non-BT.2020 colorspace stuff? > > > > No idea if anyone is using any of it. It's a bit hard to do > > right now outside the full passthrough case since we have no > > properties to control how the hardware will convert stuff. > > > > Anyways, sounds like what you're basically proposing is > > getting rid of this property and starting from scratch. > > Hmm. I g
Re: [PATCH v3 05/27] drm/msm/dpu: move pipe_hw to dpu_plane_state
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be statically allocated during boot).
The sspp pointer is set at the dpu_plane_reset(), since this is the
function which allocates the state. Once we have fully virtual
plane<->SSPP relationship, the SSPP will be allocated dynamically in the
dpu_plane_atomic_check() function.
Signed-off-by: Dmitry Baryshkov
LGTM now,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 106 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
2 files changed, 61 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d6518ef1beb2..9eac02f53fc1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -104,7 +104,6 @@ struct dpu_plane {
enum dpu_sspp pipe;
- struct dpu_hw_sspp *pipe_hw;
uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
@@ -279,6 +278,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
struct drm_framebuffer *fb, struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
const struct dpu_format *fmt = NULL;
u64 qos_lut;
u32 total_fl = 0, lut_usage;
@@ -310,7 +310,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
fmt ? (char *)&fmt->base.pixel_format : NULL,
pdpu->is_rt_pipe, total_fl, qos_lut);
- pdpu->pipe_hw->ops.setup_creq_lut(pdpu->pipe_hw, qos_lut);
+ pstate->hw_sspp->ops.setup_creq_lut(pstate->hw_sspp, qos_lut);
}
/**
@@ -322,6 +322,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane
*plane,
struct drm_framebuffer *fb)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
const struct dpu_format *fmt = NULL;
u32 danger_lut, safe_lut;
@@ -361,7 +362,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane *plane,
danger_lut,
safe_lut);
- pdpu->pipe_hw->ops.setup_danger_safe_lut(pdpu->pipe_hw,
+ pstate->hw_sspp->ops.setup_danger_safe_lut(pstate->hw_sspp,
danger_lut, safe_lut);
}
@@ -375,14 +376,15 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,
bool enable, u32 flags)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
memset(&pipe_qos_cfg, 0, sizeof(pipe_qos_cfg));
if (flags & DPU_PLANE_QOS_VBLANK_CTRL) {
- pipe_qos_cfg.creq_vblank =
pdpu->pipe_hw->cap->sblk->creq_vblank;
+ pipe_qos_cfg.creq_vblank =
pstate->hw_sspp->cap->sblk->creq_vblank;
pipe_qos_cfg.danger_vblank =
- pdpu->pipe_hw->cap->sblk->danger_vblank;
+ pstate->hw_sspp->cap->sblk->danger_vblank;
pipe_qos_cfg.vblank_en = enable;
}
@@ -408,7 +410,7 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,
pipe_qos_cfg.danger_vblank,
pdpu->is_rt_pipe);
- pdpu->pipe_hw->ops.setup_qos_ctrl(pdpu->pipe_hw,
+ pstate->hw_sspp->ops.setup_qos_ctrl(pstate->hw_sspp,
&pipe_qos_cfg);
}
@@ -422,18 +424,19 @@ static void _dpu_plane_set_ot_limit(struct drm_plane *plane,
struct drm_crtc *crtc, struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_vbif_set_ot_params ot_params;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
memset(&ot_params, 0, sizeof(ot_params));
- ot_params.xin_id = pdpu->pipe_hw->cap->xin_id;
- ot_params.num = pdpu->pipe_hw->idx - SSPP_NONE;
+ ot_params.xin_id = pstate->hw_sspp->cap->xin_id;
+ ot_params.num = pstate->hw_sspp->idx - SSPP_NONE;
ot_params.width = drm_rect_width(&pipe_cfg->src_rect);
ot_params.height = drm_rect_height(&pipe_cfg->src_rect);
ot_params.is_wfd = !pdpu->is_rt_pipe;
ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
ot_params.vbif_idx = VBIF_RT;
- ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
+ ot_params.clk_ctrl = pstate->hw_sspp->cap->clk_ctrl;
ot_params.rd = true;
dpu_vbif_set_ot_limit(dpu_kms, &ot_params);
@@ -446,14 +449,15 @@ static voi
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/3/23 14:25, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2/3/23 11:00, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 10:19, Ville Syrjälä wrote:
>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2/3/23 07:59, Sebastian Wick wrote:
On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
wrote:
>
> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
>> Userspace has no way of controlling or knowing the pixel encoding
>> currently, so there is no way for it to ever get the right values
>> here.
>
> That applies to a lot of the other values as well (they are
> explicitly RGB or YCC). The idea was that this property sets the
> infoframe/MSA/SDP value exactly, and other properties should be
> added to for use userspace to control the pixel encoding/colorspace
> conversion(if desired, or userspace just makes sure to
> directly feed in correct kind of data).
I'm all for getting userspace control over pixel encoding but even
then the kernel always knows which pixel encoding is selected and
which InfoFrame has to be sent. Is there a reason why userspace would
want to control the variant explicitly to the wrong value?
>>>
>>> I've asked this before but haven't seen an answer: Is there an existing
>>> upstream userspace project that makes use of this property (other than
>>> what Joshua is working on in gamescope right now)? That would help us
>>> understand the intent better.
>>
>> The intent was to control the infoframe colorimetry bits,
>> nothing more. No idea what real userspace there was, if any.
>>
>>>
>>> I don't think giving userspace explicit control over the exact infoframe
>>> values is the right thing to do.
>>
>> Only userspace knows what kind of data it's stuffing into
>> the pixels (and/or how it configures the csc units/etc.) to
>> generate them.
>>
>
> Yes, but userspace doesn't control or know whether we drive
> RGB or YCbCr on the wire. In fact, in some cases our driver
> needs to fallback to YCbCr420 for bandwidth reasons. There
> is currently no way for userspace to know that and I don't
> think it makes sense.
People want that control as well for whatever reason. We've
been asked to allow YCbCr 4:4:4 output many times.
The automagic 4:2:0 fallback I think is rather fundementally
incompatible with fancy color management. How would we even
know whether to use eg. BT.2020 vs. BT.709 matrix? In i915
that stuff is just always BT.709 limited range, no questions
asked.
>>>
>>> We use what we're telling the display, i.e., the value in the
>>> colorspace property. That way we know whether to use a BT.2020
>>> or BT.709 matrix.
>>
>> And given how these things have gone in the past I think
>> that is likey to bite someone at in the future. Also not
>> what this property was meant to do nor does on any other
>> driver AFAIK.
>>
>>> I don't see how it's fundamentally incompatible with fancy
>>> color management stuff.
>>>
>>> If we start forbidding drivers from falling back to YCbCr
>>> (whether 4:4:4 or 4:2:0) we will break existing behavior on
>>> amdgpu and will see bug reports.
>>
>> The compositors could deal with that if/when they start doing
>> the full color management stuff. The current stuff only really
>> works when the kernel is allowed to do whatever it wants.
>>
>>>
So I think if userspace wants real color management it's
going to have to set up the whole pipeline. And for that
we need at least one new property to control the RGB->YCbCr
conversion (or to explicitly avoid it).
And given that the proposed patch just swept all the
non-BT.2020 issues under the rug makes me think no
one has actually come up with any kind of consistent
plan for anything else really.
>>>
>>> Does anyone actually use the non-BT.2020 colorspace stuff?
>>
>> No idea if anyone is using any of it. It's a bit hard to do
>> right now outside the full passthrough case since we have no
>> properties to control how the hardware will convert stuff.
>>
>> Anyways, sounds like what you're basically proposing is
>> getting rid of this property and starting from scratch.
>
> Hmm. I guess one option would be to add that property to
> control the output encoding, but include a few extra
> "automagic" values to it which would retain the kernel's
> freedom to select whether to do the RGB->YCbCr conversion
> or not.
>
> enum output_encoding {
> auto rgb=default/nodata,ycbcr=bt601
> auto rgb=default/nodata,ycbcr=bt709
>
Re: [PATCH v3 01/27] drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg)
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Signed-off-by: Dmitry Baryshkov
LGTM now,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 48 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 52 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
3 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4246ab0b3bee..5cf0803e4187 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -136,7 +136,7 @@
#define TS_CLK1920
-static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
+static int _sspp_subblk_offset(struct dpu_hw_sspp *ctx,
int s_id,
u32 *idx)
{
@@ -168,7 +168,7 @@ static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
return rc;
}
-static void dpu_hw_sspp_setup_multirect(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_multirect(struct dpu_hw_sspp *ctx,
enum dpu_sspp_multirect_index index,
enum dpu_sspp_multirect_mode mode)
{
@@ -197,7 +197,7 @@ static void dpu_hw_sspp_setup_multirect(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(&ctx->hw, SSPP_MULTIRECT_OPMODE + idx, mode_mask);
}
-static void _sspp_setup_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -218,7 +218,7 @@ static void _sspp_setup_opmode(struct dpu_hw_pipe *ctx,
DPU_REG_WRITE(&ctx->hw, SSPP_VIG_OP_MODE + idx, opmode);
}
-static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_csc10_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -239,7 +239,7 @@ static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe
*ctx,
/*
* Setup source pixel format, flip,
*/
-static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_format(struct dpu_hw_sspp *ctx,
const struct dpu_format *fmt, u32 flags,
enum dpu_sspp_multirect_index rect_mode)
{
@@ -360,7 +360,7 @@ static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(c, SSPP_UBWC_ERROR_STATUS + idx, BIT(31));
}
-static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_sspp *ctx,
struct dpu_hw_pixel_ext *pe_ext)
{
struct dpu_hw_blk_reg_map *c;
@@ -418,8 +418,8 @@ static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_pipe
*ctx,
tot_req_pixels[3]);
}
-static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_cfg *sspp,
+static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
+ struct dpu_hw_sspp_cfg *sspp,
void *scaler_cfg)
{
u32 idx;
@@ -434,7 +434,7 @@ static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe
*ctx,
sspp->layout.format);
}
-static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx)
+static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
{
u32 idx;
@@ -447,8 +447,8 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx)
/*
* dpu_hw_sspp_setup_rects()
*/
-static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_cfg *cfg,
+static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
+ struct dpu_hw_sspp_cfg *cfg,
enum dpu_sspp_multirect_index rect_index)
{
struct dpu_hw_blk_reg_map *c;
@@ -516,8 +516,8 @@ static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx,
DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
-static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_cfg *cfg,
+static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_sspp *ctx,
+ struct dpu_hw_sspp_cfg *cfg,
enum dpu_sspp_multirect_index rect_mode)
{
int i;
@@ -543,7 +543,7 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_hw_pipe *ctx,
}
}
-static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
const struct dpu_csc_cfg *data)
{
u32 idx;
@@ -560,7 +560,7 @@ static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
dpu_hw_csc_setup(&ctx->hw, idx, data, csc10);
}
-static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_pipe *ctx, u32 color, enum
+static void
[PATCH] drm/i915/gt: Avoid redundant pointer validity check
The macro definition of gen6_for_all_pdes() expands to a for loop such
that it breaks when the page table is null. Hence there is no need to
again test validity of the page table entry pointers in the pde list.
This change is identified using itnull.cocci semantic patch.
Signed-off-by: Deepak R Varma
---
Please note: Proposed change is compile tested only.
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 5aaacc53fa4c..787b9e6d9f59 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -258,8 +258,7 @@ static void gen6_ppgtt_free_pd(struct gen6_ppgtt *ppgtt)
u32 pde;
gen6_for_all_pdes(pt, pd, pde)
- if (pt)
- free_pt(&ppgtt->base.vm, pt);
+ free_pt(&ppgtt->base.vm, pt);
}
static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
@@ -304,7 +303,7 @@ static void pd_vma_unbind(struct i915_address_space *vm,
/* Free all no longer used page tables */
gen6_for_all_pdes(pt, ppgtt->base.pd, pde) {
- if (!pt || atomic_read(&pt->used))
+ if (atomic_read(&pt->used))
continue;
free_pt(&ppgtt->base.vm, pt);
--
2.34.1
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
> >
> >
> > On 2/3/23 11:00, Ville Syrjälä wrote:
> > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> > >>
> > >>
> > >> On 2/3/23 10:19, Ville Syrjälä wrote:
> > >>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
> >
> >
> > On 2/3/23 07:59, Sebastian Wick wrote:
> > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> > > wrote:
> > >>
> > >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
> > >>> Userspace has no way of controlling or knowing the pixel encoding
> > >>> currently, so there is no way for it to ever get the right values
> > >>> here.
> > >>
> > >> That applies to a lot of the other values as well (they are
> > >> explicitly RGB or YCC). The idea was that this property sets the
> > >> infoframe/MSA/SDP value exactly, and other properties should be
> > >> added to for use userspace to control the pixel encoding/colorspace
> > >> conversion(if desired, or userspace just makes sure to
> > >> directly feed in correct kind of data).
> > >
> > > I'm all for getting userspace control over pixel encoding but even
> > > then the kernel always knows which pixel encoding is selected and
> > > which InfoFrame has to be sent. Is there a reason why userspace would
> > > want to control the variant explicitly to the wrong value?
> > >
> >
> > I've asked this before but haven't seen an answer: Is there an existing
> > upstream userspace project that makes use of this property (other than
> > what Joshua is working on in gamescope right now)? That would help us
> > understand the intent better.
> > >>>
> > >>> The intent was to control the infoframe colorimetry bits,
> > >>> nothing more. No idea what real userspace there was, if any.
> > >>>
> >
> > I don't think giving userspace explicit control over the exact
> > infoframe
> > values is the right thing to do.
> > >>>
> > >>> Only userspace knows what kind of data it's stuffing into
> > >>> the pixels (and/or how it configures the csc units/etc.) to
> > >>> generate them.
> > >>>
> > >>
> > >> Yes, but userspace doesn't control or know whether we drive
> > >> RGB or YCbCr on the wire. In fact, in some cases our driver
> > >> needs to fallback to YCbCr420 for bandwidth reasons. There
> > >> is currently no way for userspace to know that and I don't
> > >> think it makes sense.
> > >
> > > People want that control as well for whatever reason. We've
> > > been asked to allow YCbCr 4:4:4 output many times.
> > >
> > > The automagic 4:2:0 fallback I think is rather fundementally
> > > incompatible with fancy color management. How would we even
> > > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915
> > > that stuff is just always BT.709 limited range, no questions
> > > asked.
> > >
> >
> > We use what we're telling the display, i.e., the value in the
> > colorspace property. That way we know whether to use a BT.2020
> > or BT.709 matrix.
>
> And given how these things have gone in the past I think
> that is likey to bite someone at in the future. Also not
> what this property was meant to do nor does on any other
> driver AFAIK.
>
> > I don't see how it's fundamentally incompatible with fancy
> > color management stuff.
> >
> > If we start forbidding drivers from falling back to YCbCr
> > (whether 4:4:4 or 4:2:0) we will break existing behavior on
> > amdgpu and will see bug reports.
>
> The compositors could deal with that if/when they start doing
> the full color management stuff. The current stuff only really
> works when the kernel is allowed to do whatever it wants.
>
> >
> > > So I think if userspace wants real color management it's
> > > going to have to set up the whole pipeline. And for that
> > > we need at least one new property to control the RGB->YCbCr
> > > conversion (or to explicitly avoid it).
> > >
> > > And given that the proposed patch just swept all the
> > > non-BT.2020 issues under the rug makes me think no
> > > one has actually come up with any kind of consistent
> > > plan for anything else really.
> > >
> >
> > Does anyone actually use the non-BT.2020 colorspace stuff?
>
> No idea if anyone is using any of it. It's a bit hard to do
> right now outside the full passthrough case since we have no
> properties to control how the hardware will convert stuff.
>
> Anyways, sounds like what you're basically proposing is
> getting rid of this property and starting from scratch.
Hmm. I guess one option would be to add that property to
control the output encoding, but include a few extra
"automagic" values to it which would retain the kernel's
freedom to select whether to do the RGB->YCbCr conversion
or not.
enum output_encoding {
auto rgb=default/nodata,ycbcr=bt601
auto rgb=default/no
Re: (subset) [PATCH 1/4] dt-bindings: display/msm: add qcom, sc8280xp-edp to list of eDP devices
On Wed, 18 Jan 2023 05:17:15 +0200, Dmitry Baryshkov wrote: > Add qcom,sc8280xp-edp to the list of eDP devices, unblocking `aux-bus' > property and fobidding `#sound-dai-cells' property. Also since > sc8280xp-edp, overriding sc8280xp-dp, will contain 5 reg resources, drop > the reg contraint (as it will become equivalent to the top-level one, > requiring min 4 and max 5 reg entries). > > > [...] Applied, thanks! [3/4] arm64: dts: qcom: sc8280xp-crd: drop #sound-dai-cells from eDP node commit: 3cfa9e245d71f498a27f2dd8d09bbaaf50738723 [4/4] arm64: dts: qcom: sc8280xp: add p1 register blocks to DP nodes commit: 19eee67386fe68b8f39dc947d15711a5b5cef6ac Best regards, -- Bjorn Andersson
Re: [PATCH] arm64: dts: qcom: sm8350: use qcom, sm8350-dsi-ctrl compatibles
On Wed, 18 Jan 2023 05:20:24 +0200, Dmitry Baryshkov wrote: > Add the per-SoC (qcom,sm8350-dsi-ctrl) compatible strings to DSI nodes > to follow the pending DSI bindings changes. > > Applied, thanks! [1/1] arm64: dts: qcom: sm8350: use qcom,sm8350-dsi-ctrl compatibles commit: d7133d6d25fbc9374447e2ca4e23a04023824779 Best regards, -- Bjorn Andersson
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/3/23 13:56, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: >> >> >> On 2/3/23 11:00, Ville Syrjälä wrote: >>> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: On 2/3/23 10:19, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: >> >> >> On 2/3/23 07:59, Sebastian Wick wrote: >>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä >>> wrote: On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > Userspace has no way of controlling or knowing the pixel encoding > currently, so there is no way for it to ever get the right values > here. That applies to a lot of the other values as well (they are explicitly RGB or YCC). The idea was that this property sets the infoframe/MSA/SDP value exactly, and other properties should be added to for use userspace to control the pixel encoding/colorspace conversion(if desired, or userspace just makes sure to directly feed in correct kind of data). >>> >>> I'm all for getting userspace control over pixel encoding but even >>> then the kernel always knows which pixel encoding is selected and >>> which InfoFrame has to be sent. Is there a reason why userspace would >>> want to control the variant explicitly to the wrong value? >>> >> >> I've asked this before but haven't seen an answer: Is there an existing >> upstream userspace project that makes use of this property (other than >> what Joshua is working on in gamescope right now)? That would help us >> understand the intent better. > > The intent was to control the infoframe colorimetry bits, > nothing more. No idea what real userspace there was, if any. > >> >> I don't think giving userspace explicit control over the exact infoframe >> values is the right thing to do. > > Only userspace knows what kind of data it's stuffing into > the pixels (and/or how it configures the csc units/etc.) to > generate them. > Yes, but userspace doesn't control or know whether we drive RGB or YCbCr on the wire. In fact, in some cases our driver needs to fallback to YCbCr420 for bandwidth reasons. There is currently no way for userspace to know that and I don't think it makes sense. >>> >>> People want that control as well for whatever reason. We've >>> been asked to allow YCbCr 4:4:4 output many times. >>> >>> The automagic 4:2:0 fallback I think is rather fundementally >>> incompatible with fancy color management. How would we even >>> know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 >>> that stuff is just always BT.709 limited range, no questions >>> asked. >>> >> >> We use what we're telling the display, i.e., the value in the >> colorspace property. That way we know whether to use a BT.2020 >> or BT.709 matrix. > > And given how these things have gone in the past I think > that is likey to bite someone at in the future. Also not > what this property was meant to do nor does on any other > driver AFAIK. > It has implementations in other drivers but I have yet to see anyone using it. Without that it does nothing, unless there are proprietary userspace pieces that make use of this. >> I don't see how it's fundamentally incompatible with fancy >> color management stuff. >> >> If we start forbidding drivers from falling back to YCbCr >> (whether 4:4:4 or 4:2:0) we will break existing behavior on >> amdgpu and will see bug reports. > > The compositors could deal with that if/when they start doing > the full color management stuff. The current stuff only really > works when the kernel is allowed to do whatever it wants. > The compositor could deal with it but this feels like the compositor taking over things that should really be in the hands of a display driver. >> >>> So I think if userspace wants real color management it's >>> going to have to set up the whole pipeline. And for that >>> we need at least one new property to control the RGB->YCbCr >>> conversion (or to explicitly avoid it). >>> >>> And given that the proposed patch just swept all the >>> non-BT.2020 issues under the rug makes me think no >>> one has actually come up with any kind of consistent >>> plan for anything else really. >>> >> >> Does anyone actually use the non-BT.2020 colorspace stuff? > > No idea if anyone is using any of it. It's a bit hard to do > right now outside the full passthrough case since we have no > properties to control how the hardware will convert stuff. > > Anyways, sounds like what you're basically proposing is > getting rid of this property and starting from scratch. > Maybe that's the right approach. My initial idea was to tag along an existing property but that turns out to be challenging when that existing property doesn't even have a userspace implementation. I
Re: [PATCH v6 01/17] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On 2/3/23 19:21, Rob Herring wrote: > On Thu, Dec 22, 2022 at 03:22:14PM +0100, Johan Jonker wrote: >> Convert rockchip-lvds.txt to YAML. >> >> Changed: >> Add power-domains property. >> Requirements between PX30 and RK3288 >> >> Signed-off-by: Johan Jonker >> Reviewed-by: Rob Herring >> --- >> >> Changed V3: >> Filename matching compatible style >> Drop "Regulator phandle for " >> Specify properties and requirements per SoC >> Sort order and restyle >> >> Changed V2: >> Fix title >> --- >> .../display/rockchip/rockchip,lvds.yaml | 170 ++ >> .../display/rockchip/rockchip-lvds.txt| 92 -- >> 2 files changed, 170 insertions(+), 92 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml >> delete mode 100644 >> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt > > What's the plan for these patches? Don't see them in linux-next still. > Do you want me to take patches 1-8? Hi, The display patches normally go through the DRM git. Patch 2 must merge with grf.yaml. Heiko has merged now 3 PHY related patches to grf.yaml first. [PATCH v6 02/17] dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml See current https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next&qt=grep&q=jonker Not sure what Heiko's plans are. Patch 2 replaces only a description text and some accolades removal, so not "too" important. I urgent then you could merge without conflict: 1, 3-8 Patch 2 requires some adjusted now depending on the grf.yaml current next state. Johan > > Rob
Re: [PATCH] drm/i915: Make sure dsm_size has correct granularity
Hi Lucas, On 2/3/2023 7:56 PM, Lucas De Marchi wrote: On Thu, Feb 02, 2023 at 07:02:43PM +0100, Nirmoy Das wrote: DSM granularity is 1MB so make sure we stick to that. I think we need to be a bit more verbose here, because in future we may need to refer to this commit if/when things change (e.g. the granularity or the additional size needed on top of DSM). The issue this is fixing is that the address set by firmware in GEN12_DSMBASE and read here doesn't mean "anything above it until the of lmem is part of DSM". There may be a few KB that is not part of DSM. How large is that space is platform-dependent, but since it's always less than the DSM granularity, it can be simplified by simply aligning the size like is done here. v2: replace "1 * SZ_1M" with SZ_1M (Andrzej). Cc: Matthew Auld Suggested-by: Lucas De Marchi Signed-off-by: Nirmoy Das Reviewed-by: Andrzej Hajda Reviewed-by: Lucas De Marchi Are you ok with me amending the commit message and applying? Yes, I fine that, thanks for doing that. I agree this is very short description that I have wrote. After this patch I think you can follow the process to request committer access. Looking for to doing that :) Nirmoy Lucas De Marchi --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index 90a967374b1a..d8e06e783e30 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -909,7 +909,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type, dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK; if (WARN_ON(lmem_size < dsm_base)) return ERR_PTR(-ENODEV); - dsm_size = lmem_size - dsm_base; + dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M); } io_size = dsm_size; -- 2.39.0
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: > > > On 2/3/23 11:00, Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > >> > >> > >> On 2/3/23 10:19, Ville Syrjälä wrote: > >>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > On 2/3/23 07:59, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > wrote: > >> > >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > >>> Userspace has no way of controlling or knowing the pixel encoding > >>> currently, so there is no way for it to ever get the right values > >>> here. > >> > >> That applies to a lot of the other values as well (they are > >> explicitly RGB or YCC). The idea was that this property sets the > >> infoframe/MSA/SDP value exactly, and other properties should be > >> added to for use userspace to control the pixel encoding/colorspace > >> conversion(if desired, or userspace just makes sure to > >> directly feed in correct kind of data). > > > > I'm all for getting userspace control over pixel encoding but even > > then the kernel always knows which pixel encoding is selected and > > which InfoFrame has to be sent. Is there a reason why userspace would > > want to control the variant explicitly to the wrong value? > > > > I've asked this before but haven't seen an answer: Is there an existing > upstream userspace project that makes use of this property (other than > what Joshua is working on in gamescope right now)? That would help us > understand the intent better. > >>> > >>> The intent was to control the infoframe colorimetry bits, > >>> nothing more. No idea what real userspace there was, if any. > >>> > > I don't think giving userspace explicit control over the exact infoframe > values is the right thing to do. > >>> > >>> Only userspace knows what kind of data it's stuffing into > >>> the pixels (and/or how it configures the csc units/etc.) to > >>> generate them. > >>> > >> > >> Yes, but userspace doesn't control or know whether we drive > >> RGB or YCbCr on the wire. In fact, in some cases our driver > >> needs to fallback to YCbCr420 for bandwidth reasons. There > >> is currently no way for userspace to know that and I don't > >> think it makes sense. > > > > People want that control as well for whatever reason. We've > > been asked to allow YCbCr 4:4:4 output many times. > > > > The automagic 4:2:0 fallback I think is rather fundementally > > incompatible with fancy color management. How would we even > > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 > > that stuff is just always BT.709 limited range, no questions > > asked. > > > > We use what we're telling the display, i.e., the value in the > colorspace property. That way we know whether to use a BT.2020 > or BT.709 matrix. And given how these things have gone in the past I think that is likey to bite someone at in the future. Also not what this property was meant to do nor does on any other driver AFAIK. > I don't see how it's fundamentally incompatible with fancy > color management stuff. > > If we start forbidding drivers from falling back to YCbCr > (whether 4:4:4 or 4:2:0) we will break existing behavior on > amdgpu and will see bug reports. The compositors could deal with that if/when they start doing the full color management stuff. The current stuff only really works when the kernel is allowed to do whatever it wants. > > > So I think if userspace wants real color management it's > > going to have to set up the whole pipeline. And for that > > we need at least one new property to control the RGB->YCbCr > > conversion (or to explicitly avoid it). > > > > And given that the proposed patch just swept all the > > non-BT.2020 issues under the rug makes me think no > > one has actually come up with any kind of consistent > > plan for anything else really. > > > > Does anyone actually use the non-BT.2020 colorspace stuff? No idea if anyone is using any of it. It's a bit hard to do right now outside the full passthrough case since we have no properties to control how the hardware will convert stuff. Anyways, sounds like what you're basically proposing is getting rid of this property and starting from scratch. -- Ville Syrjälä Intel
Re: [PATCH] drm/i915: Make sure dsm_size has correct granularity
On Thu, Feb 02, 2023 at 07:02:43PM +0100, Nirmoy Das wrote: DSM granularity is 1MB so make sure we stick to that. I think we need to be a bit more verbose here, because in future we may need to refer to this commit if/when things change (e.g. the granularity or the additional size needed on top of DSM). The issue this is fixing is that the address set by firmware in GEN12_DSMBASE and read here doesn't mean "anything above it until the of lmem is part of DSM". There may be a few KB that is not part of DSM. How large is that space is platform-dependent, but since it's always less than the DSM granularity, it can be simplified by simply aligning the size like is done here. v2: replace "1 * SZ_1M" with SZ_1M (Andrzej). Cc: Matthew Auld Suggested-by: Lucas De Marchi Signed-off-by: Nirmoy Das Reviewed-by: Andrzej Hajda Reviewed-by: Lucas De Marchi Are you ok with me amending the commit message and applying? After this patch I think you can follow the process to request committer access. Lucas De Marchi --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index 90a967374b1a..d8e06e783e30 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -909,7 +909,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type, dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK; if (WARN_ON(lmem_size < dsm_base)) return ERR_PTR(-ENODEV); - dsm_size = lmem_size - dsm_base; + dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M); } io_size = dsm_size; -- 2.39.0
Re: [PATCH 1/2] drm/i915: Fix GEN8_MISCCPCTL
On Fri, Feb 03, 2023 at 10:03:49AM -0800, Lucas De Marchi wrote:
> On Thu, Feb 02, 2023 at 05:12:10PM -0800, Matt Roper wrote:
> > On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
> > > Register 0x9424 is not replicated on any platform, so it shouldn't be
> > > declared with REG_MCR(). Declaring it with _MMIO() is basically
> > > duplicate of the GEN7 version, so just remove the GEN8 and change all
> > > the callers to use the right functions.
> >
> > According to an old copy of bspec page 13991, 0x9400-0x97FF was an MCR
> > range on gen8 platforms. Newer copies of that bspec page forgot to even
> > include the register range table, so it's not obvious unless you dig
> > through the history and look at a version from before Aug 2020.
> >
> > However bspec page 66673 indicates that this range went back to being a
> > singleton range in gen9 (and the other forcewake pages for newer
> > platforms indicate it stayed that way), so that means BDW and CHV are
> > the _only_ platforms that should treat it as MCR. Usage for other
> > platforms should either add a new "GEN9" definition, or just go back to
> > using the GEN7 definition.
>
> sounds like more a spec mistake. This range was listed as
> "slice common". I'm not sure we'd really have to set any steering for
> specific slice. Another thing is that we didn't set any steering for a
> long time in this register and it was working. Even now there is no
> table for gen8/gen9 in drivers/gpu/drm/i915/gt/intel_gt_mcr.c, so any
> call to intel_gt_mcr_* will simply fallback to "no steering required".
>
> For me, any MCR_REG() should correspond to registers in these
> tables. I don't think there's much point in annotating the register as
> MCR in its definition and then do nothing with it. Btw, this is how I
> started getting warning wrt this register: as you knowm, in xe driver
> you added a warning for registers missing from the mcr tables,
> which I think is indeed the right thing to do for the recent platforms.
I guess that's fair. Even though gen8 had multicast registers, I
believe the two types of steering (subslice and l3bank) could always be
reconciled with a single steering value; since the IFWI took care of
initializing this in a sane way, i915 never actually needed to touch it
(except when doing unicast reads for an errorstate dump or something).
I'm not sure the same is always true for gen9 though. We should
probably add tables for those just to be safe, but that's future work
rather than something that we need to worry about for this patch.
Likewise, we should also finally kill off mcr_ranges_*[] in the
workaround file at some point; now that we have is_mcr in the workaround
itself, those range tables are redundant. But that's also work for a
future series.
>
> For gen8, this change here should not change any behavior. It
> changes for gen11+ to the correct behavior. So I don't think we need to
> care much about double checking if gen8 had a unique behavior no other
> platforms have. I think just amending the commit message with more
> information like this would be ok.
Yeah, sounds good. With a slightly updated commit message
Reviewed-by: Matt Roper
>
> Lucas De Marchi
>
> >
> >
> > Matt
> >
> > >
> > > Also use intel_uncore_rmw() rather than a read + write where possible.
> > >
> > > Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
> > > Cc: Matt Roper
> > > Cc: Balasubramani Vivekanandan
> > > Cc: Rodrigo Vivi
> > > Cc: Gustavo Sousa
> > > Cc: Matt Atwood
> > > Cc: Ashutosh Dixit
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 ++---
> > > drivers/gpu/drm/i915/intel_pm.c | 10 +-
> > > 4 files changed, 10 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > index 7fa18a3b3957..cc1539c7a6b6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > @@ -686,10 +686,7 @@
> > > #define GEN6_RSTCTL _MMIO(0x9420)
> > >
> > > #define GEN7_MISCCPCTL _MMIO(0x9424)
> > > -#define GEN7_DOP_CLOCK_GATE_ENABLE (1 << 0)
> > > -
> > > -#define GEN8_MISCCPCTL MCR_REG(0x9424)
> > > -#define GEN8_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
> > > +#define GEN7_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
> > > #define GEN12_DOP_CLOCK_GATE_RENDER_ENABLE REG_BIT(1)
> > > #define GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
> > > #define GEN8_DOP_CLOCK_GATE_GUC_ENABLE (1 << 4)
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 29718d0595f4..cfc122c17e28 100644
> > >
Re: [git pull] drm fixes for 6.2-rc7
The pull request you sent on Fri, 3 Feb 2023 13:59:18 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-02-03 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bffede38f82c27cf5e203a2c659fcc9b581dd7b8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/3/23 11:00, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: >> >> >> On 2/3/23 10:19, Ville Syrjälä wrote: >>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: On 2/3/23 07:59, Sebastian Wick wrote: > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > wrote: >> >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: >>> Userspace has no way of controlling or knowing the pixel encoding >>> currently, so there is no way for it to ever get the right values here. >> >> That applies to a lot of the other values as well (they are >> explicitly RGB or YCC). The idea was that this property sets the >> infoframe/MSA/SDP value exactly, and other properties should be >> added to for use userspace to control the pixel encoding/colorspace >> conversion(if desired, or userspace just makes sure to >> directly feed in correct kind of data). > > I'm all for getting userspace control over pixel encoding but even > then the kernel always knows which pixel encoding is selected and > which InfoFrame has to be sent. Is there a reason why userspace would > want to control the variant explicitly to the wrong value? > I've asked this before but haven't seen an answer: Is there an existing upstream userspace project that makes use of this property (other than what Joshua is working on in gamescope right now)? That would help us understand the intent better. >>> >>> The intent was to control the infoframe colorimetry bits, >>> nothing more. No idea what real userspace there was, if any. >>> I don't think giving userspace explicit control over the exact infoframe values is the right thing to do. >>> >>> Only userspace knows what kind of data it's stuffing into >>> the pixels (and/or how it configures the csc units/etc.) to >>> generate them. >>> >> >> Yes, but userspace doesn't control or know whether we drive >> RGB or YCbCr on the wire. In fact, in some cases our driver >> needs to fallback to YCbCr420 for bandwidth reasons. There >> is currently no way for userspace to know that and I don't >> think it makes sense. > > People want that control as well for whatever reason. We've > been asked to allow YCbCr 4:4:4 output many times. > > The automagic 4:2:0 fallback I think is rather fundementally > incompatible with fancy color management. How would we even > know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 > that stuff is just always BT.709 limited range, no questions > asked. > We use what we're telling the display, i.e., the value in the colorspace property. That way we know whether to use a BT.2020 or BT.709 matrix. I don't see how it's fundamentally incompatible with fancy color management stuff. If we start forbidding drivers from falling back to YCbCr (whether 4:4:4 or 4:2:0) we will break existing behavior on amdgpu and will see bug reports. > So I think if userspace wants real color management it's > going to have to set up the whole pipeline. And for that > we need at least one new property to control the RGB->YCbCr > conversion (or to explicitly avoid it). > > And given that the proposed patch just swept all the > non-BT.2020 issues under the rug makes me think no > one has actually come up with any kind of consistent > plan for anything else really. > Does anyone actually use the non-BT.2020 colorspace stuff? Harry >> >> Userspace needs full control of framebuffer pixel formats, >> as well as control over DEGAMMA, GAMMA, CTM color operations. >> It also needs to be able to select whether to drive the panel >> as sRGB or BT.2020/PQ but it doesn't make sense for it to >> control the pixel encoding on the wire (RGB vs YCbCr). >> >>> I really don't want a repeat of the disaster of the >>> 'Broadcast RGB' which has coupled together the infoframe >>> and automagic conversion stuff. And I think this one would >>> be about 100x worse given this property has something >>> to do with actual colorspaces as well. >>> >> >> I'm unaware of this disaster. Could you elaborate? > > The property now controls both the infoframe stuff (and > whatever super vague stuff DP has for it in MSA) and > full->limited range compression in the display pipeline. > And as a result there is no way to eg. allow already > limited range input, which is what some people wanted. > > And naturally it's all made a lot more terrible by all > the displays that fail to implement the spec correctly, > but that's another topic. >
Re: [PATCH v3 00/27] drm/msm/dpu: wide planes support
On 03/02/2023 20:21, Dmitry Baryshkov wrote: The review of the first half of v2 took more than a month. Let's update the reviewed patches in attempt to get the first half of the series into the acked and mergeable state. This would allow us to lower the impact (and the patch count). At 27 patches this series is approaching the limits of manageability. This patchset brings in multirect usage to support using two SSPP rectangles for a single plane. Full virtual planes support is omitted from this pull request, it will come later. Changes since v1 (which was ages ago): - Rebased on top of 6.2-rc1 - Dropped the controversial _dpu_crtc_blend_setup() split patch - Renamed dpu_hw_pipe to dpu_hw_sspp - Other misc changes I forgot to add it here, please excuse me: Changes since v2: - Renamed dpu_hw_pipe_cfg to dpu_hw_sspp_cfg - Added a patch to clean up src add / layout for the solid fill planes - Fixed several comments and commit messages which caused confusion - Added documentation for new dpu_plane_state members - Slightly reworked dpu_plane_atomic_check() to make it more logical and obvious -- With best wishes Dmitry
[PATCH v3 24/27] drm/msm/dpu: rework plane CSC setting
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index e69499490d39..05047192cb37 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -576,29 +576,18 @@ static const struct dpu_csc_cfg dpu_csc10_YUV2RGB_601L = {
{ 0x00, 0x3ff, 0x00, 0x3ff, 0x00, 0x3ff,},
};
-static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_plane *pdpu,
const struct dpu_format *fmt)
+static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt)
{
- struct dpu_plane_state *pstate = to_dpu_plane_state(pdpu->base.state);
const struct dpu_csc_cfg *csc_ptr;
- if (!pdpu) {
- DPU_ERROR("invalid plane\n");
- return NULL;
- }
-
if (!DPU_FORMAT_IS_YUV(fmt))
return NULL;
- if (BIT(DPU_SSPP_CSC_10BIT) & pstate->pipe.sspp->cap->features)
+ if (BIT(DPU_SSPP_CSC_10BIT) & pipe->sspp->cap->features)
csc_ptr = &dpu_csc10_YUV2RGB_601L;
else
csc_ptr = &dpu_csc_YUV2RGB_601L;
- DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
- csc_ptr->csc_mv[0],
- csc_ptr->csc_mv[1],
- csc_ptr->csc_mv[2]);
-
return csc_ptr;
}
@@ -1049,6 +1038,27 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
return 0;
}
+static void dpu_plane_flush_csc(struct dpu_plane *pdpu, struct dpu_sw_pipe
*pipe)
+{
+ const struct dpu_format *format =
to_dpu_format(msm_framebuffer_format(pdpu->base.state->fb));
+ const struct dpu_csc_cfg *csc_ptr;
+
+ if (!pipe->sspp || !pipe->sspp->ops.setup_csc)
+ return;
+
+ csc_ptr = _dpu_plane_get_csc(pipe, format);
+ if (!csc_ptr)
+ return;
+
+ DPU_DEBUG_PLANE(pdpu, "using 0x%X 0x%X 0x%X...\n",
+ csc_ptr->csc_mv[0],
+ csc_ptr->csc_mv[1],
+ csc_ptr->csc_mv[2]);
+
+ pipe->sspp->ops.setup_csc(pipe->sspp, csc_ptr);
+
+}
+
void dpu_plane_flush(struct drm_plane *plane)
{
struct dpu_plane *pdpu;
@@ -1072,13 +1082,8 @@ void dpu_plane_flush(struct drm_plane *plane)
else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
/* force 100% alpha */
_dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
- else if (pstate->pipe.sspp && pstate->pipe.sspp->ops.setup_csc) {
- const struct dpu_format *fmt =
to_dpu_format(msm_framebuffer_format(plane->state->fb));
- const struct dpu_csc_cfg *csc_ptr = _dpu_plane_get_csc(pdpu,
fmt);
-
- if (csc_ptr)
- pstate->pipe.sspp->ops.setup_csc(pstate->pipe.sspp,
csc_ptr);
- }
+ else
+ dpu_plane_flush_csc(pdpu, &pstate->pipe);
/* flag h/w flush complete */
if (plane->state)
--
2.39.1
[PATCH v3 27/27] drm/msm/dpu: add support for wide planes
Typically SSPP can support rectangle with width up to 2560. However it's
possible to use multirect feature and split source to use the SSPP to
output two consecutive rectangles. This commit brings in this capability
to support wider screen resolutions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 116 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +
3 files changed, 114 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 0ca3bc38ff7e..867832a752b2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -485,6 +485,12 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
fetch_active,
&pstate->pipe);
+ _dpu_crtc_blend_setup_pipe(crtc, plane,
+ mixer, cstate->num_mixers,
+ stage_cfg, pstate->stage, 1,
+ fetch_active,
+ &pstate->r_pipe);
+
/* blend config update */
for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
_dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate,
format);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index e2e85688ed3c..401ead64c6bd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -365,6 +365,9 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
+ if (!pipe->sspp)
+ return;
+
memset(&pipe_qos_cfg, 0, sizeof(pipe_qos_cfg));
if (flags & DPU_PLANE_QOS_VBLANK_CTRL) {
@@ -647,6 +650,9 @@ static int _dpu_plane_color_fill_pipe(struct
dpu_plane_state *pstate,
{
struct dpu_hw_sspp_cfg pipe_cfg;
+ if (!pipe->sspp)
+ return 0;
+
/* update sspp */
if (!pipe->sspp->ops.setup_solidfill)
return 0;
@@ -701,6 +707,8 @@ static void _dpu_plane_color_fill(struct dpu_plane *pdpu,
/* update sspp */
_dpu_plane_color_fill_pipe(pstate, &pstate->pipe, &pstate->pipe_cfg,
fill_color, fmt);
+
+ _dpu_plane_color_fill_pipe(pstate, &pstate->r_pipe,
&pstate->r_pipe_cfg, fill_color, fmt);
}
int dpu_plane_validate_multirect_v2(struct dpu_multirect_plane_states *plane)
@@ -911,6 +919,9 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane
*pdpu,
{
uint32_t min_src_size;
+ if (!pipe->sspp)
+ return 0;
+
min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
if (DPU_FORMAT_IS_YUV(fmt) &&
@@ -957,9 +968,12 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
int ret = 0, min_scale;
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
+ struct dpu_sw_pipe *pipe = &pstate->pipe;
+ struct dpu_sw_pipe *r_pipe = &pstate->r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = &pstate->pipe_cfg;
+ struct dpu_hw_sspp_cfg *r_pipe_cfg = &pstate->r_pipe_cfg;
struct drm_rect fb_rect = { 0 };
uint32_t max_linewidth;
unsigned int rotation;
@@ -983,8 +997,11 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->visible)
return 0;
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+ pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+ pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+ r_pipe->multirect_index = DPU_SSPP_RECT_SOLO;
+ r_pipe->multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+ r_pipe->sspp = NULL;
pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
@@ -1016,16 +1033,53 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
- /* check decimated source width */
if (drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) {
- DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
- DRM_RECT_ARG(&pipe_cfg->src_rect),
max_linewidth);
- return -E2BIG;
+ /* struct dpu_crtc_state *cstate =
to_dpu_crtc_state(crtc_state); */
+
+ if (drm_rect_width(&pipe_cfg->src_rect) > 2 * max_linewidth) {
+ DPU_DEBUG_PLANE(pdpu,
[PATCH v3 25/27] drm/msm/dpu: rework static color fill code
Rework static color fill code to separate the pipe / pipe_cfg handling.
This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 70 +--
1 file changed, 41 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 05047192cb37..e2e85688ed3c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -639,20 +639,54 @@ static void _dpu_plane_setup_scaler(struct dpu_sw_pipe
*pipe,
fmt);
}
+static int _dpu_plane_color_fill_pipe(struct dpu_plane_state *pstate,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *old_pipe_cfg,
+ u32 fill_color,
+ const struct dpu_format *fmt)
+{
+ struct dpu_hw_sspp_cfg pipe_cfg;
+
+ /* update sspp */
+ if (!pipe->sspp->ops.setup_solidfill)
+ return 0;
+
+ pipe->sspp->ops.setup_solidfill(pipe, fill_color);
+
+ /* override scaler/decimation if solid fill */
+ pipe_cfg.dst_rect = old_pipe_cfg->dst_rect;
+
+ pipe_cfg.src_rect.x1 = 0;
+ pipe_cfg.src_rect.y1 = 0;
+ pipe_cfg.src_rect.x2 =
+ drm_rect_width(&pipe_cfg.dst_rect);
+ pipe_cfg.src_rect.y2 =
+ drm_rect_height(&pipe_cfg.dst_rect);
+
+ if (pipe->sspp->ops.setup_format)
+ pipe->sspp->ops.setup_format(pipe, fmt, DPU_SSPP_SOLID_FILL);
+
+ if (pipe->sspp->ops.setup_rects)
+ pipe->sspp->ops.setup_rects(pipe, &pipe_cfg);
+
+ _dpu_plane_setup_scaler(pipe, fmt, true, &pipe_cfg, pstate->rotation);
+
+ return 0;
+}
+
/**
* _dpu_plane_color_fill - enables color fill on plane
* @pdpu: Pointer to DPU plane object
* @color: RGB fill color value, [23..16] Blue, [15..8] Green, [7..0] Red
* @alpha: 8-bit fill alpha value, 255 selects 100% alpha
- * Returns: 0 on success
*/
-static int _dpu_plane_color_fill(struct dpu_plane *pdpu,
+static void _dpu_plane_color_fill(struct dpu_plane *pdpu,
uint32_t color, uint32_t alpha)
{
const struct dpu_format *fmt;
const struct drm_plane *plane = &pdpu->base;
struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
- struct dpu_hw_sspp_cfg pipe_cfg;
+ u32 fill_color = (color & 0xFF) | ((alpha & 0xFF) << 24);
DPU_DEBUG_PLANE(pdpu, "\n");
@@ -661,34 +695,12 @@ static int _dpu_plane_color_fill(struct dpu_plane *pdpu,
* h/w only supports RGB variants
*/
fmt = dpu_get_dpu_format(DRM_FORMAT_ABGR);
+ /* should not happen ever */
+ if (!fmt)
+ return;
/* update sspp */
- if (fmt && pstate->pipe.sspp->ops.setup_solidfill) {
- pstate->pipe.sspp->ops.setup_solidfill(&pstate->pipe,
- (color & 0xFF) | ((alpha & 0xFF) << 24));
-
- /* override scaler/decimation if solid fill */
- pipe_cfg.dst_rect = pstate->base.dst;
-
- pipe_cfg.src_rect.x1 = 0;
- pipe_cfg.src_rect.y1 = 0;
- pipe_cfg.src_rect.x2 =
- drm_rect_width(&pipe_cfg.dst_rect);
- pipe_cfg.src_rect.y2 =
- drm_rect_height(&pipe_cfg.dst_rect);
-
- if (pstate->pipe.sspp->ops.setup_format)
- pstate->pipe.sspp->ops.setup_format(&pstate->pipe,
- fmt, DPU_SSPP_SOLID_FILL);
-
- if (pstate->pipe.sspp->ops.setup_rects)
- pstate->pipe.sspp->ops.setup_rects(&pstate->pipe,
- &pipe_cfg);
-
- _dpu_plane_setup_scaler(&pstate->pipe, fmt, true, &pipe_cfg,
pstate->rotation);
- }
-
- return 0;
+ _dpu_plane_color_fill_pipe(pstate, &pstate->pipe, &pstate->pipe_cfg,
fill_color, fmt);
}
int dpu_plane_validate_multirect_v2(struct dpu_multirect_plane_states *plane)
--
2.39.1
[PATCH v3 26/27] drm/msm/dpu: split pipe handling from _dpu_crtc_blend_setup_mixer
Rework _dpu_crtc_blend_setup_mixer() to split away pipe handling to a
separate functon. This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 86 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 ++-
2 files changed, 63 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 73e1a8c69ef0..0ca3bc38ff7e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -400,6 +400,47 @@ static void _dpu_crtc_program_lm_output_roi(struct
drm_crtc *crtc)
}
}
+static void _dpu_crtc_blend_setup_pipe(struct drm_crtc *crtc,
+ struct drm_plane *plane,
+ struct dpu_crtc_mixer *mixer,
+ u32 num_mixers,
+ struct dpu_hw_stage_cfg *stage_cfg,
+ enum dpu_stage stage,
+ unsigned int stage_idx,
+ unsigned long *fetch_active,
+ struct dpu_sw_pipe *pipe
+ )
+{
+ uint32_t lm_idx;
+ enum dpu_sspp sspp_idx;
+ struct drm_plane_state *state;
+
+ if (!pipe->sspp)
+ return;
+
+ sspp_idx = pipe->sspp->idx;
+
+ state = plane->state;
+
+ DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",
+crtc->base.id,
+stage,
+plane->base.id,
+sspp_idx - SSPP_NONE,
+state->fb ? state->fb->base.id : -1);
+
+ set_bit(sspp_idx, fetch_active);
+
+ stage_cfg->stage[stage][stage_idx] = sspp_idx;
+ stage_cfg->multirect_index[stage][stage_idx] =
+ pipe->multirect_index;
+
+ /* blend config update */
+ for (lm_idx = 0; lm_idx < num_mixers; lm_idx++)
+
mixer[lm_idx].lm_ctl->ops.update_pending_flush_sspp(mixer[lm_idx].lm_ctl,
+ sspp_idx);
+}
+
static void _dpu_crtc_blend_setup_mixer(struct drm_crtc *crtc,
struct dpu_crtc *dpu_crtc, struct dpu_crtc_mixer *mixer,
struct dpu_hw_stage_cfg *stage_cfg)
@@ -412,15 +453,12 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
struct dpu_format *format;
struct dpu_hw_ctl *ctl = mixer->lm_ctl;
- uint32_t stage_idx, lm_idx;
- int zpos_cnt[DPU_STAGE_MAX + 1] = { 0 };
+ uint32_t lm_idx;
bool bg_alpha_enable = false;
DECLARE_BITMAP(fetch_active, SSPP_MAX);
memset(fetch_active, 0, sizeof(fetch_active));
drm_atomic_crtc_for_each_plane(plane, crtc) {
- enum dpu_sspp sspp_idx;
-
state = plane->state;
if (!state)
continue;
@@ -431,39 +469,25 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
pstate = to_dpu_plane_state(state);
fb = state->fb;
- sspp_idx = pstate->pipe.sspp->idx;
- set_bit(sspp_idx, fetch_active);
-
- DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",
- crtc->base.id,
- pstate->stage,
- plane->base.id,
- sspp_idx - SSPP_VIG0,
- state->fb ? state->fb->base.id : -1);
-
format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));
if (pstate->stage == DPU_STAGE_BASE && format->alpha_enable)
bg_alpha_enable = true;
- stage_idx = zpos_cnt[pstate->stage]++;
- stage_cfg->stage[pstate->stage][stage_idx] =
- sspp_idx;
- stage_cfg->multirect_index[pstate->stage][stage_idx] =
- pstate->pipe.multirect_index;
-
trace_dpu_crtc_setup_mixer(DRMID(crtc), DRMID(plane),
- state, pstate, stage_idx,
+ state, pstate,
format->base.pixel_format,
fb ? fb->modifier : 0);
+ _dpu_crtc_blend_setup_pipe(crtc, plane,
+ mixer, cstate->num_mixers,
+ stage_cfg, pstate->stage, 0,
+ fetch_active,
+ &pstate->pipe);
+
/* blend config update */
for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++
[PATCH v3 22/27] drm/msm/dpu: rework dpu_plane_sspp_atomic_update()
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 --
1 file changed, 63 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 0986e740b978..f94e132733f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -404,12 +404,13 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane
*plane,
* _dpu_plane_set_ot_limit - set OT limit for the given plane
* @plane: Pointer to drm plane
* @pipe: Pointer to software pipe
- * @crtc: Pointer to drm crtc
* @pipe_cfg: Pointer to pipe configuration
+ * @frame_rate:CRTC's frame rate
*/
static void _dpu_plane_set_ot_limit(struct drm_plane *plane,
struct dpu_sw_pipe *pipe,
- struct drm_crtc *crtc, struct dpu_hw_sspp_cfg *pipe_cfg)
+ struct dpu_hw_sspp_cfg *pipe_cfg,
+ int frame_rate)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_vbif_set_ot_params ot_params;
@@ -421,7 +422,7 @@ static void _dpu_plane_set_ot_limit(struct drm_plane *plane,
ot_params.width = drm_rect_width(&pipe_cfg->src_rect);
ot_params.height = drm_rect_height(&pipe_cfg->src_rect);
ot_params.is_wfd = !pdpu->is_rt_pipe;
- ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
+ ot_params.frame_rate = frame_rate;
ot_params.vbif_idx = VBIF_RT;
ot_params.clk_ctrl = pipe->sspp->cap->clk_ctrl;
ot_params.rd = true;
@@ -457,26 +458,6 @@ static void _dpu_plane_set_qos_remap(struct drm_plane
*plane,
dpu_vbif_set_qos_remap(dpu_kms, &qos_params);
}
-static void _dpu_plane_set_scanout(struct drm_plane *plane,
- struct dpu_plane_state *pstate,
- struct drm_framebuffer *fb)
-{
- struct dpu_plane *pdpu = to_dpu_plane(plane);
- struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
- struct msm_gem_address_space *aspace = kms->base.aspace;
- struct dpu_hw_fmt_layout layout;
- int ret;
-
- ret = dpu_format_populate_layout(aspace, fb, &layout);
- if (ret)
- DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
- else if (pstate->pipe.sspp->ops.setup_sourceaddress) {
- trace_dpu_plane_set_scanout(&pstate->pipe,
- &layout);
- pstate->pipe.sspp->ops.setup_sourceaddress(&pstate->pipe,
&layout);
- }
-}
-
static void _dpu_plane_setup_scaler3(struct dpu_hw_sspp *pipe_hw,
uint32_t src_w, uint32_t src_h, uint32_t dst_w, uint32_t dst_h,
struct dpu_hw_scaler3_cfg *scale_cfg,
@@ -1102,35 +1083,25 @@ void dpu_plane_set_error(struct drm_plane *plane, bool
error)
pdpu->is_error = error;
}
-static void dpu_plane_sspp_atomic_update(struct drm_plane *plane)
+static void dpu_plane_sspp_update_pipe(struct drm_plane *plane,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
+ const struct dpu_format *fmt,
+ int frame_rate,
+ struct dpu_hw_fmt_layout *layout)
{
uint32_t src_flags;
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct drm_plane_state *state = plane->state;
struct dpu_plane_state *pstate = to_dpu_plane_state(state);
- struct dpu_sw_pipe *pipe = &pstate->pipe;
- struct drm_crtc *crtc = state->crtc;
- struct drm_framebuffer *fb = state->fb;
- bool is_rt_pipe;
- const struct dpu_format *fmt =
- to_dpu_format(msm_framebuffer_format(fb));
- struct dpu_hw_sspp_cfg *pipe_cfg = &pstate->pipe_cfg;
- _dpu_plane_set_scanout(plane, pstate, fb);
-
- pstate->pending = true;
-
- is_rt_pipe = (dpu_crtc_get_client_type(crtc) != NRT_CLIENT);
- pstate->needs_qos_remap |= (is_rt_pipe != pdpu->is_rt_pipe);
- pdpu->is_rt_pipe = is_rt_pipe;
+ if (layout && pipe->sspp->ops.setup_sourceaddress) {
+ trace_dpu_plane_set_scanout(pipe, layout);
+ pipe->sspp->ops.setup_sourceaddress(pipe, layout);
+ }
_dpu_plane_set_qos_ctrl(plane, pipe, false, DPU_PLANE_QOS_PANIC_CTRL);
- DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u " DRM_RECT_FMT
- ", %4.4s ubwc %d\n", fb->base.id,
DRM_RECT_FP_ARG(&state->src),
- crtc->base.id, DRM_RECT_ARG(&state->dst),
- (char *)&fmt->base.pixel_format,
DPU_FORMAT_IS_UBWC(fmt));
-
[PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check()
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88 ++-
1 file changed, 53 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f94e132733f3..e69499490d39 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -903,6 +903,51 @@ static int dpu_plane_check_inline_rotation(struct
dpu_plane *pdpu,
return 0;
}
+static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu,
+ struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *pipe_cfg,
+ const struct dpu_format *fmt)
+{
+ uint32_t min_src_size;
+
+ min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
+
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (!(pipe->sspp->cap->features & DPU_SSPP_SCALER) ||
+!(pipe->sspp->cap->features & DPU_SSPP_CSC_ANY))) {
+ DPU_DEBUG_PLANE(pdpu,
+ "plane doesn't have scaler/csc for yuv\n");
+ return -EINVAL;
+ }
+
+ /* check src bounds */
+ if (drm_rect_width(&pipe_cfg->src_rect) < min_src_size ||
+ drm_rect_height(&pipe_cfg->src_rect) < min_src_size) {
+ DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(&pipe_cfg->src_rect));
+ return -E2BIG;
+ }
+
+ /* valid yuv image */
+ if (DPU_FORMAT_IS_YUV(fmt) &&
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 & 0x1
||
+ drm_rect_width(&pipe_cfg->src_rect) & 0x1 ||
+ drm_rect_height(&pipe_cfg->src_rect) & 0x1)) {
+ DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(&pipe_cfg->src_rect));
+ return -EINVAL;
+ }
+
+ /* min dst support */
+ if (drm_rect_width(&pipe_cfg->dst_rect) < 0x1 ||
drm_rect_height(&pipe_cfg->dst_rect) < 0x1) {
+ DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(&pipe_cfg->dst_rect));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -915,7 +960,7 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = &pstate->pipe_cfg;
struct drm_rect fb_rect = { 0 };
- uint32_t min_src_size, max_linewidth;
+ uint32_t max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
const struct dpu_sspp_cfg *pipe_hw_caps = pstate->pipe.sspp->cap;
@@ -970,46 +1015,19 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
max_linewidth = pdpu->catalog->caps->max_linewidth;
- fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
- min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
-
- if (DPU_FORMAT_IS_YUV(fmt) &&
- (!(pipe_hw_caps->features & DPU_SSPP_SCALER) ||
-!(pipe_hw_caps->features & DPU_SSPP_CSC_ANY))) {
- DPU_DEBUG_PLANE(pdpu,
- "plane doesn't have scaler/csc for yuv\n");
- return -EINVAL;
-
- /* check src bounds */
- } else if (drm_rect_width(&pipe_cfg->src_rect) < min_src_size ||
- drm_rect_height(&pipe_cfg->src_rect) < min_src_size) {
- DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(&pipe_cfg->src_rect));
- return -E2BIG;
-
- /* valid yuv image */
- } else if (DPU_FORMAT_IS_YUV(fmt) &&
- (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 & 0x1
||
- drm_rect_width(&pipe_cfg->src_rect) & 0x1 ||
- drm_rect_height(&pipe_cfg->src_rect) & 0x1)) {
- DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(&pipe_cfg->src_rect));
- return -EINVAL;
-
- /* min dst support */
- } else if (drm_rect_width(&pipe_cfg->dst_rect) < 0x1 ||
drm_rect_height(&pipe_cfg->dst_rect) < 0x1) {
- DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(&pipe_cfg->dst_rect));
- return -EINVAL;
-
/* check decimated source width */
- } else if (drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) {
+ if (drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) {
[PATCH v3 21/27] drm/msm/dpu: simplify dpu_plane_validate_src()
Since the driver uses clipped src coordinates, there is no need to check
against the fb coordinates. Remove corresponding checks and inline
dpu_plane_validate_src().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30 ---
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ecf5402ab61a..0986e740b978 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -894,25 +894,6 @@ static void dpu_plane_cleanup_fb(struct drm_plane *plane,
old_pstate->needs_dirtyfb);
}
-static bool dpu_plane_validate_src(struct drm_rect *src,
- struct drm_rect *fb_rect,
- uint32_t min_src_size)
-{
- /* Ensure fb size is supported */
- if (drm_rect_width(fb_rect) > MAX_IMG_WIDTH ||
- drm_rect_height(fb_rect) > MAX_IMG_HEIGHT)
- return false;
-
- /* Ensure src rect is above the minimum size */
- if (drm_rect_width(src) < min_src_size ||
- drm_rect_height(src) < min_src_size)
- return false;
-
- /* Ensure src is fully encapsulated in fb */
- return drm_rect_intersect(fb_rect, src) &&
- drm_rect_equals(fb_rect, src);
-}
-
static int dpu_plane_check_inline_rotation(struct dpu_plane *pdpu,
const struct dpu_sspp_sub_blks
*sblk,
struct drm_rect src, const
struct dpu_format *fmt)
@@ -998,6 +979,14 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
fb_rect.x2 = new_plane_state->fb->width;
fb_rect.y2 = new_plane_state->fb->height;
+ /* Ensure fb size is supported */
+ if (drm_rect_width(&fb_rect) > MAX_IMG_WIDTH ||
+ drm_rect_height(&fb_rect) > MAX_IMG_HEIGHT) {
+ DPU_DEBUG_PLANE(pdpu, "invalid framebuffer " DRM_RECT_FMT "\n",
+ DRM_RECT_ARG(&fb_rect));
+ return -E2BIG;
+ }
+
max_linewidth = pdpu->catalog->caps->max_linewidth;
fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
@@ -1012,7 +1001,8 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
/* check src bounds */
- } else if (!dpu_plane_validate_src(&pipe_cfg->src_rect, &fb_rect,
min_src_size)) {
+ } else if (drm_rect_width(&pipe_cfg->src_rect) < min_src_size ||
+ drm_rect_height(&pipe_cfg->src_rect) < min_src_size) {
DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
DRM_RECT_ARG(&pipe_cfg->src_rect));
return -E2BIG;
--
2.39.1
[PATCH v3 20/27] drm/msm/dpu: add dpu_hw_pipe_cfg to dpu_plane_state
Now as all accesses to pipe_cfg and pstate have been cleaned, re-add
struct dpu_hw_pipe_cfg back to dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped rectangles, while
dpu_plane_atomic_update() uses clipped rectangles calculated by
drm_atomic_helper_check_plane_state()).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 64 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
2 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 09a3fde1c910..ecf5402ab61a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -951,7 +951,8 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
struct dpu_plane_state *pstate = to_dpu_plane_state(new_plane_state);
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
- struct drm_rect src, dst, fb_rect = { 0 };
+ struct dpu_hw_sspp_cfg *pipe_cfg = &pstate->pipe_cfg;
+ struct drm_rect fb_rect = { 0 };
uint32_t min_src_size, max_linewidth;
unsigned int rotation;
uint32_t supported_rotations;
@@ -984,12 +985,15 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
- src.x1 = new_plane_state->src_x >> 16;
- src.y1 = new_plane_state->src_y >> 16;
- src.x2 = src.x1 + (new_plane_state->src_w >> 16);
- src.y2 = src.y1 + (new_plane_state->src_h >> 16);
+ pipe_cfg->src_rect = new_plane_state->src;
- dst = drm_plane_state_dest(new_plane_state);
+ /* state->src is 16.16, src_rect is not */
+ pipe_cfg->src_rect.x1 >>= 16;
+ pipe_cfg->src_rect.x2 >>= 16;
+ pipe_cfg->src_rect.y1 >>= 16;
+ pipe_cfg->src_rect.y2 >>= 16;
+
+ pipe_cfg->dst_rect = new_plane_state->dst;
fb_rect.x2 = new_plane_state->fb->width;
fb_rect.y2 = new_plane_state->fb->height;
@@ -1008,30 +1012,30 @@ static int dpu_plane_atomic_check(struct drm_plane
*plane,
return -EINVAL;
/* check src bounds */
- } else if (!dpu_plane_validate_src(&src, &fb_rect, min_src_size)) {
+ } else if (!dpu_plane_validate_src(&pipe_cfg->src_rect, &fb_rect,
min_src_size)) {
DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(&src));
+ DRM_RECT_ARG(&pipe_cfg->src_rect));
return -E2BIG;
/* valid yuv image */
} else if (DPU_FORMAT_IS_YUV(fmt) &&
- (src.x1 & 0x1 || src.y1 & 0x1 ||
- drm_rect_width(&src) & 0x1 ||
- drm_rect_height(&src) & 0x1)) {
+ (pipe_cfg->src_rect.x1 & 0x1 || pipe_cfg->src_rect.y1 & 0x1
||
+ drm_rect_width(&pipe_cfg->src_rect) & 0x1 ||
+ drm_rect_height(&pipe_cfg->src_rect) & 0x1)) {
DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(&src));
+ DRM_RECT_ARG(&pipe_cfg->src_rect));
return -EINVAL;
/* min dst support */
- } else if (drm_rect_width(&dst) < 0x1 || drm_rect_height(&dst) < 0x1) {
+ } else if (drm_rect_width(&pipe_cfg->dst_rect) < 0x1 ||
drm_rect_height(&pipe_cfg->dst_rect) < 0x1) {
DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
- DRM_RECT_ARG(&dst));
+ DRM_RECT_ARG(&pipe_cfg->dst_rect));
return -EINVAL;
/* check decimated source width */
- } else if (drm_rect_width(&src) > max_linewidth) {
+ } else if (drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) {
DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
- DRM_RECT_ARG(&src), max_linewidth);
+ DRM_RECT_ARG(&pipe_cfg->src_rect),
max_linewidth);
return -E2BIG;
}
@@ -1045,7 +1049,7 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
if ((pipe_hw_caps->features & BIT(DPU_SSPP_INLINE_ROTATION)) &&
(rotation & DRM_MODE_ROTATE_90)) {
- ret = dpu_plane_check_inline_rotation(pdpu, sblk, src, fmt);
+ ret = dpu_plane_check_inline_rotation(pdpu, sblk,
pipe_cfg->src_rect, fmt);
if (ret)
return ret;
}
@@ -1120,9 +1124,7 @@ static void dpu_plane_sspp_atomic_update(struct drm_plane
*plane)
bool is_rt_pipe;
const struct dpu_format *fmt =
to_dpu_format(msm_framebuffer_format(fb));
- struct dpu_hw_sspp_cfg pi
[PATCH v3 19/27] drm/msm/dpu: make _dpu_plane_calc_clk accept mode directly
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ee261a591d45..09a3fde1c910 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -127,20 +127,19 @@ static struct dpu_kms *_dpu_plane_get_kms(struct
drm_plane *plane)
/**
* _dpu_plane_calc_bw - calculate bandwidth required for a plane
- * @plane: Pointer to drm plane.
+ * @catalog: Points to dpu catalog structure
* @fmt: Pointer to source buffer format
+ * @mode: Pointer to drm display mode
* @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated bandwidth in the plane state.
* BW Equation: src_w * src_h * bpp * fps * (v_total / v_dest)
* Prefill BW Equation: line src bytes * line_time
*/
-static void _dpu_plane_calc_bw(struct drm_plane *plane,
+static u64 _dpu_plane_calc_bw(const struct dpu_mdss_cfg *catalog,
const struct dpu_format *fmt,
+ const struct drm_display_mode *mode,
struct dpu_hw_sspp_cfg *pipe_cfg)
{
- struct dpu_plane_state *pstate;
- struct drm_display_mode *mode;
- struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
int src_width, src_height, dst_height, fps;
u64 plane_prefill_bw;
u64 plane_bw;
@@ -148,9 +147,6 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
u64 scale_factor;
int vbp, vpw, vfp;
- pstate = to_dpu_plane_state(plane->state);
- mode = &plane->state->crtc->mode;
-
src_width = drm_rect_width(&pipe_cfg->src_rect);
src_height = drm_rect_height(&pipe_cfg->src_rect);
dst_height = drm_rect_height(&pipe_cfg->dst_rect);
@@ -158,7 +154,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
vbp = mode->vtotal - mode->vsync_end;
vpw = mode->vsync_end - mode->vsync_start;
vfp = mode->vsync_start - mode->vdisplay;
- hw_latency_lines = dpu_kms->catalog->perf->min_prefill_lines;
+ hw_latency_lines = catalog->perf->min_prefill_lines;
scale_factor = src_height > dst_height ?
mult_frac(src_height, 1, dst_height) : 1;
@@ -178,37 +174,36 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
do_div(plane_prefill_bw, hw_latency_lines);
- pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
+ return max(plane_bw, plane_prefill_bw);
}
/**
* _dpu_plane_calc_clk - calculate clock required for a plane
- * @plane: Pointer to drm plane.
+ * @mode: Pointer to drm display mode
* @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated clock in the plane state.
* Clock equation: dst_w * v_total * fps * (src_h / dst_h)
*/
-static void _dpu_plane_calc_clk(struct drm_plane *plane, struct
dpu_hw_sspp_cfg *pipe_cfg)
+static u64 _dpu_plane_calc_clk(const struct drm_display_mode *mode,
+ struct dpu_hw_sspp_cfg *pipe_cfg)
{
- struct dpu_plane_state *pstate;
- struct drm_display_mode *mode;
int dst_width, src_height, dst_height, fps;
-
- pstate = to_dpu_plane_state(plane->state);
- mode = &plane->state->crtc->mode;
+ u64 plane_clk;
src_height = drm_rect_height(&pipe_cfg->src_rect);
dst_width = drm_rect_width(&pipe_cfg->dst_rect);
dst_height = drm_rect_height(&pipe_cfg->dst_rect);
fps = drm_mode_vrefresh(mode);
- pstate->plane_clk =
+ plane_clk =
dst_width * mode->vtotal * fps;
if (src_height > dst_height) {
- pstate->plane_clk *= src_height;
- do_div(pstate->plane_clk, dst_height);
+ plane_clk *= src_height;
+ do_div(plane_clk, dst_height);
}
+
+ return plane_clk;
}
/**
@@ -1219,9 +1214,9 @@ static void dpu_plane_sspp_atomic_update(struct drm_plane
*plane)
_dpu_plane_set_qos_remap(plane, pipe);
}
- _dpu_plane_calc_bw(plane, fmt, &pipe_cfg);
+ pstate->plane_fetch_bw = _dpu_plane_calc_bw(pdpu->catalog, fmt,
&crtc->mode, &pipe_cfg);
- _dpu_plane_calc_clk(plane, &pipe_cfg);
+ pstate->plane_clk = _dpu_plane_calc_clk(&crtc->mode, &pipe_cfg);
}
static void _dpu_plane_atomic_disable(struct drm_plane *plane)
--
2.39.1
[PATCH v3 13/27] drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these features is not removed from the backend
code (sspp, ctl, etc).
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 168 ++-
1 file changed, 12 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 037347e51eb8..c1579d6f5060 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1108,13 +1108,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
drm_crtc_vblank_on(crtc);
}
-struct plane_state {
- struct dpu_plane_state *dpu_pstate;
- const struct drm_plane_state *drm_pstate;
- int stage;
- u32 pipe_id;
-};
-
static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state *cstate)
{
struct drm_crtc *crtc = cstate->crtc;
@@ -1136,31 +1129,22 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
- struct plane_state *pstates;
const struct drm_plane_state *pstate;
struct drm_plane *plane;
struct drm_display_mode *mode;
- int cnt = 0, rc = 0, mixer_width = 0, i, z_pos;
+ int rc = 0;
- struct dpu_multirect_plane_states multirect_plane[DPU_STAGE_MAX * 2];
- int multirect_count = 0;
- const struct drm_plane_state *pipe_staged[SSPP_MAX];
- int left_zpos_cnt = 0, right_zpos_cnt = 0;
struct drm_rect crtc_rect = { 0 };
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
- pstates = kzalloc(sizeof(*pstates) * DPU_STAGE_MAX * 4, GFP_KERNEL);
- if (!pstates)
- return -ENOMEM;
-
if (!crtc_state->enable || !crtc_state->active) {
DRM_DEBUG_ATOMIC("crtc%d -> enable %d, active %d, skip
atomic_check\n",
crtc->base.id, crtc_state->enable,
crtc_state->active);
memset(&cstate->new_perf, 0, sizeof(cstate->new_perf));
- goto end;
+ return 0;
}
mode = &crtc_state->adjusted_mode;
@@ -1170,13 +1154,8 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
if (crtc_state->active_changed)
crtc_state->mode_changed = true;
- memset(pipe_staged, 0, sizeof(pipe_staged));
-
- if (cstate->num_mixers) {
- mixer_width = mode->hdisplay / cstate->num_mixers;
-
+ if (cstate->num_mixers)
_dpu_crtc_setup_lm_bounds(crtc, crtc_state);
- }
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
@@ -1185,38 +1164,21 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
+ int z_pos;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
DPU_ERROR("%s: failed to get plane%d state, %d\n",
dpu_crtc->name, plane->base.id, rc);
- goto end;
+ return rc;
}
- if (cnt >= DPU_STAGE_MAX * 4)
- continue;
if (!pstate->visible)
continue;
- pstates[cnt].dpu_pstate = dpu_pstate;
- pstates[cnt].drm_pstate = pstate;
- pstates[cnt].stage = pstate->normalized_zpos;
- pstates[cnt].pipe_id =
to_dpu_plane_state(pstate)->pipe.sspp->idx;
-
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
- if (pipe_staged[pstates[cnt].pipe_id]) {
- multirect_plane[multirect_count].r0 =
- pipe_staged[pstates[cnt].pipe_id];
- multirect_plane[multirect_count].r1 = pstate;
- multirect_count++;
-
- pipe_staged[pstates[cnt].pipe_id] = NULL;
- } else {
- pipe_staged[pstates[cnt].pipe_id] = pstate;
- }
-
- cnt++;
+ dpu_plane_clear_multirect(pstate);
dst = drm_plane_state_dest(pstate);
if (!drm_rect_intersect(&clip, &dst)) {
@@ -1224,63 +1186,21 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
[PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 --
3 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b485234eefb2..bd09bb319a58 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,7 +1129,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
- struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1161,11 +1160,10 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
-/* get plane state for all drm planes associated with crtc state */
+ /* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1179,8 +1177,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
- dpu_plane_clear_multirect(pstate);
-
dst = drm_plane_state_dest(pstate);
if (!drm_rect_intersect(&clip, &dst)) {
DPU_ERROR("invalid vertical/horizontal destination\n");
@@ -1189,18 +1185,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
DRM_RECT_ARG(&dst));
return -E2BIG;
}
-
- /* verify stage setting before using it */
- stage = DPU_STAGE_0 + pstate->normalized_zpos;
- if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
- DPU_ERROR("> %d plane stages assigned\n",
-
dpu_kms->catalog->caps->max_mixer_blendstages - DPU_STAGE_0);
- return -EINVAL;
- }
-
- to_dpu_plane_state(pstate)->stage = stage;
- DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
-
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 1b3033b15bfa..5aabf9694a53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -733,14 +733,6 @@ static int _dpu_plane_color_fill(struct dpu_plane *pdpu,
return 0;
}
-void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state)
-{
- struct dpu_plane_state *pstate = to_dpu_plane_state(drm_state);
-
- pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
- pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
-}
-
int dpu_plane_validate_multirect_v2(struct dpu_multirect_plane_states *plane)
{
struct dpu_plane_state *pstate[R_MAX];
@@ -994,6 +986,16 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->visible)
return 0;
+ pstate->pipe.multirect_index = DPU_SSPP_RECT_SOLO;
+ pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
+
+ pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;
+ if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
+ DPU_ERROR("> %d plane stages assigned\n",
+ pdpu->catalog->caps->max_mixer_blendstages -
DPU_STAGE_0);
+ return -EINVAL;
+ }
+
src.x1 = new_plane_state->src_x >> 16;
src.y1 = new_plane_state->src_y >> 16;
src.x2 = src.x1 + (new_plane_state->src_w >> 16);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 228db401e905..a08b0539513b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -88,12 +88,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
*/
int dpu_plane_validate_multirect_v2(struct dpu_multirect_plane_states *plane);
-/**
- * dpu_plane_clear_multirect - clear multirect bits for the given pipe
- * @drm_state: Pointer to DRM plane state
- */
-void dpu_plane_clear_multirect(const struct drm_plane_state *drm_state)
[PATCH v3 12/27] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_sspp_cfg
Remove dpu_hw_fmt_layout instance from struct dpu_hw_sspp_cfg, leaving
only src_rect and dst_rect. This way all the pipes used by the plane
will have a common layout instance (as the framebuffer is shared between
them), while still keeping a separate src/dst rectangle configuration
for each pipe.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 32 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 6 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 10 +++
3 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index fbfb39a7a229..0f069931d0ba 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -490,7 +490,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe
*pipe,
}
static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,
- struct dpu_hw_sspp_cfg *cfg)
+ struct dpu_hw_fmt_layout *layout)
{
struct dpu_hw_sspp *ctx = pipe->sspp;
u32 ystride0, ystride1;
@@ -501,41 +501,41 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_sw_pipe *pipe,
return;
if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
- for (i = 0; i < ARRAY_SIZE(cfg->layout.plane_addr); i++)
+ for (i = 0; i < ARRAY_SIZE(layout->plane_addr); i++)
DPU_REG_WRITE(&ctx->hw, SSPP_SRC0_ADDR + idx + i * 0x4,
- cfg->layout.plane_addr[i]);
+ layout->plane_addr[i]);
} else if (pipe->multirect_index == DPU_SSPP_RECT_0) {
DPU_REG_WRITE(&ctx->hw, SSPP_SRC0_ADDR + idx,
- cfg->layout.plane_addr[0]);
+ layout->plane_addr[0]);
DPU_REG_WRITE(&ctx->hw, SSPP_SRC2_ADDR + idx,
- cfg->layout.plane_addr[2]);
+ layout->plane_addr[2]);
} else {
DPU_REG_WRITE(&ctx->hw, SSPP_SRC1_ADDR + idx,
- cfg->layout.plane_addr[0]);
+ layout->plane_addr[0]);
DPU_REG_WRITE(&ctx->hw, SSPP_SRC3_ADDR + idx,
- cfg->layout.plane_addr[2]);
+ layout->plane_addr[2]);
}
if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
- ystride0 = (cfg->layout.plane_pitch[0]) |
- (cfg->layout.plane_pitch[1] << 16);
- ystride1 = (cfg->layout.plane_pitch[2]) |
- (cfg->layout.plane_pitch[3] << 16);
+ ystride0 = (layout->plane_pitch[0]) |
+ (layout->plane_pitch[1] << 16);
+ ystride1 = (layout->plane_pitch[2]) |
+ (layout->plane_pitch[3] << 16);
} else {
ystride0 = DPU_REG_READ(&ctx->hw, SSPP_SRC_YSTRIDE0 + idx);
ystride1 = DPU_REG_READ(&ctx->hw, SSPP_SRC_YSTRIDE1 + idx);
if (pipe->multirect_index == DPU_SSPP_RECT_0) {
ystride0 = (ystride0 & 0x) |
- (cfg->layout.plane_pitch[0] & 0x);
+ (layout->plane_pitch[0] & 0x);
ystride1 = (ystride1 & 0x)|
- (cfg->layout.plane_pitch[2] & 0x);
+ (layout->plane_pitch[2] & 0x);
} else {
ystride0 = (ystride0 & 0x) |
- ((cfg->layout.plane_pitch[0] << 16) &
+ ((layout->plane_pitch[0] << 16) &
0x);
ystride1 = (ystride1 & 0x) |
- ((cfg->layout.plane_pitch[2] << 16) &
+ ((layout->plane_pitch[2] << 16) &
0x);
}
}
@@ -564,7 +564,7 @@ static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
static void dpu_hw_sspp_setup_solidfill(struct dpu_sw_pipe *pipe, u32 color)
{
struct dpu_hw_sspp *ctx = pipe->sspp;
- struct dpu_hw_sspp_cfg cfg;
+ struct dpu_hw_fmt_layout cfg;
u32 idx;
if (_sspp_subblk_offset(ctx, DPU_SSPP_SRC, &idx))
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 5e9b07090a21..551036224876 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -154,13 +154,11 @@ struct dpu_hw_pixel_ext {
/**
* struct dpu_hw_sspp_cfg : SSPP configuration
- * @layout:format layout information for programming buffer to hardware
[PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
Downstream driver uses dpu->caps->smart_dma_rev to update sspp->cap->features with the bit corresponding to the supported SmartDMA version. Upstream driver does not do this, resulting in SSPP subdriver not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP feature bits to dpu hw catalog. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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 cf053e8f081e..fc818b0273e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -21,13 +21,16 @@ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_SM8250_MASK \ - (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE) |\ + BIT(DPU_SSPP_SMART_DMA_V2)) #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL)) @@ -42,6 +45,7 @@ #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\ + BIT(DPU_SSPP_SMART_DMA_V2) |\ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT)) #define DMA_CURSOR_SDM845_MASK \ -- 2.39.1
[PATCH v3 17/27] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
1 file changed, 47 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5aabf9694a53..ee261a591d45 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -128,19 +128,18 @@ static struct dpu_kms *_dpu_plane_get_kms(struct
drm_plane *plane)
/**
* _dpu_plane_calc_bw - calculate bandwidth required for a plane
* @plane: Pointer to drm plane.
- * @fb: Pointer to framebuffer associated with the given plane
+ * @fmt: Pointer to source buffer format
* @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated bandwidth in the plane state.
* BW Equation: src_w * src_h * bpp * fps * (v_total / v_dest)
* Prefill BW Equation: line src bytes * line_time
*/
static void _dpu_plane_calc_bw(struct drm_plane *plane,
- struct drm_framebuffer *fb,
+ const struct dpu_format *fmt,
struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane_state *pstate;
struct drm_display_mode *mode;
- const struct dpu_format *fmt = NULL;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
int src_width, src_height, dst_height, fps;
u64 plane_prefill_bw;
@@ -152,8 +151,6 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
pstate = to_dpu_plane_state(plane->state);
mode = &plane->state->crtc->mode;
- fmt = dpu_get_dpu_format_ext(fb->format->format, fb->modifier);
-
src_width = drm_rect_width(&pipe_cfg->src_rect);
src_height = drm_rect_height(&pipe_cfg->src_rect);
dst_height = drm_rect_height(&pipe_cfg->dst_rect);
@@ -217,25 +214,25 @@ static void _dpu_plane_calc_clk(struct drm_plane *plane,
struct dpu_hw_sspp_cfg
/**
* _dpu_plane_calc_fill_level - calculate fill level of the given source format
* @plane: Pointer to drm plane
+ * @pipe: Pointer to software pipe
* @fmt: Pointer to source buffer format
* @src_width: width of source buffer
* Return: fill level corresponding to the source buffer/format or 0 if error
*/
static int _dpu_plane_calc_fill_level(struct drm_plane *plane,
+ struct dpu_sw_pipe *pipe,
const struct dpu_format *fmt, u32 src_width)
{
struct dpu_plane *pdpu;
- struct dpu_plane_state *pstate;
u32 fixed_buff_size;
u32 total_fl;
- if (!fmt || !plane->state || !src_width || !fmt->bpp) {
+ if (!fmt || !pipe || !src_width || !fmt->bpp) {
DPU_ERROR("invalid arguments\n");
return 0;
}
pdpu = to_dpu_plane(plane);
- pstate = to_dpu_plane_state(plane->state);
fixed_buff_size = pdpu->catalog->caps->pixel_ram_size;
/* FIXME: in multirect case account for the src_width of all the planes
*/
@@ -251,7 +248,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
((src_width + 32) * fmt->bpp);
}
} else {
- if (pstate->pipe.multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL)
{
+ if (pipe->multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL) {
total_fl = (fixed_buff_size / 2) * 2 /
((src_width + 32) * fmt->bpp);
} else {
@@ -261,7 +258,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
}
DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s w:%u fl:%u\n",
- pdpu->pipe - SSPP_VIG0,
+ pipe->sspp->idx - SSPP_VIG0,
(char *)&fmt->base.pixel_format,
src_width, total_fl);
@@ -271,25 +268,22 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
/**
* _dpu_plane_set_qos_lut - set QoS LUT of the given plane
* @plane: Pointer to drm plane
- * @fb:Pointer to framebuffer associated with the
given plane
+ * @pipe: Pointer to software pipe
+ * @fmt: Pointer to source buffer format
* @pipe_cfg: Pointer to pipe configuration
*/
static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
- struct drm_framebuffer *fb, struct dpu_hw_sspp_cfg *pipe_cfg)
+ struct dpu_sw_pipe *pipe,
+ const struct dpu_format *fmt, struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
- struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
- const struct dpu_format *fmt = NULL;
u64 qos_lut;
u32 total_fl = 0, lut_usage;
if (!pdpu->is_rt_pipe
[PATCH v3 14/27] drm/msm/dpu: don't use unsupported blend stages
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index c1579d6f5060..b485234eefb2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1129,6 +1129,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
crtc);
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc_state);
+ struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
const struct drm_plane_state *pstate;
struct drm_plane *plane;
@@ -1164,7 +1165,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
struct drm_rect dst, clip = crtc_rect;
- int z_pos;
+ int stage;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1189,17 +1190,16 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
return -E2BIG;
}
- z_pos = pstate->normalized_zpos;
-
- /* verify z_pos setting before using it */
- if (z_pos >= DPU_STAGE_MAX - DPU_STAGE_0) {
+ /* verify stage setting before using it */
+ stage = DPU_STAGE_0 + pstate->normalized_zpos;
+ if (stage >= dpu_kms->catalog->caps->max_mixer_blendstages) {
DPU_ERROR("> %d plane stages assigned\n",
- DPU_STAGE_MAX - DPU_STAGE_0);
+
dpu_kms->catalog->caps->max_mixer_blendstages - DPU_STAGE_0);
return -EINVAL;
}
- to_dpu_plane_state(pstate)->stage = z_pos + DPU_STAGE_0;
- DRM_DEBUG_ATOMIC("%s: zpos %d\n", dpu_crtc->name, z_pos);
+ to_dpu_plane_state(pstate)->stage = stage;
+ DRM_DEBUG_ATOMIC("%s: stage %d\n", dpu_crtc->name, stage);
}
--
2.39.1
[PATCH v3 11/27] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4c05f4b5e050..fbfb39a7a229 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -451,7 +451,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe
*pipe,
{
struct dpu_hw_sspp *ctx = pipe->sspp;
struct dpu_hw_blk_reg_map *c;
- u32 src_size, src_xy, dst_size, dst_xy, ystride0, ystride1;
+ u32 src_size, src_xy, dst_size, dst_xy;
u32 src_size_off, src_xy_off, out_size_off, out_xy_off;
u32 idx;
@@ -482,44 +482,18 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe
*pipe,
dst_size = (drm_rect_height(&cfg->dst_rect) << 16) |
drm_rect_width(&cfg->dst_rect);
- if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
- ystride0 = (cfg->layout.plane_pitch[0]) |
- (cfg->layout.plane_pitch[1] << 16);
- ystride1 = (cfg->layout.plane_pitch[2]) |
- (cfg->layout.plane_pitch[3] << 16);
- } else {
- ystride0 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE0 + idx);
- ystride1 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE1 + idx);
-
- if (pipe->multirect_index == DPU_SSPP_RECT_0) {
- ystride0 = (ystride0 & 0x) |
- (cfg->layout.plane_pitch[0] & 0x);
- ystride1 = (ystride1 & 0x)|
- (cfg->layout.plane_pitch[2] & 0x);
- } else {
- ystride0 = (ystride0 & 0x) |
- ((cfg->layout.plane_pitch[0] << 16) &
-0x);
- ystride1 = (ystride1 & 0x) |
- ((cfg->layout.plane_pitch[2] << 16) &
-0x);
- }
- }
-
/* rectangle register programming */
DPU_REG_WRITE(c, src_size_off + idx, src_size);
DPU_REG_WRITE(c, src_xy_off + idx, src_xy);
DPU_REG_WRITE(c, out_size_off + idx, dst_size);
DPU_REG_WRITE(c, out_xy_off + idx, dst_xy);
-
- DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE0 + idx, ystride0);
- DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,
struct dpu_hw_sspp_cfg *cfg)
{
struct dpu_hw_sspp *ctx = pipe->sspp;
+ u32 ystride0, ystride1;
int i;
u32 idx;
@@ -541,6 +515,33 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_sw_pipe *pipe,
DPU_REG_WRITE(&ctx->hw, SSPP_SRC3_ADDR + idx,
cfg->layout.plane_addr[2]);
}
+
+ if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
+ ystride0 = (cfg->layout.plane_pitch[0]) |
+ (cfg->layout.plane_pitch[1] << 16);
+ ystride1 = (cfg->layout.plane_pitch[2]) |
+ (cfg->layout.plane_pitch[3] << 16);
+ } else {
+ ystride0 = DPU_REG_READ(&ctx->hw, SSPP_SRC_YSTRIDE0 + idx);
+ ystride1 = DPU_REG_READ(&ctx->hw, SSPP_SRC_YSTRIDE1 + idx);
+
+ if (pipe->multirect_index == DPU_SSPP_RECT_0) {
+ ystride0 = (ystride0 & 0x) |
+ (cfg->layout.plane_pitch[0] & 0x);
+ ystride1 = (ystride1 & 0x)|
+ (cfg->layout.plane_pitch[2] & 0x);
+ } else {
+ ystride0 = (ystride0 & 0x) |
+ ((cfg->layout.plane_pitch[0] << 16) &
+0x);
+ ystride1 = (ystride1 & 0x) |
+ ((cfg->layout.plane_pitch[2] << 16) &
+0x);
+ }
+ }
+
+ DPU_REG_WRITE(&ctx->hw, SSPP_SRC_YSTRIDE0 + idx, ystride0);
+ DPU_REG_WRITE(&ctx->hw, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
--
2.39.1
[PATCH v3 08/27] drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks
Where feasible, use dpu_sw_pipe rather than a combo of dpu_hw_sspp and
multirect_index/_mode arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 59 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 46 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 73 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 9 ++-
4 files changed, 84 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 5cf0803e4187..4d3ca8532563 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -168,17 +168,16 @@ static int _sspp_subblk_offset(struct dpu_hw_sspp *ctx,
return rc;
}
-static void dpu_hw_sspp_setup_multirect(struct dpu_hw_sspp *ctx,
- enum dpu_sspp_multirect_index index,
- enum dpu_sspp_multirect_mode mode)
+static void dpu_hw_sspp_setup_multirect(struct dpu_sw_pipe *pipe)
{
+ struct dpu_hw_sspp *ctx = pipe->sspp;
u32 mode_mask;
u32 idx;
if (_sspp_subblk_offset(ctx, DPU_SSPP_SRC, &idx))
return;
- if (index == DPU_SSPP_RECT_SOLO) {
+ if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
/**
* if rect index is RECT_SOLO, we cannot expect a
* virtual plane sharing the same SSPP id. So we go
@@ -187,8 +186,8 @@ static void dpu_hw_sspp_setup_multirect(struct dpu_hw_sspp
*ctx,
mode_mask = 0;
} else {
mode_mask = DPU_REG_READ(&ctx->hw, SSPP_MULTIRECT_OPMODE + idx);
- mode_mask |= index;
- if (mode == DPU_SSPP_MULTIRECT_TIME_MX)
+ mode_mask |= pipe->multirect_index;
+ if (pipe->multirect_mode == DPU_SSPP_MULTIRECT_TIME_MX)
mode_mask |= BIT(2);
else
mode_mask &= ~BIT(2);
@@ -239,10 +238,10 @@ static void _sspp_setup_csc10_opmode(struct dpu_hw_sspp
*ctx,
/*
* Setup source pixel format, flip,
*/
-static void dpu_hw_sspp_setup_format(struct dpu_hw_sspp *ctx,
- const struct dpu_format *fmt, u32 flags,
- enum dpu_sspp_multirect_index rect_mode)
+static void dpu_hw_sspp_setup_format(struct dpu_sw_pipe *pipe,
+ const struct dpu_format *fmt, u32 flags)
{
+ struct dpu_hw_sspp *ctx = pipe->sspp;
struct dpu_hw_blk_reg_map *c;
u32 chroma_samp, unpack, src_format;
u32 opmode = 0;
@@ -253,7 +252,8 @@ static void dpu_hw_sspp_setup_format(struct dpu_hw_sspp
*ctx,
if (_sspp_subblk_offset(ctx, DPU_SSPP_SRC, &idx) || !fmt)
return;
- if (rect_mode == DPU_SSPP_RECT_SOLO || rect_mode == DPU_SSPP_RECT_0) {
+ if (pipe->multirect_index == DPU_SSPP_RECT_SOLO ||
+ pipe->multirect_index == DPU_SSPP_RECT_0) {
op_mode_off = SSPP_SRC_OP_MODE;
unpack_pat_off = SSPP_SRC_UNPACK_PATTERN;
format_off = SSPP_SRC_FORMAT;
@@ -447,10 +447,10 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct
dpu_hw_sspp *ctx)
/*
* dpu_hw_sspp_setup_rects()
*/
-static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
- struct dpu_hw_sspp_cfg *cfg,
- enum dpu_sspp_multirect_index rect_index)
+static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe *pipe,
+ struct dpu_hw_sspp_cfg *cfg)
{
+ struct dpu_hw_sspp *ctx = pipe->sspp;
struct dpu_hw_blk_reg_map *c;
u32 src_size, src_xy, dst_size, dst_xy, ystride0, ystride1;
u32 src_size_off, src_xy_off, out_size_off, out_xy_off;
@@ -461,7 +461,8 @@ static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
c = &ctx->hw;
- if (rect_index == DPU_SSPP_RECT_SOLO || rect_index == DPU_SSPP_RECT_0) {
+ if (pipe->multirect_index == DPU_SSPP_RECT_SOLO ||
+ pipe->multirect_index == DPU_SSPP_RECT_0) {
src_size_off = SSPP_SRC_SIZE;
src_xy_off = SSPP_SRC_XY;
out_size_off = SSPP_OUT_SIZE;
@@ -482,7 +483,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
dst_size = (drm_rect_height(&cfg->dst_rect) << 16) |
drm_rect_width(&cfg->dst_rect);
- if (rect_index == DPU_SSPP_RECT_SOLO) {
+ if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
ystride0 = (cfg->layout.plane_pitch[0]) |
(cfg->layout.plane_pitch[1] << 16);
ystride1 = (cfg->layout.plane_pitch[2]) |
@@ -491,7 +492,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
ystride0 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE0 + idx);
ystride1 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE1 + idx);
- if (rect_index == DPU_SSPP_RECT_0) {
+ if (pipe->multirect_index == DPU_
[PATCH v3 16/27] drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check()
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index bd09bb319a58..73e1a8c69ef0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1132,11 +1132,9 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
const struct drm_plane_state *pstate;
struct drm_plane *plane;
- struct drm_display_mode *mode;
int rc = 0;
- struct drm_rect crtc_rect = { 0 };
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
if (!crtc_state->enable || !crtc_state->active) {
@@ -1147,7 +1145,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
- mode = &crtc_state->adjusted_mode;
DRM_DEBUG_ATOMIC("%s: check\n", dpu_crtc->name);
/* force a full mode set if active state changed */
@@ -1157,13 +1154,9 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
if (cstate->num_mixers)
_dpu_crtc_setup_lm_bounds(crtc, crtc_state);
- crtc_rect.x2 = mode->hdisplay;
- crtc_rect.y2 = mode->vdisplay;
-
/* FIXME: move this to dpu_plane_atomic_check? */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, crtc_state) {
struct dpu_plane_state *dpu_pstate = to_dpu_plane_state(pstate);
- struct drm_rect dst, clip = crtc_rect;
if (IS_ERR_OR_NULL(pstate)) {
rc = PTR_ERR(pstate);
@@ -1176,15 +1169,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
continue;
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
-
- dst = drm_plane_state_dest(pstate);
- if (!drm_rect_intersect(&clip, &dst)) {
- DPU_ERROR("invalid vertical/horizontal destination\n");
- DPU_ERROR("display: " DRM_RECT_FMT " plane: "
- DRM_RECT_FMT "\n", DRM_RECT_ARG(&crtc_rect),
- DRM_RECT_ARG(&dst));
- return -E2BIG;
- }
}
atomic_inc(&_dpu_crtc_get_kms(crtc)->bandwidth_ref);
--
2.39.1
[PATCH v3 10/27] drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index abf499275242..4c05f4b5e050 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -563,11 +563,16 @@ static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
static void dpu_hw_sspp_setup_solidfill(struct dpu_sw_pipe *pipe, u32 color)
{
struct dpu_hw_sspp *ctx = pipe->sspp;
+ struct dpu_hw_sspp_cfg cfg;
u32 idx;
if (_sspp_subblk_offset(ctx, DPU_SSPP_SRC, &idx))
return;
+ /* cleanup source addresses */
+ memset(&cfg, 0, sizeof(cfg));
+ ctx->ops.setup_sourceaddress(pipe, &cfg);
+
if (pipe->multirect_index == DPU_SSPP_RECT_SOLO ||
pipe->multirect_index == DPU_SSPP_RECT_0)
DPU_REG_WRITE(&ctx->hw, SSPP_SRC_CONSTANT_COLOR + idx, color);
--
2.39.1
[PATCH v3 09/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4d3ca8532563..abf499275242 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -419,19 +419,18 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_sspp *ctx,
}
static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
- struct dpu_hw_sspp_cfg *sspp,
- void *scaler_cfg)
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format)
{
u32 idx;
- struct dpu_hw_scaler3_cfg *scaler3_cfg = scaler_cfg;
- if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx) || !sspp
+ if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx)
|| !scaler3_cfg)
return;
dpu_hw_setup_scaler3(&ctx->hw, scaler3_cfg, idx,
ctx->cap->sblk->scaler_blk.version,
- sspp->layout.format);
+ format);
}
static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 8d566ad1877e..5e9b07090a21 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -317,13 +317,12 @@ struct dpu_hw_sspp_ops {
/**
* setup_scaler - setup scaler
-* @ctx: Pointer to pipe context
-* @pipe_cfg: Pointer to pipe configuration
-* @scaler_cfg: Pointer to scaler configuration
+* @scaler3_cfg: Pointer to scaler configuration
+* @format: pixel format parameters
*/
void (*setup_scaler)(struct dpu_hw_sspp *ctx,
- struct dpu_hw_sspp_cfg *pipe_cfg,
- void *scaler_cfg);
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format);
/**
* get_scaler_ver - get scaler h/w version
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 8f1767619d06..4f5c44d78332 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -677,8 +677,8 @@ static void _dpu_plane_setup_scaler(struct dpu_sw_pipe
*pipe,
if (pipe_hw->ops.setup_scaler &&
pipe->multirect_index != DPU_SSPP_RECT_1)
pipe_hw->ops.setup_scaler(pipe_hw,
- pipe_cfg,
- &scaler3_cfg);
+ &scaler3_cfg,
+ fmt);
}
/**
--
2.39.1
[PATCH v3 07/27] drm/msm/dpu: introduce struct dpu_sw_pipe
Wrap SSPP and multirect index/mode into a single structure that
represents software view on the pipe used.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 131 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
5 files changed, 89 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index eff1a3cc1cec..037347e51eb8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -431,7 +431,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
pstate = to_dpu_plane_state(state);
fb = state->fb;
- sspp_idx = pstate->hw_sspp->idx;
+ sspp_idx = pstate->pipe.sspp->idx;
set_bit(sspp_idx, fetch_active);
DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",
@@ -450,11 +450,10 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
stage_cfg->stage[pstate->stage][stage_idx] =
sspp_idx;
stage_cfg->multirect_index[pstate->stage][stage_idx] =
- pstate->multirect_index;
+ pstate->pipe.multirect_index;
trace_dpu_crtc_setup_mixer(DRMID(crtc), DRMID(plane),
state, pstate, stage_idx,
- sspp_idx - SSPP_VIG0,
format->base.pixel_format,
fb ? fb->modifier : 0);
@@ -1202,7 +1201,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].dpu_pstate = dpu_pstate;
pstates[cnt].drm_pstate = pstate;
pstates[cnt].stage = pstate->normalized_zpos;
- pstates[cnt].pipe_id = to_dpu_plane_state(pstate)->hw_sspp->idx;
+ pstates[cnt].pipe_id =
to_dpu_plane_state(pstate)->pipe.sspp->idx;
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
@@ -1475,7 +1474,7 @@ static int _dpu_debugfs_status_show(struct seq_file *s,
void *data)
state->crtc_x, state->crtc_y, state->crtc_w,
state->crtc_h);
seq_printf(s, "\tmultirect: mode: %d index: %d\n",
- pstate->multirect_mode, pstate->multirect_index);
+ pstate->pipe.multirect_mode,
pstate->pipe.multirect_index);
seq_puts(s, "\n");
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 00aedad975ca..a3bdce6e20df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -158,15 +158,11 @@ struct dpu_hw_pixel_ext {
* @src_rect: src ROI, caller takes into account the different operations
* such as decimation, flip etc to program this field
* @dest_rect: destination ROI.
- * @index: index of the rectangle of SSPP
- * @mode: parallel or time multiplex multirect mode
*/
struct dpu_hw_sspp_cfg {
struct dpu_hw_fmt_layout layout;
struct drm_rect src_rect;
struct drm_rect dst_rect;
- enum dpu_sspp_multirect_index index;
- enum dpu_sspp_multirect_mode mode;
};
/**
@@ -201,6 +197,18 @@ struct dpu_hw_pipe_ts_cfg {
u64 time;
};
+/**
+ * struct dpu_sw_pipe - software pipe description
+ * @sspp: backing SSPP pipe
+ * @index: index of the rectangle of SSPP
+ * @mode: parallel or time multiplex multirect mode
+ */
+struct dpu_sw_pipe {
+ struct dpu_hw_sspp *sspp;
+ enum dpu_sspp_multirect_index multirect_index;
+ enum dpu_sspp_multirect_mode multirect_mode;
+};
+
/**
* struct dpu_hw_sspp_ops - interface to the SSPP Hw driver functions
* Caller must call the init function to get the pipe context for each pipe
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2b34d97e065..229447ca1e0f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -251,7 +251,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
((src_width + 32) * fmt->bpp);
}
} else {
- if (pstate->multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL) {
+ if (pstate->pipe.multirect_mode == DPU_SSPP_MULTIRECT_PARALLEL)
{
total_fl = (fixed_buff_size / 2) * 2 /
((src_width + 32) * fmt->bpp);
} else {
@@ -310,7 +310,7 @@ s
[PATCH v3 06/27] drm/msm/dpu: drop dpu_plane_pipe function
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 7 ---
3 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f29a339a3705..eff1a3cc1cec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -431,7 +431,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
pstate = to_dpu_plane_state(state);
fb = state->fb;
- sspp_idx = dpu_plane_pipe(plane);
+ sspp_idx = pstate->hw_sspp->idx;
set_bit(sspp_idx, fetch_active);
DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",
@@ -1202,7 +1202,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].dpu_pstate = dpu_pstate;
pstates[cnt].drm_pstate = pstate;
pstates[cnt].stage = pstate->normalized_zpos;
- pstates[cnt].pipe_id = dpu_plane_pipe(plane);
+ pstates[cnt].pipe_id = to_dpu_plane_state(pstate)->hw_sspp->idx;
dpu_pstate->needs_dirtyfb = needs_dirtyfb;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 9eac02f53fc1..c2b34d97e065 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1441,11 +1441,6 @@ static const struct drm_plane_helper_funcs
dpu_plane_helper_funcs = {
.atomic_update = dpu_plane_atomic_update,
};
-enum dpu_sspp dpu_plane_pipe(struct drm_plane *plane)
-{
- return plane ? to_dpu_plane(plane)->pipe : SSPP_NONE;
-}
-
/* initialize plane */
struct drm_plane *dpu_plane_init(struct drm_device *dev,
uint32_t pipe, enum drm_plane_type type,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 08a4b6a99f51..25e261cabadc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -59,13 +59,6 @@ struct dpu_multirect_plane_states {
#define to_dpu_plane_state(x) \
container_of(x, struct dpu_plane_state, base)
-/**
- * dpu_plane_pipe - return sspp identifier for the given plane
- * @plane: Pointer to DRM plane object
- * Returns: sspp identifier of the given plane
- */
-enum dpu_sspp dpu_plane_pipe(struct drm_plane *plane);
-
/**
* dpu_plane_flush - final plane operations before commit flush
* @plane: Pointer to drm plane structure
--
2.39.1
[PATCH v3 04/27] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().
Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 10 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +---
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d95540309d4d..ec1001e10f4f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -918,8 +918,7 @@ int dpu_format_populate_layout(
struct drm_framebuffer *fb,
struct dpu_hw_fmt_layout *layout)
{
- uint32_t plane_addr[DPU_MAX_PLANES];
- int i, ret;
+ int ret;
if (!fb || !layout) {
DRM_ERROR("invalid arguments\n");
@@ -940,9 +939,6 @@ int dpu_format_populate_layout(
if (ret)
return ret;
- for (i = 0; i < DPU_MAX_PLANES; ++i)
- plane_addr[i] = layout->plane_addr[i];
-
/* Populate the addresses given the fb */
if (DPU_FORMAT_IS_UBWC(layout->format) ||
DPU_FORMAT_IS_TILE(layout->format))
@@ -950,10 +946,6 @@ int dpu_format_populate_layout(
else
ret = _dpu_format_populate_addrs_linear(aspace, fb, layout);
- /* check if anything changed */
- if (!ret && !memcmp(plane_addr, layout->plane_addr, sizeof(plane_addr)))
- ret = -EAGAIN;
-
return ret;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 2b0ebdd4c207..d6518ef1beb2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -476,9 +476,7 @@ static void _dpu_plane_set_scanout(struct drm_plane *plane,
int ret;
ret = dpu_format_populate_layout(aspace, fb, &pipe_cfg->layout);
- if (ret == -EAGAIN)
- DPU_DEBUG_PLANE(pdpu, "not updating same src addrs\n");
- else if (ret)
+ if (ret)
DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
else if (pdpu->pipe_hw->ops.setup_sourceaddress) {
trace_dpu_plane_set_scanout(pdpu->pipe_hw->idx,
--
2.39.1
[PATCH v3 05/27] drm/msm/dpu: move pipe_hw to dpu_plane_state
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be statically allocated during boot).
The sspp pointer is set at the dpu_plane_reset(), since this is the
function which allocates the state. Once we have fully virtual
plane<->SSPP relationship, the SSPP will be allocated dynamically in the
dpu_plane_atomic_check() function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 106 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
2 files changed, 61 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d6518ef1beb2..9eac02f53fc1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -104,7 +104,6 @@ struct dpu_plane {
enum dpu_sspp pipe;
- struct dpu_hw_sspp *pipe_hw;
uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
@@ -279,6 +278,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
struct drm_framebuffer *fb, struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
const struct dpu_format *fmt = NULL;
u64 qos_lut;
u32 total_fl = 0, lut_usage;
@@ -310,7 +310,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
fmt ? (char *)&fmt->base.pixel_format : NULL,
pdpu->is_rt_pipe, total_fl, qos_lut);
- pdpu->pipe_hw->ops.setup_creq_lut(pdpu->pipe_hw, qos_lut);
+ pstate->hw_sspp->ops.setup_creq_lut(pstate->hw_sspp, qos_lut);
}
/**
@@ -322,6 +322,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane
*plane,
struct drm_framebuffer *fb)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
const struct dpu_format *fmt = NULL;
u32 danger_lut, safe_lut;
@@ -361,7 +362,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane
*plane,
danger_lut,
safe_lut);
- pdpu->pipe_hw->ops.setup_danger_safe_lut(pdpu->pipe_hw,
+ pstate->hw_sspp->ops.setup_danger_safe_lut(pstate->hw_sspp,
danger_lut, safe_lut);
}
@@ -375,14 +376,15 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane
*plane,
bool enable, u32 flags)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
memset(&pipe_qos_cfg, 0, sizeof(pipe_qos_cfg));
if (flags & DPU_PLANE_QOS_VBLANK_CTRL) {
- pipe_qos_cfg.creq_vblank =
pdpu->pipe_hw->cap->sblk->creq_vblank;
+ pipe_qos_cfg.creq_vblank =
pstate->hw_sspp->cap->sblk->creq_vblank;
pipe_qos_cfg.danger_vblank =
- pdpu->pipe_hw->cap->sblk->danger_vblank;
+ pstate->hw_sspp->cap->sblk->danger_vblank;
pipe_qos_cfg.vblank_en = enable;
}
@@ -408,7 +410,7 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,
pipe_qos_cfg.danger_vblank,
pdpu->is_rt_pipe);
- pdpu->pipe_hw->ops.setup_qos_ctrl(pdpu->pipe_hw,
+ pstate->hw_sspp->ops.setup_qos_ctrl(pstate->hw_sspp,
&pipe_qos_cfg);
}
@@ -422,18 +424,19 @@ static void _dpu_plane_set_ot_limit(struct drm_plane
*plane,
struct drm_crtc *crtc, struct dpu_hw_sspp_cfg *pipe_cfg)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_vbif_set_ot_params ot_params;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
memset(&ot_params, 0, sizeof(ot_params));
- ot_params.xin_id = pdpu->pipe_hw->cap->xin_id;
- ot_params.num = pdpu->pipe_hw->idx - SSPP_NONE;
+ ot_params.xin_id = pstate->hw_sspp->cap->xin_id;
+ ot_params.num = pstate->hw_sspp->idx - SSPP_NONE;
ot_params.width = drm_rect_width(&pipe_cfg->src_rect);
ot_params.height = drm_rect_height(&pipe_cfg->src_rect);
ot_params.is_wfd = !pdpu->is_rt_pipe;
ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
ot_params.vbif_idx = VBIF_RT;
- ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
+ ot_params.clk_ctrl = pstate->hw_sspp->cap->clk_ctrl;
ot_params.rd = true;
dpu_vbif_set_ot_limit(dpu_kms, &ot_params);
@@ -446,14 +449,15 @@ static void _dpu_plane_set_ot_limit(struct drm_plane
*plane,
static void _dpu_plane_set
[PATCH v3 02/27] drm/msm/dpu: move SSPP allocation to the RM
Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 12
3 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5a4578ab62a6..b054055f120b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1275,8 +1275,6 @@ static void dpu_plane_destroy(struct drm_plane *plane)
/* this will destroy the states as well */
drm_plane_cleanup(plane);
- dpu_hw_sspp_destroy(pdpu->pipe_hw);
-
kfree(pdpu);
}
}
@@ -1482,14 +1480,10 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
pdpu->pipe = pipe;
/* initialize underlying h/w driver */
- pdpu->pipe_hw = dpu_hw_sspp_init(pipe, kms->mmio, kms->catalog);
- if (IS_ERR(pdpu->pipe_hw)) {
- DPU_ERROR("[%u]SSPP init failed\n", pipe);
- ret = PTR_ERR(pdpu->pipe_hw);
+ pdpu->pipe_hw = dpu_rm_get_sspp(&kms->rm, pipe);
+ if (!pdpu->pipe_hw || !pdpu->pipe_hw->cap || !pdpu->pipe_hw->cap->sblk)
{
+ DPU_ERROR("[%u]SSPP is invalid\n", pipe);
goto clean_plane;
- } else if (!pdpu->pipe_hw->cap || !pdpu->pipe_hw->cap->sblk) {
- DPU_ERROR("[%u]SSPP init returned invalid cfg\n", pipe);
- goto clean_sspp;
}
format_list = pdpu->pipe_hw->cap->sblk->format_list;
@@ -1499,7 +1493,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
format_list, num_formats,
supported_format_modifiers, type, NULL);
if (ret)
- goto clean_sspp;
+ goto clean_plane;
pdpu->catalog = kms->catalog;
@@ -1532,9 +1526,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
pipe, plane->base.id);
return plane;
-clean_sspp:
- if (pdpu && pdpu->pipe_hw)
- dpu_hw_sspp_destroy(pdpu->pipe_hw);
clean_plane:
kfree(pdpu);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 396429e63756..53c644ca52ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -8,6 +8,7 @@
#include "dpu_hw_lm.h"
#include "dpu_hw_ctl.h"
#include "dpu_hw_pingpong.h"
+#include "dpu_hw_sspp.h"
#include "dpu_hw_intf.h"
#include "dpu_hw_wb.h"
#include "dpu_hw_dspp.h"
@@ -91,6 +92,9 @@ int dpu_rm_destroy(struct dpu_rm *rm)
for (i = 0; i < ARRAY_SIZE(rm->hw_wb); i++)
dpu_hw_wb_destroy(rm->hw_wb[i]);
+ for (i = 0; i < ARRAY_SIZE(rm->hw_sspp); i++)
+ dpu_hw_sspp_destroy(rm->hw_sspp[i]);
+
return 0;
}
@@ -255,6 +259,24 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->dsc_blks[dsc->id - DSC_0] = &hw->base;
}
+ for (i = 0; i < cat->sspp_count; i++) {
+ struct dpu_hw_sspp *hw;
+ const struct dpu_sspp_cfg *sspp = &cat->sspp[i];
+
+ if (sspp->id < SSPP_NONE || sspp->id >= SSPP_MAX) {
+ DPU_ERROR("skip intf %d with invalid id\n", sspp->id);
+ continue;
+ }
+
+ hw = dpu_hw_sspp_init(sspp->id, mmio, cat);
+ if (IS_ERR(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed sspp object creation: err %d\n", rc);
+ goto fail;
+ }
+ rm->hw_sspp[sspp->id - SSPP_NONE] = hw;
+ }
+
return 0;
fail:
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 59de72b381f9..d62c2edb2460 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -21,6 +21,7 @@ struct dpu_global_state;
* @hw_intf: array of intf hardware resources
* @hw_wb: array of wb hardware resources
* @dspp_blks: array of dspp hardware resources
+ * @hw_sspp: array of sspp hardware resources
*/
struct dpu_rm {
struct dpu_hw_blk *pingpong_blks[PINGPONG_MAX - PINGPONG_0];
@@ -31,6 +32,7 @@ struct dpu_rm {
struct dpu_hw_blk *dspp_blks[DSPP_MAX - DSPP_0];
struct dpu_hw_blk *merge_3d_blks[MERGE_3D_MAX - MERGE_3D_0];
struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];
+ struct dpu_hw_sspp *hw_sspp[SSPP_MAX - SSPP_NONE];
};
/**
@@ -108,5 +110,15 @@ static inline struct dpu_hw_wb *dpu_rm_get_wb(struct
dpu_rm *rm, enum dpu_wb wb_
return rm->hw_wb[wb_idx - WB_0];
}
+/**
+ * dpu_rm_get_sspp
[PATCH v3 03/27] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms. We are going to break
the 1:1 correspondence between planes and SSPPs, so it makes no sense
anymore to create SSPP debugfs entries in dpu_plane.c
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index 084206da851b..00aedad975ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -388,7 +388,6 @@ struct dpu_hw_sspp *dpu_hw_sspp_init(enum dpu_sspp idx,
*/
void dpu_hw_sspp_destroy(struct dpu_hw_sspp *ctx);
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry
*debugfs_root);
int _dpu_hw_sspp_init_debugfs(struct dpu_hw_sspp *hw_pipe, struct dpu_kms
*kms, struct dentry *entry);
#endif /*_DPU_HW_SSPP_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9b5a04..0d2ef83c38ea 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -250,6 +250,24 @@ void dpu_debugfs_create_regset32(const char *name, umode_t
mode,
debugfs_create_file(name, mode, parent, regset, &dpu_regset32_fops);
}
+static void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry
*debugfs_root)
+{
+ struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
+ int i;
+
+ if (IS_ERR(entry))
+ return;
+
+ for (i = SSPP_NONE; i < SSPP_MAX; i++) {
+ struct dpu_hw_sspp *hw = dpu_rm_get_sspp(&dpu_kms->rm, i);
+
+ if (!hw)
+ continue;
+
+ _dpu_hw_sspp_init_debugfs(hw, dpu_kms, entry);
+ }
+}
+
static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index b054055f120b..2b0ebdd4c207 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1399,22 +1399,6 @@ void dpu_plane_danger_signal_ctrl(struct drm_plane
*plane, bool enable)
_dpu_plane_set_qos_ctrl(plane, enable, DPU_PLANE_QOS_PANIC_CTRL);
pm_runtime_put_sync(&dpu_kms->pdev->dev);
}
-
-/* SSPP live inside dpu_plane private data only. Enumerate them here. */
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry
*debugfs_root)
-{
- struct drm_plane *plane;
- struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
-
- if (IS_ERR(entry))
- return;
-
- drm_for_each_plane(plane, dpu_kms->dev) {
- struct dpu_plane *pdpu = to_dpu_plane(plane);
-
- _dpu_hw_sspp_init_debugfs(pdpu->pipe_hw, dpu_kms, entry);
- }
-}
#endif
static bool dpu_plane_format_mod_supported(struct drm_plane *plane,
--
2.39.1
[PATCH v3 01/27] drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg)
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 48 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 52 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
3 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 4246ab0b3bee..5cf0803e4187 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -136,7 +136,7 @@
#define TS_CLK 1920
-static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
+static int _sspp_subblk_offset(struct dpu_hw_sspp *ctx,
int s_id,
u32 *idx)
{
@@ -168,7 +168,7 @@ static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
return rc;
}
-static void dpu_hw_sspp_setup_multirect(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_multirect(struct dpu_hw_sspp *ctx,
enum dpu_sspp_multirect_index index,
enum dpu_sspp_multirect_mode mode)
{
@@ -197,7 +197,7 @@ static void dpu_hw_sspp_setup_multirect(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(&ctx->hw, SSPP_MULTIRECT_OPMODE + idx, mode_mask);
}
-static void _sspp_setup_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -218,7 +218,7 @@ static void _sspp_setup_opmode(struct dpu_hw_pipe *ctx,
DPU_REG_WRITE(&ctx->hw, SSPP_VIG_OP_MODE + idx, opmode);
}
-static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_csc10_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -239,7 +239,7 @@ static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe
*ctx,
/*
* Setup source pixel format, flip,
*/
-static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_format(struct dpu_hw_sspp *ctx,
const struct dpu_format *fmt, u32 flags,
enum dpu_sspp_multirect_index rect_mode)
{
@@ -360,7 +360,7 @@ static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(c, SSPP_UBWC_ERROR_STATUS + idx, BIT(31));
}
-static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_sspp *ctx,
struct dpu_hw_pixel_ext *pe_ext)
{
struct dpu_hw_blk_reg_map *c;
@@ -418,8 +418,8 @@ static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_pipe
*ctx,
tot_req_pixels[3]);
}
-static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_cfg *sspp,
+static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
+ struct dpu_hw_sspp_cfg *sspp,
void *scaler_cfg)
{
u32 idx;
@@ -434,7 +434,7 @@ static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe
*ctx,
sspp->layout.format);
}
-static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx)
+static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
{
u32 idx;
@@ -447,8 +447,8 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe
*ctx)
/*
* dpu_hw_sspp_setup_rects()
*/
-static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_cfg *cfg,
+static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
+ struct dpu_hw_sspp_cfg *cfg,
enum dpu_sspp_multirect_index rect_index)
{
struct dpu_hw_blk_reg_map *c;
@@ -516,8 +516,8 @@ static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx,
DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
-static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_cfg *cfg,
+static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_sspp *ctx,
+ struct dpu_hw_sspp_cfg *cfg,
enum dpu_sspp_multirect_index rect_mode)
{
int i;
@@ -543,7 +543,7 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_hw_pipe *ctx,
}
}
-static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
const struct dpu_csc_cfg *data)
{
u32 idx;
@@ -560,7 +560,7 @@ static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
dpu_hw_csc_setup(&ctx->hw, idx, data, csc10);
}
-static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_pipe *ctx, u32 color,
enum
+static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_sspp *ctx, u32 color,
enum
dpu_sspp_multirect_index rect_index)
{
u32 idx;
@@ -575,7
[PATCH v3 00/27] drm/msm/dpu: wide planes support
The review of the first half of v2 took more than a month. Let's update the reviewed patches in attempt to get the first half of the series into the acked and mergeable state. This would allow us to lower the impact (and the patch count). At 27 patches this series is approaching the limits of manageability. This patchset brings in multirect usage to support using two SSPP rectangles for a single plane. Full virtual planes support is omitted from this pull request, it will come later. Changes since v1 (which was ages ago): - Rebased on top of 6.2-rc1 - Dropped the controversial _dpu_crtc_blend_setup() split patch - Renamed dpu_hw_pipe to dpu_hw_sspp - Other misc changes Dmitry Baryshkov (27): drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg) drm/msm/dpu: move SSPP allocation to the RM drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout drm/msm/dpu: move pipe_hw to dpu_plane_state drm/msm/dpu: drop dpu_plane_pipe function drm/msm/dpu: introduce struct dpu_sw_pipe drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3() drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_sspp_cfg drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check drm/msm/dpu: don't use unsupported blend stages drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check() drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check() drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format drm/msm/dpu: populate SmartDMA features in hw catalog drm/msm/dpu: make _dpu_plane_calc_clk accept mode directly drm/msm/dpu: add dpu_hw_pipe_cfg to dpu_plane_state drm/msm/dpu: simplify dpu_plane_validate_src() drm/msm/dpu: rework dpu_plane_sspp_atomic_update() drm/msm/dpu: rework dpu_plane_atomic_check() drm/msm/dpu: rework plane CSC setting drm/msm/dpu: rework static color fill code drm/msm/dpu: split pipe handling from _dpu_crtc_blend_setup_mixer drm/msm/dpu: add support for wide planes drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 285 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 10 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 10 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 168 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 110 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 745 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 23 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 12 + drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 25 +- 11 files changed, 707 insertions(+), 721 deletions(-) -- 2.39.1
Re: [PATCH v6 01/17] dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
On Thu, Dec 22, 2022 at 03:22:14PM +0100, Johan Jonker wrote: > Convert rockchip-lvds.txt to YAML. > > Changed: > Add power-domains property. > Requirements between PX30 and RK3288 > > Signed-off-by: Johan Jonker > Reviewed-by: Rob Herring > --- > > Changed V3: > Filename matching compatible style > Drop "Regulator phandle for " > Specify properties and requirements per SoC > Sort order and restyle > > Changed V2: > Fix title > --- > .../display/rockchip/rockchip,lvds.yaml | 170 ++ > .../display/rockchip/rockchip-lvds.txt| 92 -- > 2 files changed, 170 insertions(+), 92 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt What's the plan for these patches? Don't see them in linux-next still. Do you want me to take patches 1-8? Rob
Re: [PATCH] drm/i915: Move fd_install after last use of fence
On Fri, Feb 3, 2023 at 8:49 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Because eb_composite_fence_create() drops the fence_array reference
> after creation of the sync_file, only the sync_file holds a ref to the
> fence. But fd_install() makes that reference visable to userspace, so
> it must be the last thing we do with the fence.
>
Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)")
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index f266b68cf012..0f2e056c02dd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -3476,38 +3476,38 @@ i915_gem_do_execbuffer(struct drm_device *dev,
>
> err_request:
> eb_requests_get(&eb);
> err = eb_requests_add(&eb, err);
>
> if (eb.fences)
> signal_fence_array(&eb, eb.composite_fence ?
>eb.composite_fence :
>&eb.requests[0]->fence);
>
> + if (unlikely(eb.gem_context->syncobj)) {
> + drm_syncobj_replace_fence(eb.gem_context->syncobj,
> + eb.composite_fence ?
> + eb.composite_fence :
> + &eb.requests[0]->fence);
> + }
> +
> if (out_fence) {
> if (err == 0) {
> fd_install(out_fence_fd, out_fence->file);
> args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */
> args->rsvd2 |= (u64)out_fence_fd << 32;
> out_fence_fd = -1;
> } else {
> fput(out_fence->file);
> }
> }
>
> - if (unlikely(eb.gem_context->syncobj)) {
> - drm_syncobj_replace_fence(eb.gem_context->syncobj,
> - eb.composite_fence ?
> - eb.composite_fence :
> - &eb.requests[0]->fence);
> - }
> -
> if (!out_fence && eb.composite_fence)
> dma_fence_put(eb.composite_fence);
>
> eb_requests_put(&eb);
>
> err_vma:
> eb_release_vmas(&eb, true);
> WARN_ON(err == -EDEADLK);
> i915_gem_ww_ctx_fini(&eb.ww);
>
> --
> 2.38.1
>
[RFC] drm/msm/adreno: Balance pm_runtime enable
When any of the components in the mdss hierarchy fails to bind,
previously bound components are being unbound again.
One such case happens when the DP controller fails to find its bridge or
panel, where adreno_unbind() will be invoked without adreno_load_gpu()
being called to invoke pm_runtime_enable().
The result is that once everything is bound the pm_runtime_get_sync()
call find the power-domain to have a positive disable_depth, fails
with -EACCESS and prevents the GPU device to be powered up.
Move the pm_runtime_enable() to adreno_bind(), in order to balance it
with any calls to adreno_unbind().
Fixes: 4b18299b3365 ("drm/msm/adreno: Defer enabling runpm until hw_init()")
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 36f062c7582f..ca38b837dedb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -432,15 +432,6 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
if (ret)
return NULL;
- /*
-* Now that we have firmware loaded, and are ready to begin
-* booting the gpu, go ahead and enable runpm:
-*/
- pm_runtime_enable(&pdev->dev);
-
- /* Make sure pm runtime is active and reset any previous errors */
- pm_runtime_set_active(&pdev->dev);
-
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
pm_runtime_put_sync(&pdev->dev);
@@ -548,6 +539,8 @@ static int adreno_bind(struct device *dev, struct device
*master, void *data)
return PTR_ERR(gpu);
}
+ pm_runtime_enable(dev);
+
return 0;
}
--
2.25.1
[PATCH] drm/amdgpu: Fix potential race processing vm->freed
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from multiple threads, because
the vm is global to the drm_file, you can end up with multiple threads
racing in amdgpu_vm_clear_freed(). So the freed list should be
protected with the status_lock, similar to other vm lists.
Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 33 ++
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index b9441ab457ea..aeed7bc1512f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1240,10 +1240,19 @@ int amdgpu_vm_clear_freed(struct amdgpu_device *adev,
struct amdgpu_bo_va_mapping *mapping;
uint64_t init_pte_value = 0;
struct dma_fence *f = NULL;
+ struct list_head freed;
int r;
- while (!list_empty(&vm->freed)) {
- mapping = list_first_entry(&vm->freed,
+ /*
+* Move the contents of the VM's freed list to a local list
+* that we can iterate without racing against other threads:
+*/
+ spin_lock(&vm->status_lock);
+ list_replace_init(&vm->freed, &freed);
+ spin_unlock(&vm->status_lock);
+
+ while (!list_empty(&freed)) {
+ mapping = list_first_entry(&freed,
struct amdgpu_bo_va_mapping, list);
list_del(&mapping->list);
@@ -1258,6 +1267,15 @@ int amdgpu_vm_clear_freed(struct amdgpu_device *adev,
amdgpu_vm_free_mapping(adev, vm, mapping, f);
if (r) {
dma_fence_put(f);
+
+ /*
+* Move any unprocessed mappings back to the freed
+* list:
+*/
+ spin_lock(&vm->status_lock);
+ list_splice_tail(&freed, &vm->freed);
+ spin_unlock(&vm->status_lock);
+
return r;
}
}
@@ -1583,11 +1601,14 @@ int amdgpu_vm_bo_unmap(struct amdgpu_device *adev,
mapping->bo_va = NULL;
trace_amdgpu_vm_bo_unmap(bo_va, mapping);
- if (valid)
+ if (valid) {
+ spin_lock(&vm->status_lock);
list_add(&mapping->list, &vm->freed);
- else
+ spin_unlock(&vm->status_lock);
+ } else {
amdgpu_vm_free_mapping(adev, vm, mapping,
bo_va->last_pt_update);
+ }
return 0;
}
@@ -1671,7 +1692,9 @@ int amdgpu_vm_bo_clear_mappings(struct amdgpu_device
*adev,
tmp->last = eaddr;
tmp->bo_va = NULL;
+ spin_lock(&vm->status_lock);
list_add(&tmp->list, &vm->freed);
+ spin_unlock(&vm->status_lock);
trace_amdgpu_vm_bo_unmap(NULL, tmp);
}
@@ -1788,7 +1811,9 @@ void amdgpu_vm_bo_del(struct amdgpu_device *adev,
amdgpu_vm_it_remove(mapping, &vm->va);
mapping->bo_va = NULL;
trace_amdgpu_vm_bo_unmap(bo_va, mapping);
+ spin_lock(&vm->status_lock);
list_add(&mapping->list, &vm->freed);
+ spin_unlock(&vm->status_lock);
}
list_for_each_entry_safe(mapping, next, &bo_va->invalids, list) {
list_del(&mapping->list);
--
2.38.1
Re: [PATCH 1/2] drm/i915: Fix GEN8_MISCCPCTL
On Thu, Feb 02, 2023 at 05:12:10PM -0800, Matt Roper wrote:
On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
Register 0x9424 is not replicated on any platform, so it shouldn't be
declared with REG_MCR(). Declaring it with _MMIO() is basically
duplicate of the GEN7 version, so just remove the GEN8 and change all
the callers to use the right functions.
According to an old copy of bspec page 13991, 0x9400-0x97FF was an MCR
range on gen8 platforms. Newer copies of that bspec page forgot to even
include the register range table, so it's not obvious unless you dig
through the history and look at a version from before Aug 2020.
However bspec page 66673 indicates that this range went back to being a
singleton range in gen9 (and the other forcewake pages for newer
platforms indicate it stayed that way), so that means BDW and CHV are
the _only_ platforms that should treat it as MCR. Usage for other
platforms should either add a new "GEN9" definition, or just go back to
using the GEN7 definition.
sounds like more a spec mistake. This range was listed as
"slice common". I'm not sure we'd really have to set any steering for
specific slice. Another thing is that we didn't set any steering for a
long time in this register and it was working. Even now there is no
table for gen8/gen9 in drivers/gpu/drm/i915/gt/intel_gt_mcr.c, so any
call to intel_gt_mcr_* will simply fallback to "no steering required".
For me, any MCR_REG() should correspond to registers in these
tables. I don't think there's much point in annotating the register as
MCR in its definition and then do nothing with it. Btw, this is how I
started getting warning wrt this register: as you knowm, in xe driver
you added a warning for registers missing from the mcr tables,
which I think is indeed the right thing to do for the recent platforms.
For gen8, this change here should not change any behavior. It
changes for gen11+ to the correct behavior. So I don't think we need to
care much about double checking if gen8 had a unique behavior no other
platforms have. I think just amending the commit message with more
information like this would be ok.
Lucas De Marchi
Matt
Also use intel_uncore_rmw() rather than a read + write where possible.
Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Rodrigo Vivi
Cc: Gustavo Sousa
Cc: Matt Atwood
Cc: Ashutosh Dixit
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_pm.c | 10 +-
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7fa18a3b3957..cc1539c7a6b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -686,10 +686,7 @@
#define GEN6_RSTCTL_MMIO(0x9420)
#define GEN7_MISCCPCTL _MMIO(0x9424)
-#define GEN7_DOP_CLOCK_GATE_ENABLE (1 << 0)
-
-#define GEN8_MISCCPCTL MCR_REG(0x9424)
-#define GEN8_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
+#define GEN7_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
#define GEN12_DOP_CLOCK_GATE_RENDER_ENABLE REG_BIT(1)
#define GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
#define GEN8_DOP_CLOCK_GATE_GUC_ENABLE (1 << 4)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 29718d0595f4..cfc122c17e28 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1645,7 +1645,7 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
/* Wa_14015795083 */
- wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+ wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
/* Wa_18018781329 */
wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
@@ -1664,7 +1664,7 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
pvc_init_mcr(gt, wal);
/* Wa_14015795083 */
- wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+ wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
/* Wa_18018781329 */
wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 3d2249bda368..69133420c78b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -39,9 +39,8 @@ static void guc_prepare_xfer(struct intel_gt *gt)
if (GRAPHICS_VER(uncore->i915) == 9) {
Re: [PATCH][next] drm/vmwgfx: Replace one-element array with flexible-array member
On Thu, 2023-02-02 at 19:27 -0600, Gustavo A. R. Silva wrote:
> One-element arrays are deprecated, and we are replacing them with flexible
> array members instead. So, replace one-element array with flexible-array
> member in struct vmw_view.
>
> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> routines on memcpy() and help us make progress towards globally
> enabling -fstrict-flex-arrays=3 [1].
>
> This results in no differences in binary output.
>
> Link:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F79&data=05%7C01%7Czackr%40vmware.com%7Ca3eb026ab82f44e3b1d708db0585bd84%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638109844250628429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=I7IzZMu692BHi68sJFTfSonR4OYW1Kd5D6CENIizrsw%3D&reserved=0
> Link:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F254&data=05%7C01%7Czackr%40vmware.com%7Ca3eb026ab82f44e3b1d708db0585bd84%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638109844250628429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Hk97x3i6xHOrq09iuDYojySU9H8ulvlArzGXoKrEDtU%3D&reserved=0
> Link:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fpipermail%2Fgcc-patches%2F2022-October%2F602902.html&data=05%7C01%7Czackr%40vmware.com%7Ca3eb026ab82f44e3b1d708db0585bd84%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638109844250628429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B3QRmhuEvEOem89Do6hpS3%2B5sFDcuS%2BWWh9yv6triog%3D&reserved=0
> [1]
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
> index 4ea32b01efc0..0f696ccaddc6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_so.c
> @@ -70,7 +70,7 @@ struct vmw_view {
> unsigned view_id; /* Immutable */
> u32 cmd_size; /* Immutable */
> bool committed; /* Protected by binding_mutex */
> - u32 cmd[1]; /* Immutable */
> + u32 cmd[]; /* Immutable */
> };
>
> static int vmw_view_create(struct vmw_resource *res);
Reviewed-by: Zack Rusin
Will this go in through linux-next directly or do you want me to push it through
drm-misc-next?
z
Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs
> > > +struct drm_pancsf_gpu_info {
> > > +#define DRM_PANCSF_ARCH_MAJOR(x) ((x) >> 28)
> > > +#define DRM_PANCSF_ARCH_MINOR(x) (((x) >> 24) & 0xf)
> > > +#define DRM_PANCSF_ARCH_REV(x) (((x) >> 20) & 0xf)
> > > +#define DRM_PANCSF_PRODUCT_MAJOR(x) (((x) >> 16) & 0xf)
> > > +#define DRM_PANCSF_VERSION_MAJOR(x) (((x) >> 12) & 0xf)
> > > +#define DRM_PANCSF_VERSION_MINOR(x) (((x) >> 4) & 0xff)
> > > +#define DRM_PANCSF_VERSION_STATUS(x) ((x) & 0xf)
> > > + __u32 gpu_id;
> > > + __u32 gpu_rev;
> > > +#define DRM_PANCSF_CSHW_MAJOR(x) (((x) >> 26) & 0x3f)
> > > +#define DRM_PANCSF_CSHW_MINOR(x) (((x) >> 20) & 0x3f)
> > > +#define DRM_PANCSF_CSHW_REV(x) (((x) >> 16) & 0xf)
> > > +#define DRM_PANCSF_MCU_MAJOR(x) (((x) >> 10) & 0x3f)
> > > +#define DRM_PANCSF_MCU_MINOR(x) (((x) >> 4) & 0x3f)
> > > +#define DRM_PANCSF_MCU_REV(x)((x) & 0xf)
> > > + __u32 csf_id;
> > > + __u32 l2_features;
> > > + __u32 tiler_features;
> > > + __u32 mem_features;
> > > + __u32 mmu_features;
> > > + __u32 thread_features;
> > > + __u32 max_threads;
> > > + __u32 thread_max_workgroup_size;
> > > + __u32 thread_max_barrier_size;
> > > + __u32 coherency_features;
> > > + __u32 texture_features[4];
> > > + __u32 as_present;
> > > + __u32 core_group_count;
> > > + __u64 shader_present;
> > > + __u64 l2_present;
> > > + __u64 tiler_present;
> > > +};
> > > +
> > > +struct drm_pancsf_csif_info {
> > > + __u32 csg_slot_count;
> > > + __u32 cs_slot_count;
> > > + __u32 cs_reg_count;
> > > + __u32 scoreboard_slot_count;
> > > + __u32 unpreserved_cs_reg_count;
> > > +};
> > > +
> > > +struct drm_pancsf_dev_query {
> > > + /** @type: the query type (see enum drm_pancsf_dev_query_type). */
> > > + __u32 type;
> > > +
> > > + /**
> > > + * @size: size of the type being queried.
> > > + *
> > > + * If pointer is NULL, size is updated by the driver to provide the
> > > + * output structure size. If pointer is not NULL, the the driver will
> > > + * only copy min(size, actual_structure_size) bytes to the pointer,
> > > + * and update the size accordingly. This allows us to extend query
> > > + * types without breaking userspace.
> > > + */
> > > + __u32 size;
> > > +
> > > + /**
> > > + * @pointer: user pointer to a query type struct.
> > > + *
> > > + * Pointer can be NULL, in which case, nothing is copied, but the
> > > + * actual structure size is returned. If not NULL, it must point to
> > > + * a location that's large enough to hold size bytes.
> > > + */
> > > + __u64 pointer;
> > > +};
> >
> > Genuine question: is there something wrong with the panfrost 'get_param'
> > ioctl where individual features are queried one-by-one, rather than
> > passing a big structure back to user space.
>
> Well, I've just seen the Xe driver exposing things this way, and I thought
> it was a good idea, but I don't have a strong opinion here, and if others
> think it's preferable to stick to GET_PARAM, I'm fine with that too.
I vastly prefer the info struct, GET_PARAM isn't a great interface when
there are large numbers of properties to query... Actually I just
suggested to Lina that she adopt this approach for Asahi instead of the
current GET_PARAM ioctl we have (downstream for now).
It isn't a *big* deal but GET_PARAM doesn't really seem better on any
axes.
> > I ask because we've had issues in the past with trying to 'deprecate'
> > registers - if a new version of the hardware stops providing a
> > (meaningful) value for a register then it's hard to fix up the
> > structures.
I'm not sure this is a big deal. If the register no longer exists
(meaningfully), zero it out in the info structure and trust userspace to
interpret meaningfully based on the GPU. If registers are getting
dropped between revisions, that's obviously not great. But this should
only change at major architecture boundaries; I don't see the added
value of doing the interpretation in kernel instead of userspace. I say
this with my userspace hat on, of course ;-)
> > There is obviously overhead iterating over all the register that user
> > space cares about. Another option (used by kbase) is to return some form
> > of structured data so a missing property can be encoded.
>
> I'll have a look at how kbase does that. Thanks for the pointer.
I'd be fine with the kbase approach but I don't really see the added
value over what Boris proposed in the RFC, tbh.
Re: [PATCH][next] drm/vmwgfx: Replace one-element array with flexible-array member
On Thu, Feb 02, 2023 at 07:27:10PM -0600, Gustavo A. R. Silva wrote: > One-element arrays are deprecated, and we are replacing them with flexible > array members instead. So, replace one-element array with flexible-array > member in struct vmw_view. > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > routines on memcpy() and help us make progress towards globally > enabling -fstrict-flex-arrays=3 [1]. > > This results in no differences in binary output. > > Link: https://github.com/KSPP/linux/issues/79 > Link: https://github.com/KSPP/linux/issues/254 > Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook -- Kees Cook
Re: [PATCH v2 12/27] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_pipe_cfg
On 2/3/2023 6:09 AM, Dmitry Baryshkov wrote: On 02/02/2023 22:14, Abhinav Kumar wrote: On 2/2/2023 12:10 PM, Dmitry Baryshkov wrote: On 02/02/2023 21:54, Abhinav Kumar wrote: On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote: On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar wrote: On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote: Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, leaving only src_rect and dst_rect. This way right and left pipes will have separate dpu_hw_pipe_cfg isntances, while the layout is common to both of them. Sorry for not responding to this comment earlier. https://patchwork.freedesktop.org/patch/473168/?series=99909&rev=1#comment_875370 From the perspective of wide planes you are right that the layout is common but not true from smart DMA point of view. For wide planes, yes, its usually the same buffer with just the src_x being different but conceptually and even HW wise each rectangle of the smart DMA is capable of fetching from a different buffer. From the pov, this decision of not having the dpu_hw_fmt_layout as part of dpu_hw_pipe_cfg seems incorrect to me. Yes, each rectangle/pipe can fetch from a different buffer. However in our use case the layout is not defined for each pipe. It is defined for a plane, no matter how many pipes are used for the plane, since the buffer is also defined per plane. Even if the layout is defined per plane. So lets say plane A with layout A maps to rect 1 of DMA0 plane B with layout B maps to rect 2 of DMA0 How can layout be assumed to be duplicated in this case? This is not a wide plane use-case but just smartDMA case of two different layers. Maybe I am missing something but this is the example i am interested about. PlaneA has layoutA. So dpu_plane_sspp_update_pipe() will program layoutA using (DMA0, rect1)->setup_sourceaddress(layoutA). PlaneB has layoutB, so (DMA0, rect2)->setup_sourceaddress(layoutB). Maybe the commit message is misleading. The layout is not common to rect1 and rect2. It is common to all pipes/rectangles driving a single plane. Ack, Its clear now. Reviewed-by: Abhinav Kumar I have rephrased the last sentence of the commit message in the following way. Hopefully it will be cleaner now: This way all the pipes used by the plane will have a common layout instance (as the framebuffer is shared between them), while still keeping a separate src/dst rectangle configuration for each pipe. Ack, thanks.
Re: [Intel-gfx] [PATCH 4/6] drm/i915/guc: More debug print updates - GuC selftests
On 2/3/2023 01:54, Michal Wajdeczko wrote:
On 03.02.2023 01:11, john.c.harri...@intel.com wrote:
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 35 ++-
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++--
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 +++---
3 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index e28518fe8b908..6cc1e9c7a47d6 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -3,6 +3,7 @@
* Copyright �� 2021 Intel Corporation
*/
+#include "intel_guc_print.h"
You've included right headers but then you mostly used gt_xxx() macros
instead of guc_xxx() ones which IMHO are way more appropriate as we are
in GuC selftests
Yeah, forgot to go back and change the include.
I started with a blanked update to guc_ instead of drm_ but only then
realised that the tests do not actually do anything so low level as to
require access the guc object. Which means having to jump through hoops
to get to a guc object purely for the purpose of using the guc debug
functions. Yes, it is a GuC specific selftest but there is no GuC
specific code in the file and that is really the criteria used for the
debug print decision.
John.
Michal
#include "selftests/igt_spinner.h"
#include "selftests/intel_scheduler_helpers.h"
@@ -65,7 +66,7 @@ static int intel_guc_scrub_ctbs(void *arg)
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
ret = PTR_ERR(ce);
- drm_err(>->i915->drm, "Failed to create context, %d:
%d\n", i, ret);
+ gt_err(gt, "Failed to create context, %d: %d\n", i,
ret);
goto err;
}
@@ -86,7 +87,7 @@ static int intel_guc_scrub_ctbs(void *arg)
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
- drm_err(>->i915->drm, "Failed to create request, %d:
%d\n", i, ret);
+ gt_err(gt, "Failed to create request, %d: %d\n", i,
ret);
goto err;
}
@@ -96,7 +97,7 @@ static int intel_guc_scrub_ctbs(void *arg)
for (i = 0; i < 3; ++i) {
ret = i915_request_wait(last[i], 0, HZ);
if (ret < 0) {
- drm_err(>->i915->drm, "Last request failed to complete:
%d\n", ret);
+ gt_err(gt, "Last request failed to complete: %d\n",
ret);
goto err;
}
i915_request_put(last[i]);
@@ -113,7 +114,7 @@ static int intel_guc_scrub_ctbs(void *arg)
/* GT will not idle if G2H are lost */
ret = intel_gt_wait_for_idle(gt, HZ);
if (ret < 0) {
- drm_err(>->i915->drm, "GT failed to idle: %d\n", ret);
+ gt_err(gt, "GT failed to idle: %d\n", ret);
goto err;
}
@@ -153,7 +154,7 @@ static int intel_guc_steal_guc_ids(void *arg)
ce = kcalloc(GUC_MAX_CONTEXT_ID, sizeof(*ce), GFP_KERNEL);
if (!ce) {
- drm_err(>->i915->drm, "Context array allocation failed\n");
+ guc_err(guc, "Context array allocation failed\n");
return -ENOMEM;
}
@@ -167,24 +168,24 @@ static int intel_guc_steal_guc_ids(void *arg)
if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[context_index]);
ce[context_index] = NULL;
- drm_err(>->i915->drm, "Failed to create context: %d\n", ret);
+ guc_err(guc, "Failed to create context: %d\n", ret);
goto err_wakeref;
}
ret = igt_spinner_init(&spin, engine->gt);
if (ret) {
- drm_err(>->i915->drm, "Failed to create spinner: %d\n", ret);
+ guc_err(guc, "Failed to create spinner: %d\n", ret);
goto err_contexts;
}
spin_rq = igt_spinner_create_request(&spin, ce[context_index],
MI_ARB_CHECK);
if (IS_ERR(spin_rq)) {
ret = PTR_ERR(spin_rq);
- drm_err(>->i915->drm, "Failed to create spinner request:
%d\n", ret);
+ guc_err(guc, "Failed to create spinner request: %d\n", ret);
goto err_contexts;
}
ret = request_add_spin(spin_rq, &spin);
if (ret) {
- drm_err(>->i915->drm, "Failed to add Spinner request: %d\n",
ret);
+ guc_err(guc, "Failed to add Spinner request: %d\n", ret);
goto err_spin_rq;
}
@@ -194,7 +195,7 @@ static int intel_guc_steal_guc_ids(void *arg)
if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[
Re: [PATCH drm-next 03/14] drm: manager to keep track of GPUs VA mappings
On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote: > This adds the infrastructure for a manager implementation to keep track > of GPU virtual address (VA) mappings. > > New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers > start implementing, allow userspace applications to request multiple and > arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is > intended to serve the following purposes in this context. > > 1) Provide a dedicated range allocator to track GPU VA allocations and >mappings, making use of the drm_mm range allocator. > > 2) Generically connect GPU VA mappings to their backing buffers, in >particular DRM GEM objects. > > 3) Provide a common implementation to perform more complex mapping >operations on the GPU VA space. In particular splitting and merging >of GPU VA mappings, e.g. for intersecting mapping requests or partial >unmap requests. > Over the past week I've hacked together a PoC port of Xe to GPUVA [1], so far it seems really promising. 95% of the way to being feature equivalent of the current Xe VM bind implementation and have line of sight to getting sparse bindings implemented on top of GPUVA too. IMO this has basically everything we need for Xe with a few tweaks. I am out until 2/14 but wanted to get my thoughts / suggestions out on the list before I leave. 1. GPUVA post didn't support the way Xe does userptrs - a NULL GEM. I believe with [2], [3], and [4] GPUVA will support NULL GEMs. Also my thinking sparse binds will also have NULL GEMs, more on sparse bindings below. 2. I agree with Christian that drm_mm probably isn't what we want to base the GPUVA implementation on, rather a RB tree or Maple tree has been discussed. The implementation should be fairly easy to tune once we have benchmarks running so not to concerned here as we can figure this out down the line. 3. In Xe we want create xe_vm_op list which inherits from drm_gpuva_op I've done this with a hack [5], I believe when we rebase we can do this with a custom callback to allocate a large op size. 4. I'd like add user bits to drm_gpuva_flags like I do in [6]. This is similar to DMA_FENCE_FLAG_USER_BITS. 5. In Xe we have VM prefetch operation which is needed for our compute UMD with page faults. I'd like add prefetch type of operation like we do in [7]. 6. In Xe we have VM unbind all mappings for a GEM IOCTL, I'd like to add support to generate this operation list to GPUVA like we do in [8]. 7. I've thought about how Xe will implement sparse mappings (read 0, writes dropped). My current thinking is a sparse mapping will be represented as a drm_gpuva rather than region like in Nouveau. Making regions optional to me seems likes good idea rather than forcing the user of GPUVA code to create 1 large region for the manager as I currently do in the Xe PoC. 8. Personally I'd like the caller to own the locking for GEM drm_gpuva list (drm_gpuva_link_*, drm_gpuva_unlink_* functions). In Xe we almost certainly will have the GEM dma-resv lock when we touch this list so an extra lock here is redundant. Also it kinda goofy that caller owns the for drm_gpuva insertion / removal but not the locking for this list. WRT to Christian thoughts on a common uAPI rules for VM binds, I kinda like that idea but I don't think that is necessary. All of pur uAPI should be close but also the GPUVA implementation should be flexible enough to fit all of our needs and I think for the most part it is. Let me know what everything thinks about this. It would be great if when I'm back on 2/14 I can rebase the Xe port to GPUVA on another version of the GPUVA code and get sparse binding support implementation. Also I'd like to get GPUVA merged in the Xe repo ASAP as our VM bind code badly needed to be cleaned and this was the push we needed to make this happen. Matt [1] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314 [2] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=2ae21d7a3f52e5eb2c105ed8ae231471274bdc36 [3] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=49fca9f5d96201f5cbd1b19c7ff17eedfac65cdc [4] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=61fa6b1e1f10e791ae82358fa971b04421d53024 [5] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=87fc08dcf0840e794b38269fe4c6a95d088d79ec [6] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=a4826c22f6788bc29906ffa263c1cd3c4661fa77 [7] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=f008bbb55b213868e52c7b9cda4c1bfb95af6aee [8] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/314/diffs?commit_id=41f4f71c05d04d2b17d988dd95369b5df2d7f681 > Idea-suggested-by: Dave Airlie > Signed-off-by: Danilo Krummrich > --- > Documentation/gpu/drm-mm.rst| 31 + > drivers/gpu/drm/Makefile|
Re: [PATCH v2 05/27] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout
On 2/3/2023 6:16 AM, Dmitry Baryshkov wrote: On 28/01/2023 01:59, Abhinav Kumar wrote: On 1/26/2023 10:05 PM, Dmitry Baryshkov wrote: On Fri, 27 Jan 2023 at 02:52, Abhinav Kumar wrote: On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote: The pipe's layout is not cached, corresponding data structure is zeroed out each time in the dpu_plane_sspp_atomic_update(), right before the call to _dpu_plane_set_scanout() -> dpu_format_populate_layout(). Drop plane_addr comparison against previous layout and corresponding EAGAIN handling. Signed-off-by: Dmitry Baryshkov The change itself LGTM, hence But, shouldnt we add this EAGAIN validation or in other words fix this rather than drop this? What for? Does it really save us anything? What's the price of re-programming the SSPP_SRC0_ADDR registers? There are 4 Src registers being programmed per sspp. With number of layers going up this will be 4x. So lets say there are 5 layers and only one of their address has changed, we need to reprogram only 4 regs but now will reprogram 20. I think this was the original intention for this change, however the implementation ended up being written in a way when this condition doesn't trigger at all. Yes, and thats why I wrote that we should fix this rather than drop this. Thats why i thought this is a good optimization. But still, that is a separate change so I am fine if this goes in first as its just removing dead code anyway. Reviewed-by: Abhinav Kumar
Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs
Hi Steven, On Fri, 3 Feb 2023 15:41:38 + Steven Price wrote: > Hi Boris, > > Thanks for the post - it's great to see the progress! Thanks for chiming in! > > On 01/02/2023 08:48, Boris Brezillon wrote: > > Mali v10 (second Valhal iteration) and later GPUs replaced the Job > > Manager block by a command stream based interface called CSF (for > > Command Stream Frontend). This interface is not only turning the job > > chain based submission model into a command stream based one, but also > > introducing FW-assisted scheduling of command stream queues. This is a > > fundamental shift in both how userspace is supposed to submit jobs, but > > also how the driver is architectured. We initially tried to retrofit the > > CSF model into panfrost, but this ended up introducing unneeded > > complexity to the existing driver, which we all know is a potential > > source of regression. > > While I agree there's some big differences which effectively mandate > splitting the driver I do think there are some parts which make a lot of > sense to share. > > For example pancsf_regs.h and panfrost_regs.h are really quite similar > and I think could easily be combined. For registers, I'm not so sure. I mean, yes, most of them are identical, but some disappeared, while others were kept but with a different layout (see GPU_CMD), or bits re-purposed for different meaning (MMU_INT_STAT where BUS_FAULT just became OPERATION_COMPLETE). This makes the whole thing very confusing, so I'd rather keep those definitions separate for my own sanity (spent a bit of time trying to understand why my GPU command was doing nothing or why I was receiving BUS_FAULT interrupts, before realizing I was referring to the old layout) :-). > The clock/regulator code is pretty > much a direct copy/paste (just adding support for more clocks), etc. Clock and regulators, maybe, but there's not much to be shared here. I mean, Linux already provides quite a few helpers making the clk/regulator retrieval/enabling/disabling pretty straightforward. Not to mention that, by keeping them separate, we don't really need to deal with old Mali HW quirks, and we can focus on new HW bugs instead :-). > > What would be ideal is factoring out 'generic' parts from panfrost and > then being able to use them from pancsf. I've been refactoring this pancsf driver a few times already, and I must admit I'd prefer to keep things separate, at least for the initial submission. If we see things that should be shared, then we can do that in a follow-up series, but I think it's a bit premature to do it now. > > I had a go at starting that: > > https://gitlab.arm.com/linux-arm/linux-sp/-/tree/pancsf-refactor > > (lightly tested for Panfrost, only build tested for pancsf). Thanks, I'll have a look. > > That saves around 200 lines overall and avoids needing to maintain two > lots of clock/regulator code. There's definite scope for sharing (most) > register definitions between the drivers and quite possibly some of the > MMU/memory code (although there's diminishing returns there). Yeah, actually the MMU code is likely to diverge even more if we want to support VM_BIND (require pre-allocating pages for the page-table updates, so the map/unmap operations can't fail in the run_job path), so I'm not sure it's a good idea to share that bit, at least not until we have a clearer idea of how we want things done. > > > So here comes a brand new driver for CSF-based hardware. This is a > > preliminary version and some important features are missing (like devfreq > > , PM support and a memory shrinker implem, to name a few). The goal of > > this RFC is to gather some preliminary feedback on both the uAPI and some > > basic building blocks, like the MMU/VM code, the tiler heap allocation > > logic... > > At the moment I don't have any CSF hardware available, so this review is > a pure code review. That's still very useful. > I'll try to organise some hardware and do some > testing, but it's probably going to take a while to arrive and get setup. I'm actively working on the driver, and fixing things as I go, so let me know when you're ready to test and I'll point you to the latest version. > > +#define DRM_PANCSF_SYNC_OP_MIN_SIZE24 > > +#define DRM_PANCSF_QUEUE_SUBMIT_MIN_SIZE 32 > > +#define DRM_PANCSF_QUEUE_CREATE_MIN_SIZE 8 > > +#define DRM_PANCSF_VM_BIND_OP_MIN_SIZE 48 > > I'm not sure why these are #defines rather than using sizeof()? Yeah, I don't really like that. Those min sizes are here to deal with potential new versions of the various objects passed as arrays referenced from the main ioctl struct, so we can't really use sizeof(struct drm_pancsf_xxx), because the size will change when those structs are extended. I'm considering using some macro trickery based on offsetof(struct drm_pancsf_xxx, last_mandatory_field) + sizeof(drm_pancsf_xxx.last_mandatory_field) to get the minimum struct size instead of those static defin
Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support
Hi, On 2023-02-03 14:09, Sascha Hauer wrote: > Hi, > > On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote: >> hi, >> >> I'm trying this patch series with 6.1.x kernel. it works fine on rk356x >> based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4). >> >> on rk3399 with this patch, I can see large noise area (about one third right >> side of the screen) at 4k@30. 1080p works fine as same as before. >> >> can someone reproduce this problem on rk3399? > > I have a RK339 board here, I can try to reproduce this next week. Of > course I have no idea what the issue might be, in the downstream Kernel > I can't find anything that is handled specially for the RK3399. > > What might be worth checking is the VOP clock rate. Does the VOP clock > in /sys/kernel/debug/clk/clk_summary (I don't know which one it is > though) match the pixelclock? > > If nothing else helps I can change the code to only allow the higher > resolutions on RK3568 where we know it works. This series only seem to pick up part of the dw-hdmi related changes that originates from an old chromium 4.4 kernel. Maybe that is the reason this cause issues on other SoCs? I have very recently resumed kernel coding after being away for the last 2-3 years and was planning on resuming work on a HDMI 2.0 series based on old work at [1], [2] and [3]. Those patches never got any traction last time around, maybe there is more interest now, seeing this series :-) I was planning on basing such series on top of this, but seeing how this seem to have issues on other SoCs I am not sure how to proceed. With the patches at [3] (and related patches) HDMI 2.0 modes (4K@60hz) is possible with at least RK3288, RK3328, RK3399 and RK3568 SoCs. However, those patches needs to be cleaned up a bit before they will hit the mailing list. [1] https://lore.kernel.org/all/20200108210740.28769-1-jo...@kwiboo.se/ [2] https://lore.kernel.org/all/20200922205933.5540-1-jo...@kwiboo.se/ [3] https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-1000-drm-rockchip.patch Regards, Jonas > > Sascha > >> >> -- >> FUKAUMI Naoki >> >> On 1/31/23 17:09, Sascha Hauer wrote: >>> Heiko, Sandy, >>> >>> Ok to apply these patches? >>> >>> Sascha >>> >>> On Wed, Jan 18, 2023 at 02:22:10PM +0100, Sascha Hauer wrote: It's been some time since I last sent this series. This version fixes a regression Dan Johansen reported. The reason turned out to be simple, I used the YUV420 register values instead of the RGB ones. I realized that we cannot achieve several modes offered by my monitor as these require pixelclocks that are slightly below the standard pixelclocks. As these are lower than the standard clock rates the PLL driver offers the clk driver falls back to a way lower frequency which results in something the monitor can't display, so this series now contains a patch to discard these unachievable modes. Sascha Changes since v2: - Use correct register values for mpll_cfg - Add patch to discard modes we cannot achieve Changes since v1: - Allow non standard clock rates only on Synopsys phy as suggested by Robin Murphy Sascha Hauer (3): drm/rockchip: dw_hdmi: relax mode_valid hook drm/rockchip: dw_hdmi: Add support for 4k@30 resolution drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 - 1 file changed, 32 insertions(+), 8 deletions(-) -- 2.30.2 >>> >> >> >
[PATCH] drm/i915: Move fd_install after last use of fence
From: Rob Clark
Because eb_composite_fence_create() drops the fence_array reference
after creation of the sync_file, only the sync_file holds a ref to the
fence. But fd_install() makes that reference visable to userspace, so
it must be the last thing we do with the fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f266b68cf012..0f2e056c02dd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3476,38 +3476,38 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_request:
eb_requests_get(&eb);
err = eb_requests_add(&eb, err);
if (eb.fences)
signal_fence_array(&eb, eb.composite_fence ?
eb.composite_fence :
&eb.requests[0]->fence);
+ if (unlikely(eb.gem_context->syncobj)) {
+ drm_syncobj_replace_fence(eb.gem_context->syncobj,
+ eb.composite_fence ?
+ eb.composite_fence :
+ &eb.requests[0]->fence);
+ }
+
if (out_fence) {
if (err == 0) {
fd_install(out_fence_fd, out_fence->file);
args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */
args->rsvd2 |= (u64)out_fence_fd << 32;
out_fence_fd = -1;
} else {
fput(out_fence->file);
}
}
- if (unlikely(eb.gem_context->syncobj)) {
- drm_syncobj_replace_fence(eb.gem_context->syncobj,
- eb.composite_fence ?
- eb.composite_fence :
- &eb.requests[0]->fence);
- }
-
if (!out_fence && eb.composite_fence)
dma_fence_put(eb.composite_fence);
eb_requests_put(&eb);
err_vma:
eb_release_vmas(&eb, true);
WARN_ON(err == -EDEADLK);
i915_gem_ww_ctx_fini(&eb.ww);
--
2.38.1
Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs
On 03/02/2023 16:29, Alyssa Rosenzweig wrote: >>> Mali v10 (second Valhal iteration) and later GPUs replaced the Job >>> Manager block by a command stream based interface called CSF (for >>> Command Stream Frontend). This interface is not only turning the job >>> chain based submission model into a command stream based one, but also >>> introducing FW-assisted scheduling of command stream queues. This is a >>> fundamental shift in both how userspace is supposed to submit jobs, but >>> also how the driver is architectured. We initially tried to retrofit the >>> CSF model into panfrost, but this ended up introducing unneeded >>> complexity to the existing driver, which we all know is a potential >>> source of regression. >> >> While I agree there's some big differences which effectively mandate >> splitting the driver I do think there are some parts which make a lot of >> sense to share. >> >> For example pancsf_regs.h and panfrost_regs.h are really quite similar >> and I think could easily be combined. The clock/regulator code is pretty >> much a direct copy/paste (just adding support for more clocks), etc. >> >> What would be ideal is factoring out 'generic' parts from panfrost and >> then being able to use them from pancsf. >> >> I had a go at starting that: >> >> https://gitlab.arm.com/linux-arm/linux-sp/-/tree/pancsf-refactor >> >> (lightly tested for Panfrost, only build tested for pancsf). >> >> That saves around 200 lines overall and avoids needing to maintain two >> lots of clock/regulator code. There's definite scope for sharing (most) >> register definitions between the drivers and quite possibly some of the >> MMU/memory code (although there's diminishing returns there). > > 200 lines saved in a 5kloc+ driver doesn't seem worth much, especially > against the added testing combinatorics, TBH. The main reason I can see > to unify is if we want VM_BIND (and related goodies) on JM hardware too. > That's only really for Vulkan and I really don't see the case for Vulkan > on anything older than Valhall at this point. So it comes down to > whether we want to start Vulkan at v9 or skip to v10. The separate > panfrost/pancsf drivers approach strongly favours the latter. While I agree 200 lines isn't much in the grand scheme what I really don't want is to have to maintain two (almost) identical versions of the same code. I agree with the concept entirely of having a separate .ko and not trying to keep it all "one driver". Just, for the bits where it's clearly copy/pasted from the existing Panfrost, lets move that code into a common file and build it into both drivers. Ultimately the 200 line saving was just a couple of hours this morning - indeed I was 'reviewing' by comparing against Panfrost and thinking "if it works in Panfrost it must be correct" - the review would be even easier if it wasn't new code ;) And as far as I'm aware the changes I'm proposing don't make any difference to testing - I'm not sure I understand that statement. The MMU/memory code I'm undecided on. There's clearly copied code there but quite a few differences. If we can unify and get extra goodies for Panfrost then it's worth doing, if the unification is going to be hard or risk regressions then perhaps not - especially if Mesa isn't going to get the features (which depends whether anyone working on Mesa wants to work on Vulkan for Bifrost). Anyway, just to be clear I don't want to stand in the way of getting this merged. If necessary the refactor can be done on top afterwards (indeed that's what I've got in my repo). Thanks, Steve
Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs
> > Mali v10 (second Valhal iteration) and later GPUs replaced the Job > > Manager block by a command stream based interface called CSF (for > > Command Stream Frontend). This interface is not only turning the job > > chain based submission model into a command stream based one, but also > > introducing FW-assisted scheduling of command stream queues. This is a > > fundamental shift in both how userspace is supposed to submit jobs, but > > also how the driver is architectured. We initially tried to retrofit the > > CSF model into panfrost, but this ended up introducing unneeded > > complexity to the existing driver, which we all know is a potential > > source of regression. > > While I agree there's some big differences which effectively mandate > splitting the driver I do think there are some parts which make a lot of > sense to share. > > For example pancsf_regs.h and panfrost_regs.h are really quite similar > and I think could easily be combined. The clock/regulator code is pretty > much a direct copy/paste (just adding support for more clocks), etc. > > What would be ideal is factoring out 'generic' parts from panfrost and > then being able to use them from pancsf. > > I had a go at starting that: > > https://gitlab.arm.com/linux-arm/linux-sp/-/tree/pancsf-refactor > > (lightly tested for Panfrost, only build tested for pancsf). > > That saves around 200 lines overall and avoids needing to maintain two > lots of clock/regulator code. There's definite scope for sharing (most) > register definitions between the drivers and quite possibly some of the > MMU/memory code (although there's diminishing returns there). 200 lines saved in a 5kloc+ driver doesn't seem worth much, especially against the added testing combinatorics, TBH. The main reason I can see to unify is if we want VM_BIND (and related goodies) on JM hardware too. That's only really for Vulkan and I really don't see the case for Vulkan on anything older than Valhall at this point. So it comes down to whether we want to start Vulkan at v9 or skip to v10. The separate panfrost/pancsf drivers approach strongly favours the latter.
Re: [PATCH] drm/amd/display: fix read errors pertaining to dp_lttpr_status_show()
On 2/3/23 10:43, Hamza Mahfooz wrote:
Currently, it is likely that we will read the relevant LTTPR caps after
link training has completed (which can cause garbage data to be read),
however according to the DP 2.0 spec that should be done before link
training has commenced. So, instead of reading the registers on demand,
use the values provided to us by DC.
Signed-off-by: Hamza Mahfooz
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 72 ++-
1 file changed, 22 insertions(+), 50 deletions(-)
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 e783082a4eef..cbc241596c1f 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
@@ -36,6 +36,7 @@
#include "dsc.h"
#include "link_hwss.h"
#include "dc/dc_dmub_srv.h"
+#include "link/protocols/link_dp_capability.h"
#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
#include "amdgpu_dm_psr.h"
@@ -418,67 +419,38 @@ static ssize_t dp_phy_settings_read(struct file *f, char
__user *buf,
return result;
}
-static int dp_lttpr_status_show(struct seq_file *m, void *d)
+static int dp_lttpr_status_show(struct seq_file *m, void *unused)
{
- char *data;
- struct amdgpu_dm_connector *connector = file_inode(m->file)->i_private;
- struct dc_link *link = connector->dc_link;
- uint32_t read_size = 1;
- uint8_t repeater_count = 0;
+ struct drm_connector *connector = m->private;
+ struct amdgpu_dm_connector *aconnector =
+ to_amdgpu_dm_connector(connector);
+ struct dc_lttpr_caps caps = aconnector->dc_link->dpcd_caps.lttpr_caps;
- data = kzalloc(read_size, GFP_KERNEL);
- if (!data)
- return 0;
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
- dm_helpers_dp_read_dpcd(link->ctx, link, 0xF0002, data, read_size);
+ seq_printf(m, "phy repeater count: %u (raw: 0x%x)\n",
+ dp_parse_lttpr_repeater_count(caps.phy_repeater_cnt),
+ caps.phy_repeater_cnt);
- switch ((uint8_t)*data) {
- case 0x80:
- repeater_count = 1;
- break;
- case 0x40:
- repeater_count = 2;
- break;
- case 0x20:
- repeater_count = 3;
- break;
- case 0x10:
- repeater_count = 4;
- break;
- case 0x8:
- repeater_count = 5;
- break;
- case 0x4:
- repeater_count = 6;
- break;
- case 0x2:
- repeater_count = 7;
+ seq_puts(m, "phy repeater mode: ");
+
+ switch (caps.mode) {
+ case DP_PHY_REPEATER_MODE_TRANSPARENT:
+ seq_puts(m, "transparent");
break;
- case 0x1:
- repeater_count = 8;
+ case DP_PHY_REPEATER_MODE_NON_TRANSPARENT:
+ seq_puts(m, "non-transparent");
break;
- case 0x0:
- repeater_count = 0;
+ case 0x00:
+ seq_puts(m, "non lttpr");
break;
default:
- repeater_count = (uint8_t)*data;
+ seq_printf(m, "read error (raw: 0x%x)", caps.mode);
break;
}
- seq_printf(m, "phy repeater count: %d\n", repeater_count);
-
- dm_helpers_dp_read_dpcd(link->ctx, link, 0xF0003, data, read_size);
-
- if ((uint8_t)*data == 0x55)
- seq_printf(m, "phy repeater mode: transparent\n");
- else if ((uint8_t)*data == 0xAA)
- seq_printf(m, "phy repeater mode: non-transparent\n");
- else if ((uint8_t)*data == 0x00)
- seq_printf(m, "phy repeater mode: non lttpr\n");
- else
- seq_printf(m, "phy repeater mode: read error\n");
-
- kfree(data);
+ seq_puts(m, "\n");
return 0;
}
Reviewed-by: Aurabindo Pillai
Re: remove arch/sh
Hi Randy,
On Fri, Feb 3, 2023 at 4:57 PM Randy Dunlap wrote:
> Is this "sh64" still accurate and applicable? from
> Documentation/kbuild/kbuild.rst:
>
> But some architectures such as x86 and sparc have aliases.
>
> - x86: i386 for 32 bit, x86_64 for 64 bit
> - sh: sh for 32 bit, sh64 for 64 bit <<<
> - sparc: sparc32 for 32 bit, sparc64 for 64 bit
No, support for sh64 was removed in commit 37744feebc086908
("sh: remove sh5 support") in v5.8.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > On 2/3/23 10:19, Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > >> > >> > >> On 2/3/23 07:59, Sebastian Wick wrote: > >>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > >>> wrote: > > On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > > Userspace has no way of controlling or knowing the pixel encoding > > currently, so there is no way for it to ever get the right values here. > > That applies to a lot of the other values as well (they are > explicitly RGB or YCC). The idea was that this property sets the > infoframe/MSA/SDP value exactly, and other properties should be > added to for use userspace to control the pixel encoding/colorspace > conversion(if desired, or userspace just makes sure to > directly feed in correct kind of data). > >>> > >>> I'm all for getting userspace control over pixel encoding but even > >>> then the kernel always knows which pixel encoding is selected and > >>> which InfoFrame has to be sent. Is there a reason why userspace would > >>> want to control the variant explicitly to the wrong value? > >>> > >> > >> I've asked this before but haven't seen an answer: Is there an existing > >> upstream userspace project that makes use of this property (other than > >> what Joshua is working on in gamescope right now)? That would help us > >> understand the intent better. > > > > The intent was to control the infoframe colorimetry bits, > > nothing more. No idea what real userspace there was, if any. > > > >> > >> I don't think giving userspace explicit control over the exact infoframe > >> values is the right thing to do. > > > > Only userspace knows what kind of data it's stuffing into > > the pixels (and/or how it configures the csc units/etc.) to > > generate them. > > > > Yes, but userspace doesn't control or know whether we drive > RGB or YCbCr on the wire. In fact, in some cases our driver > needs to fallback to YCbCr420 for bandwidth reasons. There > is currently no way for userspace to know that and I don't > think it makes sense. People want that control as well for whatever reason. We've been asked to allow YCbCr 4:4:4 output many times. The automagic 4:2:0 fallback I think is rather fundementally incompatible with fancy color management. How would we even know whether to use eg. BT.2020 vs. BT.709 matrix? In i915 that stuff is just always BT.709 limited range, no questions asked. So I think if userspace wants real color management it's going to have to set up the whole pipeline. And for that we need at least one new property to control the RGB->YCbCr conversion (or to explicitly avoid it). And given that the proposed patch just swept all the non-BT.2020 issues under the rug makes me think no one has actually come up with any kind of consistent plan for anything else really. > > Userspace needs full control of framebuffer pixel formats, > as well as control over DEGAMMA, GAMMA, CTM color operations. > It also needs to be able to select whether to drive the panel > as sRGB or BT.2020/PQ but it doesn't make sense for it to > control the pixel encoding on the wire (RGB vs YCbCr). > > > I really don't want a repeat of the disaster of the > > 'Broadcast RGB' which has coupled together the infoframe > > and automagic conversion stuff. And I think this one would > > be about 100x worse given this property has something > > to do with actual colorspaces as well. > > > > I'm unaware of this disaster. Could you elaborate? The property now controls both the infoframe stuff (and whatever super vague stuff DP has for it in MSA) and full->limited range compression in the display pipeline. And as a result there is no way to eg. allow already limited range input, which is what some people wanted. And naturally it's all made a lot more terrible by all the displays that fail to implement the spec correctly, but that's another topic. -- Ville Syrjälä Intel
Re: remove arch/sh
Hi-- On 2/3/23 02:33, Geert Uytterhoeven wrote: > Hi Adrian, > > On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz > wrote: >> On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: >>> On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: Since this is my very first time stepping up as a kernel maintainer, I was hoping to get some pointers on what to do to make this happen. So far, we have set up a new kernel tree and I have set up a local development and test environment for SH kernels using my SH7785LCR board as the target platform. Do I just need to send a patch asking to change the corresponding entry in the MAINTAINERS file? >>> >>> I'm not sure a there is a document, but: >>> >>> - add the MAINTAINERS change to your tree >>> - ask Stephen to get your tree included in linux-next >>> >>> then eventually send a pull request to Linus with all of that. Make >>> sure it's been in linux-next for a while. >> >> OK, thanks for the pointers! Will try to get this done by next week. >> >> We're still discussing among SuperH developer community whether there will >> be a second >> maintainer, so please bear with us a few more days. I will collect patches >> in the >> meantime. > > Thanks a lot! > > If you need any help with process, setup, ... don't hesitate to ask > (on e.g. #renesas-soc on Libera). While Adrian and Geert are reading this, I have a question: Is this "sh64" still accurate and applicable? from Documentation/kbuild/kbuild.rst: But some architectures such as x86 and sparc have aliases. - x86: i386 for 32 bit, x86_64 for 64 bit - sh: sh for 32 bit, sh64 for 64 bit <<< - sparc: sparc32 for 32 bit, sparc64 for 64 bit Thanks. -- ~Randy
[PATCH] drm/i915/hwmon: Enable PL1 power limit
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
initialization.
Bspec: 51864
v2: Add Bspec reference (Gwan-gyeong)
v3: Add Fixes tag
Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
Signed-off-by: Ashutosh Dixit
Reviewed-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/i915_hwmon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 1225bc432f0d5..4683a5b96eff1 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private *i915)
for_each_gt(gt, i915, i)
hwm_energy(&hwmon->ddat_gt[i], &energy);
}
+
+ /* Enable PL1 power limit */
+ if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
+ hwm_locked_with_pm_intel_uncore_rmw(ddat,
hwmon->rg.pkg_rapl_limit,
+ PKG_PWR_LIM_1_EN,
PKG_PWR_LIM_1_EN);
}
void i915_hwmon_register(struct drm_i915_private *i915)
--
2.38.0
[PATCH] drm/amd/display: fix read errors pertaining to dp_lttpr_status_show()
Currently, it is likely that we will read the relevant LTTPR caps after
link training has completed (which can cause garbage data to be read),
however according to the DP 2.0 spec that should be done before link
training has commenced. So, instead of reading the registers on demand,
use the values provided to us by DC.
Signed-off-by: Hamza Mahfooz
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 72 ++-
1 file changed, 22 insertions(+), 50 deletions(-)
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 e783082a4eef..cbc241596c1f 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
@@ -36,6 +36,7 @@
#include "dsc.h"
#include "link_hwss.h"
#include "dc/dc_dmub_srv.h"
+#include "link/protocols/link_dp_capability.h"
#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
#include "amdgpu_dm_psr.h"
@@ -418,67 +419,38 @@ static ssize_t dp_phy_settings_read(struct file *f, char
__user *buf,
return result;
}
-static int dp_lttpr_status_show(struct seq_file *m, void *d)
+static int dp_lttpr_status_show(struct seq_file *m, void *unused)
{
- char *data;
- struct amdgpu_dm_connector *connector = file_inode(m->file)->i_private;
- struct dc_link *link = connector->dc_link;
- uint32_t read_size = 1;
- uint8_t repeater_count = 0;
+ struct drm_connector *connector = m->private;
+ struct amdgpu_dm_connector *aconnector =
+ to_amdgpu_dm_connector(connector);
+ struct dc_lttpr_caps caps = aconnector->dc_link->dpcd_caps.lttpr_caps;
- data = kzalloc(read_size, GFP_KERNEL);
- if (!data)
- return 0;
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
- dm_helpers_dp_read_dpcd(link->ctx, link, 0xF0002, data, read_size);
+ seq_printf(m, "phy repeater count: %u (raw: 0x%x)\n",
+ dp_parse_lttpr_repeater_count(caps.phy_repeater_cnt),
+ caps.phy_repeater_cnt);
- switch ((uint8_t)*data) {
- case 0x80:
- repeater_count = 1;
- break;
- case 0x40:
- repeater_count = 2;
- break;
- case 0x20:
- repeater_count = 3;
- break;
- case 0x10:
- repeater_count = 4;
- break;
- case 0x8:
- repeater_count = 5;
- break;
- case 0x4:
- repeater_count = 6;
- break;
- case 0x2:
- repeater_count = 7;
+ seq_puts(m, "phy repeater mode: ");
+
+ switch (caps.mode) {
+ case DP_PHY_REPEATER_MODE_TRANSPARENT:
+ seq_puts(m, "transparent");
break;
- case 0x1:
- repeater_count = 8;
+ case DP_PHY_REPEATER_MODE_NON_TRANSPARENT:
+ seq_puts(m, "non-transparent");
break;
- case 0x0:
- repeater_count = 0;
+ case 0x00:
+ seq_puts(m, "non lttpr");
break;
default:
- repeater_count = (uint8_t)*data;
+ seq_printf(m, "read error (raw: 0x%x)", caps.mode);
break;
}
- seq_printf(m, "phy repeater count: %d\n", repeater_count);
-
- dm_helpers_dp_read_dpcd(link->ctx, link, 0xF0003, data, read_size);
-
- if ((uint8_t)*data == 0x55)
- seq_printf(m, "phy repeater mode: transparent\n");
- else if ((uint8_t)*data == 0xAA)
- seq_printf(m, "phy repeater mode: non-transparent\n");
- else if ((uint8_t)*data == 0x00)
- seq_printf(m, "phy repeater mode: non lttpr\n");
- else
- seq_printf(m, "phy repeater mode: read error\n");
-
- kfree(data);
+ seq_puts(m, "\n");
return 0;
}
--
2.39.1
Re: [RFC PATCH] drm/pancsf: Add a new driver for Mali CSF-based GPUs
Hi Boris, Thanks for the post - it's great to see the progress! On 01/02/2023 08:48, Boris Brezillon wrote: > Mali v10 (second Valhal iteration) and later GPUs replaced the Job > Manager block by a command stream based interface called CSF (for > Command Stream Frontend). This interface is not only turning the job > chain based submission model into a command stream based one, but also > introducing FW-assisted scheduling of command stream queues. This is a > fundamental shift in both how userspace is supposed to submit jobs, but > also how the driver is architectured. We initially tried to retrofit the > CSF model into panfrost, but this ended up introducing unneeded > complexity to the existing driver, which we all know is a potential > source of regression. While I agree there's some big differences which effectively mandate splitting the driver I do think there are some parts which make a lot of sense to share. For example pancsf_regs.h and panfrost_regs.h are really quite similar and I think could easily be combined. The clock/regulator code is pretty much a direct copy/paste (just adding support for more clocks), etc. What would be ideal is factoring out 'generic' parts from panfrost and then being able to use them from pancsf. I had a go at starting that: https://gitlab.arm.com/linux-arm/linux-sp/-/tree/pancsf-refactor (lightly tested for Panfrost, only build tested for pancsf). That saves around 200 lines overall and avoids needing to maintain two lots of clock/regulator code. There's definite scope for sharing (most) register definitions between the drivers and quite possibly some of the MMU/memory code (although there's diminishing returns there). > So here comes a brand new driver for CSF-based hardware. This is a > preliminary version and some important features are missing (like devfreq > , PM support and a memory shrinker implem, to name a few). The goal of > this RFC is to gather some preliminary feedback on both the uAPI and some > basic building blocks, like the MMU/VM code, the tiler heap allocation > logic... At the moment I don't have any CSF hardware available, so this review is a pure code review. I'll try to organise some hardware and do some testing, but it's probably going to take a while to arrive and get setup. > It's also here to give concrete code to refer to for the discussion > around scheduling and VM_BIND support that started on the Xe/nouveau > threads[1][2]. Right now, I'm still using a custom timesharing-based > scheduler, but I plan to give Daniel's suggestion a try (having one > drm_gpu_scheduler per drm_sched_entity, and replacing the tick-based > scheduler by some group slot manager with an LRU-based group eviction > mechanism). I also have a bunch of things I need to figure out regarding > the VM-based memory management code. The current design assumes explicit > syncs everywhere, but we don't use resv objects yet. I see other modern > drivers are adding BOOKKEEP fences to the VM resv object and using this > VM resv to synchronize with kernel operations on the VM, but we > currently don't do any of that. As Daniel pointed out it's likely to > become an issue when we throw the memory shrinker into the mix. And of > course, the plan is to transition to the drm_gpuva_manager infrastructure > being discussed here [2] before merging the driver. Kind of related to > this shrinker topic, I'm wondering if it wouldn't make sense to use > the TTM infra for our buffer management (AFAIU, we'd get LRU-based BO > eviction for free, without needing to expose an MADVISE(DONT_NEED) kind > of API), but I'm a bit worried about the extra complexity this would pull > in. I'm afraid I haven't done much review of this yet - my knowledge of how this is done in kbase is lacking as I was already leaving GPU around the time this was being implemented... but since it's all about to change perhaps that's for the best ;) > Note that DT bindings are currently undocumented. For those who really > care, they're based on the panfrost bindings, so I don't expect any > pain points on that front. I'll provide a proper doc once all other > aspects have been sorted out. > > Regards, > > Boris > > [1]https://lore.kernel.org/dri-devel/2022122127.34560-1-matthew.br...@intel.com/ > [2]https://lore.kernel.org/lkml/y8joce%2fpynz2z...@dut025-tglu.fm.intel.com/ > > Signed-off-by: Boris Brezillon > Cc: Alyssa Rosenzweig > Cc: Steven Price > Cc: Robin Murphy > Cc: Daniel Vetter > Cc: Daniel Stone > Cc: Jason Ekstrand > --- > drivers/gpu/drm/Kconfig|2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/pancsf/Kconfig | 15 + > drivers/gpu/drm/pancsf/Makefile| 14 + > drivers/gpu/drm/pancsf/pancsf_device.c | 391 > drivers/gpu/drm/pancsf/pancsf_device.h | 168 ++ > drivers/gpu/drm/pancsf/pancsf_drv.c| 812 +++ > drivers/gpu/drm/pancsf/pancsf_gem.c| 161 ++ > drivers/gpu/drm/pancsf/pancsf_gem.h| 45 + >
Re: [PATCH v7 3/6] drm/tidss: Add support for AM625 DSS
On 25/01/2023 13:35, Aradhya Bhatia wrote: Add support for the DSS controller on TI's new AM625 SoC in the tidss driver. The first video port (VP0) in am625-dss can output OLDI signals through 2 OLDI TXes. A 3rd output port has been added with "DISPC_PORT_OLDI" bus type. Not a big thing here as you add support for a new SoC, but the ordering of the patches is not optimal. Here you add the AM625 DSS support, but then you continue actually adding the DSS support (well, mainly OLDI) in the following patches. I think patch 6 could be before this patch. Parts of patch 4 could also be before this patch. The AM65X renames from patch 5 could be before this patch. I'm mainly thinking of a case where someone uses AM625 and is bisecting a problem. What happens if his board uses OLDI, and he happens to hit one of these patches during bisect? If the display just stays black, but otherwise everything works fine, then no problem. But if it crashes or starts spamming sync losts or such or gives errors, it's not so nice. Tomi
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/3/23 10:19, Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: >> >> >> On 2/3/23 07:59, Sebastian Wick wrote: >>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä >>> wrote: On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > Userspace has no way of controlling or knowing the pixel encoding > currently, so there is no way for it to ever get the right values here. That applies to a lot of the other values as well (they are explicitly RGB or YCC). The idea was that this property sets the infoframe/MSA/SDP value exactly, and other properties should be added to for use userspace to control the pixel encoding/colorspace conversion(if desired, or userspace just makes sure to directly feed in correct kind of data). >>> >>> I'm all for getting userspace control over pixel encoding but even >>> then the kernel always knows which pixel encoding is selected and >>> which InfoFrame has to be sent. Is there a reason why userspace would >>> want to control the variant explicitly to the wrong value? >>> >> >> I've asked this before but haven't seen an answer: Is there an existing >> upstream userspace project that makes use of this property (other than >> what Joshua is working on in gamescope right now)? That would help us >> understand the intent better. > > The intent was to control the infoframe colorimetry bits, > nothing more. No idea what real userspace there was, if any. > >> >> I don't think giving userspace explicit control over the exact infoframe >> values is the right thing to do. > > Only userspace knows what kind of data it's stuffing into > the pixels (and/or how it configures the csc units/etc.) to > generate them. > Yes, but userspace doesn't control or know whether we drive RGB or YCbCr on the wire. In fact, in some cases our driver needs to fallback to YCbCr420 for bandwidth reasons. There is currently no way for userspace to know that and I don't think it makes sense. Userspace needs full control of framebuffer pixel formats, as well as control over DEGAMMA, GAMMA, CTM color operations. It also needs to be able to select whether to drive the panel as sRGB or BT.2020/PQ but it doesn't make sense for it to control the pixel encoding on the wire (RGB vs YCbCr). > I really don't want a repeat of the disaster of the > 'Broadcast RGB' which has coupled together the infoframe > and automagic conversion stuff. And I think this one would > be about 100x worse given this property has something > to do with actual colorspaces as well. > I'm unaware of this disaster. Could you elaborate? Harry
Re: [PATCH v7 5/6] drm/tidss: Add IO CTRL and Power support for OLDI TX in am625
On 25/01/2023 13:35, Aradhya Bhatia wrote:
The ctrl mmr module of the AM625 is different from the AM65X SoC. Thus
the ctrl mmr registers that supported the OLDI TX power have become
different in AM625 SoC.
The common mode voltage of the LVDS buffers becomes random when the
bandgap reference is turned off. This causes uncertainity in the LVDS
Data and Clock signal outputs, making it behave differently under
different conditions and panel setups. The bandgap reference must be
powered on before using the OLDI IOs, to keep the common voltage trimmed
down to desired levels.
Add support to enable/disable OLDI IO signals as well as the bandgap
reference circuit for the LVDS signals.
Signed-off-by: Aradhya Bhatia
---
Note:
- Dropped Tomi Valkeinen's reviewed-by tag in this patch because I did
not implement one of his comments which suggested to remove the
'oldi_supported' variable. While the oldi support is indeed based on
SoC variations, keeping that variable helps take into account the case
where an OLDI supporting SoC by-passes OLDI TXes and gives out DPI
video signals straight from DSS.
Hmm why is that relevent for this patch? It doesn't use oldi_supported
or the new has_oldi.
drivers/gpu/drm/tidss/tidss_dispc.c | 57 +++-
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 40 -
2 files changed, 76 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 37a73e309330..0e03557bc142 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -934,21 +934,56 @@ int dispc_vp_bus_check(struct dispc_device *dispc, u32
hw_videoport,
static void dispc_oldi_tx_power(struct dispc_device *dispc, bool power)
{
- u32 val = power ? 0 : OLDI_PWRDN_TX;
+ u32 val;
if (WARN_ON(!dispc->oldi_io_ctrl))
return;
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT0_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT1_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT2_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT3_IO_CTRL,
- OLDI_PWRDN_TX, val);
- regmap_update_bits(dispc->oldi_io_ctrl, OLDI_CLK_IO_CTRL,
- OLDI_PWRDN_TX, val);
+ if (dispc->feat->subrev == DISPC_AM65X) {
Slight nitpick, but I think switch-case makes sense for the subrev. Even
if there are just two options here, using switch makes the structure
clearer.
+ val = power ? 0 : AM65X_OLDI_PWRDN_TX;
+
+ regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT0_IO_CTRL,
+ AM65X_OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT1_IO_CTRL,
+ AM65X_OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT2_IO_CTRL,
+ AM65X_OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_DAT3_IO_CTRL,
+ AM65X_OLDI_PWRDN_TX, val);
+ regmap_update_bits(dispc->oldi_io_ctrl, AM65X_OLDI_CLK_IO_CTRL,
+ AM65X_OLDI_PWRDN_TX, val);
+
+ } else if (dispc->feat->subrev == DISPC_AM625) {
+ if (power) {
+ switch (dispc->oldi_mode) {
+ case OLDI_MODE_SINGLE_LINK:
+ /* Power down OLDI TX 1 */
+ val = AM625_OLDI1_PWRDN_TX;
+ break;
+
+ case OLDI_MODE_CLONE_SINGLE_LINK:
+ case OLDI_MODE_DUAL_LINK:
+ /* No Power down */
+ val = 0;
+ break;
+
+ default:
+ /* Power down both OLDI TXes and LVDS Bandgap */
+ val = AM625_OLDI0_PWRDN_TX |
AM625_OLDI1_PWRDN_TX |
+ AM625_OLDI_PWRDN_BG;
+ break;
+ }
+
+ } else {
+ /* Power down both OLDI TXes and LVDS Bandgap */
+ val = AM625_OLDI0_PWRDN_TX | AM625_OLDI1_PWRDN_TX |
+ AM625_OLDI_PWRDN_BG;
+ }
+
+ regmap_update_bits(dispc->oldi_io_ctrl, AM625_OLDI_PD_CTRL,
+ AM625_OLDI0_PWRDN_TX | AM625_OLDI1_PWRDN_TX |
+ AM625_OLDI_PWRDN_BG, val);
+ }
}
static void dispc_set_num_datalines(struct dispc_device *dispc,
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > On 2/3/23 07:59, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > wrote: > >> > >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote: > >>> Userspace has no way of controlling or knowing the pixel encoding > >>> currently, so there is no way for it to ever get the right values here. > >> > >> That applies to a lot of the other values as well (they are > >> explicitly RGB or YCC). The idea was that this property sets the > >> infoframe/MSA/SDP value exactly, and other properties should be > >> added to for use userspace to control the pixel encoding/colorspace > >> conversion(if desired, or userspace just makes sure to > >> directly feed in correct kind of data). > > > > I'm all for getting userspace control over pixel encoding but even > > then the kernel always knows which pixel encoding is selected and > > which InfoFrame has to be sent. Is there a reason why userspace would > > want to control the variant explicitly to the wrong value? > > > > I've asked this before but haven't seen an answer: Is there an existing > upstream userspace project that makes use of this property (other than > what Joshua is working on in gamescope right now)? That would help us > understand the intent better. The intent was to control the infoframe colorimetry bits, nothing more. No idea what real userspace there was, if any. > > I don't think giving userspace explicit control over the exact infoframe > values is the right thing to do. Only userspace knows what kind of data it's stuffing into the pixels (and/or how it configures the csc units/etc.) to generate them. I really don't want a repeat of the disaster of the 'Broadcast RGB' which has coupled together the infoframe and automagic conversion stuff. And I think this one would be about 100x worse given this property has something to do with actual colorspaces as well. -- Ville Syrjälä Intel
Re: [PATCH v7 4/6] drm/tidss: Add support to configure OLDI mode for am625-dss
On 25/01/2023 13:35, Aradhya Bhatia wrote:
The newer version of DSS (AM625-DSS) has 2 OLDI TXes at its disposal.
These can be configured to support the following modes:
1. OLDI_SINGLE_LINK_SINGLE_MODE
Single Output over OLDI 0.
+--++-+ +---+
| || | | |
| CRTC +--->+ ENCODER +->| PANEL |
| || | | |
+--++-+ +---+
2. OLDI_SINGLE_LINK_CLONE_MODE
Duplicate Output over OLDI 0 and 1.
+--++-+ +---+
| || | | |
| CRTC +---+--->| ENCODER +->| PANEL |
| | || | | |
+--+ |+-+ +---+
|
|+-+ +---+
|| | | |
+--->| ENCODER +->| PANEL |
| | | |
+-+ +---+
3. OLDI_DUAL_LINK_MODE
Combined Output over OLDI 0 and 1.
+--++-+ +---+
| || +->| |
| CRTC +--->+ ENCODER | | PANEL |
| || +->| |
+--++-+ +---+
Following the above pathways for different modes, 2 encoder/panel-bridge
pipes get created for clone mode, and 1 pipe in cases of single link and
dual link mode.
Add support for confguring the OLDI modes using OF and LVDS DRM helper
functions.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 24 ++-
drivers/gpu/drm/tidss/tidss_dispc.h | 12 ++
drivers/gpu/drm/tidss/tidss_drv.h | 3 +
drivers/gpu/drm/tidss/tidss_encoder.c | 4 +-
drivers/gpu/drm/tidss/tidss_encoder.h | 3 +-
drivers/gpu/drm/tidss/tidss_kms.c | 221 --
6 files changed, 245 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index b55ccbcaa67f..37a73e309330 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -88,6 +88,8 @@ const struct dispc_features dispc_k2g_feats = {
.subrev = DISPC_K2G,
+ .has_oldi = false,
+
.common = "common",
.common_regs = tidss_k2g_common_regs,
@@ -166,6 +168,8 @@ const struct dispc_features dispc_am625_feats = {
.subrev = DISPC_AM625,
+ .has_oldi = true,
+
.common = "common",
.common_regs = tidss_am65x_common_regs,
@@ -218,6 +222,8 @@ const struct dispc_features dispc_am65x_feats = {
.subrev = DISPC_AM65X,
+ .has_oldi = true,
+
.common = "common",
.common_regs = tidss_am65x_common_regs,
@@ -309,6 +315,8 @@ const struct dispc_features dispc_j721e_feats = {
.subrev = DISPC_J721E,
+ .has_oldi = false,
+
.common = "common_m",
.common_regs = tidss_j721e_common_regs,
@@ -361,6 +369,8 @@ struct dispc_device {
struct dss_vp_data vp_data[TIDSS_MAX_VPS];
+ enum dispc_oldi_modes oldi_mode;
+
u32 *fourccs;
u32 num_fourccs;
@@ -1963,6 +1973,12 @@ const u32 *dispc_plane_formats(struct dispc_device *dispc, unsigned int *len)
return dispc->fourccs;
}
+void dispc_set_oldi_mode(struct dispc_device *dispc,
+enum dispc_oldi_modes oldi_mode)
+{
+ dispc->oldi_mode = oldi_mode;
+}
+
static s32 pixinc(int pixels, u8 ps)
{
if (pixels == 1)
@@ -2647,7 +2663,7 @@ int dispc_runtime_resume(struct dispc_device *dispc)
REG_GET(dispc, DSS_SYSSTATUS, 2, 2),
REG_GET(dispc, DSS_SYSSTATUS, 3, 3));
- if (dispc->feat->subrev == DISPC_AM65X)
+ if (dispc->feat->has_oldi)
dev_dbg(dispc->dev, "OLDI RESETDONE %d,%d,%d\n",
REG_GET(dispc, DSS_SYSSTATUS, 5, 5),
REG_GET(dispc, DSS_SYSSTATUS, 6, 6),
@@ -2688,7 +2704,7 @@ static int dispc_iomap_resource(struct platform_device
*pdev, const char *name,
return 0;
}
-static int dispc_init_am65x_oldi_io_ctrl(struct device *dev,
+static int dispc_init_am6xx_oldi_io_ctrl(struct device *dev,
struct dispc_device *dispc)
{
dispc->oldi_io_ctrl =
@@ -2827,8 +2843,8 @@ int dispc_init(struct tidss_device *tidss)
dispc->vp_data[i].gamma_table = gamma_table;
}
- if (feat->subrev == DISPC_AM65X) {
- r = dispc_init_am65x_oldi_io_ctrl(dev, dispc);
+ if (feat->has_oldi) {
+ r = dispc_init_am6xx_oldi_io_ctrl(dev, dispc);
if (r)
return r;
}
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index 971f2856f015..880bc7de68b3 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -64,6 +64,15 @@ enum dispc_dss_subrevision {
DISPC_J721E,
};
+enum dispc_oldi_modes {
+ OLDI_MODE
Re: [PATCH v3 00/19] fix DRM_USE_DYNAMIC_DEBUG regression
On Fri, Feb 03, 2023 at 11:34:02AM +0200, Jani Nikula wrote: > On Wed, 25 Jan 2023, Jim Cromie wrote: > > Hi everyone, > > > > In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in > > drivers at modprobe. > > I realize we haven't actually addressed the regression in any way yet, > and any distro enabling DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE will have > DRM_USE_DYNAMIC_DEBUG=y by default, and we're hitting the issue with > trying to gather logs from users on v6.1 or later. It hampers debugging > pretty badly. > > I appreciate the effort in fixing the problem properly here, but we'll > need a fix that we can backport to stable kernels. > > Maybe just Ville's idea of > > config DRM_USE_DYNAMIC_DEBUG > bool "use dynamic debug to implement drm.debug" > - default y > + default n > + depends on BROKEN > depends on DRM > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE > > but we'll need that as a patch and merged and backported ASAP. +1 for this Regards Stanislaw
Re: [PATCH 1/4] accel/ivpu: Fix FW API data alignment issues
On 2/3/2023 1:05 AM, Jacek Lawrynowicz wrote:
Hi,
On 02.02.2023 16:04, Jeffrey Hugo wrote:
On 2/2/2023 2:21 AM, Stanislaw Gruszka wrote:
From: Andrzej Kacprowski
FW API structures have been updated to fix misaligned
structure members.
Also changed JSM message header format to account for
future improvements.
Added explicit check for minimum supported JSM API version.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Stanislaw Gruszka
/*
* Job format.
@@ -119,7 +119,7 @@ struct vpu_job_queue_entry {
u64 root_page_table_update_counter; /**< Page tables update events
counter */
u64 preemption_buffer_address; /**< Address of the preemption buffer to
use for this job */
u64 preemption_buffer_size; /**< Size of the preemption buffer to use
for this job */
- u8 reserved[VPU_JOB_RESERVED_BYTES];
+ u8 reserved_0[VPU_JOB_RESERVED_BYTES];
This seems spurious, just adding "_0" to the name. Seems like the majority of
the changes are like this (although you have a _1 at the very end). Are you anticipating
adding additional reserved fields in the near future?
These headers are our HW/FW interface and we (as a KMD team) do not have full
control over them.
The FW team has its own conventions which could probably treated the same as
some auto generated HW interface headers accepted as-is.
We could modify them on import but it would be harder then maintain them.
If this doesn't bug you too much I would prefer to leave them as-is, OK?
Ah, these are pulled direct from the FW. Fair enough.
Reviewed-by: Jeffrey Hugo
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/2/23 21:07, Joshua Ashton wrote:
> Userspace has no way of controlling or knowing the pixel encoding
> currently, so there is no way for it to ever get the right values here.
>
> When we do add pixel_encoding control from userspace,we can pick the
> right value for the colorimetry packet based on the
> pixel_encoding + the colorspace.
>
> Let's deprecate these values, and have one BT.2020 colorspace entry
> that userspace can use.
>
Would be good to do the same for the other entries as well but those
are a bit more ambiguous since there are no clear _RGB variants and
the intention seems to be to use _DEFAULT for RGB.
> Note: _CYCC was effectively 'removed' by this change, but that was not
> possible to be taken advantage of anyway, as there is currently no
> pixel_encoding control so it would not be possible to output
> linear YCbCr.
>
> 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/display/drm_hdmi_helper.c | 9 -
> drivers/gpu/drm/drm_connector.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 20 +---
> include/drm/drm_connector.h | 19 ++-
> 4 files changed, 29 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c
> b/drivers/gpu/drm/display/drm_hdmi_helper.c
> index 0264abe55278..c85860600395 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
> @@ -99,8 +99,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
> #define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
> #define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) | ACE(0))
> #define HDMI_COLORIMETRY_BT2020_CYCC (C(3) | EC(5) | ACE(0))
> -#define HDMI_COLORIMETRY_BT2020_RGB (C(3) | EC(6) | ACE(0))
> -#define HDMI_COLORIMETRY_BT2020_YCC (C(3) | EC(6) | ACE(0))
> +#define HDMI_COLORIMETRY_BT2020 (C(3) | EC(6) | ACE(0))
These definitions might still be useful to a driver that is populating
the infoframe. But since they're currently unused I have no strong
objection to removing them.
If we're dropping them should we also drop the _CYCC variant?
> #define HDMI_COLORIMETRY_DCI_P3_RGB_D65 (C(3) | EC(7) | ACE(0))
> #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER (C(3) | EC(7) | ACE(1))
>
> @@ -113,9 +112,9 @@ static const u32 hdmi_colorimetry_val[] = {
> [DRM_MODE_COLORIMETRY_SYCC_601] = HDMI_COLORIMETRY_SYCC_601,
> [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> - [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> - [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> - [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
> + [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_1] = HDMI_COLORIMETRY_BT2020,
> + [DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_2] = HDMI_COLORIMETRY_BT2020,
> + [DRM_MODE_COLORIMETRY_BT2020] = HDMI_COLORIMETRY_BT2020,
> };
>
> #undef C
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 61c29ce74b03..58699ab15a6a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1029,11 +1029,11 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> /* 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" },
> + { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_1, "BT2020_DEPRECATED_1" },
> /* Colorimetry based on ITU-R BT.2020 */
> - { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + { DRM_MODE_COLORIMETRY_BT2020_DEPRECATED_2, "BT2020_DEPRECATED_2" },
> /* Colorimetry based on ITU-R BT.2020 */
> - { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> + { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
> /* 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" },
> @@ -1054,7 +1054,7 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> /* Colorimetry based on SMPTE RP 431-2 */
> { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> /* Colorimetry based on ITU-R BT.2020 */
> - { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + { DRM_MODE_COLORIMETRY_BT2020, "BT2020" },
Above we've made the old _YCC value the new, non-deprecated BT2020
entry, but here you're using the _RGB one for that. Would it make
sense to make the old _YCC value deprecated an
