Re: [PATCH v2 1/2] dt-bindings: display: bridge: Add GPIO display mux binding
Hi Laurent, On Tue, Feb 7, 2023 at 11:21 PM Laurent Pinchart wrote: > > Hello Pin-yen, > > On Tue, Feb 07, 2023 at 06:30:36PM +0800, Pin-yen Lin wrote: > > On Tue, Feb 7, 2023 at 6:25 PM Laurent Pinchart wrote: > > > On Tue, Feb 07, 2023 at 06:07:44PM +0800, Pin-yen Lin wrote: > > > > On Wed, Jan 18, 2023 at 4:17 AM Rob Herring wrote: > > > > > On Mon, Jan 16, 2023 at 07:08:19PM +0800, Pin-yen Lin wrote: > > > > > > From: Nicolas Boichat > > > > > > > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > > > > > > > Signed-off-by: Nicolas Boichat > > > > > > Signed-off-by: Pin-yen Lin > > > > > > --- > > > > > > > > > > > > Changes in v2: > > > > > > - Referenced existing dt-binding schemas from graph.yaml > > > > > > - Added ddc-i2c-bus into the bindings > > > > > > > > > > > > .../bindings/display/bridge/gpio-mux.yaml | 95 > > > > > > +++ > > > > > > 1 file changed, 95 insertions(+) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > new file mode 100644 > > > > > > index ..da29ba078f05 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > @@ -0,0 +1,95 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: Generic display mux (1 input, 2 outputs) > > > > > > + > > > > > > +maintainers: > > > > > > + - Nicolas Boichat > > > > > > + > > > > > > +description: | > > > > > > + This bindings describes a simple display (e.g. HDMI) mux, that > > > > > > has 1 > > > > > > + input, and 2 outputs. The mux status is controlled by hardware, > > > > > > and > > > > > > + its status is read back using a GPIO. > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > +const: gpio-display-mux > > > > > > + > > > > > > + detect-gpios: > > > > > > +maxItems: 1 > > > > > > +description: GPIO that indicates the active output > > > > > > > > > > What are we detecting? That implies an input, but this is selecting > > > > > the > > > > > output path, right? Or what does 'mux status is controlled by > > > > > hardware' > > > > > mean exactly? Something else? That does not sound very generic. > > > > > > > > The GPIO (or any kind of MUX) is an input that indicates where the > > > > output should go. The actual "output selection" procedure is done in > > > > the driver. That is, the driver monitors this GPIO and selects the > > > > output path accordingly. In our use case, the GPIO is reported by the > > > > embedded controller on the device. > > > > > > > > [1] listed other similar bridges that can leverage this driver, so we > > > > called this driver "generic". > > > > > > > > [1]: > > > > https://lore.kernel.org/all/CAJMQK-jGw8kJFNjoHjeZUL+3NCiOS2hgGERnAnMwNsL_cm_J=q...@mail.gmail.com/ > > > > > > > > > In any case, we have a common mux binding so any kind of mux control > > > > > could be used here, not just GPIO. Then you can make this just a > > > > > generic > > > > > display mux. > > > > > > > > Thanks for sharing this, I'll update the binding in the next version. > > > > > > > > > > + > > > > > > + ddc-i2c-bus: > > > > > > +description: phandle link to the I2C controller used for DDC > > > > > > EDID probing > > > > > > +$ref: /schemas/types.yaml#/definitions/phandle > > > > > > > > > > This belongs in the connector node(s). > > > > > > > > The HDMI bridge before the MUX doesn't (and doesn't have to) know that > > > > its next bridge is a MUX. We put it here so that the HDMI bridge can > > > > parse the phandle and get the bus node. > > > > > > How does that work, does the HDMI encoder driver parse the ddc-i2c-bus > > > property of the next DT node in the OF graph ? > > > > Yes. In our use case, mtk_hdmi.c[2] checks the remote node of its > > output port to get the bus phandle. sun4i_hdmi_enc.c[3] seems to use a > > similar approach as well. > > Peeking into nodes of other devices is a bad practice. I don't know how > the code you mention below got merged, but I'm pretty sure I would have > flagged it if I had reviewed the patches :-) > > The ddc-i2c-bus property should instead be specified in the node where > it logically belongs (in this case, the connector node), and handled by > the connector driver. You can then use drm_bridge operations to tie > things together, like done in the drm_bridge_connector helper. I'd > recommend using the drm_bridge_connector helper if you can, either > as-is, or by extending it. So, even if the connector does not have its own i2c
Re: [PATCH] drm/vmwgfx: Make the driver work without the dummy resources
Am 10.02.23 um 03:34 schrieb Zack Rusin:
From: Zack Rusin
In change 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
ttm stopped allocating dummy resources but vmwgfx was never ported to
handle it. Make the driver treat null resources as initial creation and
port code to handle null resources in general.
Fixes kernel oops'es on boot with vmwgfx.
Signed-off-by: Zack Rusin
Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
Cc: Christian König
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Christian König
Sorry for the noise.
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 18 ++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 54e942df3b8e..71eeabf001c8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -837,7 +837,8 @@ void vmw_query_move_notify(struct ttm_buffer_object *bo,
mutex_lock(_priv->binding_mutex);
/* If BO is being moved from MOB to system memory */
- if (new_mem->mem_type == TTM_PL_SYSTEM &&
+ if (old_mem &&
+ new_mem->mem_type == TTM_PL_SYSTEM &&
old_mem->mem_type == VMW_PL_MOB) {
struct vmw_fence_obj *fence;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 4daebc5b9eb4..af8562c95cc3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -515,9 +515,13 @@ static int vmw_move(struct ttm_buffer_object *bo,
struct ttm_resource *new_mem,
struct ttm_place *hop)
{
- struct ttm_resource_manager *old_man = ttm_manager_type(bo->bdev,
bo->resource->mem_type);
- struct ttm_resource_manager *new_man = ttm_manager_type(bo->bdev,
new_mem->mem_type);
- int ret;
+ struct ttm_resource_manager *new_man;
+ struct ttm_resource_manager *old_man = NULL;
+ int ret = 0;
+
+ new_man = ttm_manager_type(bo->bdev, new_mem->mem_type);
+ if (bo->resource)
+ old_man = ttm_manager_type(bo->bdev, bo->resource->mem_type);
if (new_man->use_tt && !vmw_memtype_is_system(new_mem->mem_type)) {
ret = vmw_ttm_bind(bo->bdev, bo->ttm, new_mem);
@@ -525,9 +529,15 @@ static int vmw_move(struct ttm_buffer_object *bo,
return ret;
}
+ if (!bo->resource || (bo->resource->mem_type == TTM_PL_SYSTEM &&
+ bo->ttm == NULL)) {
+ ttm_bo_move_null(bo, new_mem);
+ return 0;
+ }
+
vmw_move_notify(bo, bo->resource, new_mem);
- if (old_man->use_tt && new_man->use_tt) {
+ if (old_man && old_man->use_tt && new_man->use_tt) {
if (vmw_memtype_is_system(bo->resource->mem_type)) {
ttm_bo_move_null(bo, new_mem);
return 0;
error: 'const struct dc_dsc_config' has no member named 'is_frl'
Hi, The 'is_frl' struct field is conditional: #if defined(CONFIG_DRM_AMD_DC_DCN) bool is_frl; /* indicate if DSC is applied based on HDMI FRL sink's capability */ #endif so code that uses it should be careful, otherwise build errors may happen: ../drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c: In function 'dp_active_dongle_validate_timing': ../drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:126:66: error: 'const struct dc_dsc_config' has no member named 'is_frl' 126 | if (timing->flags.DSC && !timing->dsc_cfg.is_frl) | Seen on arch=um and arch=riscv (RV64). -- ~Randy
Re: [Freedreno] [PATCH v3 27/27] drm/msm/dpu: add support for wide planes
On 10/02/2023 03:12, Abhinav Kumar wrote:
Hi Dmitry
On 2/9/2023 4:09 PM, Dmitry Baryshkov wrote:
.
On Fri, 10 Feb 2023 at 00:12, Abhinav Kumar
wrote:
Hi Dmitry
On 2/9/2023 1:23 PM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Thu, 9 Feb 2023 at 21:25, Abhinav Kumar
wrote:
On 2/9/2023 3:45 AM, Dmitry Baryshkov wrote:
On Thu, 9 Feb 2023 at 04:19, Abhinav Kumar
wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Typically SSPP can support rectangle with width up to 2560.
However it's
Not always 2560. Depends on the chipset.
_typically_
Would just say maxlinewidth of SSPP instead of giving some
hardcoded number.
Ack.
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,
>pipe);
+ _dpu_crtc_blend_setup_pipe(crtc, plane,
+ mixer, cstate->num_mixers,
+ stage_cfg,
pstate->stage, 1,
+ fetch_active,
+ >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(_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;
instead of checking if sspp was present, is it not better for the
caller
to check if the rpipe is valid before calling this?
+
/* 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, >pipe,
>pipe_cfg, fill_color, fmt);
+
+ _dpu_plane_color_fill_pipe(pstate, >r_pipe,
>r_pipe_cfg, fill_color, fmt);
}
So cant we do
if (pstate->r_pipe.sspp)
_dpu_plane_color_fill_pipe(pstate, >r_pipe,
>r_pipe_cfg, fill_color, fmt);
It just seems better to me as the caller would already know if
the sspp
was assigned.
I think I had this kind of code earlier, but then I found it more
logical to move the check to the called function. I'll move it back.
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 = >pipe;
+ struct dpu_sw_pipe *r_pipe = >r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
+ struct dpu_hw_sspp_cfg *r_pipe_cfg = >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;
+
[PATCH] drm/amd/display: Remove the unused variable pre_connection_type
Variable pre_connection_type is not effectively used, so delete it.
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4031
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/link/link_detection.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
index 63e75c392031..d224a44c4cc8 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
@@ -886,7 +886,6 @@ static bool detect_link_and_local_sink(struct dc_link *link,
struct dc_sink *prev_sink = NULL;
struct dpcd_caps prev_dpcd_caps;
enum dc_connection_type new_connection_type = dc_connection_none;
- enum dc_connection_type pre_connection_type = dc_connection_none;
const uint32_t post_oui_delay = 30; // 30ms
DC_LOGGER_INIT(link->ctx->logger);
@@ -923,7 +922,6 @@ static bool detect_link_and_local_sink(struct dc_link *link,
link_disconnect_sink(link);
if (new_connection_type != dc_connection_none) {
- pre_connection_type = link->type;
link->type = new_connection_type;
link->link_state_valid = false;
--
2.20.1.7.g153144c
[PATCH] drm/vmwgfx: Make the driver work without the dummy resources
From: Zack Rusin
In change 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
ttm stopped allocating dummy resources but vmwgfx was never ported to
handle it. Make the driver treat null resources as initial creation and
port code to handle null resources in general.
Fixes kernel oops'es on boot with vmwgfx.
Signed-off-by: Zack Rusin
Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO
creation")
Cc: Christian König
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 18 ++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 54e942df3b8e..71eeabf001c8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -837,7 +837,8 @@ void vmw_query_move_notify(struct ttm_buffer_object *bo,
mutex_lock(_priv->binding_mutex);
/* If BO is being moved from MOB to system memory */
- if (new_mem->mem_type == TTM_PL_SYSTEM &&
+ if (old_mem &&
+ new_mem->mem_type == TTM_PL_SYSTEM &&
old_mem->mem_type == VMW_PL_MOB) {
struct vmw_fence_obj *fence;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 4daebc5b9eb4..af8562c95cc3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -515,9 +515,13 @@ static int vmw_move(struct ttm_buffer_object *bo,
struct ttm_resource *new_mem,
struct ttm_place *hop)
{
- struct ttm_resource_manager *old_man = ttm_manager_type(bo->bdev,
bo->resource->mem_type);
- struct ttm_resource_manager *new_man = ttm_manager_type(bo->bdev,
new_mem->mem_type);
- int ret;
+ struct ttm_resource_manager *new_man;
+ struct ttm_resource_manager *old_man = NULL;
+ int ret = 0;
+
+ new_man = ttm_manager_type(bo->bdev, new_mem->mem_type);
+ if (bo->resource)
+ old_man = ttm_manager_type(bo->bdev, bo->resource->mem_type);
if (new_man->use_tt && !vmw_memtype_is_system(new_mem->mem_type)) {
ret = vmw_ttm_bind(bo->bdev, bo->ttm, new_mem);
@@ -525,9 +529,15 @@ static int vmw_move(struct ttm_buffer_object *bo,
return ret;
}
+ if (!bo->resource || (bo->resource->mem_type == TTM_PL_SYSTEM &&
+ bo->ttm == NULL)) {
+ ttm_bo_move_null(bo, new_mem);
+ return 0;
+ }
+
vmw_move_notify(bo, bo->resource, new_mem);
- if (old_man->use_tt && new_man->use_tt) {
+ if (old_man && old_man->use_tt && new_man->use_tt) {
if (vmw_memtype_is_system(bo->resource->mem_type)) {
ttm_bo_move_null(bo, new_mem);
return 0;
--
2.38.1
[PATCH] drm/amd/display: Remove the unused variable ds_port
Variable ds_port is not effectively used, so delete it.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:280:35:
warning: variable ‘ds_port’ set but not used.
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4030
Signed-off-by: Jiapeng Chong
---
.../drm/amd/display/dc/link/protocols/link_dp_capability.c| 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index 24d356ebd7a9..816bf4ff8017 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -277,7 +277,6 @@ static void dp_wa_power_up_0010FA(struct dc_link *link,
uint8_t *dpcd_data,
int length)
{
int retry = 0;
- union dp_downstream_port_present ds_port = { 0 };
if (!link->dpcd_caps.dpcd_rev.raw) {
do {
@@ -290,9 +289,6 @@ static void dp_wa_power_up_0010FA(struct dc_link *link,
uint8_t *dpcd_data,
} while (retry++ < 4 && !link->dpcd_caps.dpcd_rev.raw);
}
- ds_port.byte = dpcd_data[DP_DOWNSTREAMPORT_PRESENT -
-DP_DPCD_REV];
-
if (link->dpcd_caps.dongle_type == DISPLAY_DONGLE_DP_VGA_CONVERTER) {
switch (link->dpcd_caps.branch_dev_id) {
/* 0010FA active dongles (DP-VGA, DP-DLDVI converters) power
down
--
2.20.1.7.g153144c
Re: [git pull] drm fixes for 6.2-rc8
The pull request you sent on Fri, 10 Feb 2023 11:19:51 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-02-10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/38c1e0c65865426676123cc9a127526fa02bcac6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[RFC] drm/i915/uapi/huc: two levels of HuC authentication
Starting on DG2, the owner of HuC authentication is the GSC FW. On MTL,
with the GSC moving into the media GT and being loaded by i915, this can
result in a significant delay in HuC readiness on init/resume. To reduce
the impact, the HuC load & authentication has been split in 2 parts:
1) The HuC is loaded via DMA and authenticated by the GuC, like on older
platforms. However, this is now considered a partial authentication and
only allows clear-media workloads.
2) After the GSC FW is loaded, the HuC is re-authenticated with a PXP
command. This is a full authentication and allows all workloads.
This way, only the protected content operations are impacted by the
GSC-introduced delay, which is not an issue because GSC is required
for those anyway.
To report the different steps to userspace, a new value is introduced
for the HuC status ioctl.
RFC: I'm asking for comments ahead of the implementation to make sure
there are no concerns with the proposed interface change. I've kept
value '1' as the "full authentication" mode because that is what it
represents on older platforms. The media driver currently checks for
value != 0, which will keep working for clear-media and allow it to
start submitting without waiting for the GSC auth, while the protected
content side of things will have to adapt to explicitly check for
value == 1 (which will work on existing platforms as well).
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Alan Previn
Cc: Ankit Jain
Cc: Tony Ye
Cc: Carl Zhang
---
include/uapi/drm/i915_drm.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8df261c5ab9b..8a69014f3fd9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -659,7 +659,8 @@ typedef struct drm_i915_irq_wait {
* If the IOCTL is successful, the returned parameter will be set to one of the
* following values:
* * 0 if HuC firmware load is not complete,
- * * 1 if HuC firmware is authenticated and running.
+ * * 1 if HuC firmware is loaded and fully authenticated,
+ * * 2 if HuC firmware is loaded and authenticated for clear media only
*/
#define I915_PARAM_HUC_STATUS 42
--
2.37.3
[git pull] drm fixes for 6.2-rc8
Hi Linus, Weekly fixes, the amdgpu had a few small fixes to display flicker on certain configurations, however it was found the the flicker was lessened but there were other unintended consequences, so for now they've been reverted and replaced with an option for users to test with so future fixes can be developed. Otherwise apart from the usual bunch of i915 and amdgpu, there's a client, virtio-gpu and an nvidiafb fix that reorders its loading to avoid failure. Dave. drm-fixes-2023-02-10: drm fixes for 6.2-rc8 client: - refcount fix amdgpu: - a bunch of attempted flicker fixes that regressed turned into a user workaround option for now - Properly fix S/G display with AGP aperture enabled - Fix cursor offset with 180 rotation - SMU13 fixes - Use TGID for GPUVM traces - Fix oops on in fence error path - Don't run IB tests on hw rings when sw rings are in use - memory leak fix i915: - Display watermark fix - fbdev fix for PSR, FBC, DRRS - Move fd_install after last use of fence - Initialize the obj flags for shmem objects - Fix VBT DSI DVO port handling virtio-gpu: - fence fix nvidiafb: - regression fix for driver load when no hw supported The following changes since commit 4ec5183ec48656cec489c49f989c508b68b518e3: Linux 6.2-rc7 (2023-02-05 13:13:28 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-02-10 for you to fetch changes up to 777c1e01cb7e1947765fb0c3b9b71dab18e53e46: Merge tag 'amd-drm-fixes-6.2-2023-02-09' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-02-10 09:49:13 +1000) drm fixes for 6.2-rc8 client: - refcount fix amdgpu: - a bunch of attempted flicker fixes that regressed turned into a user workaround option for now - Properly fix S/G display with AGP aperture enabled - Fix cursor offset with 180 rotation - SMU13 fixes - Use TGID for GPUVM traces - Fix oops on in fence error path - Don't run IB tests on hw rings when sw rings are in use - memory leak fix i915: - Display watermark fix - fbdev fix for PSR, FBC, DRRS - Move fd_install after last use of fence - Initialize the obj flags for shmem objects - Fix VBT DSI DVO port handling virtio-gpu: - fence fix nvidiafb: - regression fix for driver load when no hw supported Alex Deucher (8): 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 "drm/amd/display: disable S/G display on DCN 3.1.4" drm/amdgpu: add S/G display parameter Revert "drm/amd/display: disable S/G display on DCN 3.1.2/3" Revert "drm/amd/display: disable S/G display on DCN 2.1.0" Revert "drm/amd/display: disable S/G display on DCN 3.1.5" Aravind Iddamsetty (1): drm/i915: Initialize the obj flags for shmem objects Bert Karwatzki (1): drm/amdgpu: fix memory leak in amdgpu_cs_sync_rings Christian König (1): drm/client: fix circular reference counting issue Dave Airlie (5): nvidiafb: detect the hardware support before removing console. Merge tag 'amd-drm-fixes-6.2-2023-02-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2023-02-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2023-02-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-6.2-2023-02-09' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Evan Quan (3): drm/amd/pm: add SMU 13.0.7 missing GetPptLimit message mapping drm/amd/pm: bump SMU 13.0.0 driver_if header version drm/amd/pm: bump SMU 13.0.7 driver_if header version Friedrich Vock (1): drm/amdgpu: Use the TGID for trace_amdgpu_vm_update_ptes Guilherme G. Piccoli (1): drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini Jane Jian (1): drm/amdgpu/smu: skip pptable init under sriov JesseZhang (1): amd/amdgpu: remove test ib on hw ring Jouni Högander (1): drm/i915/fbdev: Implement fb_dirty for intel custom fb helper Kenneth Feng (1): drm/amd/amdgpu: enable athub cg 11.0.3 Kent Russell (1): drm/amdgpu: Add unique_id support for GC 11.0.1/2 Melissa Wen (1): drm/amd/display: fix cursor offset on rotation 180 Rob Clark (1): drm/i915: Move fd_install after last use of fence Ryan Neph (1): drm/virtio: exbuf->fence_fd unmodified on interrupted wait Ville Syrjälä (2): drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabled drm/i915: Fix VBT DSI DVO port handling drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 11 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
Re: [Freedreno] [PATCH v3 27/27] drm/msm/dpu: add support for wide planes
Hi Dmitry
On 2/9/2023 4:09 PM, Dmitry Baryshkov wrote:
.
On Fri, 10 Feb 2023 at 00:12, Abhinav Kumar wrote:
Hi Dmitry
On 2/9/2023 1:23 PM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Thu, 9 Feb 2023 at 21:25, Abhinav Kumar wrote:
On 2/9/2023 3:45 AM, Dmitry Baryshkov wrote:
On Thu, 9 Feb 2023 at 04:19, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Typically SSPP can support rectangle with width up to 2560. However it's
Not always 2560. Depends on the chipset.
_typically_
Would just say maxlinewidth of SSPP instead of giving some hardcoded number.
Ack.
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,
>pipe);
+ _dpu_crtc_blend_setup_pipe(crtc, plane,
+mixer, cstate->num_mixers,
+stage_cfg, pstate->stage, 1,
+fetch_active,
+>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(_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;
instead of checking if sspp was present, is it not better for the caller
to check if the rpipe is valid before calling this?
+
/* 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, >pipe, >pipe_cfg,
fill_color, fmt);
+
+ _dpu_plane_color_fill_pipe(pstate, >r_pipe, >r_pipe_cfg,
fill_color, fmt);
}
So cant we do
if (pstate->r_pipe.sspp)
_dpu_plane_color_fill_pipe(pstate, >r_pipe,
>r_pipe_cfg, fill_color, fmt);
It just seems better to me as the caller would already know if the sspp
was assigned.
I think I had this kind of code earlier, but then I found it more
logical to move the check to the called function. I'll move it back.
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 = >pipe;
+ struct dpu_sw_pipe *r_pipe = >r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
+ struct dpu_hw_sspp_cfg *r_pipe_cfg = >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
[PATCH -next] drm/amd/display: clean up some inconsistent indentings
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:145 get_ddc_line() warn: inconsistent indenting drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:201 dc_link_construct_phy() warn: inconsistent indenting Reported-by: Abaci Robot Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4026 Signed-off-by: Yang Li --- drivers/gpu/drm/amd/display/dc/link/link_factory.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/link_factory.c b/drivers/gpu/drm/amd/display/dc/link/link_factory.c index 13a766273755..23f668d90460 100644 --- a/drivers/gpu/drm/amd/display/dc/link/link_factory.c +++ b/drivers/gpu/drm/amd/display/dc/link/link_factory.c @@ -142,7 +142,7 @@ static enum channel_id get_ddc_line(struct dc_link *link) struct ddc *ddc; enum channel_id channel; - channel = CHANNEL_ID_UNKNOWN; + channel = CHANNEL_ID_UNKNOWN; ddc = get_ddc_pin(link->ddc); @@ -196,8 +196,8 @@ static bool dc_link_construct_phy(struct dc_link *link, DC_LOGGER_INIT(dc_ctx->logger); - link->irq_source_hpd = DC_IRQ_SOURCE_INVALID; - link->irq_source_hpd_rx = DC_IRQ_SOURCE_INVALID; + link->irq_source_hpd = DC_IRQ_SOURCE_INVALID; + link->irq_source_hpd_rx = DC_IRQ_SOURCE_INVALID; link->link_status.dpcd_caps = >dpcd_caps; link->dc = init_params->dc; -- 2.20.1.7.g153144c
[PATCH -next] drm/amd/display: Simplify bool conversion
./drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c:1610:68-73:
WARNING: conversion to bool not needed here
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4025
Signed-off-by: Yang Li
---
.../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index 24d356ebd7a9..cb38afde3fc8 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -1607,7 +1607,7 @@ static bool retrieve_link_cap(struct dc_link *link)
dpcd_data[DP_TRAINING_AUX_RD_INTERVAL];
link->dpcd_caps.ext_receiver_cap_field_present =
-
aux_rd_interval.bits.EXT_RECEIVER_CAP_FIELD_PRESENT == 1 ? true:false;
+
aux_rd_interval.bits.EXT_RECEIVER_CAP_FIELD_PRESENT == 1;
if (aux_rd_interval.bits.EXT_RECEIVER_CAP_FIELD_PRESENT == 1) {
uint8_t ext_cap_data[16];
--
2.20.1.7.g153144c
[PATCH v4 5/8] drm/i915/pxp: Add ARB session creation and cleanup
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Also add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit which means the GSC firmware is busy and we should
resubmit.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 9 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 92 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 ++-
5 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index aecc65b5da70..c25e9ff16b57 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -353,8 +353,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ if (wait_for(intel_uc_fw_is_running(>ctrl_gt->uc.gsc.fw),
250))
+ return -ENXIO;
+ } else {
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
+ }
mutex_lock(>arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index b2523d6918c7..9089e02a8c2d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
@@ -27,4 +28,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID BIT(0)
+ #define PXP43_INIT_SESSION_APPTYPE BIT(1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_mode;
+ #define PXP43_INIT_SESSION_PROTECTION_ARB 0x2
+ u32 sub_session_id;
+ u32 init_flags;
+ u32 rsvd[12];
+} __packed;
+
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_out {
+ struct pxp_cmd_header header;
+ u32 rsvd[8];
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_43_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 51b9959f7813..42fc05582d0a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -9,6 +9,7 @@
#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_42.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
@@ -120,6 +121,97 @@ static int gsccs_send_message(struct intel_pxp *pxp,
return ret;
}
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ struct gsccs_session_resources *exec = >gsccs_res;
+ struct pxp43_create_arb_in msg_in = {0};
+ struct pxp43_create_arb_out msg_out = {0};
+ u64 gsc_session_retry = 0;
+ int ret, tries = 0;
+
+ /* get a unique host-session-handle (used later in HW cmds) at time of
session creation */
+ get_random_bytes(>host_session_handle,
sizeof(exec->host_session_handle));
+
+ msg_in.header.api_version = PXP_APIVER(4, 3);
+ msg_in.header.command_id = PXP43_CMDID_INIT_SESSION;
+ msg_in.header.stream_id = (FIELD_PREP(PXP43_INIT_SESSION_APPID,
arb_session_id) |
+ FIELD_PREP(PXP43_INIT_SESSION_VALID, 1) |
+ FIELD_PREP(PXP43_INIT_SESSION_APPTYPE, 0));
+ msg_in.header.buffer_len = sizeof(msg_in) - sizeof(msg_in.header);
+ msg_in.protection_mode = PXP43_INIT_SESSION_PROTECTION_ARB;
+
+ /*
+* Keep sending request if GSC firmware was busy.
+* Based on specs, we can expects a worst case pending-bit
+* delay of 2000 milisecs.
+*/
+ do {
+ ret = gsccs_send_message(pxp,
+_in, sizeof(msg_in),
+_out, sizeof(msg_out), NULL,
+_session_retry);
+ /*
[PATCH v4 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- On MTL, when an i915 subsystem needs to send a command request
to the security firmware, it will send that via the GSC-
engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
passes it along to the GSC firmware.
- The GSC FW on the other hand needs additional metadata to know
which usage service is being called (PXP, HDCP, proxy, etc) along
with session specific info. Thus an extra header called GSC-CS
HECI Memory Header, (C) in below diagram is prepended before
the FW specific API, (D).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers, different for
PPGGTT (this patch) vs GGTT (HDCP series) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 110
[PATCH v4 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c| 19 +++
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 3 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index c25e9ff16b57..425e552e335d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -119,6 +119,7 @@ static void destroy_vcs_context(struct intel_pxp *pxp)
static void pxp_init_full(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp->ctrl_gt;
+ intel_wakeref_t wakeref;
int ret;
/*
@@ -140,10 +141,15 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
ret = intel_pxp_gsccs_init(pxp);
- else
+ if (!ret) {
+ with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm,
wakeref)
+ intel_pxp_init_hw(pxp);
+ }
+ } else {
ret = intel_pxp_tee_component_init(pxp);
+ }
if (ret)
goto out_context;
@@ -239,15 +245,20 @@ int intel_pxp_init(struct drm_i915_private *i915)
void intel_pxp_fini(struct drm_i915_private *i915)
{
+ intel_wakeref_t wakeref;
+
if (!i915->pxp)
return;
i915->pxp->arb_is_valid = false;
- if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0)) {
+ with_intel_runtime_pm(>pxp->ctrl_gt->i915->runtime_pm,
wakeref)
+ intel_pxp_fini_hw(i915->pxp);
intel_pxp_gsccs_fini(i915->pxp);
- else
+ } else {
intel_pxp_tee_component_fini(i915->pxp);
+ }
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
* The PXP component gets automatically unbound when we go into S3 and
* re-bound after we come out, so in that scenario we can defer the
* hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
*/
- if (!pxp->pxp_component)
+ if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
intel_pxp_init_hw(pxp);
--
2.39.0
[PATCH v4 6/8] drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for uncore when touching
IRQ registers despite the pxp->ctrl_gt being the media-tile.
No difference for legacy of course.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 24 +---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..9f6e300486b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
if (!intel_pxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..3a725397349f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -4,10 +4,12 @@
*/
#include
+#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
+#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -17,6 +19,22 @@
#include "intel_pxp_types.h"
#include "intel_runtime_pm.h"
+/**
+ * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
+ * @pxp: pointer to pxp struct
+ *
+ * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
+ * but for MTL+ that has a media-tile, although the KCR engine is in the
+ * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
+ * In the end, we don't use pxp->ctrl_gt for IRQ, we always return root gt.
+ */
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ WARN_ON_ONCE(!pxp->ctrl_gt->i915->media_gt &&
!gt_is_root(pxp->ctrl_gt));
+
+ return to_gt(pxp->ctrl_gt->i915);
+}
+
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
* @pxp: pointer to pxp struct
@@ -29,7 +47,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
return;
- gt = pxp->ctrl_gt;
+ gt = intel_pxp_get_irq_gt(pxp);
lockdep_assert_held(gt->irq_lock);
@@ -68,7 +86,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
void intel_pxp_irq_enable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
spin_lock_irq(gt->irq_lock);
@@ -83,7 +101,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
/*
* We always need to submit a global termination when we re-enable the
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8c292dc86f68..eea87c9eb62b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -9,6 +9,7 @@
#include
struct intel_pxp;
+struct intel_gt;
#define GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT BIT(1)
#define GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT BIT(2)
@@ -23,6 +24,8 @@ struct intel_pxp;
void intel_pxp_irq_enable(struct intel_pxp *pxp);
void intel_pxp_irq_disable(struct intel_pxp *pxp);
void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp);
+
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -35,6 +38,11 @@ static inline void intel_pxp_irq_enable(struct intel_pxp
*pxp)
static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
}
+
+static inline struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ return NULL;
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
--
2.39.0
[PATCH v4 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priveleged batches for submission to GSC engine
and require two buffers for the request:
- a buffer for the HECI packet that contains PXP FW commands
- a batch-buffer that contains the engine instruction for
sending the HECI packet to the GSC firmware.
Thus, add the allocation and freeing of these buffers in gsccs
init and fini.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 223 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 7 +
3 files changed, 232 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..b2523d6918c7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,10 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
+#define PXP43_MAX_HECI_OUT_SIZE (SZ_32K)
+
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 13693e78b57e..51b9959f7813 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,19 +6,210 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
+static int gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec = >gsccs_res;
+ struct intel_gsc_mtl_header *header = exec->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!exec->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_IN_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ mutex_lock(>tee_mutex);
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, GSC_HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec->host_session_handle);
+
+ /* check if this is a host-session-handle cleanup call */
+ if (!msg_in && !msg_out)
+ header->flags |= GSC_HECI_FLAG_MSG_CLEANUP;
+
+ /* copy caller provided gsc message handle if this is polling for a
prior msg completion */
+ header->gsc_message_handle = *gsc_msg_handle_retry;
+
+ /* NOTE: zero size packets are used for session-cleanups */
+ if (msg_in && msg_in_size)
+ memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
+
+ pkt.addr_in = i915_vma_offset(exec->pkt_vma);
+ pkt.size_in = header->message_size;
+ pkt.addr_out = pkt.addr_in + PXP43_MAX_HECI_IN_SIZE;
+ pkt.size_out = msg_out_size_max + sizeof(*header);
+ pkt.heci_pkt_vma = exec->pkt_vma;
+ pkt.bb_vma = exec->bb_vma;
+
+ ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>uc.gsc,
+ exec->ce, ,
exec->bb_vaddr, 500);
+ if (ret) {
+ drm_err(>drm, "failed to send gsc PXP msg (%d)\n", ret);
+ goto unlock;
+ }
+
+ /* we keep separate location for reply, so get the response header loc
first */
+ header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
+
+ /* Response validity marker, status and busyness */
+ if (header->validity_marker != GSC_HECI_VALIDITY_MARKER) {
+ drm_err(>drm, "gsc PXP reply with invalid validity
marker\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->status != 0) {
+ drm_dbg(>drm, "gsc PXP reply status has error = 0x%08x\n",
+ header->status);
+ ret =
[PATCH v4 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the timeouts for new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a8d942b16223..4ecf0f2ab6ec 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1150,6 +1150,7 @@ static const struct intel_device_info mtl_info = {
.has_guc_deprivilege = 1,
.has_mslice_steering = 0,
.has_snoop = 1,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 4ddf2ee60222..03f006f9dc2e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
KCR_SIP(pxp->kcr_base),
mask,
in_play ? mask : 0,
- 100);
+ 250);
intel_runtime_pm_put(uncore->rpm, wakeref);
--
2.39.0
[PATCH v4 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 32
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6
5 files changed, 58 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 1b25a6039152..c360776a98b5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -100,7 +100,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 560d94d23114..aecc65b5da70 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
+ if (pxp->ctrl_gt->type == GT_MEDIA)
+ pxp->kcr_base = MTL_KCR_BASE;
+ else
+ pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
ret = create_vcs_context(pxp);
@@ -368,14 +375,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define KCR_GLOBAL_TERMINATE(base)
[PATCH v4 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.
Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 19 +--
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 61 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 2 -
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 7 +++
6 files changed, 113 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 918470a04591..ec2f7d4ed638 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -332,6 +332,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..560d94d23114 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -165,9 +169,11 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
/*
* For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC firmware is coming online
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+ intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw))
return i915->media_gt;
/*
@@ -207,7 +213,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
+ /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+ mutex_init(>pxp->tee_mutex);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +237,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..13693e78b57e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+ struct gsccs_session_resources *strm_res = >gsccs_res;
+
+ if (strm_res->ce)
+ intel_context_put(strm_res->ce);
+
+ memset(strm_res, 0, sizeof(*strm_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct gsccs_session_resources *strm_res =
[PATCH v4 0/8] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #3. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #5. Take note that Patch #4 adds the buffer allocation and gsccs-send- message without actually being called by the arb-creation code which gets added in Patch #5. Additionally, a seperate series being reviewed is introducing a change for session teardown (in pxp front- end layer that will need backend support by both legacy and gsccs). If we squash all of these together (buffer-alloc, send-message, arb-creation and, in future, session-termination), the single patch will be rather large. That said, we are keeping Patch #4 and #5 separate for now, but at merge time, we can squash them together if maintainer requires it. Changes from prior revs: v1 : - fixed when building with CONFIG_PXP disabled. - more alignment with gsc_mtl_header structure from the HDCP v2 : - (all following changes as per reviews from Daniele) - squashed Patch #1 from v1 into the next one. - replaced unnecessary "uses_gsccs" boolean in the pxp with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". - moved the stashing of gsccs resources from a dynamically allocated opaque handle to an explicit sub-struct in 'struct intel_pxp'. - moved the buffer object allocations from Patch #1 of this series to Patch #5 (but keep the context allocation in Patch #1). - used the kernel default ppgtt for the gsccs context. - optimized the buffer allocation and deallocation code and drop the need to stash the drm_i915_gem_object. - use a macro with the right mmio reg base (depending on root-tile vs media-tile) along with common relative offset to access all KCR registers thus minimizing changes to the KCR register access codes. - fixed bugs in the heci packet request submission code in Patch #3 (of this series) - add comments in the mtl-gsc-heci-header regarding the host-session-handle. - re-use tee-mutex instead of introducing a gsccs specific cmd mutex. - minor cosmetic improvements in Patch #5. - before creating arb session, ensure intel_pxp_start first ensures the GSC FW is up and running. - use 2 second timeout for the pending-bit scenario when sending command to GSC-FW as per specs. - simplify intel_pxp_get_irq_gt with addition comments - redo Patch #7 to minimize the changes without introducing a common abstraction helper for suspend/resume/init/fini codes that have to change the kcr power state. v3 : - rebase onto latest drm-tip with the updated firmware session invalidation flow - on Patch#1: move 'mutex_init(>tee_mutex)' to a common init place in intel_pxp_init since its needed everywhere (Daniele) - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" (Daniele) - on Patch#2: move the introduction of host_session_handle to Patch#4 where it starts getting used. - on Patch#4: move host-session-handle initialization to the allocate-resources during gsccs-init (away from Patch#5) and add the required call to PXP-firmware to cleanup the host-session-handle in destroy-resources during gsccs-fini - on Patch#5: add dispatching of arb session termination firmware cmd during session teardown (as per latest upstream flows) Alan Previn (8): drm/i915/pxp: Add GSC-CS back-end resource init and cleanup drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC drm/i915/pxp: Add GSC-CS backend to send GSC fw messages drm/i915/pxp: Add ARB session creation and cleanup drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component drm/i915/pxp: Enable PXP with MTL-GSC-CS drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 3 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |
Re: [PATCH v3] drm/ast: Fix start address computation
On 2023/2/9 下午 05:55, Thomas Zimmermann wrote:
Am 09.02.23 um 10:44 schrieb Jocelyn Falempe:
During the driver conversion to shmem, the start address for the
scanout buffer was set to the base PCI address.
In most cases it works because only the lower 24bits are used, and
due to alignment it was almost always 0.
But on some unlucky hardware, it's not the case, and some unitilized
'uninitialized'
memory is displayed on the BMC.
With shmem, the primary plane is always at offset 0 in GPU memory.
* v2: rewrite the patch to set the offset to 0. (Thomas Zimmermann)
* v3: move the change to plane_init() and also fix the cursor plane.
(Jammy Huang)
Tested on a sr645 affected by this bug.
Fixes: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
Reviewed-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c
b/drivers/gpu/drm/ast/ast_mode.c
index c7443317c747..66a4a41c3fe9 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -714,7 +714,7 @@ static int ast_primary_plane_init(struct
ast_private *ast)
struct ast_plane *ast_primary_plane = >primary_plane;
struct drm_plane *primary_plane = _primary_plane->base;
void __iomem *vaddr = ast->vram;
- u64 offset = ast->vram_base;
+ u64 offset = 0; /* with shmem, the primary plane is always at
offset 0 */
unsigned long cursor_size = roundup(AST_HWC_SIZE +
AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
unsigned long size = ast->vram_fb_available - cursor_size;
int ret;
@@ -972,7 +972,7 @@ static int ast_cursor_plane_init(struct
ast_private *ast)
return -ENOMEM;
vaddr = ast->vram + ast->vram_fb_available - size;
- offset = ast->vram_base + ast->vram_fb_available - size;
+ offset = ast->vram_fb_available - size;
ret = ast_plane_init(dev, ast_cursor_plane, vaddr, offset, size,
0x01, _cursor_plane_funcs,
--
Best Regards
Jammy
Re: [Freedreno] [PATCH v3 27/27] drm/msm/dpu: add support for wide planes
.
On Fri, 10 Feb 2023 at 00:12, Abhinav Kumar wrote:
>
> Hi Dmitry
>
> On 2/9/2023 1:23 PM, Dmitry Baryshkov wrote:
> > Hi Abhinav,
> >
> > On Thu, 9 Feb 2023 at 21:25, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/9/2023 3:45 AM, Dmitry Baryshkov wrote:
> >>> On Thu, 9 Feb 2023 at 04:19, Abhinav Kumar
> >>> wrote:
>
>
>
> On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
> > Typically SSPP can support rectangle with width up to 2560. However it's
>
> Not always 2560. Depends on the chipset.
> >>>
> >>> _typically_
> >>>
> >>
> >> Would just say maxlinewidth of SSPP instead of giving some hardcoded
> >> number.
> >
> > Ack.
> >
> >>
>
> > 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,
> >>pipe);
> >
> > + _dpu_crtc_blend_setup_pipe(crtc, plane,
> > +mixer, cstate->num_mixers,
> > +stage_cfg, pstate->stage, 1,
> > +fetch_active,
> > +>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(_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;
>
> instead of checking if sspp was present, is it not better for the caller
> to check if the rpipe is valid before calling this?
>
> > +
> > /* 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, >pipe,
> > >pipe_cfg, fill_color, fmt);
> > +
> > + _dpu_plane_color_fill_pipe(pstate, >r_pipe,
> > >r_pipe_cfg, fill_color, fmt);
> > }
>
> So cant we do
>
> if (pstate->r_pipe.sspp)
> _dpu_plane_color_fill_pipe(pstate, >r_pipe,
> >r_pipe_cfg, fill_color, fmt);
>
> It just seems better to me as the caller would already know if the sspp
> was assigned.
> >>>
> >>>I think I had this kind of code earlier, but then I found it more
> >>> logical to move the check to the called function. I'll move it back.
> >>>
>
> >
> > 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
Re: linux-next: duplicate patch in the drm-misc-fixes tree
On Fri, Feb 10, 2023 at 9:47 AM Stephen Rothwell wrote:
>
> Hi all,
>
> The following commit is also in the drm-fixes tree as a different commit
> (but the same patch):
>
> 94d8b6572a1f ("nvidiafb: detect the hardware support before removing
> console.")
>
> This is commit
>
> 04119ab1a49f ("nvidiafb: detect the hardware support before removing
> console.")
>
> in the drm-fixes tree.
Just FYI misc team, I've force pushed drm-misc-fixes to drop this
patch, please make sure any local misc fixes don't bring it back in if
we can avoid it.
Dave.
linux-next: duplicate patch in the drm-misc-fixes tree
Hi all,
The following commit is also in the drm-fixes tree as a different commit
(but the same patch):
94d8b6572a1f ("nvidiafb: detect the hardware support before removing
console.")
This is commit
04119ab1a49f ("nvidiafb: detect the hardware support before removing
console.")
in the drm-fixes tree.
--
Cheers,
Stephen Rothwell
pgprtHhPEVMrj.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
missed somethings on host-session-handle - for next rev.
On Wed, 2023-01-25 at 00:06 -0800, Teres Alexis, Alan Previn wrote:
> Add GSC engine based method for sending PXP firmware packets
> to the GSC firmware for MTL (and future) products.
>
> Use the newly added helpers to populate the GSC-CS memory
> header and send the message packet to the FW by dispatching
> the GSC_HECI_CMD_PKT instruction on the GSC engine.
>
> We use non-priveleged batches for submission to GSC engine
> and require two buffers for the request:
> - a buffer for the HECI packet that contains PXP FW commands
> - a batch-buffer that contains the engine instruction for
>sending the HECI packet to the GSC firmware.
>
> Thus, add the allocation and freeing of these buffers in gsccs
> init and fini.
>
> Signed-off-by: Alan Previn
> ---
> .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 +
> drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 174 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 +
> 3 files changed, 183 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> index ad67e3f49c20..b2523d6918c7 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
> @@ -12,6 +12,10 @@
> /* PXP-Cmd-Op definitions */
> #define PXP43_CMDID_START_HUC_AUTH 0x003A
>
> +/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
> +#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
> +#define PXP43_MAX_HECI_OUT_SIZE (SZ_32K)
> +
> /* PXP-Input-Packet: HUC-Authentication */
> struct pxp43_start_huc_auth_in {
> struct pxp_cmd_header header;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
> index b304864902c8..35b6bfa55dfc 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
> @@ -6,12 +6,154 @@
> #include "gem/i915_gem_internal.h"
>
> #include "gt/intel_context.h"
> +#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
>
> #include "i915_drv.h"
> #include "intel_pxp_cmd_interface_43.h"
> #include "intel_pxp_gsccs.h"
> #include "intel_pxp_types.h"
>
>
alan:snip
> static void
> gsccs_destroy_execution_resource(struct intel_pxp *pxp)
> {
> @@ -19,6 +161,10 @@ gsccs_destroy_execution_resource(struct intel_pxp *pxp)
>
we should send a message to firmware to cleanup all resources associated with
i915's host-session-handle here
>
> if (strm_res->ce)
> intel_context_put(strm_res->ce);
> + if (strm_res->bb_vma)
> + i915_vma_unpin_and_release(_res->bb_vma,
> I915_VMA_RELEASE_MAP);
> + if (strm_res->pkt_vma)
> + i915_vma_unpin_and_release(_res->pkt_vma,
> I915_VMA_RELEASE_MAP);
>
> memset(strm_res, 0, sizeof(*strm_res));
> }
>
alan:snip
>* First, ensure the GSC engine is present.
> @@ -40,11 +187,28 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
>
> mutex_init(>tee_mutex);
>
> + /*
> + * Now, allocate, pin and map two objects, one for the heci message
> packet
> + * and another for the batch buffer we submit into GSC engine (that
> includes the packet).
> + * NOTE: GSC-CS backend is currently only supported on MTL, so we
> allocate shmem.
> + */
> + err = gsccs_create_buffer(pxp->ctrl_gt, "Heci Packet",
> + PXP43_MAX_HECI_IN_SIZE +
> PXP43_MAX_HECI_OUT_SIZE,
> + _res->pkt_vma, _res->pkt_vaddr);
> + if (err)
> + return err;
> +
> + err = gsccs_create_buffer(pxp->ctrl_gt, "Batch Buffer", PAGE_SIZE,
> + _res->bb_vma, _res->bb_vaddr);
> + if (err)
> + goto free_pkt;
> +
> /* Finally, create an intel_context to be used during the submission */
> ce = intel_context_create(engine);
> if (IS_ERR(ce)) {
> drm_err(>i915->drm, "Failed creating gsccs backend ctx\n");
> - return PTR_ERR(ce);
> + err = PTR_ERR(ce);
> + goto free_batch;
> }
> i915_vm_put(ce->vm);
> ce->vm = i915_vm_get(pxp->ctrl_gt->vm);
> @@ -52,6 +216,14 @@ gsccs_allocate_execution_resource(struct intel_pxp *pxp)
> strm_res->ce = ce;
we should be allocatting the host-session-handle here
(the same one should be used throughout i915 life-cycle until unload)
so we can remove that from the arb-session-creation on next patch
alan:snip
Re: [RFC PATCH v2 1/4] drm/msm/dpu: Move TE setup to prepare_for_kickoff()
On Fri, 10 Feb 2023 at 00:31, Jessica Zhang wrote:
>
>
>
> On 2/9/2023 10:51 AM, Dmitry Baryshkov wrote:
> > On 09/02/2023 20:44, Jessica Zhang wrote:
> >> Currently, DPU will enable TE during prepare_commit(). However, this
> >> will cause issues when trying to read/write to register in
> >> get_autorefresh_config(), because the core clock rates aren't set at
> >> that time.
> >>
> >> This used to work because phys_enc->hw_pp is only initialized in mode
> >> set [1], so the first prepare_commit() will return before any register
> >> read/write as hw_pp would be NULL.
> >>
> >> However, when we try to implement support for INTF TE, we will run into
> >> the clock issue described above as hw_intf will *not* be NULL on the
> >> first prepare_commit(). This is because the initialization of
> >> dpu_enc->hw_intf has been moved to dpu_encoder_setup() [2].
> >>
> >> To avoid this issue, let's enable TE during prepare_for_kickoff()
> >> instead as the core clock rates are guaranteed to be set then.
> >>
> >> Depends on: "Implement tearcheck support on INTF block" [3]
> >>
> >> [1]
> >> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L1109
> >> [2]
> >> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L2339
> >> [3] https://patchwork.freedesktop.org/series/112332/
> >>
> >> Signed-off-by: Jessica Zhang
> >> ---
> >> .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 78 ++-
> >> 1 file changed, 43 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> >> index cb05036f2916..561406d92a1a 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> >> @@ -583,39 +583,6 @@ static void dpu_encoder_phys_cmd_destroy(struct
> >> dpu_encoder_phys *phys_enc)
> >> kfree(cmd_enc);
> >> }
> >> -static void dpu_encoder_phys_cmd_prepare_for_kickoff(
> >> -struct dpu_encoder_phys *phys_enc)
> >> -{
> >> -struct dpu_encoder_phys_cmd *cmd_enc =
> >> -to_dpu_encoder_phys_cmd(phys_enc);
> >> -int ret;
> >> -
> >> -if (!phys_enc->hw_pp) {
> >> -DPU_ERROR("invalid encoder\n");
> >> -return;
> >> -}
> >> -DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n",
> >> DRMID(phys_enc->parent),
> >> - phys_enc->hw_pp->idx - PINGPONG_0,
> >> - atomic_read(_enc->pending_kickoff_cnt));
> >> -
> >> -/*
> >> - * Mark kickoff request as outstanding. If there are more than one,
> >> - * outstanding, then we have to wait for the previous one to
> >> complete
> >> - */
> >> -ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
> >> -if (ret) {
> >> -/* force pending_kickoff_cnt 0 to discard failed kickoff */
> >> -atomic_set(_enc->pending_kickoff_cnt, 0);
> >> -DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
> >> - DRMID(phys_enc->parent), ret,
> >> - phys_enc->hw_pp->idx - PINGPONG_0);
> >> -}
> >> -
> >> -DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
> >> -phys_enc->hw_pp->idx - PINGPONG_0,
> >> -atomic_read(_enc->pending_kickoff_cnt));
> >> -}
> >> -
> >> static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
> >> struct dpu_encoder_phys *phys_enc)
> >> {
> >> @@ -641,8 +608,7 @@ static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
> >> return false;
> >> }
> >> -static void dpu_encoder_phys_cmd_prepare_commit(
> >> -struct dpu_encoder_phys *phys_enc)
> >> +static void dpu_encoder_phys_cmd_enable_te(struct dpu_encoder_phys
> >> *phys_enc)
> >> {
> >> struct dpu_encoder_phys_cmd *cmd_enc =
> >> to_dpu_encoder_phys_cmd(phys_enc);
> >> @@ -700,6 +666,48 @@ static void dpu_encoder_phys_cmd_prepare_commit(
> >>"disabled autorefresh\n");
> >> }
> >> +static void dpu_encoder_phys_cmd_prepare_for_kickoff(
> >> +struct dpu_encoder_phys *phys_enc)
> >> +{
> >> +struct dpu_encoder_phys_cmd *cmd_enc =
> >> +to_dpu_encoder_phys_cmd(phys_enc);
> >> +int ret;
> >> +
> >> +if (!phys_enc->hw_pp) {
> >> +DPU_ERROR("invalid encoder\n");
> >> +return;
> >> +}
> >> +
> >> +
> >> +DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n",
> >> DRMID(phys_enc->parent),
> >> + phys_enc->hw_pp->idx - PINGPONG_0,
> >> + atomic_read(_enc->pending_kickoff_cnt));
> >> +
> >> +/*
> >> + * Mark kickoff request as outstanding. If there are more than one,
> >> + * outstanding, then we have to wait for the previous one to
> >> complete
> >> + */
> >> +ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
> >> +if (ret) {
> >> +/* force pending_kickoff_cnt 0 to discard failed kickoff */
> >> +
Re: [RFC PATCH v2 3/4] drm/msm/dpu: Remove empty prepare_commit() function
On 2/9/2023 10:51 AM, Dmitry Baryshkov wrote:
On 09/02/2023 20:44, Jessica Zhang wrote:
Now that the TE setup has been moved to prepare_for_kickoff(),
move empty prepare_commit() from DPU driver.
s/move/remove/
Also the DPU's prepare_commit() is not empty. Please mention
dpu_encoder_prepare_commit() becoming (or being) empty.
Hi Dmitry,
Acked.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 7 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 ---
4 files changed, 53 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index dcceed91aed8..35e120b5ef53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2090,25 +2090,6 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc)
-{
- struct dpu_encoder_virt *dpu_enc;
- struct dpu_encoder_phys *phys;
- int i;
-
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- dpu_enc = to_dpu_encoder_virt(drm_enc);
-
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- phys = dpu_enc->phys_encs[i];
- if (phys->ops.prepare_commit)
- phys->ops.prepare_commit(phys);
- }
-}
-
#ifdef CONFIG_DEBUG_FS
static int _dpu_encoder_status_show(struct seq_file *s, void *data)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9e7236ef34e6..2c9ef8d1b877 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -146,13 +146,6 @@ struct drm_encoder *dpu_encoder_init(
int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
struct msm_display_info *disp_info);
-/**
- * dpu_encoder_prepare_commit - prepare encoder at the very beginning
of an
- * atomic commit, before any registers are written
- * @drm_enc: Pointer to previously created drm encoder structure
- */
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc);
-
/**
* dpu_encoder_set_idle_timeout - set the idle timeout for video
* and command mode encoders.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 561406d92a1a..4c189b9fa9b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -703,11 +703,6 @@ static void
dpu_encoder_phys_cmd_prepare_for_kickoff(
atomic_read(_enc->pending_kickoff_cnt));
}
-static void dpu_encoder_phys_cmd_prepare_commit(
- struct dpu_encoder_phys *phys_enc)
-{
-}
-
static int _dpu_encoder_phys_cmd_wait_for_ctl_start(
struct dpu_encoder_phys *phys_enc)
{
@@ -807,7 +802,6 @@ static void dpu_encoder_phys_cmd_trigger_start(
static void dpu_encoder_phys_cmd_init_ops(
struct dpu_encoder_phys_ops *ops)
{
- ops->prepare_commit = dpu_encoder_phys_cmd_prepare_commit;
Also please don't forget to remove prepare_commit from
dpu_encoder_phys_ops.
Acked.
Thanks,
Jessica Zhang
ops->is_master = dpu_encoder_phys_cmd_is_master;
ops->atomic_mode_set = dpu_encoder_phys_cmd_atomic_mode_set;
ops->enable = dpu_encoder_phys_cmd_enable;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 165958d47ec6..6f7ddbf0d9b7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -425,26 +425,6 @@ static ktime_t dpu_kms_vsync_time(struct msm_kms
*kms, struct drm_crtc *crtc)
return ktime_get();
}
-static void dpu_kms_prepare_commit(struct msm_kms *kms,
- struct drm_atomic_state *state)
-{
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
- struct drm_encoder *encoder;
- int i;
-
- if (!kms)
- return;
-
- /* Call prepare_commit for all affected encoders */
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- drm_for_each_encoder_mask(encoder, crtc->dev,
- crtc_state->encoder_mask) {
- dpu_encoder_prepare_commit(encoder);
- }
- }
-}
-
static void dpu_kms_flush_commit(struct msm_kms *kms, unsigned
crtc_mask)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -949,7 +929,6 @@ static const struct msm_kms_funcs kms_funcs = {
.enable_commit = dpu_kms_enable_commit,
.disable_commit = dpu_kms_disable_commit,
.vsync_time = dpu_kms_vsync_time,
- .prepare_commit = dpu_kms_prepare_commit,
.flush_commit = dpu_kms_flush_commit,
.wait_flush =
Re: [RFC PATCH v2 1/4] drm/msm/dpu: Move TE setup to prepare_for_kickoff()
On 2/9/2023 10:51 AM, Dmitry Baryshkov wrote:
On 09/02/2023 20:44, Jessica Zhang wrote:
Currently, DPU will enable TE during prepare_commit(). However, this
will cause issues when trying to read/write to register in
get_autorefresh_config(), because the core clock rates aren't set at
that time.
This used to work because phys_enc->hw_pp is only initialized in mode
set [1], so the first prepare_commit() will return before any register
read/write as hw_pp would be NULL.
However, when we try to implement support for INTF TE, we will run into
the clock issue described above as hw_intf will *not* be NULL on the
first prepare_commit(). This is because the initialization of
dpu_enc->hw_intf has been moved to dpu_encoder_setup() [2].
To avoid this issue, let's enable TE during prepare_for_kickoff()
instead as the core clock rates are guaranteed to be set then.
Depends on: "Implement tearcheck support on INTF block" [3]
[1]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L1109
[2]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L2339
[3] https://patchwork.freedesktop.org/series/112332/
Signed-off-by: Jessica Zhang
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 78 ++-
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index cb05036f2916..561406d92a1a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -583,39 +583,6 @@ static void dpu_encoder_phys_cmd_destroy(struct
dpu_encoder_phys *phys_enc)
kfree(cmd_enc);
}
-static void dpu_encoder_phys_cmd_prepare_for_kickoff(
- struct dpu_encoder_phys *phys_enc)
-{
- struct dpu_encoder_phys_cmd *cmd_enc =
- to_dpu_encoder_phys_cmd(phys_enc);
- int ret;
-
- if (!phys_enc->hw_pp) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n",
DRMID(phys_enc->parent),
- phys_enc->hw_pp->idx - PINGPONG_0,
- atomic_read(_enc->pending_kickoff_cnt));
-
- /*
- * Mark kickoff request as outstanding. If there are more than one,
- * outstanding, then we have to wait for the previous one to
complete
- */
- ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
- if (ret) {
- /* force pending_kickoff_cnt 0 to discard failed kickoff */
- atomic_set(_enc->pending_kickoff_cnt, 0);
- DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
- DRMID(phys_enc->parent), ret,
- phys_enc->hw_pp->idx - PINGPONG_0);
- }
-
- DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
- phys_enc->hw_pp->idx - PINGPONG_0,
- atomic_read(_enc->pending_kickoff_cnt));
-}
-
static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
struct dpu_encoder_phys *phys_enc)
{
@@ -641,8 +608,7 @@ static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
return false;
}
-static void dpu_encoder_phys_cmd_prepare_commit(
- struct dpu_encoder_phys *phys_enc)
+static void dpu_encoder_phys_cmd_enable_te(struct dpu_encoder_phys
*phys_enc)
{
struct dpu_encoder_phys_cmd *cmd_enc =
to_dpu_encoder_phys_cmd(phys_enc);
@@ -700,6 +666,48 @@ static void dpu_encoder_phys_cmd_prepare_commit(
"disabled autorefresh\n");
}
+static void dpu_encoder_phys_cmd_prepare_for_kickoff(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_encoder_phys_cmd *cmd_enc =
+ to_dpu_encoder_phys_cmd(phys_enc);
+ int ret;
+
+ if (!phys_enc->hw_pp) {
+ DPU_ERROR("invalid encoder\n");
+ return;
+ }
+
+
+ DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n",
DRMID(phys_enc->parent),
+ phys_enc->hw_pp->idx - PINGPONG_0,
+ atomic_read(_enc->pending_kickoff_cnt));
+
+ /*
+ * Mark kickoff request as outstanding. If there are more than one,
+ * outstanding, then we have to wait for the previous one to
complete
+ */
+ ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
+ if (ret) {
+ /* force pending_kickoff_cnt 0 to discard failed kickoff */
+ atomic_set(_enc->pending_kickoff_cnt, 0);
+ DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
+ DRMID(phys_enc->parent), ret,
+ phys_enc->hw_pp->idx - PINGPONG_0);
+ }
+
+ dpu_encoder_phys_cmd_enable_te(phys_enc);
+
+ DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
+ phys_enc->hw_pp->idx - PINGPONG_0,
+ atomic_read(_enc->pending_kickoff_cnt));
+}
Quoting v1:
Could you please move the function back to the place, so that we can see
the actual difference?
Hi Dmitry,
Sorry if I missed your reply to my reply in V1, but as stated in the V1
patch: the reason the
Re: [Freedreno] [PATCH v3 27/27] drm/msm/dpu: add support for wide planes
Hi Dmitry
On 2/9/2023 1:23 PM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Thu, 9 Feb 2023 at 21:25, Abhinav Kumar wrote:
On 2/9/2023 3:45 AM, Dmitry Baryshkov wrote:
On Thu, 9 Feb 2023 at 04:19, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Typically SSPP can support rectangle with width up to 2560. However it's
Not always 2560. Depends on the chipset.
_typically_
Would just say maxlinewidth of SSPP instead of giving some hardcoded number.
Ack.
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,
>pipe);
+ _dpu_crtc_blend_setup_pipe(crtc, plane,
+mixer, cstate->num_mixers,
+stage_cfg, pstate->stage, 1,
+fetch_active,
+>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(_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;
instead of checking if sspp was present, is it not better for the caller
to check if the rpipe is valid before calling this?
+
/* 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, >pipe, >pipe_cfg,
fill_color, fmt);
+
+ _dpu_plane_color_fill_pipe(pstate, >r_pipe, >r_pipe_cfg,
fill_color, fmt);
}
So cant we do
if (pstate->r_pipe.sspp)
_dpu_plane_color_fill_pipe(pstate, >r_pipe,
>r_pipe_cfg, fill_color, fmt);
It just seems better to me as the caller would already know if the sspp
was assigned.
I think I had this kind of code earlier, but then I found it more
logical to move the check to the called function. I'll move it back.
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 = >pipe;
+ struct dpu_sw_pipe *r_pipe = >r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
+ struct dpu_hw_sspp_cfg *r_pipe_cfg = >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 =
[Cc: drm-misc folks] Re: [Intel-gfx] [CI 1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
On Tue, 2023-02-07 at 14:59 +0200, Imre Deak wrote:
> Hi all,
>
> On Mon, Feb 06, 2023 at 01:48:53PM +0200, Imre Deak wrote:
> > Add the MST topology for a CRTC to the atomic state if the driver
> > needs to force a modeset on the CRTC after the encoder compute config
> > functions are called.
> >
> > Later the MST encoder's disable hook also adds the state, but that isn't
> > guaranteed to work (since in that hook getting the state may fail, which
> > can't be handled there). This should fix that, while a later patch fixes
> > the use of the MST state in the disable hook.
> >
> > v2: Add missing forward struct declartions, caught by hdrtest.
> > v3: Factor out intel_dp_mst_add_topology_state_for_connector() used
> > later in the patchset.
> >
> > Cc: Lyude Paul
> > Cc: Ville Syrjälä
> > Cc: sta...@vger.kernel.org # 6.1
> > Reviewed-by: Ville Syrjälä # v2
> > Reviewed-by: Lyude Paul
> > Signed-off-by: Imre Deak
>
> Is it ok to merge these 4 patches (also at [1]), via the i915 tree?
>
> If so could it be also acked from the AMD and Nouveau side?
Whichever branch works best for y'all is fine by me, if it's via i915's tree I
guess we might need to back-merge drm-misc at some point so I can write up
equivalent fixes for nouveau as well.
(Added Thomas Zimmermann to Cc)
>
> [1] https://patchwork.freedesktop.org/series/113703/
>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 4 ++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 61
> > drivers/gpu/drm/i915/display/intel_dp_mst.h | 4 ++
> > 3 files changed, 69 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 12ade593c..38106cf63b3b9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5936,6 +5936,10 @@ int intel_modeset_all_pipes(struct
> > intel_atomic_state *state,
> > if (ret)
> > return ret;
> >
> > + ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc);
> > + if (ret)
> > + return ret;
> > +
> > ret = intel_atomic_add_affected_planes(state, crtc);
> > if (ret)
> > return ret;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 8b0e4defa3f10..f3cb12dcfe0a7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -1223,3 +1223,64 @@ bool intel_dp_mst_is_slave_trans(const struct
> > intel_crtc_state *crtc_state)
> > return crtc_state->mst_master_transcoder != INVALID_TRANSCODER &&
> >crtc_state->mst_master_transcoder != crtc_state->cpu_transcoder;
> > }
> > +
> > +/**
> > + * intel_dp_mst_add_topology_state_for_connector - add MST topology state
> > for a connector
> > + * @state: atomic state
> > + * @connector: connector to add the state for
> > + * @crtc: the CRTC @connector is attached to
> > + *
> > + * Add the MST topology state for @connector to @state.
> > + *
> > + * Returns 0 on success, negative error code on failure.
> > + */
> > +static int
> > +intel_dp_mst_add_topology_state_for_connector(struct intel_atomic_state
> > *state,
> > + struct intel_connector *connector,
> > + struct intel_crtc *crtc)
> > +{
> > + struct drm_dp_mst_topology_state *mst_state;
> > +
> > + if (!connector->mst_port)
> > + return 0;
> > +
> > + mst_state = drm_atomic_get_mst_topology_state(>base,
> > +
> > >mst_port->mst_mgr);
> > + if (IS_ERR(mst_state))
> > + return PTR_ERR(mst_state);
> > +
> > + mst_state->pending_crtc_mask |= drm_crtc_mask(>base);
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * intel_dp_mst_add_topology_state_for_crtc - add MST topology state for a
> > CRTC
> > + * @state: atomic state
> > + * @crtc: CRTC to add the state for
> > + *
> > + * Add the MST topology state for @crtc to @state.
> > + *
> > + * Returns 0 on success, negative error code on failure.
> > + */
> > +int intel_dp_mst_add_topology_state_for_crtc(struct intel_atomic_state
> > *state,
> > +struct intel_crtc *crtc)
> > +{
> > + struct drm_connector *_connector;
> > + struct drm_connector_state *conn_state;
> > + int i;
> > +
> > + for_each_new_connector_in_state(>base, _connector, conn_state,
> > i) {
> > + struct intel_connector *connector =
> > to_intel_connector(_connector);
> > + int ret;
> > +
> > + if (conn_state->crtc != >base)
> > + continue;
> > +
> > + ret = intel_dp_mst_add_topology_state_for_connector(state,
> > connector, crtc);
> > + if (ret)
> > + return ret;
> > + }
>
Re: [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Wed, 2023-02-08 at 09:41 +0200, Imre Deak wrote: > On Tue, Feb 07, 2023 at 07:21:48PM -0500, Lyude Paul wrote: > > On Tue, 2023-02-07 at 14:11 +0200, Imre Deak wrote: > > > > And then disabled say, payload #1, that immediately after we get the ACT > > that > > the payload table in hardware would look like this: > > > > Payload #2: 15 slots, start_slot=0 > > Payload #3: 15 slots, start_slot=15 > > The above is the actual and expected HW state state yes. > > > But it sounds like it actually would look like this in the real world? > > > > Payload #2: 15 slots, start_slot=15 > > Payload #3: 15 slots, start_slot=30 > > No, the problem currently is not that start_slot of the subsequent > payloads are not shifted towards the beginning. Rather the atomic state > doesn't get updated properly, becoming out of sync with the HW. For > instance in a commit resizing payload #1, in the commit phase > (intel_atomic_commit_tail()) will begin by removing payload #1. The > initial state is > > old payload state new payload state > Payload #1: 15 slots, start_slot=020 slots, start_slot=0 > Payload #2: 15 slots, start_slot=15 15 slots, start_slot=15 > Payload #3: 15 slots, start_slot=30 15 slots, start_slot=30 > > mgr->next_start_slot = 45 > > intel_mst_disable_dp() will pass the old MST and payload state to > drm_dp_remove_payload(): The MST state was added during atomic check, > since payload #1 changed, then intel_atomic_commit() -> > drm_atomic_helper_swap_state() sets the MST current state (returned by > drm_atomic_get_mst_topology_state()) to point to the old state. So at OK - this took me a while to wrap my head around but you're completely right. It appears I totally misunderstood where the state swapping actually happens during the check -> commit sequence. I think if that's how things work too then yeah, it definitely might not be a bad idea to move the start slot out of the atomic state :P. I guess we could just keep this in the mst manager struct instead of the commit state and make the rules for access be the same: protect them through commit ordering, and document that the proper way of accessing start values outside of the context of an atomic commit (if this was needed for some reason) is: * grab mst lock * call drm_dp_mst_atomic_wait_for_dependencies() * read values under lock Thank y'all again so much for helping out with this! It is super appreciated, and once you guys push these patches upstream I will look into adopting this for nouveau. I already poked some folks from AMD as well to make sure they're keeping an eye on this (although looking at the Cc I realize they were already added a while ago, whoops lol). > the point drm_dp_remove_payload() returns we have: > > old payload state new payload state > Payload #1: 15 slots, start_slot=-1 20 slots, start_slot=0 > Payload #2: 15 slots, start_slot=015 slots, start_slot=15 > Payload #3: 15 slots, start_slot=15 15 slots, start_slot=30 > > mgr->next_start_slot = 30 > > then after re-enabling payload #1, after drm_dp_add_payload_part1() > returns (passing to it the new MST and payload state) we have: > > old payload state new payload state > Payload #1: 15 slots, start_slot=-1 20 slots, start_slot=30 > Payload #2: 15 slots, start_slot=015 slots, start_slot=15 > Payload #3: 15 slots, start_slot=15 15 slots, start_slot=30 > > mgr->next_start_slot = 50 > > So in the new SW state payload #1 and #3 incorrectly overlap, with the > actual HW state being: > > Payload #1: 20 slots, start_slot=30 > Payload #2: 15 slots, start_slot=0 > Payload #3: 15 slots, start_slot=15 > > A subsequent commit will see the wrong start_slot in the SW state for > payload #2 (15) and #3 (30). > > > So I'm curious, is there something I missed here? At what point does the MST > > hub at the other end decide that it's time to move the start slots back? > > The hub shifts back payloads after the DPCD write command to 0x1c0 - > 0x1c2 to remove a payload. (The HW OTOH does the corresponding shift at > the point of disabling the stream, in intel_mst_post_disable_dp() -> > intel_disable_transcoder() for i915). > > > (keep in mind, the MST specification does explicitly mention that > > there should never be holes in the payload table - so something has to > > be shifting the payloads back). > > Right, the hubs I checked conform to this. > > > > > So if you guys think it'd be better design-wise to store this something > > > > else, > > > > I've got no strong feelings either way > > > > > > > > > > > For 0-2: > > > > > > > > > > > > Reviewed-by: Lyude Paul > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Lyude Paul > > > > > > > Cc: Ville Syrjälä > > > > > > > Cc: Ben Skeggs > > > > > > > Cc: Karol Herbst > > > > > > > Cc: Harry Wentland > > > > > > > Cc: Alex Deucher > > > > > > > Cc: Wayne Lin > > > > > > > Cc: sta...@vger.kernel.org #
Re: [PATCH v3 27/27] drm/msm/dpu: add support for wide planes
Hi Abhinav,
On Thu, 9 Feb 2023 at 21:25, Abhinav Kumar wrote:
>
>
>
> On 2/9/2023 3:45 AM, Dmitry Baryshkov wrote:
> > On Thu, 9 Feb 2023 at 04:19, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
> >>> Typically SSPP can support rectangle with width up to 2560. However it's
> >>
> >> Not always 2560. Depends on the chipset.
> >
> > _typically_
> >
>
> Would just say maxlinewidth of SSPP instead of giving some hardcoded number.
Ack.
>
> >>
> >>> 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,
> >>> >pipe);
> >>>
> >>> + _dpu_crtc_blend_setup_pipe(crtc, plane,
> >>> +mixer, cstate->num_mixers,
> >>> +stage_cfg, pstate->stage, 1,
> >>> +fetch_active,
> >>> +>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(_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;
> >>
> >> instead of checking if sspp was present, is it not better for the caller
> >> to check if the rpipe is valid before calling this?
> >>
> >>> +
> >>>/* 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, >pipe,
> >>> >pipe_cfg, fill_color, fmt);
> >>> +
> >>> + _dpu_plane_color_fill_pipe(pstate, >r_pipe,
> >>> >r_pipe_cfg, fill_color, fmt);
> >>>}
> >>
> >> So cant we do
> >>
> >> if (pstate->r_pipe.sspp)
> >> _dpu_plane_color_fill_pipe(pstate, >r_pipe,
> >> >r_pipe_cfg, fill_color, fmt);
> >>
> >> It just seems better to me as the caller would already know if the sspp
> >> was assigned.
> >
> > I think I had this kind of code earlier, but then I found it more
> > logical to move the check to the called function. I'll move it back.
> >
> >>
> >>>
> >>>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 = >pipe;
> >>> + struct dpu_sw_pipe *r_pipe = >r_pipe;
> >>>const struct drm_crtc_state *crtc_state = NULL;
> >>>const struct dpu_format *fmt;
> >>>struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
> >>> + struct dpu_hw_sspp_cfg *r_pipe_cfg = >r_pipe_cfg;
> >>>
Re: [PATCH] drm/nouveau/disp: Fix nvif_outp_acquire_dp() argument size
I think that shoud be fine, which branch is it on?
On Fri, 2023-01-27 at 11:42 -0800, Kees Cook wrote:
> On Wed, Jan 25, 2023 at 04:24:19PM -0500, Lyude Paul wrote:
> > Sorry! I've been pretty busy until now, this is:
> >
> > Reviewed-by: Lyude Paul
> >
> > Let me know if you've pushed it already or if you want me to push it to drm-
> > misc
>
> Either way is fine. I'm currently carrying it, but I can easily drop it
> if you prefer it go via drm-misc.
>
> Thanks!
>
> -Kees
>
> >
> > On Wed, 2023-01-25 at 12:15 -0800, Kees Cook wrote:
> > > Ping. I'll take this via my tree unless someone else wants to take it...
> > >
> > > On Sun, Nov 27, 2022 at 10:30:41AM -0800, Kees Cook wrote:
> > > > Both Coverity and GCC with -Wstringop-overflow noticed that
> > > > nvif_outp_acquire_dp() accidentally defined its second argument with 1
> > > > additional element:
> > > >
> > > > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > > > 'nv50_pior_atomic_enable':
> > > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error:
> > > > 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15
> > > > [-Werror=stringop-overflow=]
> > > > 1813 | nvif_outp_acquire_dp(_encoder->outp,
> > > > nv_encoder->dp.dpcd, 0, 0, false, false);
> > > > |
> > > > ^~~
> > > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: note: referencing
> > > > argument 2 of type 'u8[16]' {aka 'unsigned char[16]'}
> > > > drivers/gpu/drm/nouveau/include/nvif/outp.h:24:5: note: in a call to
> > > > function 'nvif_outp_acquire_dp'
> > > >24 | int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16],
> > > > | ^~~~
> > > >
> > > > Avoid these warnings by defining the argument size using the matching
> > > > define (DP_RECEIVER_CAP_SIZE, 15) instead of having it be a literal
> > > > (and incorrect) value (16).
> > > >
> > > > Reported-by: coverity-bot
> > > > Addresses-Coverity-ID: 1527269 ("Memory - corruptions")
> > > > Addresses-Coverity-ID: 1527268 ("Memory - corruptions")
> > > > Link: https://lore.kernel.org/lkml/202211100848.FFBA2432@keescook/
> > > > Link: https://lore.kernel.org/lkml/202211100848.F4C2819BB@keescook/
> > > > Fixes: 813443721331 ("drm/nouveau/disp: move DP link config into
> > > > acquire")
> > > > Cc: Ben Skeggs
> > > > Cc: Karol Herbst
> > > > Cc: Lyude Paul
> > > > Cc: David Airlie
> > > > Cc: Daniel Vetter
> > > > Cc: Dave Airlie
> > > > Cc: "Gustavo A. R. Silva"
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: nouv...@lists.freedesktop.org
> > > > Signed-off-by: Kees Cook
> > > > ---
> > > > drivers/gpu/drm/nouveau/include/nvif/outp.h | 3 ++-
> > > > drivers/gpu/drm/nouveau/nvif/outp.c | 2 +-
> > > > 2 files changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > > b/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > > index 45daadec3c0c..fa76a7b5e4b3 100644
> > > > --- a/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > > +++ b/drivers/gpu/drm/nouveau/include/nvif/outp.h
> > > > @@ -3,6 +3,7 @@
> > > > #define __NVIF_OUTP_H__
> > > > #include
> > > > #include
> > > > +#include
> > > > struct nvif_disp;
> > > >
> > > > struct nvif_outp {
> > > > @@ -21,7 +22,7 @@ int nvif_outp_acquire_rgb_crt(struct nvif_outp *);
> > > > int nvif_outp_acquire_tmds(struct nvif_outp *, int head,
> > > >bool hdmi, u8 max_ac_packet, u8 rekey, u8
> > > > scdc, bool hda);
> > > > int nvif_outp_acquire_lvds(struct nvif_outp *, bool dual, bool bpc8);
> > > > -int nvif_outp_acquire_dp(struct nvif_outp *, u8 dpcd[16],
> > > > +int nvif_outp_acquire_dp(struct nvif_outp *outp, u8
> > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > > int link_nr, int link_bw, bool hda, bool mst);
> > > > void nvif_outp_release(struct nvif_outp *);
> > > > int nvif_outp_infoframe(struct nvif_outp *, u8 type, struct
> > > > nvif_outp_infoframe_v0 *, u32 size);
> > > > diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c
> > > > b/drivers/gpu/drm/nouveau/nvif/outp.c
> > > > index 7da39f1eae9f..c24bc5eae3ec 100644
> > > > --- a/drivers/gpu/drm/nouveau/nvif/outp.c
> > > > +++ b/drivers/gpu/drm/nouveau/nvif/outp.c
> > > > @@ -127,7 +127,7 @@ nvif_outp_acquire(struct nvif_outp *outp, u8 proto,
> > > > struct nvif_outp_acquire_v0
> > > > }
> > > >
> > > > int
> > > > -nvif_outp_acquire_dp(struct nvif_outp *outp, u8 dpcd[16],
> > > > +nvif_outp_acquire_dp(struct nvif_outp *outp, u8
> > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > > int link_nr, int link_bw, bool hda, bool mst)
> > > > {
> > > > struct nvif_outp_acquire_v0 args;
> > > > --
> > > > 2.34.1
> > > >
> > >
> >
> > --
> > Cheers,
> > Lyude Paul (she/her)
> > Software Engineer at Red Hat
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v3 27/27] drm/msm/dpu: add support for wide planes
On 2/9/2023 3:45 AM, Dmitry Baryshkov wrote:
On Thu, 9 Feb 2023 at 04:19, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Typically SSPP can support rectangle with width up to 2560. However it's
Not always 2560. Depends on the chipset.
_typically_
Would just say maxlinewidth of SSPP instead of giving some hardcoded number.
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,
>pipe);
+ _dpu_crtc_blend_setup_pipe(crtc, plane,
+mixer, cstate->num_mixers,
+stage_cfg, pstate->stage, 1,
+fetch_active,
+>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(_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;
instead of checking if sspp was present, is it not better for the caller
to check if the rpipe is valid before calling this?
+
/* 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, >pipe, >pipe_cfg,
fill_color, fmt);
+
+ _dpu_plane_color_fill_pipe(pstate, >r_pipe, >r_pipe_cfg,
fill_color, fmt);
}
So cant we do
if (pstate->r_pipe.sspp)
_dpu_plane_color_fill_pipe(pstate, >r_pipe,
>r_pipe_cfg, fill_color, fmt);
It just seems better to me as the caller would already know if the sspp
was assigned.
I think I had this kind of code earlier, but then I found it more
logical to move the check to the called function. I'll move it back.
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 = >pipe;
+ struct dpu_sw_pipe *r_pipe = >r_pipe;
const struct drm_crtc_state *crtc_state = NULL;
const struct dpu_format *fmt;
struct dpu_hw_sspp_cfg *pipe_cfg = >pipe_cfg;
+ struct dpu_hw_sspp_cfg *r_pipe_cfg = >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 @@
Re: [RFC PATCH v2 1/4] drm/msm/dpu: Move TE setup to prepare_for_kickoff()
On 09/02/2023 20:44, Jessica Zhang wrote:
Currently, DPU will enable TE during prepare_commit(). However, this
will cause issues when trying to read/write to register in
get_autorefresh_config(), because the core clock rates aren't set at
that time.
This used to work because phys_enc->hw_pp is only initialized in mode
set [1], so the first prepare_commit() will return before any register
read/write as hw_pp would be NULL.
However, when we try to implement support for INTF TE, we will run into
the clock issue described above as hw_intf will *not* be NULL on the
first prepare_commit(). This is because the initialization of
dpu_enc->hw_intf has been moved to dpu_encoder_setup() [2].
To avoid this issue, let's enable TE during prepare_for_kickoff()
instead as the core clock rates are guaranteed to be set then.
Depends on: "Implement tearcheck support on INTF block" [3]
[1]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L1109
[2]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L2339
[3] https://patchwork.freedesktop.org/series/112332/
Signed-off-by: Jessica Zhang
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 78 ++-
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index cb05036f2916..561406d92a1a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -583,39 +583,6 @@ static void dpu_encoder_phys_cmd_destroy(struct
dpu_encoder_phys *phys_enc)
kfree(cmd_enc);
}
-static void dpu_encoder_phys_cmd_prepare_for_kickoff(
- struct dpu_encoder_phys *phys_enc)
-{
- struct dpu_encoder_phys_cmd *cmd_enc =
- to_dpu_encoder_phys_cmd(phys_enc);
- int ret;
-
- if (!phys_enc->hw_pp) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n", DRMID(phys_enc->parent),
- phys_enc->hw_pp->idx - PINGPONG_0,
- atomic_read(_enc->pending_kickoff_cnt));
-
- /*
-* Mark kickoff request as outstanding. If there are more than one,
-* outstanding, then we have to wait for the previous one to complete
-*/
- ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
- if (ret) {
- /* force pending_kickoff_cnt 0 to discard failed kickoff */
- atomic_set(_enc->pending_kickoff_cnt, 0);
- DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
- DRMID(phys_enc->parent), ret,
- phys_enc->hw_pp->idx - PINGPONG_0);
- }
-
- DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
- phys_enc->hw_pp->idx - PINGPONG_0,
- atomic_read(_enc->pending_kickoff_cnt));
-}
-
static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
struct dpu_encoder_phys *phys_enc)
{
@@ -641,8 +608,7 @@ static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
return false;
}
-static void dpu_encoder_phys_cmd_prepare_commit(
- struct dpu_encoder_phys *phys_enc)
+static void dpu_encoder_phys_cmd_enable_te(struct dpu_encoder_phys *phys_enc)
{
struct dpu_encoder_phys_cmd *cmd_enc =
to_dpu_encoder_phys_cmd(phys_enc);
@@ -700,6 +666,48 @@ static void dpu_encoder_phys_cmd_prepare_commit(
"disabled autorefresh\n");
}
+static void dpu_encoder_phys_cmd_prepare_for_kickoff(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_encoder_phys_cmd *cmd_enc =
+ to_dpu_encoder_phys_cmd(phys_enc);
+ int ret;
+
+ if (!phys_enc->hw_pp) {
+ DPU_ERROR("invalid encoder\n");
+ return;
+ }
+
+
+ DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n", DRMID(phys_enc->parent),
+ phys_enc->hw_pp->idx - PINGPONG_0,
+ atomic_read(_enc->pending_kickoff_cnt));
+
+ /*
+* Mark kickoff request as outstanding. If there are more than one,
+* outstanding, then we have to wait for the previous one to complete
+*/
+ ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
+ if (ret) {
+ /* force pending_kickoff_cnt 0 to discard failed kickoff */
+ atomic_set(_enc->pending_kickoff_cnt, 0);
+ DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
+ DRMID(phys_enc->parent), ret,
+ phys_enc->hw_pp->idx - PINGPONG_0);
+ }
+
+ dpu_encoder_phys_cmd_enable_te(phys_enc);
+
+ DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
+ phys_enc->hw_pp->idx - PINGPONG_0,
+
Re: [RFC PATCH v2 3/4] drm/msm/dpu: Remove empty prepare_commit() function
On 09/02/2023 20:44, Jessica Zhang wrote:
Now that the TE setup has been moved to prepare_for_kickoff(),
move empty prepare_commit() from DPU driver.
s/move/remove/
Also the DPU's prepare_commit() is not empty. Please mention
dpu_encoder_prepare_commit() becoming (or being) empty.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 7 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 ---
4 files changed, 53 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index dcceed91aed8..35e120b5ef53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2090,25 +2090,6 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc)
-{
- struct dpu_encoder_virt *dpu_enc;
- struct dpu_encoder_phys *phys;
- int i;
-
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- dpu_enc = to_dpu_encoder_virt(drm_enc);
-
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- phys = dpu_enc->phys_encs[i];
- if (phys->ops.prepare_commit)
- phys->ops.prepare_commit(phys);
- }
-}
-
#ifdef CONFIG_DEBUG_FS
static int _dpu_encoder_status_show(struct seq_file *s, void *data)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9e7236ef34e6..2c9ef8d1b877 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -146,13 +146,6 @@ struct drm_encoder *dpu_encoder_init(
int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
struct msm_display_info *disp_info);
-/**
- * dpu_encoder_prepare_commit - prepare encoder at the very beginning of an
- * atomic commit, before any registers are written
- * @drm_enc:Pointer to previously created drm encoder structure
- */
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc);
-
/**
* dpu_encoder_set_idle_timeout - set the idle timeout for video
*and command mode encoders.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 561406d92a1a..4c189b9fa9b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -703,11 +703,6 @@ static void dpu_encoder_phys_cmd_prepare_for_kickoff(
atomic_read(_enc->pending_kickoff_cnt));
}
-static void dpu_encoder_phys_cmd_prepare_commit(
- struct dpu_encoder_phys *phys_enc)
-{
-}
-
static int _dpu_encoder_phys_cmd_wait_for_ctl_start(
struct dpu_encoder_phys *phys_enc)
{
@@ -807,7 +802,6 @@ static void dpu_encoder_phys_cmd_trigger_start(
static void dpu_encoder_phys_cmd_init_ops(
struct dpu_encoder_phys_ops *ops)
{
- ops->prepare_commit = dpu_encoder_phys_cmd_prepare_commit;
Also please don't forget to remove prepare_commit from dpu_encoder_phys_ops.
ops->is_master = dpu_encoder_phys_cmd_is_master;
ops->atomic_mode_set = dpu_encoder_phys_cmd_atomic_mode_set;
ops->enable = dpu_encoder_phys_cmd_enable;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 165958d47ec6..6f7ddbf0d9b7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -425,26 +425,6 @@ static ktime_t dpu_kms_vsync_time(struct msm_kms *kms,
struct drm_crtc *crtc)
return ktime_get();
}
-static void dpu_kms_prepare_commit(struct msm_kms *kms,
- struct drm_atomic_state *state)
-{
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
- struct drm_encoder *encoder;
- int i;
-
- if (!kms)
- return;
-
- /* Call prepare_commit for all affected encoders */
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- drm_for_each_encoder_mask(encoder, crtc->dev,
- crtc_state->encoder_mask) {
- dpu_encoder_prepare_commit(encoder);
- }
- }
-}
-
static void dpu_kms_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -949,7 +929,6 @@ static const struct msm_kms_funcs kms_funcs = {
.enable_commit = dpu_kms_enable_commit,
.disable_commit = dpu_kms_disable_commit,
.vsync_time = dpu_kms_vsync_time,
- .prepare_commit =
Re: Try to address the drm_debugfs issues
On Thu, Feb 09, 2023 at 04:52:54PM +0100, Christian König wrote: > Am 09.02.23 um 15:19 schrieb Maxime Ripard: > > On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote: > > > Am 09.02.23 um 14:06 schrieb Maíra Canal: > > > > On 2/9/23 09:13, Christian König wrote: > > > > > Am 09.02.23 um 12:23 schrieb Maíra Canal: > > > > > > On 2/9/23 05:18, Christian König wrote: > > > > > > > Hello everyone, > > > > > > > > > > > > > > the drm_debugfs has a couple of well known design problems. > > > > > > > > > > > > > > Especially it wasn't possible to add files between > > > > > > > initializing and registering > > > > > > > of DRM devices since the underlying debugfs directory wasn't > > > > > > > created yet. > > > > > > > > > > > > > > The resulting necessity of the driver->debugfs_init() > > > > > > > callback function is a > > > > > > > mid-layering which is really frowned on since it creates a > > > > > > > horrible > > > > > > > driver->DRM->driver design layering. > > > > > > > > > > > > > > The recent patch "drm/debugfs: create device-centered > > > > > > > debugfs functions" tried > > > > > > > to address those problem, but doesn't seem to work > > > > > > > correctly. This looks like > > > > > > > a misunderstanding of the call flow around > > > > > > > drm_debugfs_init(), which is called > > > > > > > multiple times, once for the primary and once for the render node. > > > > > > > > > > > > > > So what happens now is the following: > > > > > > > > > > > > > > 1. drm_dev_init() initially allocates the drm_minor objects. > > > > > > > 2. ... back to the driver ... > > > > > > > 3. drm_dev_register() is called. > > > > > > > > > > > > > > 4. drm_debugfs_init() is called for the primary node. > > > > > > > 5. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and > > > > > > > drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() > > > > > > > to add the files > > > > > > > for the primary node. > > > > > > > 6. The driver->debugfs_init() callback is called to add > > > > > > > debugfs files for the > > > > > > > primary node. > > > > > > > 7. The added files are consumed and added to the primary > > > > > > > node debugfs directory. > > > > > > > > > > > > > > 8. drm_debugfs_init() is called for the render node. > > > > > > > 9. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and > > > > > > > drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() > > > > > > > to add the files > > > > > > > again for the render node. > > > > > > > 10. The driver->debugfs_init() callback is called to add > > > > > > > debugfs files for the > > > > > > > render node. > > > > > > > 11. The added files are consumed and added to the render > > > > > > > node debugfs directory. > > > > > > > > > > > > > > 12. Some more files are added through drm_debugfs_add_file(). > > > > > > > 13. drm_debugfs_late_register() add the files once more to > > > > > > > the primary node > > > > > > > debugfs directory. > > > > > > > 14. From this point on files added through > > > > > > > drm_debugfs_add_file() are simply ignored. > > > > > > > 15. ... back to the driver ... > > > > > > > > > > > > > > Because of this the dev->debugfs_mutex lock is also > > > > > > > completely pointless since > > > > > > > any concurrent use of the interface would just randomly > > > > > > > either add the files to > > > > > > > the primary or render node or just not at all. > > > > > > > > > > > > > > Even worse is that this implementation nails the coffin for > > > > > > > removing the > > > > > > > driver->debugfs_init() mid-layering because otherwise > > > > > > > drivers can't control > > > > > > > where their debugfs (primary/render node) are actually added. > > > > > > > > > > > > > > This patch set here now tries to clean this up a bit, but > > > > > > > most likely isn't > > > > > > > fully complete either since I didn't audit every driver/call path. > > > > > > I tested the patchset on the v3d, vc4 and vkms and all the files > > > > > > are generated > > > > > > as expected, but I'm getting the following errors on dmesg: > > > > > > > > > > > > [ 3.872026] debugfs: File 'v3d_ident' in directory '0' > > > > > > already present! > > > > > > [ 3.872064] debugfs: File 'v3d_ident' in directory '128' > > > > > > already present! > > > > > > [ 3.872078] debugfs: File 'v3d_regs' in directory '0' already > > > > > > present! > > > > > > [ 3.872087] debugfs: File 'v3d_regs' in directory '128' > > > > > > already present! > > > > > > [ 3.872097] debugfs: File 'measure_clock' in directory '0' > > > > > > already present! > > > > > > [ 3.872105] debugfs: File 'measure_clock' in directory '128' > > > > > > already present! > > > > > > [ 3.872116] debugfs: File 'bo_stats' in directory '0' already > > > > > > present! > > > > > > [ 3.872124] debugfs: File 'bo_stats' in directory '128' > > > > > > already present! > > > > > > > > > > > > It looks like the render
Re: [RFC PATCH v2 4/4] drm/msm/mdp4: Remove empty prepare_commit() function
On 09/02/2023 20:44, Jessica Zhang wrote: Remove empty prepare_commit() function from MDP4 driver. Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 - 1 file changed, 5 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [RFC PATCH v2 2/4] drm/msm: Check for NULL before calling prepare_commit()
On 09/02/2023 20:44, Jessica Zhang wrote: Add a NULL check before calling prepare_commit() in msm_atomic_commit_tail() Signed-off-by: Jessica Zhang Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[RFC PATCH v2 4/4] drm/msm/mdp4: Remove empty prepare_commit() function
Remove empty prepare_commit() function from MDP4 driver.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 9a1a0769575d..6e37072ed302 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -84,10 +84,6 @@ static void mdp4_disable_commit(struct msm_kms *kms)
mdp4_disable(mdp4_kms);
}
-static void mdp4_prepare_commit(struct msm_kms *kms, struct drm_atomic_state
*state)
-{
-}
-
static void mdp4_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
{
/* TODO */
@@ -154,7 +150,6 @@ static const struct mdp_kms_funcs kms_funcs = {
.disable_vblank = mdp4_disable_vblank,
.enable_commit = mdp4_enable_commit,
.disable_commit = mdp4_disable_commit,
- .prepare_commit = mdp4_prepare_commit,
.flush_commit= mdp4_flush_commit,
.wait_flush = mdp4_wait_flush,
.complete_commit = mdp4_complete_commit,
--
2.39.1
[RFC PATCH v2 3/4] drm/msm/dpu: Remove empty prepare_commit() function
Now that the TE setup has been moved to prepare_for_kickoff(),
move empty prepare_commit() from DPU driver.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 7 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 ---
4 files changed, 53 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index dcceed91aed8..35e120b5ef53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2090,25 +2090,6 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc)
-{
- struct dpu_encoder_virt *dpu_enc;
- struct dpu_encoder_phys *phys;
- int i;
-
- if (!drm_enc) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- dpu_enc = to_dpu_encoder_virt(drm_enc);
-
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- phys = dpu_enc->phys_encs[i];
- if (phys->ops.prepare_commit)
- phys->ops.prepare_commit(phys);
- }
-}
-
#ifdef CONFIG_DEBUG_FS
static int _dpu_encoder_status_show(struct seq_file *s, void *data)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9e7236ef34e6..2c9ef8d1b877 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -146,13 +146,6 @@ struct drm_encoder *dpu_encoder_init(
int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc,
struct msm_display_info *disp_info);
-/**
- * dpu_encoder_prepare_commit - prepare encoder at the very beginning of an
- * atomic commit, before any registers are written
- * @drm_enc:Pointer to previously created drm encoder structure
- */
-void dpu_encoder_prepare_commit(struct drm_encoder *drm_enc);
-
/**
* dpu_encoder_set_idle_timeout - set the idle timeout for video
*and command mode encoders.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 561406d92a1a..4c189b9fa9b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -703,11 +703,6 @@ static void dpu_encoder_phys_cmd_prepare_for_kickoff(
atomic_read(_enc->pending_kickoff_cnt));
}
-static void dpu_encoder_phys_cmd_prepare_commit(
- struct dpu_encoder_phys *phys_enc)
-{
-}
-
static int _dpu_encoder_phys_cmd_wait_for_ctl_start(
struct dpu_encoder_phys *phys_enc)
{
@@ -807,7 +802,6 @@ static void dpu_encoder_phys_cmd_trigger_start(
static void dpu_encoder_phys_cmd_init_ops(
struct dpu_encoder_phys_ops *ops)
{
- ops->prepare_commit = dpu_encoder_phys_cmd_prepare_commit;
ops->is_master = dpu_encoder_phys_cmd_is_master;
ops->atomic_mode_set = dpu_encoder_phys_cmd_atomic_mode_set;
ops->enable = dpu_encoder_phys_cmd_enable;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 165958d47ec6..6f7ddbf0d9b7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -425,26 +425,6 @@ static ktime_t dpu_kms_vsync_time(struct msm_kms *kms,
struct drm_crtc *crtc)
return ktime_get();
}
-static void dpu_kms_prepare_commit(struct msm_kms *kms,
- struct drm_atomic_state *state)
-{
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
- struct drm_encoder *encoder;
- int i;
-
- if (!kms)
- return;
-
- /* Call prepare_commit for all affected encoders */
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- drm_for_each_encoder_mask(encoder, crtc->dev,
- crtc_state->encoder_mask) {
- dpu_encoder_prepare_commit(encoder);
- }
- }
-}
-
static void dpu_kms_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -949,7 +929,6 @@ static const struct msm_kms_funcs kms_funcs = {
.enable_commit = dpu_kms_enable_commit,
.disable_commit = dpu_kms_disable_commit,
.vsync_time = dpu_kms_vsync_time,
- .prepare_commit = dpu_kms_prepare_commit,
.flush_commit= dpu_kms_flush_commit,
.wait_flush = dpu_kms_wait_flush,
.complete_commit = dpu_kms_complete_commit,
--
2.39.1
[RFC PATCH v2 2/4] drm/msm: Check for NULL before calling prepare_commit()
Add a NULL check before calling prepare_commit() in msm_atomic_commit_tail() Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/msm_atomic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 1686fbb611fd..c8a0a5cc5ca5 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -206,7 +206,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state) * Now that there is no in-progress flush, prepare the * current update: */ - kms->funcs->prepare_commit(kms, state); + if (kms->funcs->prepare_commit) + kms->funcs->prepare_commit(kms, state); /* * Push atomic updates down to hardware: -- 2.39.1
[RFC PATCH v2 1/4] drm/msm/dpu: Move TE setup to prepare_for_kickoff()
Currently, DPU will enable TE during prepare_commit(). However, this
will cause issues when trying to read/write to register in
get_autorefresh_config(), because the core clock rates aren't set at
that time.
This used to work because phys_enc->hw_pp is only initialized in mode
set [1], so the first prepare_commit() will return before any register
read/write as hw_pp would be NULL.
However, when we try to implement support for INTF TE, we will run into
the clock issue described above as hw_intf will *not* be NULL on the
first prepare_commit(). This is because the initialization of
dpu_enc->hw_intf has been moved to dpu_encoder_setup() [2].
To avoid this issue, let's enable TE during prepare_for_kickoff()
instead as the core clock rates are guaranteed to be set then.
Depends on: "Implement tearcheck support on INTF block" [3]
[1]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L1109
[2]
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c#L2339
[3] https://patchwork.freedesktop.org/series/112332/
Signed-off-by: Jessica Zhang
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 78 ++-
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index cb05036f2916..561406d92a1a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -583,39 +583,6 @@ static void dpu_encoder_phys_cmd_destroy(struct
dpu_encoder_phys *phys_enc)
kfree(cmd_enc);
}
-static void dpu_encoder_phys_cmd_prepare_for_kickoff(
- struct dpu_encoder_phys *phys_enc)
-{
- struct dpu_encoder_phys_cmd *cmd_enc =
- to_dpu_encoder_phys_cmd(phys_enc);
- int ret;
-
- if (!phys_enc->hw_pp) {
- DPU_ERROR("invalid encoder\n");
- return;
- }
- DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n", DRMID(phys_enc->parent),
- phys_enc->hw_pp->idx - PINGPONG_0,
- atomic_read(_enc->pending_kickoff_cnt));
-
- /*
-* Mark kickoff request as outstanding. If there are more than one,
-* outstanding, then we have to wait for the previous one to complete
-*/
- ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
- if (ret) {
- /* force pending_kickoff_cnt 0 to discard failed kickoff */
- atomic_set(_enc->pending_kickoff_cnt, 0);
- DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
- DRMID(phys_enc->parent), ret,
- phys_enc->hw_pp->idx - PINGPONG_0);
- }
-
- DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
- phys_enc->hw_pp->idx - PINGPONG_0,
- atomic_read(_enc->pending_kickoff_cnt));
-}
-
static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
struct dpu_encoder_phys *phys_enc)
{
@@ -641,8 +608,7 @@ static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
return false;
}
-static void dpu_encoder_phys_cmd_prepare_commit(
- struct dpu_encoder_phys *phys_enc)
+static void dpu_encoder_phys_cmd_enable_te(struct dpu_encoder_phys *phys_enc)
{
struct dpu_encoder_phys_cmd *cmd_enc =
to_dpu_encoder_phys_cmd(phys_enc);
@@ -700,6 +666,48 @@ static void dpu_encoder_phys_cmd_prepare_commit(
"disabled autorefresh\n");
}
+static void dpu_encoder_phys_cmd_prepare_for_kickoff(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_encoder_phys_cmd *cmd_enc =
+ to_dpu_encoder_phys_cmd(phys_enc);
+ int ret;
+
+ if (!phys_enc->hw_pp) {
+ DPU_ERROR("invalid encoder\n");
+ return;
+ }
+
+
+ DRM_DEBUG_KMS("id:%u pp:%d pending_cnt:%d\n", DRMID(phys_enc->parent),
+ phys_enc->hw_pp->idx - PINGPONG_0,
+ atomic_read(_enc->pending_kickoff_cnt));
+
+ /*
+* Mark kickoff request as outstanding. If there are more than one,
+* outstanding, then we have to wait for the previous one to complete
+*/
+ ret = _dpu_encoder_phys_cmd_wait_for_idle(phys_enc);
+ if (ret) {
+ /* force pending_kickoff_cnt 0 to discard failed kickoff */
+ atomic_set(_enc->pending_kickoff_cnt, 0);
+ DRM_ERROR("failed wait_for_idle: id:%u ret:%d pp:%d\n",
+ DRMID(phys_enc->parent), ret,
+ phys_enc->hw_pp->idx - PINGPONG_0);
+ }
+
+ dpu_encoder_phys_cmd_enable_te(phys_enc);
+
+ DPU_DEBUG_CMDENC(cmd_enc, "pp:%d pending_cnt %d\n",
+ phys_enc->hw_pp->idx - PINGPONG_0,
+
[RFC PATCH v2 0/4] Move TE setup to prepare_for_kickoff()
Move TE setup to prepare_for_kickoff() and remove empty prepare_commit() functions in both MDP4 and DPU drivers. Changes in V2: - Added changes to remove empty prepare_commit() functions Jessica Zhang (4): drm/msm/dpu: Move TE setup to prepare_for_kickoff() drm/msm: Check for NULL before calling prepare_commit() drm/msm/dpu: Remove empty prepare_commit() function drm/msm/mdp4: Remove empty prepare_commit() function drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 7 -- .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 74 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 -- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 5 -- drivers/gpu/drm/msm/msm_atomic.c | 3 +- 6 files changed, 40 insertions(+), 89 deletions(-) -- 2.39.1
Re: [PATCH 1/3] drm/msm/adreno: Add Adreno A690 support
On 08/02/2023 05:40, Bjorn Andersson wrote:
From: Bjorn Andersson
Introduce support for the Adreno A690, found in Qualcomm SC8280XP.
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 120 -
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 34 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 14 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10 +-
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index aae60cbd9164..81dfcc5073ad 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -588,6 +588,63 @@ const struct adreno_reglist a660_hwcg[] = {
{},
};
+const struct adreno_reglist a690_hwcg[] = {
+ {REG_A6XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_SP0, 0x0220},
+ {REG_A6XX_RBBM_CLOCK_DELAY_SP0, 0x0080},
+ {REG_A6XX_RBBM_CLOCK_HYST_SP0, 0xF3CF},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL4_TP0, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY4_TP0, 0x0001},
+ {REG_A6XX_RBBM_CLOCK_HYST_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST2_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST3_TP0, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST4_TP0, 0x0007},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RB0, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RB0, 0x0100},
+ {REG_A6XX_RBBM_CLOCK_CNTL_CCU0, 0x2220},
+ {REG_A6XX_RBBM_CLOCK_HYST_RB_CCU0, 0x00040F00},
+ {REG_A6XX_RBBM_CLOCK_CNTL_RAC, 0x25222022},
+ {REG_A6XX_RBBM_CLOCK_CNTL2_RAC, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_RAC, 0x0011},
+ {REG_A6XX_RBBM_CLOCK_HYST_RAC, 0x00445044},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TSE_RAS_RBBM, 0x0422},
+ {REG_A6XX_RBBM_CLOCK_MODE_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_MODE_GPC, 0x0022},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ_2, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_MODE_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TSE_RAS_RBBM, 0x4000},
+ {REG_A6XX_RBBM_CLOCK_DELAY_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GPC, 0x0200},
+ {REG_A6XX_RBBM_CLOCK_DELAY_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_TSE_RAS_RBBM, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_VFD, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_GPC, 0x04104004},
+ {REG_A6XX_RBBM_CLOCK_HYST_HLSQ, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_TEX_FCHE, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_TEX_FCHE, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_TEX_FCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_UCHE, 0x},
+ {REG_A6XX_RBBM_CLOCK_HYST_UCHE, 0x0004},
+ {REG_A6XX_RBBM_CLOCK_DELAY_UCHE, 0x0002},
+ {REG_A6XX_RBBM_CLOCK_CNTL, 0x8AA8AA82},
+ {REG_A6XX_RBBM_ISDB_CNT, 0x0182},
+ {REG_A6XX_RBBM_RAC_THRESHOLD_CNT, 0x},
+ {REG_A6XX_RBBM_SP_HYST_CNT, 0x},
+ {REG_A6XX_RBBM_CLOCK_CNTL_GMU_GX, 0x0222},
+ {REG_A6XX_RBBM_CLOCK_DELAY_GMU_GX, 0x0111},
+ {REG_A6XX_RBBM_CLOCK_HYST_GMU_GX, 0x0555},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_MODE_CNTL, 0x20200},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_DELAY_CNTL, 0x10111},
+ {REG_A6XX_GPU_GMU_AO_GMU_CGC_HYST_CNTL, 0x},
+ {}
+};
+
static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -747,6 +804,45 @@ static const u32 a660_protect[] = {
A6XX_PROTECT_NORDWR(0x1f8c0, 0x), /* note: infinite range */
};
+/* These are for a690 */
+static const u32 a690_protect[] = {
+ A6XX_PROTECT_RDONLY(0x0, 0x004ff),
+ A6XX_PROTECT_RDONLY(0x00501, 0x1),
Judging from msm-5.4 this should be , 0x0005
+ A6XX_PROTECT_RDONLY(0x0050b, 0x002f4),
+ A6XX_PROTECT_NORDWR(0x0050e, 0x0),
+ A6XX_PROTECT_NORDWR(0x00510, 0x0),
+ A6XX_PROTECT_NORDWR(0x00534, 0x0),
+ A6XX_PROTECT_NORDWR(0x00800, 0x00082),
+ A6XX_PROTECT_NORDWR(0x008a0, 0x8),
+ A6XX_PROTECT_NORDWR(0x008ab, 0x00024),
+ A6XX_PROTECT_RDONLY(0x008d0, 0x000bc),
+ A6XX_PROTECT_NORDWR(0x00900, 0x0004d),
+ A6XX_PROTECT_NORDWR(0x0098d, 0x00272),
+ A6XX_PROTECT_NORDWR(0x00e00, 0x1),
+ A6XX_PROTECT_NORDWR(0x00e03, 0xc),
+ A6XX_PROTECT_NORDWR(0x03c00, 0x000c3),
+ A6XX_PROTECT_RDONLY(0x03cc4, 0x01fff),
+ A6XX_PROTECT_NORDWR(0x08630, 0x001cf),
+ A6XX_PROTECT_NORDWR(0x08e00, 0x0),
+ A6XX_PROTECT_NORDWR(0x08e08, 0x8),
+
Re: [PATCH 4/9] dt-bindings: gpu: mali-bifrost: Add new MT8183 compatible
On Wed, 08 Feb 2023 11:37:04 +0100, AngeloGioacchino Del Regno wrote: > Since new platform data was required in Panfrost for getting GPU DVFS > finally working on MediaTek SoCs, add a new "mediatek,mt8183b-mali" > compatible. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/gpu/arm,mali-bifrost.yaml| 20 +++ > 1 file changed, 20 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH 3/9] dt-bindings: gpu: mali-bifrost: Add compatible for MT8195 SoC
On Wed, 08 Feb 2023 11:37:03 +0100, AngeloGioacchino Del Regno wrote: > The MediaTek MT8195 SoC has a Mali G57 MC5 (Valhall-JM) and has the > same number of power domains and requirements as MT8192 in terms of > bindings. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH 2/9] dt-bindings: gpu: mali-bifrost: Allow up to 5 power domains for MT8192
On Wed, 08 Feb 2023 11:37:02 +0100, AngeloGioacchino Del Regno wrote: > MediaTek MT8192 (and similar) needs five power domains for the > Mali GPU and no sram-supply: change the binding to allow so. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/gpu/arm,mali-bifrost.yaml| 34 +-- > 1 file changed, 31 insertions(+), 3 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH 1/9] dt-bindings: gpu: mali-bifrost: Don't allow sram-supply by default
On Thu, Feb 09, 2023 at 10:15:33AM +0100, AngeloGioacchino Del Regno wrote: > Il 09/02/23 03:50, Chen-Yu Tsai ha scritto: > > On Wed, Feb 8, 2023 at 6:37 PM AngeloGioacchino Del Regno > > wrote: > > > > > > The sram-supply is MediaTek-specific, it is and will ever be used > > > only for the mediatek,mt8183-mali compatible due to the addition of > > > the mediatek-regulator-coupler driver: change the binding to add > > > this supply when mediatek,mt8183-mali is present as a compatible > > > instead of disabling it when not present. > > > > > > This is done in preparation for adding new bindings for other > > > MediaTek SoCs, such as MT8192 and others. > > > > > > Signed-off-by: AngeloGioacchino Del Regno > > > > > > --- > > > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > > index 78964c140b46..69212f3b1328 100644 > > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > > > @@ -57,8 +57,6 @@ properties: > > > > > > mali-supply: true > > > > > > - sram-supply: true > > > - > > > > Have you tried actually validating the device trees against this? > > Based on my previous tests this gives out errors. > > I did... and I didn't get any complaint... but perhaps something went wrong > on my side? > > I mean, I can retry just to be sure. You should need unevaluatedProperties instead of additionalProperties for this to work. The latter cannot 'see' into an if/then schema. But really we want the default top level to allow this and then disallow it in an if/then schema. Rob
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Thu, Feb 09, 2023 at 05:03:19PM +, Simon Ser wrote: > On Thursday, February 9th, 2023 at 17:38, Joshua Ashton > wrote: > > > > I mean, the strings are the uAPI, not the integers, right? > > > > Both are uAPI these days. > > Yes. The integers are uAPI, if you change them you'll break libliftoff > users. There is an old thread discussing this somewhere. The tl;dr was > that there is no use-case for exposing the same string with a different > integer, so no good reason to justify the substantial complexity of > handling this case. If people actually depend on that we should probably have tests to make sure no one breaks it by accident. -- Ville Syrjälä Intel
Re: drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
It certainly is a learning process! Let me try to get things together properly myself, will be useful in the long run. Darrell On Thu, 9 Feb 2023 at 15:53, Hans de Goede wrote: > > Hi, > > On 2/9/23 16:36, Maxime Ripard wrote: > > Hi, > > > > On Wed, Feb 08, 2023 at 07:04:58PM +, Darrell Kavanagh wrote: > >> I've resolved this by adding a matching quirk in > >> drivers/firmware/efi/sysfb_efi.c - see below. > > Right, this is a known issue on Lenovo 2-in-1s with > the panel mounted 90 degree rotated issue. For some reason > the efifb info still gives a landscape resolution even though > the actual resolution really is portrait. This also messes > up the pitch of the framebuffer leading to the weird corrupted > looking output you saw. > > >> I've resolved this by adding a matching quirk in > >> drivers/firmware/efi/sysfb_efi.c - see below. > >> > >> Are you the right people to be notifying about this? > > > > Yes, we are. > > > > Howewer, please follow > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > > In particular, a proper commit log and your Signed-off-By tag is missing. > > Are we, do patches to that file go through drm-misc ? : > > [hans@shalem linux]$ scripts/get_maintainer.pl -f > drivers/firmware/efi/sysfb_efi.c > Ard Biesheuvel (maintainer:EXTENSIBLE FIRMWARE INTERFACE > (EFI)) > linux-...@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)) > linux-ker...@vger.kernel.org (open list) > > Either way this should be turned into a proper patch with a proper > Signed-off-By message as Maxime mentioned. > > My offer for the drm_panel_orientation_quirks.c patch to turn it into > a proper patch for you also extends to this one. If you want that, > please let me know and again add your Signed-off-by as a standalone > separate line in your reply so that I can use it for the commit message. > > Regards, > > Hans > >
[pull] amdgpu drm-fixes-6.2
Hi Dave, Daniel, A few last minute display fixes. The following changes since commit c6ac406cd8ff610a2d5da298b1d3071acfcde7f0: drm/amdgpu/smu: skip pptable init under sriov (2023-02-08 22:33:37 -0500) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.2-2023-02-09 for you to fetch changes up to e7d636476ba73e61460619bd8822e16af3cba509: Revert "drm/amd/display: disable S/G display on DCN 3.1.5" (2023-02-09 10:29:28 -0500) amd-drm-fixes-6.2-2023-02-09: amdgpu: - Add a parameter to disable S/G display - Re-enable S/G display on all DCNs Alex Deucher (4): drm/amdgpu: add S/G display parameter Revert "drm/amd/display: disable S/G display on DCN 3.1.2/3" Revert "drm/amd/display: disable S/G display on DCN 2.1.0" Revert "drm/amd/display: disable S/G display on DCN 3.1.5" drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++ 3 files changed, 19 insertions(+)
Re: [regression][6.0] After commit b261509952bc19d1012cf732f853659be6ebc61e I see WARNING message at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x63/0x70
Hi Mikhail, seems like your report flew past me, thanks for the ping. This might be a simple issue of not backing off when deadlock was hit. drm_atomic_normalize_zpos() can return an error code, and I ignored it (oops!) Can you give this patch a try? https://gitlab.freedesktop.org/-/snippets/7414 - Leo On 2/9/23 04:27, Mikhail Gavrilov wrote: Harry, please don't ignore me. This issue still happens in 6.1 and 6.2 Leo you are the author of the problematic commit please don't stand aside. Really nobody is interested in clean logs without warnings and errors? I am 100% sure that reverting commit b261509952bc19d1012cf732f853659be6ebc61e will stop these warnings. I also attached fresh logs from 6.2.0-0.rc6. 6.2-rc7 I started to build without commit b261509952bc19d1012cf732f853659be6ebc61e to avoid these warnings. On Thu, Oct 13, 2022 at 6:36 PM Mikhail Gavrilov Hi! I bisected an issue of the 6.0 kernel which started happening after 6.0-rc7 on all my machines. Backtrace of this issue looks like as: [ 2807.339439] [ cut here ] [ 2807.339445] WARNING: CPU: 11 PID: 2061 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x63/0x70 [ 2807.339453] Modules linked in: tls uinput rfcomm snd_seq_dummy snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr bnep intel_rapl_msr intel_rapl_common snd_sof_amd_renoir snd_sof_amd_acp snd_sof_pci snd_hda_codec_realtek sunrpc snd_sof snd_hda_codec_hdmi snd_hda_codec_generic snd_sof_utils snd_hda_intel snd_intel_dspcfg mt7921e snd_intel_sdw_acpi binfmt_misc snd_soc_core mt7921_common snd_hda_codec snd_compress vfat ac97_bus edac_mce_amd mt76_connac_lib snd_pcm_dmaengine fat snd_hda_core snd_rpl_pci_acp6x snd_pci_acp6x mt76 btusb snd_hwdep kvm_amd btrtl snd_seq btbcm mac80211 snd_seq_device kvm btintel btmtk libarc4 snd_pcm snd_pci_acp5x bluetooth snd_timer snd_rn_pci_acp3x irqbypass snd_acp_config snd_soc_acpi cfg80211 rapl snd joydev pcspkr asus_nb_wmi wmi_bmof [ 2807.339519] snd_pci_acp3x soundcore i2c_piix4 k10temp amd_pmc asus_wireless zram amdgpu drm_ttm_helper ttm hid_asus asus_wmi crct10dif_pclmul iommu_v2 crc32_pclmul ledtrig_audio crc32c_intel gpu_sched sparse_keymap platform_profile hid_multitouch polyval_clmulni nvme ucsi_acpi drm_buddy polyval_generic drm_display_helper ghash_clmulni_intel serio_raw nvme_core ccp typec_ucsi rfkill sp5100_tco r8169 cec nvme_common typec wmi video i2c_hid_acpi i2c_hid ip6_tables ip_tables fuse [ 2807.339540] Unloaded tainted modules: acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 acpi_cpufreq():1 amd64_edac():1 amd64_edac():1 acpi_cpufreq():1 pcc_cpufreq():1 fjes():1 amd64_edac():1 acpi_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 amd64_edac():1 acpi_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 fjes():1 acpi_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 fjes():1 acpi_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 acpi_cpufreq():1 fjes():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 acpi_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 fjes():1 acpi_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 fjes():1 [ 2807.339579] acpi_cpufreq():1 fjes():1 pcc_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 acpi_cpufreq():1 fjes():1 acpi_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 acpi_cpufreq():1 fjes():1 acpi_cpufreq():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 [ 2807.339596] CPU: 11 PID: 2061 Comm: gnome-shell Tainted: GW L 6.0.0-rc4-07-cb0eca01ad9756e853efec3301203c2b5b45aa9f+ #16 [ 2807.339598] Hardware name: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY/G513QY, BIOS G513QY.318 03/29/2022 [ 2807.339600] RIP: 0010:drm_modeset_drop_locks+0x63/0x70 [ 2807.339602] Code: 42 08 48 89 10 48 89 1b 48 8d bb 50 ff ff ff 48 89 5b 08 e8 3f 41 55 00 48 8b 45 78 49 39 c4 75 c6 5b 5d 41 5c c3 cc cc cc cc <0f> 0b eb ac 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 41 54 [ 2807.339604] RSP: 0018:b6ad46e07b80 EFLAGS: 00010282 [ 2807.339606] RAX: 0001 RBX: RCX: 0002 [ 2807.339607] RDX: 0001 RSI: a6a118b1 RDI: b6ad46e07c00 [ 2807.339608] RBP: b6ad46e07c00 R08: R09: [ 2807.339609] R10: R11: 0001 R12: [ 2807.339610] R13: 9801ca24bb00 R14: 9801ca24bb00 R15:
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On Thursday, February 9th, 2023 at 17:38, Joshua Ashton wrote: > > I mean, the strings are the uAPI, not the integers, right? > > Both are uAPI these days. Yes. The integers are uAPI, if you change them you'll break libliftoff users. There is an old thread discussing this somewhere. The tl;dr was that there is no use-case for exposing the same string with a different integer, so no good reason to justify the substantial complexity of handling this case.
Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum
On 2/8/23 09:30, Pekka Paalanen wrote:
On Fri, 3 Feb 2023 02:07:44 +
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.
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))
#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" },
{ DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
{ DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
/* Standard Definition Colorimetry based on IEC 61966-2-4 */
@@ -1066,9 +1066,9 @@ static const struct drm_prop_enum_list dp_colorspaces[] =
{
/* Colorimetry based on IEC 61966-2-5 [33] */
{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
/* 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 */
- {
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes our fixes for this week with a few patches targeting stable. drm-intel-fixes-2023-02-09: - Display watermark fix (Ville) - fbdev fix for PSR, FBC, DRRS (Jouni) - Move fd_install after last use of fence (Rob) - Initialize the obj flags for shmem objects (Aravind) - Fix VBT DSI DVO port handling (Ville) Thanks, Rodrigo. The following changes since commit 4ec5183ec48656cec489c49f989c508b68b518e3: Linux 6.2-rc7 (2023-02-05 13:13:28 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-02-09 for you to fetch changes up to 6a7ff131f17f44c593173c5ee30e2c03ef211685: drm/i915: Fix VBT DSI DVO port handling (2023-02-08 08:39:44 -0500) - Display watermark fix (Ville) - fbdev fix for PSR, FBC, DRRS (Jouni) - Move fd_install after last use of fence (Rob) - Initialize the obj flags for shmem objects (Aravind) - Fix VBT DSI DVO port handling (Ville) Aravind Iddamsetty (1): drm/i915: Initialize the obj flags for shmem objects Jouni Högander (1): drm/i915/fbdev: Implement fb_dirty for intel custom fb helper Rob Clark (1): drm/i915: Move fd_install after last use of fence Ville Syrjälä (2): drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabled drm/i915: Fix VBT DSI DVO port handling drivers/gpu/drm/i915/display/intel_bios.c | 33 ++ drivers/gpu/drm/i915/display/intel_fbdev.c | 12 ++ drivers/gpu/drm/i915/display/skl_watermark.c | 3 ++- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +-- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +- 5 files changed, 45 insertions(+), 19 deletions(-)
Re: drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
Hi, On 2/9/23 16:36, Maxime Ripard wrote: > Hi, > > On Wed, Feb 08, 2023 at 07:04:58PM +, Darrell Kavanagh wrote: >> I've resolved this by adding a matching quirk in >> drivers/firmware/efi/sysfb_efi.c - see below. Right, this is a known issue on Lenovo 2-in-1s with the panel mounted 90 degree rotated issue. For some reason the efifb info still gives a landscape resolution even though the actual resolution really is portrait. This also messes up the pitch of the framebuffer leading to the weird corrupted looking output you saw. >> I've resolved this by adding a matching quirk in >> drivers/firmware/efi/sysfb_efi.c - see below. >> >> Are you the right people to be notifying about this? > > Yes, we are. > > Howewer, please follow > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > In particular, a proper commit log and your Signed-off-By tag is missing. Are we, do patches to that file go through drm-misc ? : [hans@shalem linux]$ scripts/get_maintainer.pl -f drivers/firmware/efi/sysfb_efi.c Ard Biesheuvel (maintainer:EXTENSIBLE FIRMWARE INTERFACE (EFI)) linux-...@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)) linux-ker...@vger.kernel.org (open list) Either way this should be turned into a proper patch with a proper Signed-off-By message as Maxime mentioned. My offer for the drm_panel_orientation_quirks.c patch to turn it into a proper patch for you also extends to this one. If you want that, please let me know and again add your Signed-off-by as a standalone separate line in your reply so that I can use it for the commit message. Regards, Hans
Re: Try to address the drm_debugfs issues
Am 09.02.23 um 15:19 schrieb Maxime Ripard: On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote: Am 09.02.23 um 14:06 schrieb Maíra Canal: On 2/9/23 09:13, Christian König wrote: Am 09.02.23 um 12:23 schrieb Maíra Canal: On 2/9/23 05:18, Christian König wrote: Hello everyone, the drm_debugfs has a couple of well known design problems. Especially it wasn't possible to add files between initializing and registering of DRM devices since the underlying debugfs directory wasn't created yet. The resulting necessity of the driver->debugfs_init() callback function is a mid-layering which is really frowned on since it creates a horrible driver->DRM->driver design layering. The recent patch "drm/debugfs: create device-centered debugfs functions" tried to address those problem, but doesn't seem to work correctly. This looks like a misunderstanding of the call flow around drm_debugfs_init(), which is called multiple times, once for the primary and once for the render node. So what happens now is the following: 1. drm_dev_init() initially allocates the drm_minor objects. 2. ... back to the driver ... 3. drm_dev_register() is called. 4. drm_debugfs_init() is called for the primary node. 5. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() to add the files for the primary node. 6. The driver->debugfs_init() callback is called to add debugfs files for the primary node. 7. The added files are consumed and added to the primary node debugfs directory. 8. drm_debugfs_init() is called for the render node. 9. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() to add the files again for the render node. 10. The driver->debugfs_init() callback is called to add debugfs files for the render node. 11. The added files are consumed and added to the render node debugfs directory. 12. Some more files are added through drm_debugfs_add_file(). 13. drm_debugfs_late_register() add the files once more to the primary node debugfs directory. 14. From this point on files added through drm_debugfs_add_file() are simply ignored. 15. ... back to the driver ... Because of this the dev->debugfs_mutex lock is also completely pointless since any concurrent use of the interface would just randomly either add the files to the primary or render node or just not at all. Even worse is that this implementation nails the coffin for removing the driver->debugfs_init() mid-layering because otherwise drivers can't control where their debugfs (primary/render node) are actually added. This patch set here now tries to clean this up a bit, but most likely isn't fully complete either since I didn't audit every driver/call path. I tested the patchset on the v3d, vc4 and vkms and all the files are generated as expected, but I'm getting the following errors on dmesg: [ 3.872026] debugfs: File 'v3d_ident' in directory '0' already present! [ 3.872064] debugfs: File 'v3d_ident' in directory '128' already present! [ 3.872078] debugfs: File 'v3d_regs' in directory '0' already present! [ 3.872087] debugfs: File 'v3d_regs' in directory '128' already present! [ 3.872097] debugfs: File 'measure_clock' in directory '0' already present! [ 3.872105] debugfs: File 'measure_clock' in directory '128' already present! [ 3.872116] debugfs: File 'bo_stats' in directory '0' already present! [ 3.872124] debugfs: File 'bo_stats' in directory '128' already present! It looks like the render node is being added twice, since this doesn't happen for vc4 and vkms. Thanks for the feedback and yes that's exactly what I meant with that I haven't looked into all code paths. Could it be that v3d registers it's debugfs files from the debugfs_init callback? Although this is true, I'm not sure if this is the reason why the files are being registered twice, as this doesn't happen to vc4, and it also uses the debugfs_init callback. I believe it is somewhat related to the fact that v3d is the primary node and the render node. I see. Thanks for the hint. Best Regards, - Maíra Canal One alternative would be to just completely nuke support for separate render node debugfs files and only add a symlink to the primary node. Opinions? What do you think of this approach? I can't come up with any reason why we should have separate debugfs files for render nodes and I think it is pretty much the same reason you came up with the patch for per device debugfs files instead of per minor. They are two entirely separate devices and drivers, it doesn't make much sense to move their debugfs files to one or the other. Well exactly that isn't true. The primary and render node are just two file under /dev for the same hardware device and driver. We just offer different functionality through the two interfaces, but essentially there isn't any information we could expose for one which
Re: drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
Hi Darrell,
On 2/3/23 19:32, Darrell Kavanagh wrote:
> Hi,
>
> This is another Lenovo with detachable keyboard and 1200x1920 screen
> mounted sideways.
>
> The following has been tested with 6.2.0-rc6.
>
> Thanks,
> Darrell
Thank you for your patch. Note that instead of "Hi, ... Thanks, Darrell"
there should be a message describing the what and why of the patch
here, see e.g. :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_panel_orientation_quirks.c?id=653f2d94fcda200b02bd79cea2e0307b26c1b747
I also notice that the diff output below has a bit weird file-paths,
so this patch is clearly not the output of "git format-patch" +
"git send-email" on a standard linux source tree git clone.
The whole kernel patch workflow can be a bit daunting if you are just
trying to submit a small quirk like this.
So you can either try again if you want to, or I can fix all of this up
for you if that is preferred.
If you want me to fix this up for you, there is one thing which I still
need from you, your patch is missing a Signed-off-by line in the commit-message.
I can only accept patches with a Signed-off-by line in the commit-message like
this:
Signed-off-by: Your Real Name
By adding this line you indicate that you are the author of the code and
are submitting it under the existing license for the file which you are
modifying (typically GPL-2.0) or that you have permission from the author
to submit it under this license. See:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
If you want me to fix this up for you, please reply to this email
with the proper Signed-off-by: ... line for me to add to the commit
message.
Regards,
Hans
>
> index 3659f04..590bb7b 100644
> --- a/kernel/drm_panel_orientation
> _quirks.c
> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> D330-10IGM"),
> },
> .driver_data = (void *)_rightside_up,
> + }, {/* Lenovo IdeaPad Duet 3 10IGL5 */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3
> 10IGL5"),
> + },
> + .driver_data = (void *)_rightside_up,
> }, {/* Lenovo Ideapad D330-10IGL (HD) */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>
Re: [PATCH v3 0/4] Reserve DSPPs based on user request
Hi, On Thu, Feb 9, 2023 at 3:26 AM Kalyan Thota wrote: > > Kindly ignore my previous email. Sent too early !! > > We have tested the changes on top of tip: > https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/heads/chromeos-5.15 > + 5 CTM patches ( that you have quoted ) > We didn’t see the issue that you have reported on herobrine. Night light > always came up on primary display as the reservation with dspp was > successful. Are you seeing any reservation failures for primary display ? > > Attached a debug patch, can you share the logs when you see the issue. Sounds good. Since officially this hardware is not available to the public at this time, I have shared the `dmesg` privately to your (and Abhinav's) Google partner accounts. Yell if you don't see the notificatioin. I don't have any reason to believe there's anything secret in the dmesg, but it didn't seem worth the time to fully audit it. For that dmesg, I: 1. Made sure that night light was off. 2. Updated the kernel with the 5 patches + the debug patch. 3. Booted up and logged into ChromeOS 4. Tried turning night light off/on several times and saw nothing on dmesg while I did this (and night light didn't work) 5. Unplugged power and servo (just to make sure they didn't interfere) 6. Echoed "DOUG: plug in external display now" several times to "/dev/kmsg" 7. Plugged in my external display, which is behind a Type C dock 8. Turned night light on/off several times. Night light worked on the internal display. In case it matters, my ChromeOS root filesystem is R111-15328.0.0 > >-Original Message- > >From: Kalyan Thota > >Sent: Thursday, February 9, 2023 9:47 AM > >To: Doug Anderson ; Kalyan Thota (QUIC) > > > >Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > >freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- > >ker...@vger.kernel.org; robdcl...@chromium.org; swb...@chromium.org; > >Vinod Polimera (QUIC) ; > >dmitry.barysh...@linaro.org; Abhinav Kumar (QUIC) > >; marijn.suij...@somainline.org > >Subject: RE: [PATCH v3 0/4] Reserve DSPPs based on user request > > > >Hi Doug, > > > >Have you picked the core change to program dspp's (below) ? the current > >series > >will go on top of it. > >https://patchwork.kernel.org/project/linux-arm-msm/patch/1671542719-12655- > >1-git-send-email-quic_kaly...@quicinc.com/ > > > >Thanks, > >Kalyan > > > >>-Original Message- > >>From: Doug Anderson > >>Sent: Wednesday, February 8, 2023 10:44 PM > >>To: Kalyan Thota (QUIC) > >>Cc: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > >>freedr...@lists.freedesktop.org; devicet...@vger.kernel.org; linux- > >>ker...@vger.kernel.org; robdcl...@chromium.org; swb...@chromium.org; > >>Vinod Polimera (QUIC) ; > >>dmitry.barysh...@linaro.org; Abhinav Kumar (QUIC) > >>; marijn.suij...@somainline.org > >>Subject: Re: [PATCH v3 0/4] Reserve DSPPs based on user request > >> > >>WARNING: This email originated from outside of Qualcomm. Please be wary > >>of any links or attachments, and do not enable macros. > >> > >>Hi, > >> > >>On Wed, Feb 8, 2023 at 5:42 AM Kalyan Thota > >>wrote: > >>> > >>> This series will enable color features on sc7280 target which has > >>> primary panel as eDP > >>> > >>> The series removes DSPP allocation based on encoder type and allows > >>> the DSPP reservation based on user request via CTM. > >>> > >>> The series will release/reserve the dpu resources when ever there is > >>> a topology change to suit the new requirements. > >>> > >>> Kalyan Thota (4): > >>> drm/msm/dpu: clear DSPP reservations in rm release > >>> drm/msm/dpu: add DSPPs into reservation upon a CTM request > >>> drm/msm/dpu: avoid unnecessary check in DPU reservations > >>> drm/msm/dpu: reserve the resources on topology change > >>> > >>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 2 + > >>> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 58 > >>> -- > >>--- > >>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 + > >>> 3 files changed, 37 insertions(+), 25 deletions(-) > >> > >>I tried out your changes, but unfortunately it seems like there's something > >wrong. > >>:( I did this: > >> > >>1. Picked your 5 patches to the chromeos-5.15 tree (this series plus > >>[1]) > >> > >>2. Put them on herobrine villager. > >> > >>3. Booted up with no external display plugged in. > >> > >>4. Tried to enable night light in the ChromeOS UI. > >> > >>5. Night light didn't turn on for the internal display. > >> > >> > >>I also tried applying them to the top of msm-next (had to resolve some > >>small conflicts). Same thing, night light didn't work. > >> > >> > >>I thought maybe this was because the Chrome browser hasn't been updated > >>to properly use atomic_check for testing for night light, so I hacked > >>my herobrine device tree to not mark "mdss_dp" as "okay". Now there's _only_ > >an eDP display. > >>Same thing, night light didn't work. > >> > >> >
[RFC 3/3] drm/i915: Waitboost external waits
From: Tvrtko Ursulin
Userspace waits coming via the drm_syncobj route have so far been
bypassing the waitboost mechanism.
Use the previously added dma-fence wait tracking API and apply the
same waitboosting logic which applies to other entry points.
This should fix the perfomance regressions experience by clvk and
similar userspace which relies on drm_syncobj.
At the same time, but for documentation purposes only, use the new
dma-fence API from i915_request_wait too.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..e24fac5c1567 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -94,7 +94,12 @@ static bool i915_fence_signaled(struct dma_fence *fence)
static bool i915_fence_enable_signaling(struct dma_fence *fence)
{
- return i915_request_enable_breadcrumb(to_request(fence));
+ struct i915_request *rq = to_request(fence);
+
+ if (dma_fence_wait_count(>fence) && !i915_request_started(rq))
+ intel_rps_boost(rq);
+
+ return i915_request_enable_breadcrumb(rq);
}
static signed long i915_fence_wait(struct dma_fence *fence,
@@ -2037,11 +2042,13 @@ long i915_request_wait_timeout(struct i915_request *rq,
* but at a cost of spending more power processing the workload
* (bad for battery).
*/
- if (flags & I915_WAIT_PRIORITY && !i915_request_started(rq))
+ if (((flags & I915_WAIT_PRIORITY) || dma_fence_wait_count(>fence))
+ && !i915_request_started(rq))
intel_rps_boost(rq);
wait.tsk = current;
- if (dma_fence_add_callback(>fence, , request_wait_wake))
+ if (dma_fence_add_wait_callback(>fence, ,
+ request_wait_wake))
goto out;
/*
--
2.34.1
[RFC 2/3] drm/syncobj: Mark syncobj waits as external waiters
From: Tvrtko Ursulin
Use the previously added dma-fence tracking of explicit waiters.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..776b90774a64 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1065,9 +1065,9 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
if ((flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE) ||
dma_fence_is_signaled(fence) ||
(!entries[i].fence_cb.func &&
-dma_fence_add_callback(fence,
- [i].fence_cb,
- syncobj_wait_fence_func))) {
+dma_fence_add_wait_callback(fence,
+[i].fence_cb,
+
syncobj_wait_fence_func))) {
/* The fence has been signaled */
if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL) {
signaled_count++;
--
2.34.1
[RFC 1/3] dma-fence: Track explicit waiters
From: Tvrtko Ursulin
Track how many callers are explicity waiting on a fence to signal and
allow querying that via new dma_fence_wait_count() API.
This provides infrastructure on top of which generic "waitboost" concepts
can be implemented by individual drivers. Wait-boosting is any reactive
activity, such as raising the GPU clocks, which happens while there are
active external waiters.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 102 ++--
include/linux/dma-fence.h | 14 +
2 files changed, 88 insertions(+), 28 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0de0482cd36e..d463c06ebd6d 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -344,6 +344,24 @@ void __dma_fence_might_wait(void)
}
#endif
+static void incr_wait_count(struct dma_fence *fence, struct dma_fence_cb *cb)
+{
+ lockdep_assert_held(fence->lock);
+
+ __set_bit(DMA_FENCE_CB_FLAG_WAITCOUNT_BIT, >flags);
+ fence->waitcount++;
+ WARN_ON_ONCE(!fence->waitcount);
+}
+
+static void decr_wait_count(struct dma_fence *fence, struct dma_fence_cb *cb)
+{
+ lockdep_assert_held(fence->lock);
+
+ if (__test_and_clear_bit(DMA_FENCE_CB_FLAG_WAITCOUNT_BIT, >flags)) {
+ WARN_ON_ONCE(!fence->waitcount);
+ fence->waitcount--;
+ }
+}
/**
* dma_fence_signal_timestamp_locked - signal completion of a fence
@@ -384,6 +402,7 @@ int dma_fence_signal_timestamp_locked(struct dma_fence
*fence,
list_for_each_entry_safe(cur, tmp, _list, node) {
INIT_LIST_HEAD(>node);
+ decr_wait_count(fence, cur);
cur->func(fence, cur);
}
@@ -612,35 +631,15 @@ void dma_fence_enable_sw_signaling(struct dma_fence
*fence)
unsigned long flags;
spin_lock_irqsave(fence->lock, flags);
+ fence->waitcount++;
+ WARN_ON_ONCE(!fence->waitcount);
__dma_fence_enable_signaling(fence);
spin_unlock_irqrestore(fence->lock, flags);
}
EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
-/**
- * dma_fence_add_callback - add a callback to be called when the fence
- * is signaled
- * @fence: the fence to wait on
- * @cb: the callback to register
- * @func: the function to call
- *
- * Add a software callback to the fence. The caller should keep a reference to
- * the fence.
- *
- * @cb will be initialized by dma_fence_add_callback(), no initialization
- * by the caller is required. Any number of callbacks can be registered
- * to a fence, but a callback can only be registered to one fence at a time.
- *
- * If fence is already signaled, this function will return -ENOENT (and
- * *not* call the callback).
- *
- * Note that the callback can be called from an atomic context or irq context.
- *
- * Returns 0 in case of success, -ENOENT if the fence is already signaled
- * and -EINVAL in case of error.
- */
-int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
- dma_fence_func_t func)
+static int add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
+ dma_fence_func_t func, bool wait)
{
unsigned long flags;
int ret = 0;
@@ -655,10 +654,15 @@ int dma_fence_add_callback(struct dma_fence *fence,
struct dma_fence_cb *cb,
spin_lock_irqsave(fence->lock, flags);
+ if (wait)
+ incr_wait_count(fence, cb);
+
if (__dma_fence_enable_signaling(fence)) {
cb->func = func;
list_add_tail(>node, >cb_list);
} else {
+ if (wait)
+ decr_wait_count(fence, cb);
INIT_LIST_HEAD(>node);
ret = -ENOENT;
}
@@ -667,8 +671,44 @@ int dma_fence_add_callback(struct dma_fence *fence, struct
dma_fence_cb *cb,
return ret;
}
+
+/**
+ * dma_fence_add_callback - add a callback to be called when the fence
+ * is signaled
+ * @fence: the fence to wait on
+ * @cb: the callback to register
+ * @func: the function to call
+ *
+ * Add a software callback to the fence. The caller should keep a reference to
+ * the fence.
+ *
+ * @cb will be initialized by dma_fence_add_callback(), no initialization
+ * by the caller is required. Any number of callbacks can be registered
+ * to a fence, but a callback can only be registered to one fence at a time.
+ *
+ * If fence is already signaled, this function will return -ENOENT (and
+ * *not* call the callback).
+ *
+ * Note that the callback can be called from an atomic context or irq context.
+ *
+ * Returns 0 in case of success, -ENOENT if the fence is already signaled
+ * and -EINVAL in case of error.
+ */
+int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
+ dma_fence_func_t func)
+{
+ return add_callback(fence, cb, func, false);
+}
EXPORT_SYMBOL(dma_fence_add_callback);
+int
[RFC 0/3] Waitboost drm syncobj waits
From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences which are actively waited upon from userspace. This has it's pros and cons and can certainly be discussed at lenght. However fact is some workloads really like it. Problem is that with the arrival of drm syncobj and a new userspace waiting entry point it added, the waitboost mechanism was bypassed. Hence I cooked up this mini series really (really) quickly to see if some discussion can be had. It adds a concept of "wait count" to dma fence, which is incremented for every explicit dma_fence_enable_sw_signaling and dma_fence_add_wait_callback (like dma_fence_add_callback but from explicit/userspace wait paths). Individual drivers can then inspect this via dma_fence_wait_count() and decide to wait boost the waits on such fences. Again, quickly put together and smoke tested only - no guarantees whatsoever and I will rely on interested parties to test and report if it even works or how well. Tvrtko Ursulin (3): dma-fence: Track explicit waiters drm/syncobj: Mark syncobj waits as external waiters drm/i915: Waitboost external waits drivers/dma-buf/dma-fence.c | 102 drivers/gpu/drm/drm_syncobj.c | 6 +- drivers/gpu/drm/i915/i915_request.c | 13 +++- include/linux/dma-fence.h | 14 4 files changed, 101 insertions(+), 34 deletions(-) -- 2.34.1
[PATCH 5/6] drm/tidss: Remove return values from dispc_plane_{setup, enable}()
Calls to dispc_plane_setup() and dispc_plane_enable() cannot fail.
Remove the return value.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_dispc.c | 12
drivers/gpu/drm/tidss/tidss_dispc.h | 8
drivers/gpu/drm/tidss/tidss_plane.c | 11 +--
3 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 165365b515e1..dca077411f77 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -1985,9 +1985,9 @@ dma_addr_t dispc_plane_state_p_uv_addr(const struct
drm_plane_state *state)
(y * fb->pitches[1] / fb->format->vsub);
}
-int dispc_plane_setup(struct dispc_device *dispc, u32 hw_plane,
- const struct drm_plane_state *state,
- u32 hw_videoport)
+void dispc_plane_setup(struct dispc_device *dispc, u32 hw_plane,
+ const struct drm_plane_state *state,
+ u32 hw_videoport)
{
bool lite = dispc->feat->vid_lite[hw_plane];
u32 fourcc = state->fb->format->format;
@@ -2066,15 +2066,11 @@ int dispc_plane_setup(struct dispc_device *dispc, u32
hw_plane,
else
VID_REG_FLD_MOD(dispc, hw_plane, DISPC_VID_ATTRIBUTES, 0,
28, 28);
-
- return 0;
}
-int dispc_plane_enable(struct dispc_device *dispc, u32 hw_plane, bool enable)
+void dispc_plane_enable(struct dispc_device *dispc, u32 hw_plane, bool enable)
{
VID_REG_FLD_MOD(dispc, hw_plane, DISPC_VID_ATTRIBUTES, !!enable, 0, 0);
-
- return 0;
}
static u32 dispc_vid_get_fifo_size(struct dispc_device *dispc, u32 hw_plane)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h
b/drivers/gpu/drm/tidss/tidss_dispc.h
index e49432f0abf5..946ed769caaf 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -123,10 +123,10 @@ int dispc_runtime_resume(struct dispc_device *dispc);
int dispc_plane_check(struct dispc_device *dispc, u32 hw_plane,
const struct drm_plane_state *state,
u32 hw_videoport);
-int dispc_plane_setup(struct dispc_device *dispc, u32 hw_plane,
- const struct drm_plane_state *state,
- u32 hw_videoport);
-int dispc_plane_enable(struct dispc_device *dispc, u32 hw_plane, bool enable);
+void dispc_plane_setup(struct dispc_device *dispc, u32 hw_plane,
+ const struct drm_plane_state *state,
+ u32 hw_videoport);
+void dispc_plane_enable(struct dispc_device *dispc, u32 hw_plane, bool enable);
const u32 *dispc_plane_formats(struct dispc_device *dispc, unsigned int *len);
int dispc_init(struct tidss_device *tidss);
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
b/drivers/gpu/drm/tidss/tidss_plane.c
index fe2c41f0cd4f..0b12405edb47 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -113,7 +113,6 @@ static void tidss_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *new_state =
drm_atomic_get_new_plane_state(state,
plane);
u32 hw_videoport;
- int ret;
dev_dbg(ddev->dev, "%s\n", __func__);
@@ -124,15 +123,7 @@ static void tidss_plane_atomic_update(struct drm_plane
*plane,
hw_videoport = to_tidss_crtc(new_state->crtc)->hw_videoport;
- ret = dispc_plane_setup(tidss->dispc, tplane->hw_plane_id,
- new_state, hw_videoport);
-
- if (ret) {
- dev_err(plane->dev->dev, "%s: Failed to setup plane %d\n",
- __func__, tplane->hw_plane_id);
- dispc_plane_enable(tidss->dispc, tplane->hw_plane_id, false);
- return;
- }
+ dispc_plane_setup(tidss->dispc, tplane->hw_plane_id, new_state,
hw_videoport);
dispc_plane_enable(tidss->dispc, tplane->hw_plane_id, true);
}
--
2.39.1
[PATCH 4/6] drm/mgag200: Implement struct drm_plane_helper_funcs.atomic_enable
Enable the primary plane for mgag200 hardware via atomic_enable.
Atomic helpers invoke this callback only when the plane becomes
active.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +++
drivers/gpu/drm/mgag200/mgag200_mode.c | 19 ---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 9e604dbb8e44..57c7edcab602 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -375,12 +375,15 @@ int mgag200_primary_plane_helper_atomic_check(struct
drm_plane *plane,
struct drm_atomic_state
*new_state);
void mgag200_primary_plane_helper_atomic_update(struct drm_plane *plane,
struct drm_atomic_state
*old_state);
+void mgag200_primary_plane_helper_atomic_enable(struct drm_plane *plane,
+ struct drm_atomic_state *state);
void mgag200_primary_plane_helper_atomic_disable(struct drm_plane *plane,
struct drm_atomic_state
*old_state);
#define MGAG200_PRIMARY_PLANE_HELPER_FUNCS \
DRM_GEM_SHADOW_PLANE_HELPER_FUNCS, \
.atomic_check = mgag200_primary_plane_helper_atomic_check, \
.atomic_update = mgag200_primary_plane_helper_atomic_update, \
+ .atomic_enable = mgag200_primary_plane_helper_atomic_enable, \
.atomic_disable = mgag200_primary_plane_helper_atomic_disable
#define MGAG200_PRIMARY_PLANE_FUNCS \
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 47e86eadb239..0f2dd26755df 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -501,7 +501,6 @@ void mgag200_primary_plane_helper_atomic_update(struct
drm_plane *plane,
struct drm_framebuffer *fb = plane_state->fb;
struct drm_atomic_helper_damage_iter iter;
struct drm_rect damage;
- u8 seq1;
drm_atomic_helper_damage_iter_init(, old_plane_state, plane_state);
drm_atomic_for_each_plane_damage(, ) {
@@ -511,13 +510,19 @@ void mgag200_primary_plane_helper_atomic_update(struct
drm_plane *plane,
/* Always scanout image at VRAM offset 0 */
mgag200_set_startadd(mdev, (u32)0);
mgag200_set_offset(mdev, fb);
+}
- if (!old_plane_state->crtc && plane_state->crtc) { // enabling
- RREG_SEQ(0x01, seq1);
- seq1 &= ~MGAREG_SEQ1_SCROFF;
- WREG_SEQ(0x01, seq1);
- msleep(20);
- }
+void mgag200_primary_plane_helper_atomic_enable(struct drm_plane *plane,
+ struct drm_atomic_state *state)
+{
+ struct drm_device *dev = plane->dev;
+ struct mga_device *mdev = to_mga_device(dev);
+ u8 seq1;
+
+ RREG_SEQ(0x01, seq1);
+ seq1 &= ~MGAREG_SEQ1_SCROFF;
+ WREG_SEQ(0x01, seq1);
+ msleep(20);
}
void mgag200_primary_plane_helper_atomic_disable(struct drm_plane *plane,
--
2.39.1
[PATCH 3/6] drm/mgag200: Remove disable handling from atomic_update
The primary plane has the atomic_disable helper set, so atomic_update
won't be called if the plane gets disabled. Remove the respective branch
from the helper.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 0a5aaf78172a..47e86eadb239 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -503,9 +503,6 @@ void mgag200_primary_plane_helper_atomic_update(struct
drm_plane *plane,
struct drm_rect damage;
u8 seq1;
- if (!fb)
- return;
-
drm_atomic_helper_damage_iter_init(, old_plane_state, plane_state);
drm_atomic_for_each_plane_damage(, ) {
mgag200_handle_damage(mdev, shadow_plane_state->data, fb,
);
--
2.39.1
[PATCH 2/6] drm/ast: Implement struct drm_plane_helper_funcs.atomic_enable
Enable the primary plane for ast hardware via atomic_enable. Atomic
helpers invoke this callback only when the plane becomes active.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index dcb8ced4ce75..7e8a6a39de35 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -672,17 +672,28 @@ static void ast_primary_plane_helper_atomic_update(struct
drm_plane *plane,
/*
* Some BMCs stop scanning out the video signal after the driver
-* reprogrammed the offset or scanout address. This stalls display
-* output for several seconds and makes the display unusable.
-* Therefore only update the offset if it changes and reprogram the
-* address after enabling the plane.
+* reprogrammed the offset. This stalls display output for several
+* seconds and makes the display unusable. Therefore only update
+* the offset if it changes.
*/
if (!old_fb || old_fb->pitches[0] != fb->pitches[0])
ast_set_offset_reg(ast, fb);
- if (!old_fb) {
- ast_set_start_address_crt1(ast, (u32)ast_plane->offset);
- ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0x00);
- }
+}
+
+static void ast_primary_plane_helper_atomic_enable(struct drm_plane *plane,
+ struct drm_atomic_state
*state)
+{
+ struct ast_private *ast = to_ast_private(plane->dev);
+ struct ast_plane *ast_plane = to_ast_plane(plane);
+
+ /*
+* Some BMCs stop scanning out the video signal after the driver
+* reprogrammed the scanout address. This stalls display
+* output for several seconds and makes the display unusable.
+* Therefore only reprogram the address after enabling the plane.
+*/
+ ast_set_start_address_crt1(ast, (u32)ast_plane->offset);
+ ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0x00);
}
static void ast_primary_plane_helper_atomic_disable(struct drm_plane *plane,
@@ -697,6 +708,7 @@ static const struct drm_plane_helper_funcs
ast_primary_plane_helper_funcs = {
DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
.atomic_check = ast_primary_plane_helper_atomic_check,
.atomic_update = ast_primary_plane_helper_atomic_update,
+ .atomic_enable = ast_primary_plane_helper_atomic_enable,
.atomic_disable = ast_primary_plane_helper_atomic_disable,
};
--
2.39.1
[PATCH 6/6] drm/tidss: Implement struct drm_plane_helper_funcs.atomic_enable
Enable the primary plane for tidss hardware via atomic_enable.
Atomic helpers invoke this callback only when the plane becomes
active.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_plane.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c
b/drivers/gpu/drm/tidss/tidss_plane.c
index 0b12405edb47..6bdd6e4a955a 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -124,6 +124,16 @@ static void tidss_plane_atomic_update(struct drm_plane
*plane,
hw_videoport = to_tidss_crtc(new_state->crtc)->hw_videoport;
dispc_plane_setup(tidss->dispc, tplane->hw_plane_id, new_state,
hw_videoport);
+}
+
+static void tidss_plane_atomic_enable(struct drm_plane *plane,
+ struct drm_atomic_state *state)
+{
+ struct drm_device *ddev = plane->dev;
+ struct tidss_device *tidss = to_tidss(ddev);
+ struct tidss_plane *tplane = to_tidss_plane(plane);
+
+ dev_dbg(ddev->dev, "%s\n", __func__);
dispc_plane_enable(tidss->dispc, tplane->hw_plane_id, true);
}
@@ -151,6 +161,7 @@ static void drm_plane_destroy(struct drm_plane *plane)
static const struct drm_plane_helper_funcs tidss_plane_helper_funcs = {
.atomic_check = tidss_plane_atomic_check,
.atomic_update = tidss_plane_atomic_update,
+ .atomic_enable = tidss_plane_atomic_enable,
.atomic_disable = tidss_plane_atomic_disable,
};
--
2.39.1
[PATCH 1/6] drm/atomic-helper: Add atomic_enable plane-helper callback
Add atomic_enable to struct drm_plane_helper_funcs. It enables a
plane independently from updating the plane's content. As such, it is
the inverse of the atomic_disable plane helper. Useful for hardware
where plane enable state is independent from plane content.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_atomic_helper.c | 20
include/drm/drm_atomic_helper.h | 26 +
include/drm/drm_modeset_helper_vtables.h | 29 +++-
3 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d579fd8f7cb8..8606876f7233 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2702,6 +2702,11 @@ void drm_atomic_helper_commit_planes(struct drm_device
*dev,
funcs->atomic_disable(plane, old_state);
} else if (new_plane_state->crtc || disabling) {
funcs->atomic_update(plane, old_state);
+
+ if (!disabling && funcs->atomic_enable) {
+ if (drm_atomic_plane_enabling(old_plane_state,
new_plane_state))
+ funcs->atomic_enable(plane, old_state);
+ }
}
}
@@ -2762,6 +2767,7 @@ drm_atomic_helper_commit_planes_on_crtc(struct
drm_crtc_state *old_crtc_state)
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(old_state, plane);
const struct drm_plane_helper_funcs *plane_funcs;
+ bool disabling;
plane_funcs = plane->helper_private;
@@ -2771,12 +2777,18 @@ drm_atomic_helper_commit_planes_on_crtc(struct
drm_crtc_state *old_crtc_state)
WARN_ON(new_plane_state->crtc &&
new_plane_state->crtc != crtc);
- if (drm_atomic_plane_disabling(old_plane_state,
new_plane_state) &&
- plane_funcs->atomic_disable)
+ disabling = drm_atomic_plane_disabling(old_plane_state,
new_plane_state);
+
+ if (disabling && plane_funcs->atomic_disable) {
plane_funcs->atomic_disable(plane, old_state);
- else if (new_plane_state->crtc ||
-drm_atomic_plane_disabling(old_plane_state,
new_plane_state))
+ } else if (new_plane_state->crtc || disabling) {
plane_funcs->atomic_update(plane, old_state);
+
+ if (!disabling && plane_funcs->atomic_enable) {
+ if (drm_atomic_plane_enabling(old_plane_state,
new_plane_state))
+ plane_funcs->atomic_enable(plane,
old_state);
+ }
+ }
}
if (crtc_funcs && crtc_funcs->atomic_flush)
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 33f982cd1a27..536a0b0091c3 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -209,6 +209,32 @@ int drm_atomic_helper_page_flip_target(
__drm_atomic_get_current_plane_state((crtc_state)->state, \
plane)))
+/**
+ * drm_atomic_plane_enabling - check whether a plane is being enabled
+ * @old_plane_state: old atomic plane state
+ * @new_plane_state: new atomic plane state
+ *
+ * Checks the atomic state of a plane to determine whether it's being enabled
+ * or not. This also WARNs if it detects an invalid state (both CRTC and FB
+ * need to either both be NULL or both be non-NULL).
+ *
+ * RETURNS:
+ * True if the plane is being enabled, false otherwise.
+ */
+static inline bool drm_atomic_plane_enabling(struct drm_plane_state
*old_plane_state,
+struct drm_plane_state
*new_plane_state)
+{
+ /*
+* When enabling a plane, CRTC and FB should always be set together.
+* Anything else should be considered a bug in the atomic core, so we
+* gently warn about it.
+*/
+ WARN_ON((!new_plane_state->crtc && new_plane_state->fb) ||
+ (new_plane_state->crtc && !new_plane_state->fb));
+
+ return !old_plane_state->crtc && new_plane_state->crtc;
+}
+
/**
* drm_atomic_plane_disabling - check whether a plane is being disabled
* @old_plane_state: old atomic plane state
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index 206f495bbf06..965faf082a6d 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1331,6 +1331,32 @@ struct drm_plane_helper_funcs {
*/
void (*atomic_update)(struct drm_plane *plane,
struct drm_atomic_state *state);
+
+ /**
+*
[PATCH 0/6] drm: Add struct drm_plane_helper_funcs.atomic_enable
Add atomic_enable, a plane helper that enables a plane. It is supposed
to be the inverse of atomic_disable.
While atomic_update can handle all of a plane's enable, disable and
update functionality, many drivers also implement atomic_disable to
do disabling separately. Some drivers also try to detect whether the
plane gets enabled and can benefit if DRM's atomic helpers already
do this. Give them the respective callback. At least in the case of
ast, avoiding to enable the primary plane improves performance with
some BMCs.
Tested on AST2100 hardware.
Thomas Zimmermann (6):
drm/atomic-helper: Add atomic_enable plane-helper callback
drm/ast: Implement struct drm_plane_helper_funcs.atomic_enable
drm/mgag200: Remove disable handling from atomic_update
drm/mgag200: Implement struct drm_plane_helper_funcs.atomic_enable
drm/tidss: Remove return values from dispc_plane_{setup,enable}()
drm/tidss: Implement struct drm_plane_helper_funcs.atomic_enable
drivers/gpu/drm/ast/ast_mode.c | 28 ---
drivers/gpu/drm/drm_atomic_helper.c | 20
drivers/gpu/drm/mgag200/mgag200_drv.h| 3 +++
drivers/gpu/drm/mgag200/mgag200_mode.c | 22 ++
drivers/gpu/drm/tidss/tidss_dispc.c | 12 --
drivers/gpu/drm/tidss/tidss_dispc.h | 8 +++
drivers/gpu/drm/tidss/tidss_plane.c | 20
include/drm/drm_atomic_helper.h | 26 +
include/drm/drm_modeset_helper_vtables.h | 29 +++-
9 files changed, 124 insertions(+), 44 deletions(-)
base-commit: 1a019dd7a5d25f7c1c9b77931138290e28947e6a
--
2.39.1
Re: drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5
Hi, On Wed, Feb 08, 2023 at 07:04:58PM +, Darrell Kavanagh wrote: > I've resolved this by adding a matching quirk in > drivers/firmware/efi/sysfb_efi.c - see below. > > Are you the right people to be notifying about this? Yes, we are. Howewer, please follow https://www.kernel.org/doc/html/latest/process/submitting-patches.html In particular, a proper commit log and your Signed-off-By tag is missing. Maxime signature.asc Description: PGP signature
Re: [PATCH][next] drm/amd/display: Fix spelling mistakes of function name in error message
Applied. Thanks!
Alex
On Thu, Feb 9, 2023 at 7:53 AM Colin Ian King wrote:
>
> The function name is being reported as dc_link_contruct when it is
> actually dc_link_construct_phy. Fix this by using %s and the __func__
> for the function name.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/link/link_factory.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/link/link_factory.c
> b/drivers/gpu/drm/amd/display/dc/link/link_factory.c
> index 13a766273755..3fc93fc593fb 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/link_factory.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/link_factory.c
> @@ -452,7 +452,7 @@ static bool dc_link_construct_phy(struct dc_link *link,
> link->psr_settings.psr_vtotal_control_support = false;
> link->psr_settings.psr_version = DC_PSR_VERSION_UNSUPPORTED;
>
> - DC_LOG_DC("BIOS object table - dc_link_contruct finished
> successfully.\n");
> + DC_LOG_DC("BIOS object table - %s finished successfully.\n",
> __func__);
> return true;
> device_tag_fail:
> link->link_enc->funcs->destroy(>link_enc);
> @@ -469,7 +469,7 @@ static bool dc_link_construct_phy(struct dc_link *link,
> link->hpd_gpio = NULL;
> }
>
> - DC_LOG_DC("BIOS object table - dc_link_contruct failed.\n");
> + DC_LOG_DC("BIOS object table - %s failed.\n", __func__);
> return false;
> }
>
> --
> 2.30.2
>
Re: [PATCH v2] drm/amd/display: remove duplicate include header
Applied. Thanks! Alex On Thu, Feb 9, 2023 at 5:48 AM wrote: > > From: Ye Xingchen > > link_hwss.h is included more than once in link_dpms.c . > > Signed-off-by: Ye Xingchen > --- > v1 -> v2 > Fix the U+00A0 non-breaking space in the subject line. > drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > index 9cdfa7f7dc77..0c26b3589608 100644 > --- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > +++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c > @@ -51,7 +51,6 @@ > #include "link_enc_cfg.h" > #include "resource.h" > #include "dsc.h" > -#include "link_hwss.h" > #include "dccg.h" > #include "clk_mgr.h" > #include "atomfirmware.h" > -- > 2.25.1
Re: [PATCH] drm/amd/display: fix link_validation build failure
Applied. Thanks!
Alex
On Thu, Feb 9, 2023 at 7:45 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When CONFIG_DRM_AMD_DC_DCN is disabled, the is_frl member
> is not defined:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c: In function
> 'dp_active_dongle_validate_timing':
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:126:66:
> error: 'const struct dc_dsc_config' has no member named 'is_frl'
> 126 | if (timing->flags.DSC &&
> !timing->dsc_cfg.is_frl)
> | ^
>
> Use the same #ifdef as the other references to this.
>
> Fixes: 5461d1ea ("drm/amd/display: break down dc_link.c")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/display/dc/link/link_validation.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/link/link_validation.c
> b/drivers/gpu/drm/amd/display/dc/link/link_validation.c
> index cd821d077d73..8ddebf3bdd46 100644
> --- a/drivers/gpu/drm/amd/display/dc/link/link_validation.c
> +++ b/drivers/gpu/drm/amd/display/dc/link/link_validation.c
> @@ -123,9 +123,11 @@ static bool dp_active_dongle_validate_timing(
> if (dongle_caps->dp_hdmi_frl_max_link_bw_in_kbps > 0) { // DP
> to HDMI FRL converter
> struct dc_crtc_timing outputTiming = *timing;
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> if (timing->flags.DSC && !timing->dsc_cfg.is_frl)
> /* DP input has DSC, HDMI FRL output doesn't
> have DSC, remove DSC from output timing */
> outputTiming.flags.DSC = 0;
> +#endif
> if (dc_bandwidth_in_kbps_from_timing() >
> dongle_caps->dp_hdmi_frl_max_link_bw_in_kbps)
> return false;
> } else { // DP to HDMI TMDS converter
> --
> 2.39.1
>
Re: [PATCH] drm/amd/display: set should_disable_otg storage-class-specifier to static
Applied. Thanks!
Alex
On Thu, Feb 9, 2023 at 8:41 AM Tom Rix wrote:
>
> smatch reports
> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c:90:6:
> warning: symbol 'should_disable_otg' was not declared. Should it be static?
>
> should_disable_otg() is only used in dcn315_clk_mgr.c, so it should be static
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> index 8c368bcc8e7e..a737782b2840 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
> @@ -87,7 +87,7 @@ static int dcn315_get_active_display_cnt_wa(
> return display_count;
> }
>
> -bool should_disable_otg(struct pipe_ctx *pipe)
> +static bool should_disable_otg(struct pipe_ctx *pipe)
> {
> bool ret = true;
>
> --
> 2.26.3
>
Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface
On 01/31, Pekka Paalanen wrote:
> On Mon, 9 Jan 2023 14:38:09 -0100
> Melissa Wen wrote:
>
> > On 01/09, Melissa Wen wrote:
> > > Hi,
> > >
> > > After collecting comments in different places, here is a second version
> > > of the work on adding DRM CRTC 3D LUT support to the current DRM color
> > > mgmt interface. In comparison to previous proposals [1][2][3], here we
> > > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT,
> > > that means the following DRM CRTC color correction pipeline:
> > >
> > > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D LUT
>
> Hi Melissa,
>
> that makes sense to me, for CRTCs. It would be really good to have that
> as a diagram in the KMS UAPI documentation.
>
Hi Pekka,
Thanks for your feedbacks and your time reviewing this proposal.
> If someone wants to add a 3D LUT to KMS planes as well, then I'm not
> sure if it should be this order or swapped. I will probably have an
> opinion about that once Weston is fully HDR capable and has been tried
> in the wild for a while with the HDR color operations fine-tuned based
> on community feedback. IOW, not for a long time. The YUV to RGB
> conversion factors in there as well.
>
I see, this is also the reason I reuse here Alex Hung's proposal for
pre-blending API. I'll work on better documentation.
>
> > >
> > > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung
> > > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a
> > > LUT3D_SIZE, that allows userspace to use different supported settings of
> > > 3D LUT, fitting VA-API and new color API better. In this sense, I
> > > adjusted the pre-blending proposal for post-blending usage.
> > >
> > > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to
> > > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an
> > > extra/optional patch to define a default value for LUT3D_MODE, inspired
> > > by what we do for the plane blend mode property (pre-multiplied).
> > >
> > > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage
> > > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current
> > > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT
> > > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context
> > > for DCN 301 (easily extendible to other DCN families). Finally, from
> > > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display
> > > driver, exposing modes supported by HW and programming user shaper and
> > > 3D LUT accordingly.
> > >
> > > Our target userspace is Gamescope/SteamOS.
> > >
> > > Basic IGT tests were based on [5][6] and are available here (in-progress):
> > > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api
> > >
> > > [1]
> > > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/
> > > [2]
> > > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69
> > > [3]
> > > https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
> > > [4]
> > > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/
> > > [5] https://patchwork.freedesktop.org/series/90165/
> > > [6] https://patchwork.freedesktop.org/series/109402/
> > > [VA_API]
> > > http://intel.github.io/libva/structVAProcFilterParameterBuffer3DLUT.html
> > > [KMS_pipe_API] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11
> > >
> > > Let me know your thoughts.
> >
> > +Simon Ser, +Pekka Paalanen who might also be interested in this series.
>
> Unfortunately I don't have the patch emails to reply to, so here's a
> messy bunch of comments. I'll concentrate on the UAPI design as always.
Sorry, the patchset is here:
https://lore.kernel.org/dri-devel/20230109143846.1966301-1-m...@igalia.com/
In the next version, I won't forget cc'ing you at first.
>
> +/*
> + * struct drm_mode_lut3d_mode - 3D LUT mode information.
> + * @lut_size: number of valid points on every dimension of 3D LUT.
> + * @lut_stride: number of points on every dimension of 3D LUT.
> + * @bit_depth: number of bits of RGB. If color_mode defines entries with
> higher
> + * bit_depth the least significant bits will be truncated.
> + * @color_format: fourcc values, ex. DRM_FORMAT_XRGB16161616 or
> DRM_FORMAT_XBGR16161616.
> + * @flags: flags for hardware-sepcific features
> + */
> +struct drm_mode_lut3d_mode {
> + __u16 lut_size;
> + __u16 lut_stride[3];
> + __u16 bit_depth;
> + __u32 color_format;
> + __u32 flags;
> +};
>
> Why is lut_stride an array of 3, but lut_size is not?
It cames from VA-API:
https://intel.github.io/libva/structVAProcFilterParameterBuffer3DLUT.html#a682756be15d09327ba725b74a863cbcc
In short, the reason is that lut_size is the valid points and is
the same for every dimensions, but lut_stride may vary.
>
> What is the color_mode the comment is
Re: Try to address the drm_debugfs issues
On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote: > Am 09.02.23 um 14:06 schrieb Maíra Canal: > > On 2/9/23 09:13, Christian König wrote: > > > Am 09.02.23 um 12:23 schrieb Maíra Canal: > > > > On 2/9/23 05:18, Christian König wrote: > > > > > Hello everyone, > > > > > > > > > > the drm_debugfs has a couple of well known design problems. > > > > > > > > > > Especially it wasn't possible to add files between > > > > > initializing and registering > > > > > of DRM devices since the underlying debugfs directory wasn't > > > > > created yet. > > > > > > > > > > The resulting necessity of the driver->debugfs_init() > > > > > callback function is a > > > > > mid-layering which is really frowned on since it creates a horrible > > > > > driver->DRM->driver design layering. > > > > > > > > > > The recent patch "drm/debugfs: create device-centered > > > > > debugfs functions" tried > > > > > to address those problem, but doesn't seem to work > > > > > correctly. This looks like > > > > > a misunderstanding of the call flow around > > > > > drm_debugfs_init(), which is called > > > > > multiple times, once for the primary and once for the render node. > > > > > > > > > > So what happens now is the following: > > > > > > > > > > 1. drm_dev_init() initially allocates the drm_minor objects. > > > > > 2. ... back to the driver ... > > > > > 3. drm_dev_register() is called. > > > > > > > > > > 4. drm_debugfs_init() is called for the primary node. > > > > > 5. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and > > > > > drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() > > > > > to add the files > > > > > for the primary node. > > > > > 6. The driver->debugfs_init() callback is called to add > > > > > debugfs files for the > > > > > primary node. > > > > > 7. The added files are consumed and added to the primary > > > > > node debugfs directory. > > > > > > > > > > 8. drm_debugfs_init() is called for the render node. > > > > > 9. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and > > > > > drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() > > > > > to add the files > > > > > again for the render node. > > > > > 10. The driver->debugfs_init() callback is called to add > > > > > debugfs files for the > > > > > render node. > > > > > 11. The added files are consumed and added to the render > > > > > node debugfs directory. > > > > > > > > > > 12. Some more files are added through drm_debugfs_add_file(). > > > > > 13. drm_debugfs_late_register() add the files once more to > > > > > the primary node > > > > > debugfs directory. > > > > > 14. From this point on files added through > > > > > drm_debugfs_add_file() are simply ignored. > > > > > 15. ... back to the driver ... > > > > > > > > > > Because of this the dev->debugfs_mutex lock is also > > > > > completely pointless since > > > > > any concurrent use of the interface would just randomly > > > > > either add the files to > > > > > the primary or render node or just not at all. > > > > > > > > > > Even worse is that this implementation nails the coffin for > > > > > removing the > > > > > driver->debugfs_init() mid-layering because otherwise > > > > > drivers can't control > > > > > where their debugfs (primary/render node) are actually added. > > > > > > > > > > This patch set here now tries to clean this up a bit, but > > > > > most likely isn't > > > > > fully complete either since I didn't audit every driver/call path. > > > > > > > > I tested the patchset on the v3d, vc4 and vkms and all the files > > > > are generated > > > > as expected, but I'm getting the following errors on dmesg: > > > > > > > > [ 3.872026] debugfs: File 'v3d_ident' in directory '0' > > > > already present! > > > > [ 3.872064] debugfs: File 'v3d_ident' in directory '128' > > > > already present! > > > > [ 3.872078] debugfs: File 'v3d_regs' in directory '0' already > > > > present! > > > > [ 3.872087] debugfs: File 'v3d_regs' in directory '128' > > > > already present! > > > > [ 3.872097] debugfs: File 'measure_clock' in directory '0' > > > > already present! > > > > [ 3.872105] debugfs: File 'measure_clock' in directory '128' > > > > already present! > > > > [ 3.872116] debugfs: File 'bo_stats' in directory '0' already > > > > present! > > > > [ 3.872124] debugfs: File 'bo_stats' in directory '128' > > > > already present! > > > > > > > > It looks like the render node is being added twice, since this > > > > doesn't happen > > > > for vc4 and vkms. > > > > > > Thanks for the feedback and yes that's exactly what I meant with > > > that I haven't looked into all code paths. > > > > > > Could it be that v3d registers it's debugfs files from the > > > debugfs_init callback? > > > > Although this is true, I'm not sure if this is the reason why the files > > are > > being registered twice, as this doesn't happen to vc4, and it also uses > > the > > debugfs_init callback. I
Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Add a new immutable plane property by which a plane can advertise > a handful of recommended plane sizes. This would be mostly exposed > by cursor planes as a slightly more capable replacement for > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > a one size fits all limit for the whole device. > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > size via the cursor size caps. But always using the max sized > cursor can waste a surprising amount of power, so a better > stragey is desirable. > > Most other drivers don't specify any cursor size at all, in > which case the ioctl code just claims that 64x64 is a great > choice. Whether that is actually true is debatable. > > A poll of various compositor developers informs us that > blindly probing with setcursor/atomic ioctl to determine > suitable cursor sizes is not acceptable, thus the > introduction of the new property to supplant the cursor > size caps. The compositor will now be free to select a > more optimal cursor size from the short list of options. > > Note that the reported sizes (either via the property or the > caps) make no claims about things such as plane scaling. So > these things should only really be consulted for simple > "cursor like" use cases. > > v2: Try to add some docs > > Cc: Simon Ser > Cc: Jonas Ådahl > Cc: Daniel Stone > Cc: Pekka Paalanen > Acked-by: Harry Wentland > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_mode_config.c | 7 + > drivers/gpu/drm/drm_plane.c | 48 +++ > include/drm/drm_mode_config.h | 5 > include/drm/drm_plane.h | 4 +++ > include/uapi/drm/drm_mode.h | 11 +++ > 5 files changed, 75 insertions(+) > > diff --git a/drivers/gpu/drm/drm_mode_config.c > b/drivers/gpu/drm/drm_mode_config.c > index 87eb591fe9b5..21860f94a18c 100644 > --- a/drivers/gpu/drm/drm_mode_config.c > +++ b/drivers/gpu/drm/drm_mode_config.c > @@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct > drm_device *dev) > return -ENOMEM; > dev->mode_config.modifiers_property = prop; > > + prop = drm_property_create(dev, > +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB, > +"SIZE_HINTS", 0); > + if (!prop) > + return -ENOMEM; > + dev->mode_config.size_hints_property = prop; > + > return 0; > } > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 24e7998d1731..ae51b1f83755 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -140,6 +140,21 @@ > * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have > been > * various bugs in this area with inconsistencies between the capability > * flag and per-plane properties. > + * > + * SIZE_HINTS: > + * Blob property which contains the set of recommended plane size > + * which can used for simple "cursor like" use cases (eg. no scaling). > + * Using these hints frees userspace from extensive probing of > + * supported plane sizes through atomic/setcursor ioctls. > + * > + * For optimal usage userspace should pick the smallest size > + * that satisfies its own requirements. > + * > + * The blob contains an array of struct drm_plane_size_hint. > + * > + * Drivers should only attach this property to planes that > + * support a very limited set of sizes (eg. cursor planes > + * on typical hardware). This is a bit awkward since problematic drivers would only expose this property if they are new enough. A way to avoid this is for all new drivers expose this property, but special case the size 0x0 as "everything below the max limit goes". Then userspace can do (ignoring the missing cap fallback). if (has(SIZE_HINTS)) size = figure_out_size(SIZE_HINTS, DRM_CAP_CURSOR_WIDTH, DRM_CAP_CURSOR_HEIGHT, preferred_size); else size = DRM_CAP_CURSOR_WIDTH x DRM_CAP_CURSOR_WIDTH; With `figure_out_size()` knowing how to deal with 0x0 in the size hints to use `preferred_size` directly. Jonas > */ > > static unsigned int drm_num_planes(struct drm_device *dev) > @@ -1582,3 +1597,36 @@ int drm_plane_create_scaling_filter_property(struct > drm_plane *plane, > return 0; > } > EXPORT_SYMBOL(drm_plane_create_scaling_filter_property); > + > +/** > + * drm_plane_add_size_hint_property - create a size hint property > + * > + * @plane: drm plane > + * @hints: size hints > + * @num_hints: number of size hints > + * > + * Create a size hints property for the plane. > + * > + * RETURNS: > + * Zero for success or -errno > + */ > +int drm_plane_add_size_hints_property(struct drm_plane *plane, > +
Re: Try to address the drm_debugfs issues
Am 09.02.23 um 14:06 schrieb Maíra Canal: On 2/9/23 09:13, Christian König wrote: Am 09.02.23 um 12:23 schrieb Maíra Canal: On 2/9/23 05:18, Christian König wrote: Hello everyone, the drm_debugfs has a couple of well known design problems. Especially it wasn't possible to add files between initializing and registering of DRM devices since the underlying debugfs directory wasn't created yet. The resulting necessity of the driver->debugfs_init() callback function is a mid-layering which is really frowned on since it creates a horrible driver->DRM->driver design layering. The recent patch "drm/debugfs: create device-centered debugfs functions" tried to address those problem, but doesn't seem to work correctly. This looks like a misunderstanding of the call flow around drm_debugfs_init(), which is called multiple times, once for the primary and once for the render node. So what happens now is the following: 1. drm_dev_init() initially allocates the drm_minor objects. 2. ... back to the driver ... 3. drm_dev_register() is called. 4. drm_debugfs_init() is called for the primary node. 5. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() to add the files for the primary node. 6. The driver->debugfs_init() callback is called to add debugfs files for the primary node. 7. The added files are consumed and added to the primary node debugfs directory. 8. drm_debugfs_init() is called for the render node. 9. drm_framebuffer_debugfs_init(), drm_client_debugfs_init() and drm_atomic_debugfs_init() call drm_debugfs_add_file(s)() to add the files again for the render node. 10. The driver->debugfs_init() callback is called to add debugfs files for the render node. 11. The added files are consumed and added to the render node debugfs directory. 12. Some more files are added through drm_debugfs_add_file(). 13. drm_debugfs_late_register() add the files once more to the primary node debugfs directory. 14. From this point on files added through drm_debugfs_add_file() are simply ignored. 15. ... back to the driver ... Because of this the dev->debugfs_mutex lock is also completely pointless since any concurrent use of the interface would just randomly either add the files to the primary or render node or just not at all. Even worse is that this implementation nails the coffin for removing the driver->debugfs_init() mid-layering because otherwise drivers can't control where their debugfs (primary/render node) are actually added. This patch set here now tries to clean this up a bit, but most likely isn't fully complete either since I didn't audit every driver/call path. I tested the patchset on the v3d, vc4 and vkms and all the files are generated as expected, but I'm getting the following errors on dmesg: [ 3.872026] debugfs: File 'v3d_ident' in directory '0' already present! [ 3.872064] debugfs: File 'v3d_ident' in directory '128' already present! [ 3.872078] debugfs: File 'v3d_regs' in directory '0' already present! [ 3.872087] debugfs: File 'v3d_regs' in directory '128' already present! [ 3.872097] debugfs: File 'measure_clock' in directory '0' already present! [ 3.872105] debugfs: File 'measure_clock' in directory '128' already present! [ 3.872116] debugfs: File 'bo_stats' in directory '0' already present! [ 3.872124] debugfs: File 'bo_stats' in directory '128' already present! It looks like the render node is being added twice, since this doesn't happen for vc4 and vkms. Thanks for the feedback and yes that's exactly what I meant with that I haven't looked into all code paths. Could it be that v3d registers it's debugfs files from the debugfs_init callback? Although this is true, I'm not sure if this is the reason why the files are being registered twice, as this doesn't happen to vc4, and it also uses the debugfs_init callback. I believe it is somewhat related to the fact that v3d is the primary node and the render node. I see. Thanks for the hint. Best Regards, - Maíra Canal One alternative would be to just completely nuke support for separate render node debugfs files and only add a symlink to the primary node. Opinions? What do you think of this approach? I can't come up with any reason why we should have separate debugfs files for render nodes and I think it is pretty much the same reason you came up with the patch for per device debugfs files instead of per minor. Regards, Christian. Regards, Christian. Otherwise, the patchset looks good to me, but maybe Daniel has some other thoughts about it. Best Regards, - Maíra Canal Please comment/discuss. Cheers, Christian.
Re: [PATCH v11 7/9] dt-bindings: display: bridge: it6505: Add mode-switch support
On Wed, Feb 8, 2023 at 10:00 PM Pin-yen Lin wrote: > > Hi Rob, > > Thanks for the review. > > On Wed, Feb 8, 2023 at 4:52 AM Rob Herring wrote: > > > > On Sat, Feb 04, 2023 at 09:30:38PM +0800, Pin-yen Lin wrote: > > > ITE IT6505 can be used in systems to switch the DP traffic between > > > two downstreams, which can be USB Type-C DisplayPort alternate mode > > > lane or regular DisplayPort output ports. > > > > > > Update the binding to accommodate this usage by introducing a > > > data-lanes and a mode-switch property on endpoints. > > > > > > Signed-off-by: Pin-yen Lin > > > > > > --- > > > > > > Changes in v11: > > > - Updated the description of the endpoints in the bindings > > > - Referenced video-interfaces.yaml instead for the endpoints binding > > > - Removed duplicated definitions from inherited schema > > > > > > Changes in v9: > > > - Fixed subject prefix again > > > - Changed the naming of the example node for it6505 > > > > > > Changes in v8: > > > - Updated bindings for data-lanes property > > > - Fixed subject prefix > > > > > > Changes in v7: > > > - Fixed issues reported by dt_binding_check. > > > - Updated the schema and the example dts for data-lanes. > > > - Changed to generic naming for the example dts node. > > > > > > Changes in v6: > > > - Remove switches node and use endpoints and data-lanes property to > > > describe the connections. > > > > > > .../bindings/display/bridge/ite,it6505.yaml | 101 +++--- > > > 1 file changed, 88 insertions(+), 13 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > > b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > > index b16a9d9127dd..8ae9c5cba22c 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml > > > @@ -75,22 +75,49 @@ properties: > > >port@1: > > > $ref: /schemas/graph.yaml#/$defs/port-base > > > unevaluatedProperties: false > > > -description: Video port for DP output > > > +description: > > > + Video port for DP output. Each endpoint connects to a video > > > output > > > + downstream, and the "data-lanes" property is used to describe > > > the pin > > > + connections. 0, 1, 2, 3 in "data-lanes" maps to TX0, TX1, TX2, > > > TX3, > > > + respectively. > > > > > > -properties: > > > - endpoint: > > > -$ref: /schemas/graph.yaml#/$defs/endpoint-base > > > + > > > +patternProperties: > > > + "^endpoint@[01]$": > > > +$ref: /schemas/media/video-interfaces.yaml# > > > unevaluatedProperties: false > > > > > > properties: > > > + reg: true > > > + > > > + remote-endpoint: true > > > + > > >data-lanes: > > > -minItems: 1 > > > -uniqueItems: true > > > -items: > > > - - enum: [ 0, 1 ] > > > - - const: 1 > > > - - const: 2 > > > - - const: 3 > > > +oneOf: > > > + - items: > > > + - enum: [0, 1, 2, 3] > > > + > > > + - items: > > > + - const: 0 > > > + - const: 1 > > > + > > > + - items: > > > + - const: 2 > > > + - const: 3 > > > + > > > + - items: > > > + - const: 0 > > > + - const: 1 > > > + - const: 2 > > > + - const: 3 > > > + > > > + mode-switch: > > > +type: boolean > > > +description: Register this node as a Type-C mode switch > > > or not. > > > > Existing users put this property in the device's node, not the endpoint. > > That seems more like a property of the device, than the DP link. > > In our use case, we want to register two mode switches for the same > device. That's why we put the "mode-switch" property in the endpoints > instead of the device node. Then do that. Register a mode switch for each endpoint connected to a USB-C connector. You can walk the graph to see what type of connector. The only way I could see this as an issue is you have 2 USB-C connectors and one is a mode switch and one is not. Not sure if such a scenario is likely or possible. If it is, please educate me. > > You are using fwnode_typec_mux_get(), right? > > Yes. This is called by cros_ec_typec.c[1] in our use case. That code looks for 'mode-switch' in the device's node, not the endpoint. So how does it work for you? Rob
[PATCH 10/11] drm: Include for mode parsing
Include in drm_connector.c to get video_get_options()
and avoid the dependency on . The replaced function
fb_get_options() is just a tiny wrapper around video_get_opions(). No
functional changes.
Include to get fwnode_handle_put(), which had been
provided via .
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_connector.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9d0250c28e9b..ca5fb54b7aab 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -33,9 +33,11 @@
#include
#include
-#include
+#include
#include
+#include
+
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -154,9 +156,10 @@ EXPORT_SYMBOL(drm_get_connector_type_name);
static void drm_connector_get_cmdline_mode(struct drm_connector *connector)
{
struct drm_cmdline_mode *mode = >cmdline_mode;
- char *option = NULL;
+ const char *option;
- if (fb_get_options(connector->name, ))
+ option = video_get_options(connector->name);
+ if (!option)
return;
if (!drm_mode_parse_command_line_for_connector(option,
--
2.39.1
[PATCH 09/11] driver/ps3: Include for mode parsing
Include in ps3av.c to get video_get_options() and
avoid the dependency on . The replaced function
fb_get_options() is just a tiny wrapper around video_get_opions(). No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/ps3/ps3av.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index 8f3e60f1bfe2..f6c9e56bdba7 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -11,13 +11,14 @@
#include
#include
#include
-#include
#include
#include
#include
#include
+#include
+
#include "vuart.h"
#define BUFSIZE 4096 /* vuart buf size */
@@ -921,9 +922,7 @@ EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int ps3av_probe(struct ps3_system_bus_device *dev)
{
-#ifdef CONFIG_FB
- char *mode_option = NULL;
-#endif
+ const char *mode_option;
int res;
int id;
@@ -971,14 +970,9 @@ static int ps3av_probe(struct ps3_system_bus_device *dev)
ps3av_get_hw_conf(ps3av);
-#ifdef CONFIG_FB
- fb_get_options(NULL, _option);
- if (mode_option) {
- if (!strcmp(mode_option, "safe"))
- safe_mode = 1;
- kfree(mode_option);
- }
-#endif /* CONFIG_FB */
+ mode_option = video_get_options(NULL);
+ if (mode_option && !strcmp(mode_option, "safe"))
+ safe_mode = 1;
id = ps3av_auto_videomode(>av_hw_conf);
if (id < 0) {
printk(KERN_ERR "%s: invalid id :%d\n", __func__, id);
--
2.39.1
[PATCH 11/11] drm: Fix comment on mode parsing
Do not claim that there's a default mode in the video= option parser. if no option string has been given, the parser does nothing. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_modes.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 40d482a01178..ac9a406250c5 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -2339,8 +2339,7 @@ static int drm_mode_parse_cmdline_named_mode(const char *name, * @mode: preallocated drm_cmdline_mode structure to fill out * * This parses @mode_option command line modeline for modes and options to - * configure the connector. If @mode_option is NULL the default command line - * modeline in fb_mode_option will be parsed instead. + * configure the connector. * * This uses the same parameters as the fb modedb.c, except for an extra * force-enable, force-enable-digital and force-disable bit at the end:: -- 2.39.1
[PATCH 08/11] fbdev: Handle video= parameter in video/cmdline.c
Handle the command-line parameter video= in video/cmdline.c. Implement
the fbdev helper fb_get_options() on top. Will allows to handle the
kernel parameter in DRM without fbdev dependencies.
Note that __video_get_options() has the meaning of its return value
inverted compared to fb_get_options(). The new helper returns true if
the adapter has been enabled, and false otherwise.
There is the ofonly parameter, which disables output for non-OF-based
framebuffers. It is only for offb and looks like a workaround. The actual
purpose it not clear to me. Use 'video=off' or 'nomodeset' instead.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/video/Kconfig | 3 +
drivers/video/Makefile| 1 +
drivers/video/cmdline.c | 133 ++
drivers/video/fbdev/Kconfig | 5 +-
drivers/video/fbdev/core/Makefile | 3 +-
drivers/video/fbdev/core/fb_cmdline.c | 93 +++---
include/video/cmdline.h | 20
8 files changed, 172 insertions(+), 88 deletions(-)
create mode 100644 drivers/video/cmdline.c
create mode 100644 include/video/cmdline.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dc0f94f02a82..81c8a99c744a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -10,13 +10,13 @@ menuconfig DRM
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
select DRM_PANEL_ORIENTATION_QUIRKS
select HDMI
- select FB_CMDLINE
select I2C
select DMA_SHARED_BUFFER
select SYNC_FILE
# gallium uses SYS_kcmp for os_same_file_description() to de-duplicate
# device and dmabuf fd. Let's make sure that is available for our userspace.
select KCMP
+ select VIDEO_CMDLINE
select VIDEO_NOMODESET
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6d2fde6c5d11..bf05363d8906 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -11,6 +11,9 @@ config APERTURE_HELPERS
Support tracking and hand-over of aperture ownership. Required
by graphics drivers for firmware-provided framebuffers.
+config VIDEO_CMDLINE
+ bool
+
config VIDEO_NOMODESET
bool
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index a50eb528ed3c..831c9fa57a6c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_APERTURE_HELPERS)+= aperture.o
obj-$(CONFIG_VGASTATE)+= vgastate.o
+obj-$(CONFIG_VIDEO_CMDLINE) += cmdline.o
obj-$(CONFIG_VIDEO_NOMODESET) += nomodeset.o
obj-$(CONFIG_HDMI)+= hdmi.o
diff --git a/drivers/video/cmdline.c b/drivers/video/cmdline.c
new file mode 100644
index ..d3d257489c3d
--- /dev/null
+++ b/drivers/video/cmdline.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Based on the fbdev code in drivers/video/fbdev/core/fb_cmdline:
+ *
+ * Copyright (C) 2014 Intel Corp
+ * Copyright (C) 1994 Martin Schaller
+ *
+ * 2001 - Documented with DocBook
+ * - Brad Douglas
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Authors:
+ *Daniel Vetter
+ */
+
+#include /* for FB_MAX */
+#include
+
+#include
+
+/*
+ * FB_MAX is the maximum number of framebuffer devices and also
+ * the maximum number of video= parameters. Although not directly
+ * related to each other, it makes sense to keep it that way.
+ */
+static const char *video_options[FB_MAX] __read_mostly;
+static const char *video_option __read_mostly;
+static int video_of_only __read_mostly;
+
+static const char *__video_get_option_string(const char *name)
+{
+ const char *options = NULL;
+ size_t name_len = 0;
+
+ if (name)
+ name_len = strlen(name);
+
+ if (name_len) {
+ unsigned int i;
+ const char *opt;
+
+ for (i = 0; i < ARRAY_SIZE(video_options); ++i) {
+ if (!video_options[i])
+ continue;
+ if (video_options[i][0] == '\0')
+ continue;
+ opt = video_options[i];
+ if (!strncmp(opt, name, name_len) && opt[name_len] ==
':')
+ options = opt + name_len + 1;
+ }
+ }
+
+ /* No match, return global options */
+ if (!options)
+ options = video_option;
+
+ return options;
+}
+
+/**
+ * video_get_options - get kernel boot parameters
+ * @name: name of the output as it would appear in the boot parameter
+ * line (video=:)
+ *
+ * Looks up the video= options for the given name. Names are
[PATCH 01/11] fbdev: Fix contact info in fb_cmdline.c
Fix Daniel's email address. No functional changes. Signed-off-by: Thomas Zimmermann Cc: Daniel Vetter --- drivers/video/fbdev/core/fb_cmdline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fb_cmdline.c b/drivers/video/fbdev/core/fb_cmdline.c index 3b5bd666b952..6792010d6716 100644 --- a/drivers/video/fbdev/core/fb_cmdline.c +++ b/drivers/video/fbdev/core/fb_cmdline.c @@ -12,7 +12,7 @@ * for more details. * * Authors: - *Vetter + *Daniel Vetter */ #include #include -- 2.39.1
[PATCH 07/11] fbdev: Move option-string lookup into helper
Move the lookup of the option string into an internal helper. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_cmdline.c | 60 ---
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
index 512da89ff8b5..f811c7b679e1 100644
--- a/drivers/video/fbdev/core/fb_cmdline.c
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -21,6 +21,36 @@ static char *video_options[FB_MAX] __read_mostly;
static const char *fb_mode_option __read_mostly;
static int ofonly __read_mostly;
+static const char *__fb_get_options(const char *name)
+{
+ const char *options = NULL;
+ size_t name_len = 0;
+
+ if (name)
+ name_len = strlen(name);
+
+ if (name_len) {
+ unsigned int i;
+ const char *opt;
+
+ for (i = 0; i < ARRAY_SIZE(video_options); ++i) {
+ if (!video_options[i])
+ continue;
+ if (video_options[i][0] == '\0')
+ continue;
+ opt = video_options[i];
+ if (!strncmp(opt, name, name_len) && opt[name_len] ==
':')
+ options = opt + name_len + 1;
+ }
+ }
+
+ /* No match, return global options */
+ if (!options)
+ options = fb_mode_option;
+
+ return options;
+}
+
/**
* fb_get_options - get kernel boot parameters
* @name: framebuffer name as it would appear in
@@ -35,36 +65,18 @@ static int ofonly __read_mostly;
*/
int fb_get_options(const char *name, char **option)
{
- const char *options = NULL;
int retval = 0;
- size_t name_len;
- char *opt;
+ const char *options;
- if (name)
- name_len = strlen(name);
-
- if (name_len && ofonly && strncmp(name, "offb", 4))
+ if (name && ofonly && strncmp(name, "offb", 4))
retval = 1;
- if (name_len && !retval) {
- unsigned int i;
+ options = __fb_get_options(name);
- for (i = 0; i < FB_MAX; i++) {
- if (video_options[i] == NULL)
- continue;
- if (!video_options[i][0])
- continue;
- opt = video_options[i];
- if (!strncmp(name, opt, name_len) &&
- opt[name_len] == ':')
- options = opt + name_len + 1;
- }
+ if (options) {
+ if (!strncmp(options, "off", 3))
+ retval = 1;
}
- /* No match, pass global option */
- if (!options && option && fb_mode_option)
- options = fb_mode_option;
- if (options && !strncmp(options, "off", 3))
- retval = 1;
if (option) {
if (options)
--
2.39.1
[PATCH 05/11] fbdev: Read video= option with fb_get_option() in modedb
Get the kernel's global video= parameter with fb_get_option(). Done
to unexport the internal fbdev state fb_mode_config. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/modedb.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/modedb.c
b/drivers/video/fbdev/core/modedb.c
index 6473e0dfe146..23cf8eba785d 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -620,6 +620,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
const struct fb_videomode *default_mode,
unsigned int default_bpp)
{
+ char *mode_option_buf = NULL;
int i;
/* Set up defaults */
@@ -635,8 +636,10 @@ int fb_find_mode(struct fb_var_screeninfo *var,
default_bpp = 8;
/* Did the user specify a video mode? */
- if (!mode_option)
- mode_option = fb_mode_option;
+ if (!mode_option) {
+ fb_get_options(NULL, _option_buf);
+ mode_option = mode_option_buf;
+ }
if (mode_option) {
const char *name = mode_option;
unsigned int namelen = strlen(name);
@@ -715,6 +718,7 @@ int fb_find_mode(struct fb_var_screeninfo *var,
res_specified = 1;
}
done:
+ kfree(mode_option_buf);
if (cvt) {
struct fb_videomode cvt_mode;
int ret;
--
2.39.1
[PATCH 06/11] fbdev: Unexport fb_mode_option
There are no external users of fb_mode_option. Unexport the variable
and declare it static.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_cmdline.c | 4 +---
include/linux/fb.h| 1 -
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
index cc8a88e8f308..512da89ff8b5 100644
--- a/drivers/video/fbdev/core/fb_cmdline.c
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -18,11 +18,9 @@
#include
static char *video_options[FB_MAX] __read_mostly;
+static const char *fb_mode_option __read_mostly;
static int ofonly __read_mostly;
-const char *fb_mode_option;
-EXPORT_SYMBOL_GPL(fb_mode_option);
-
/**
* fb_get_options - get kernel boot parameters
* @name: framebuffer name as it would appear in
diff --git a/include/linux/fb.h b/include/linux/fb.h
index daf336385613..054e8950b274 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -764,7 +764,6 @@ struct dmt_videomode {
const struct fb_videomode *mode;
};
-extern const char *fb_mode_option;
extern const struct fb_videomode vesa_modes[];
extern const struct dmt_videomode dmt_modes[];
--
2.39.1
[PATCH 04/11] drivers/ps3: Read video= option with fb_get_option()
Get the kernel's global video= parameter with fb_get_option(). Done
to unexport the internal fbdev state fb_mode_config. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/ps3/ps3av.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index 516e6d14d32e..8f3e60f1bfe2 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -921,6 +921,9 @@ EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int ps3av_probe(struct ps3_system_bus_device *dev)
{
+#ifdef CONFIG_FB
+ char *mode_option = NULL;
+#endif
int res;
int id;
@@ -969,8 +972,12 @@ static int ps3av_probe(struct ps3_system_bus_device *dev)
ps3av_get_hw_conf(ps3av);
#ifdef CONFIG_FB
- if (fb_mode_option && !strcmp(fb_mode_option, "safe"))
- safe_mode = 1;
+ fb_get_options(NULL, _option);
+ if (mode_option) {
+ if (!strcmp(mode_option, "safe"))
+ safe_mode = 1;
+ kfree(mode_option);
+ }
#endif /* CONFIG_FB */
id = ps3av_auto_videomode(>av_hw_conf);
if (id < 0) {
--
2.39.1
[PATCH 03/11] fbdev: Support NULL for name in option-string lookup
Ignore the per-driver video options if no driver name has been
specified to fb_get_option(). Return the global options in this
case.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_cmdline.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
index 702b00b71870..cc8a88e8f308 100644
--- a/drivers/video/fbdev/core/fb_cmdline.c
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -39,13 +39,18 @@ int fb_get_options(const char *name, char **option)
{
const char *options = NULL;
int retval = 0;
- int name_len = strlen(name), i;
+ size_t name_len;
char *opt;
+ if (name)
+ name_len = strlen(name);
+
if (name_len && ofonly && strncmp(name, "offb", 4))
retval = 1;
if (name_len && !retval) {
+ unsigned int i;
+
for (i = 0; i < FB_MAX; i++) {
if (video_options[i] == NULL)
continue;
--
2.39.1
[PATCH 02/11] fbdev: Transfer video= option strings to caller; clarify ownership
In fb_get_options(), always duplicate the returned option string and
transfer ownership of the memory to the function's caller.
Until now, only the global option string got duplicated and transferred
to the caller; the per-driver options were owned by fb_get_options().
In the end, it was impossible for the function's caller to detect if
it had to release the string's memory buffer. Hence, all calling drivers
leak the memory buffer. The leaks have existed ever since, but drivers
only call fb_get_option() once as part of module initialization. So the
amount of leaked memory is not significant.
Fix the semantics of fb_get_option() by unconditionally transferring
ownership of the memory buffer to the caller. Later patches can resolve
the memory leaks in the fbdev drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_cmdline.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
index 6792010d6716..702b00b71870 100644
--- a/drivers/video/fbdev/core/fb_cmdline.c
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -30,13 +30,17 @@ EXPORT_SYMBOL_GPL(fb_mode_option);
* (video=:)
* @option: the option will be stored here
*
+ * The caller owns the string returned in @option and is
+ * responsible for releasing the memory.
+ *
* NOTE: Needed to maintain backwards compatibility
*/
int fb_get_options(const char *name, char **option)
{
- char *opt, *options = NULL;
+ const char *options = NULL;
int retval = 0;
int name_len = strlen(name), i;
+ char *opt;
if (name_len && ofonly && strncmp(name, "offb", 4))
retval = 1;
@@ -55,12 +59,16 @@ int fb_get_options(const char *name, char **option)
}
/* No match, pass global option */
if (!options && option && fb_mode_option)
- options = kstrdup(fb_mode_option, GFP_KERNEL);
+ options = fb_mode_option;
if (options && !strncmp(options, "off", 3))
retval = 1;
- if (option)
- *option = options;
+ if (option) {
+ if (options)
+ *option = kstrdup(options, GFP_KERNEL);
+ else
+ *option = NULL;
+ }
return retval;
}
--
2.39.1
[PATCH 00/11] drm,fbdev: Move video= option to drivers/video
The kernel's video= option sets the initial video mode. It is shared by fbdev and DRM, but located within the fbdev code. Move it to drivers/video/ and adapt callers. Allows DRM (and others) to use the option without depending on fbdev. While at it, fix the interface of the lookup functions. This requires a number of changes. First clarify the ownership of the option string in patch 2. The helper fb_get_options() returns the video= parameter's value. It's sometimes a copy and sometimes the original string. Hence callers, mostly fbdev drivers, have just leaked the returned string. Change this to always duplicate the option string in fb_get_options() and transfer ownership of the copy to the caller. We can then start to fix the memory leaks in the fbdev drivers. There's a global video= setting and a number of per-output settings. In patches 3 to 5, support explicit lookup of the global video option and lookup the string in fbdev's modedb and in a PS3 driver. Then avoid exporting the global setting's internal state variable in patch 6. Finally, in patches 7 to 11, move the video= option to drivers/video. It can be used directly in DRM and a PS3 driver. This fixes any memory leaks from the returned option string. For fbdev drivers, the helper fb_get_options() remains as an adapter aroudn the new interface. Tested with DRM and fbdev and built for the PS3. Thomas Zimmermann (11): fbdev: Fix contact info in fb_cmdline.c fbdev: Transfer video= option strings to caller; clarify ownership fbdev: Support NULL for name in option-string lookup drivers/ps3: Read video= option with fb_get_option() fbdev: Read video= option with fb_get_option() in modedb fbdev: Unexport fb_mode_option fbdev: Move option-string lookup into helper fbdev: Handle video= parameter in video/cmdline.c driver/ps3: Include for mode parsing drm: Include for mode parsing drm: Fix comment on mode parsing drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/drm_connector.c | 9 +- drivers/gpu/drm/drm_modes.c | 3 +- drivers/ps3/ps3av.c | 9 +- drivers/video/Kconfig | 3 + drivers/video/Makefile| 1 + drivers/video/cmdline.c | 133 ++ drivers/video/fbdev/Kconfig | 5 +- drivers/video/fbdev/core/Makefile | 3 +- drivers/video/fbdev/core/fb_cmdline.c | 94 +- drivers/video/fbdev/core/modedb.c | 8 +- include/linux/fb.h| 1 - include/video/cmdline.h | 20 13 files changed, 202 insertions(+), 89 deletions(-) create mode 100644 drivers/video/cmdline.c create mode 100644 include/video/cmdline.h base-commit: 1a019dd7a5d25f7c1c9b77931138290e28947e6a -- 2.39.1
[PATCH] drm/amd/display: set should_disable_otg storage-class-specifier to static
smatch reports
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c:90:6:
warning: symbol 'should_disable_otg' was not declared. Should it be static?
should_disable_otg() is only used in dcn315_clk_mgr.c, so it should be static
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
index 8c368bcc8e7e..a737782b2840 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
@@ -87,7 +87,7 @@ static int dcn315_get_active_display_cnt_wa(
return display_count;
}
-bool should_disable_otg(struct pipe_ctx *pipe)
+static bool should_disable_otg(struct pipe_ctx *pipe)
{
bool ret = true;
--
2.26.3
Re: [PATCH v2 4/8] arm64: dts: qcom: sm8350: reorder device nodes
On 09/02/2023 05:28, Bjorn Andersson wrote: On Mon, Feb 06, 2023 at 04:57:03PM +0200, Dmitry Baryshkov wrote: Start ordering DT nodes according to agreed order. Move apps SMMU, GIC, timer, apps RSC, cpufreq ADSP and cDSP nodes to the end to the proper position at the end of /soc/. I think "according to agreed order" means "sorted by address", but it would be nice to have that expressed in the message. If nothing else for others to know what such agreed order might be. Unfortunately this doesn't apply to my tree, and it's not clear where it failed. Could you please rebase this? Done -- With best wishes Dmitry
[PATCH v3 6/6] arm64: dts: qcom: sm8350-hdk: enable GPU
Enable the GPU on the SM8350-HDK device. The ZAP shader is required for
the GPU to function properly.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
index 54654eb75c28..09baf6959c71 100644
--- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
@@ -284,6 +284,14 @@ _dma1 {
status = "okay";
};
+ {
+ status = "okay";
+
+ zap-shader {
+ firmware-name = "qcom/sm8350/a660_zap.mbn";
+ };
+};
+
{
clock-frequency = <40>;
status = "okay";
--
2.39.1
[PATCH v3 5/6] arm64: dts: qcom: sm8350: add GPU, GMU, GPU CC and SMMU nodes
Add device nodes required to enable GPU on the SM8350 platform.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 178 +++
1 file changed, 178 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 742e9dd17084..4c1a2f814b5c 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1765,6 +1766,183 @@ tcsr_mutex: hwlock@1f4 {
#hwlock-cells = <1>;
};
+ gpu: gpu@3d0 {
+ compatible = "qcom,adreno-660.1", "qcom,adreno";
+
+ reg = <0 0x03d0 0 0x4>,
+ <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+
+ interrupts = ;
+
+ iommus = <_smmu 0 0x400>, <_smmu 1 0x400>;
+
+ operating-points-v2 = <_opp_table>;
+
+ qcom,gmu = <>;
+
+ status = "disabled";
+
+ zap-shader {
+ memory-region = <_gpu_mem>;
+ };
+
+ /* note: downstream checks gpu binning for 670 Mhz */
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-84000 {
+ opp-hz = /bits/ 64 <84000>;
+ opp-level =
;
+ };
+
+ opp-77800 {
+ opp-hz = /bits/ 64 <77800>;
+ opp-level =
;
+ };
+
+ opp-73800 {
+ opp-hz = /bits/ 64 <73800>;
+ opp-level =
;
+ };
+
+ opp-67600 {
+ opp-hz = /bits/ 64 <67600>;
+ opp-level = ;
+ };
+
+ opp-60800 {
+ opp-hz = /bits/ 64 <60800>;
+ opp-level =
;
+ };
+
+ opp-54000 {
+ opp-hz = /bits/ 64 <54000>;
+ opp-level =
;
+ };
+
+ opp-49100 {
+ opp-hz = /bits/ 64 <49100>;
+ opp-level =
;
+ };
+
+ opp-44300 {
+ opp-hz = /bits/ 64 <44300>;
+ opp-level = ;
+ };
+
+ opp-37900 {
+ opp-hz = /bits/ 64 <37900>;
+ opp-level =
;
+ };
+
+ opp-31500 {
+ opp-hz = /bits/ 64 <31500>;
+ opp-level =
;
+ };
+ };
+ };
+
+ gmu: gmu@3d6a000 {
+ compatible = "qcom,adreno-gmu-660.1", "qcom,adreno-gmu";
+
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x03de 0 0x1>,
+ <0 0x0b29 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc";
+
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = < GPU_CC_CX_GMU_CLK>,
+< GPU_CC_CXO_CLK>,
+< GCC_DDRSS_GPU_AXI_CLK>,
+< GCC_GPU_MEMNOC_GFX_CLK>,
+< GPU_CC_AHB_CLK>,
+< GPU_CC_HUB_CX_INT_CLK>,
+< GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>;
+ clock-names = "gmu",
+ "cxo",
+ "axi",
+ "memnoc",
+ "ahb",
+ "hub",
+
[PATCH v3 4/6] arm64: dts: qcom: sm8350: finish reordering nodes
Finish reordering DT nodes by their address. Move PDC, tsens, AOSS,
SRAM, SPMI and TLMM nodes to the proper position.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 764 +--
1 file changed, 382 insertions(+), 382 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 8bf38d350521..742e9dd17084 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1882,276 +1882,6 @@ compute-cb@3 {
};
};
- pdc: interrupt-controller@b22 {
- compatible = "qcom,sm8350-pdc", "qcom,pdc";
- reg = <0 0x0b22 0 0x3>, <0 0x17c000f0 0 0x60>;
- qcom,pdc-ranges = <0 480 40>, <40 140 14>, <54 263 1>,
<55 306 4>,
- <59 312 3>, <62 374 2>, <64 434 2>,
<66 438 3>,
- <69 86 1>, <70 520 54>, <124 609
31>, <155 63 1>,
- <156 716 12>;
- #interrupt-cells = <2>;
- interrupt-parent = <>;
- interrupt-controller;
- };
-
- tsens0: thermal-sensor@c263000 {
- compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
- reg = <0 0x0c263000 0 0x1ff>, /* TM */
- <0 0x0c222000 0 0x8>; /* SROT */
- #qcom,sensors = <15>;
- interrupts-extended = < 26 IRQ_TYPE_LEVEL_HIGH>,
-< 28 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow", "critical";
- #thermal-sensor-cells = <1>;
- };
-
- tsens1: thermal-sensor@c265000 {
- compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
- reg = <0 0x0c265000 0 0x1ff>, /* TM */
- <0 0x0c223000 0 0x8>; /* SROT */
- #qcom,sensors = <14>;
- interrupts-extended = < 27 IRQ_TYPE_LEVEL_HIGH>,
-< 29 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "uplow", "critical";
- #thermal-sensor-cells = <1>;
- };
-
- aoss_qmp: power-management@c30 {
- compatible = "qcom,sm8350-aoss-qmp", "qcom,aoss-qmp";
- reg = <0 0x0c30 0 0x400>;
- interrupts-extended = < IPCC_CLIENT_AOP
IPCC_MPROC_SIGNAL_GLINK_QMP
-IRQ_TYPE_EDGE_RISING>;
- mboxes = < IPCC_CLIENT_AOP
IPCC_MPROC_SIGNAL_GLINK_QMP>;
-
- #clock-cells = <0>;
- };
-
- sram@c3f {
- compatible = "qcom,rpmh-stats";
- reg = <0 0x0c3f 0 0x400>;
- };
-
- spmi_bus: spmi@c44 {
- compatible = "qcom,spmi-pmic-arb";
- reg = <0x0 0x0c44 0x0 0x1100>,
- <0x0 0x0c60 0x0 0x200>,
- <0x0 0x0e60 0x0 0x10>,
- <0x0 0x0e70 0x0 0xa>,
- <0x0 0x0c40a000 0x0 0x26000>;
- reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
- interrupt-names = "periph_irq";
- interrupts-extended = < 1 IRQ_TYPE_LEVEL_HIGH>;
- qcom,ee = <0>;
- qcom,channel = <0>;
- #address-cells = <2>;
- #size-cells = <0>;
- interrupt-controller;
- #interrupt-cells = <4>;
- };
-
- tlmm: pinctrl@f10 {
- compatible = "qcom,sm8350-tlmm";
- reg = <0 0x0f10 0 0x30>;
- interrupts = ;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- gpio-ranges = < 0 0 204>;
- wakeup-parent = <>;
-
- sdc2_default_state: sdc2-default-state {
- clk-pins {
- pins = "sdc2_clk";
- drive-strength = <16>;
- bias-disable;
- };
-
- cmd-pins {
- pins = "sdc2_cmd";
- drive-strength = <16>;
- bias-pull-up;
-
