The drm_plane_create_zpos_property() function asks for an initial value,
and will set the associated plane state variable with that value if a
state is present.
However, that function is usually called at a time where there's no
state yet. Since the drm_plane_state reset helper doesn't take care of
reading that value when it's called, it means that in most cases the
initial value will be 0, or the drivers will have to work around it.
Let's add some code in __drm_atomic_helper_plane_state_reset() to get
the initial zpos value if the property has been attached in order to fix
this.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-8-maxime@cerno.tech
While the omap_plane_init() function calls
drm_plane_create_zpos_property() with an initial value of 0,
omap_plane_reset() will force it to another value depending on the plane
type.
Fix the discrepancy by setting the initial zpos value to the same value
in the drm_plane_create_zpos_property() call.
Reviewed-by: Tomi Valkeinen <tomba@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-5-maxime@cerno.tech
Devices can also be child nodes when we also control that device
through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
drm_of_find_panel_or_bridge can lookup panel or bridge for a given
device has port and endpoint and it fails to lookup if the device
has a child nodes.
This patch add support to lookup for a child node of the given parent
that isn't either port or ports.
Example OF graph representation of DSI host, which has port but
not has ports and has child panel node.
dsi {
compatible = "allwinner,sun6i-a31-mipi-dsi";
#address-cells = <1>;
#size-cells = <0>;
port {
dsi_in_tcon0: endpoint {
remote-endpoint = <tcon0_out_dsi>;
};
panel@0 {
reg = <0>;
};
};
Example OF graph representation of DSI host, which has ports but
not has port and has child panel node.
dsi {
compatible = "samsung,exynos5433-mipi-dsi";
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dsi_to_mic: endpoint {
remote-endpoint = <&mic_to_dsi>;
};
};
};
panel@0 {
reg = <0>;
};
};
Example OF graph representation of DSI host, which has neither a port
nor a ports but has child panel node.
dsi0 {
compatible = "ste,mcde-dsi";
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
reg = <0>;
};
};
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220202160414.16493-1-jagan@amarulasolutions.com
Someone on IRC once asked an innocent enough sounding question: Why
with xf86-video-modesetting is es2gears limited at 120fps.
So I broke out the perfetto tracing mesa MR and took a look. It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting for vblank.. es2gears would rapidly push two frames to Xorg,
which would blit them to screen and in idle hook (I assume) call the
DIRTYFB ioctl. Which in turn would do an atomic update to flush the
dirty rects, which would stall until the next vblank. And then the
whole process would repeat.
But this is a bit silly, we only need dirtyfb for command mode DSI
panels. So track in plane state whether dirtyfb is required, and
track in the fb how many attached planes require dirtyfb so that we
can skip it when not required. (Note, mdp4 does not actually have
cmd mode support.)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220223191118.881321-1-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore. Add put_device() call to fix this.
Fixes: e94236cde4 ("drm/tegra: dsi: Add ganged mode support")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The link_status array was not large enough to read the Adjust Request
Post Cursor2 register, so remove the common helper function to avoid
an OOB read, found with a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':
drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]
59 | return link_status[r - DP_LANE0_1_STATUS];
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replace the only user of the helper with an open-coded fetch and decode,
similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Fixes: 79465e0ffe ("drm/dp: Add helper to get post-cursor adjustments")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20220105173507.2420910-1-keescook@chromium.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
TE-gpio, if defined, is placed in the panel's node, not the parent DSI
node. Change the devm_gpiod_get_optional() to gpiod_get_optional() and
pass proper device node to it. The code already has a proper cleanup
path, so it looks that the devm_* variant has been applied accidentally
during the conversion to gpiod API.
Fixes: ee6c8b5afa ("drm/exynos: Replace legacy gpio interface for gpiod interface")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixed a typo.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
TE-gpio is optional and if it is not found then gpiod_get_optional()
returns NULL. In such case the code will continue and try to convert NULL
gpiod to irq what in turn fails. The failure is then propagated and driver
is not registered.
Fix this by returning early from exynos_dsi_register_te_irq() if no
TE-gpio is found.
Fixes: ee6c8b5afa ("drm/exynos: Replace legacy gpio interface for gpiod interface")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypassed the hierarchical setup and messed up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypassed the hierarchical setup and messed up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
platform_get_resource_byname(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypassed the hierarchical setup and messed up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_byname().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypassed the hierarchical setup and messed up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
platform_get_resource_byname(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypassed the hierarchical setup and messed up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_byname().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Silence [-Wmissing-prototypes] sparse warnings from the display folder
such as:
../drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn315/dcn315_smu.c:126:5: warning: no previous prototype for ‘dcn315_smu_send_msg_with_param’ [-Wmissing-prototypes]
126 | int dcn315_smu_send_msg_with_param(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
v2: drop unused function dcn315_smu_set_voltage_via_phyclk() to avoid
adding a warning (Alex)
Cc: Qingqing Zhuo (Lillian) <qingqing.zhuo@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Magali Lemes <magalilemes00@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Silence the following sparse warnings:
../drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:865:16:
sparse: warning: Using plain integer as NULL pointer
../drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c:1588:84:
sparse: warning: Using plain integer as NULL pointer
../drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c:2725:84:
sparse: warning: Using plain integer as NULL pointer
../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1919:16:
sparse: warning: Using plain integer as NULL pointer
v2: drop removal of default case to avoid adding warnings (Alex)
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Magali Lemes <magalilemes00@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When CONFIG_DRM_AMD_DC_DCN is not set, the function
'dm_helpers_enable_periodic_detection' doesn't have its prototype defined,
causing the following warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:805:6:
warning: no previous prototype for function 'dm_helpers_enable_periodic_detection' [-Wmissing-prototypes]
void dm_helpers_enable_periodic_detection(struct dc_context *ctx, bool enable)
^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:805:1:
note: declare 'static' if the function is not intended to be used outside
of this translation unit
void dm_helpers_enable_periodic_detection(struct dc_context *ctx, bool enable)
^
static
1 warning generated.
This commit silences this warning by adding a conditional directive
around the mentioned function, and also corrects a small spelling error.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Magali Lemes <magalilemes00@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Part of the documentation of the 'dc_process_dmub_aux_transfer_async'
function was misplaced, being put together with the
‘dc_enable_dmub_notifications’ documentation. This caused the following
warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3757: warning:
expecting prototype for dc_process_dmub_aux_transfer_async(). Prototype
was for dc_enable_dmub_notifications() instead
This commit fixes the warning by placing the function documentations in
their right place.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Magali Lemes <magalilemes00@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
During DC init, we read power management tables from PMFW. This info is
exchanged in the form of a binary blob inside gpu memory. In order to
parse the binary blob, the correct struct needs to be used.
[How]
Fix dcn316's definition of the DfPstateTable_t struct to align with PMFW
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
According to my investigation of the state of PCI
reset recently it's not working. The reason is
due to the fact the kernel PCI code rejects SBR
when there are more then one PF under same bridge
which we always have (at least AUDIO PF but usually
more) and that because SBR will reset all the PFS
and devices under the same bridge as you and you
cannot assume they support SBR.
Once we anble FLR support we can reenable this option as
FLR is doable on single PF and doens't have this
restriction.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This parameter controls xGMI p2p communication, which is enabled by
default. However, it can be disabled by setting it to 0. In case xGMI
p2p is disabled in a dGPU, PCIe p2p interface will be used instead.
This parameter is ignored in GPUs that do not support xGMI
p2p configuration.
Signed-off-by: Alex Sierra <alex.sierra@amd.com>
Acked-by: Luben Tuikov <luben.tuikov@amd.com>
Acked-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
