The DPU_INTF_TE bit is set for all INTF blocks on DPU >= 5.0, however
only INTF_1 and INTF_2 actually support tearing control (both are
INTF_DSI). Rather than trying to limit the DPU_INTF_TE feature bit to
those two INTF instances, check for the major && INTF type.
Reviewed-by: Marijn Suijten
As the INTF is fixed at the encoder creation time, we can move the
check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
This function can return an error if INTF doesn't have required feature.
Performing this check in dpu_encoder_phys_cmd_tearcheck_config() is less
useful, as this
rop two feature flags, DPU_INTF_TE and DPU_PINGPONG_TE, in favour of
performing the MDSS revision checks instead.
Changes since v2:
- Added guarding checks for hw_intf and hw_pp in debug print (Marijn)
- Removed extra empty lines (Marijn)
Changes since v1:
- Added missing patch
- Reworked commit
Inline the _setup_intf_ops() function, it makes it easier to handle
different conditions involving INTF configuration.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 48 ++---
1 file changed, 22 insertions(+), 26
Inline the _setup_pingpong_ops() function, it makes it easier to handle
different conditions involving PINGPONG configuration.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 39 ---
1 file changed, 17
The dpu_encoder_phys_cmd_te_rd_ptr_irq() function uses neither hw_intf
nor hw_pp data, so we can drop the corresponding check.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8
1 file changed, 8 deletions(-)
diff
The DPU_PINGPONG_TE flag became unused, we can drop it now.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff
The DPU_PINGPONG_TE bit is set for all PINGPONG blocks on DPU < 5.0.
Rather than checking for the flag, check for the presense of the
corresponding interrupt line.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 --
Replace the only user of the DPU_INTF_TE feature flag with the direct
DPU version comparison.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 -
Now as we have standard per-encoder debugfs directory, move DPU encoder
status file to that directory.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +++--
1 file changed, 6 insertions(+), 39 deletions(-)
diff --git
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder. As a showcase for this dir, migrate `bridge_chains' debugfs
file (which
Each of connectors and CRTCs used by the DRM device provides debugfs
directory, which is used by several standard debugfs files and can
further be extended by the driver. Add such generic debugfs directories
for encoder.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_debugfs.c | 25
Instead of having a single file with all bridge chains, list bridges
under a corresponding per-encoder debugfs directory.
Example of the listing:
$ cat /sys/kernel/debug/dri/0/encoder-0/bridges
bridge[0]: dsi_mgr_bridge_funcs
type: [0] Unknown
ops: [0]
bridge[1]:
On 29/08/2023 21:47, Stephen Boyd wrote:
This driver open-codes a few of the DPCD register reads when it can be
simplified by using the helpers instead. This series reworks the MSM DP
driver to use the DPCD helpers and removes some dead code along the way.
There's the potential for even more
On 29/08/2023 21:47, Stephen Boyd wrote:
This function is simply drm_dp_is_branch() so use that instead of
open-coding it.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
On 29/08/2023 21:47, Stephen Boyd wrote:
The function dp_link_parse_sink_count() is really just
drm_dp_read_sink_count(). It debug prints out the bit for content
protection (DP_SINK_CP_READY), but that is not useful beyond debug
because 'link->dp_link.sink_count' is overwritten to only contain
On 29/08/2023 21:47, Stephen Boyd wrote:
These are open-coded versions of common functions. Replace them with the
common code to improve readability.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 4 ++--
1 file changed, 2
On 29/08/2023 21:47, Stephen Boyd wrote:
The member 'aux_cfg_update_done' is always false. This is dead code that
never runs. Remove it.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 15 ---
1 file changed, 15
On 29/08/2023 21:47, Stephen Boyd wrote:
We read the downstream port count and capability info but never use it
anywhere. Remove 'ds_port_cnt' and 'ds_cap_info' and any associated code
from this driver. Fold the check for 'dfp_present' into a call to
drm_dp_is_branch() at the one place it is
On 29/08/2023 21:47, Stephen Boyd wrote:
Use the common function drm_dp_read_sink_count() instead of open-coding
it. This shrinks the kernel text a tiny bit.
Cc: Vinod Polimera
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 19 +++
1
On 29/08/2023 21:47, Stephen Boyd wrote:
This function duplicates the common function drm_dp_read_dpcd_caps().
The array of DPCD registers filled in is one size larger than the
function takes, but from what I can tell that extra byte was never used.
Resize the array and use the common function
Read the downstream port info and set the subconnector type accordingly.
Signed-off-by: Dmitry Baryshkov
---
Dependencies: https://patchwork.freedesktop.org/series/123221/
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 -
drivers/gpu/drm/msm/dp/dp_panel.c | 5 +
On 09/08/2023 01:19, Kuogee Hsieh wrote:
DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will
cause PLL unlocked initially and then PLL gets locked at the end of
initialization. PLL_UNLOCKED interrupt will fire during this time if the
interrupt mask is enabled.
However
In order to simplify source code and to reduce the amount of ifdefs in
the C files, extract the DRM bridge functionality to the separate file.
Suggested-by: Heikki Krogerus
Suggested-by: Bryan O'Donoghue
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/qcom/Makefile | 4 ++
We need a way to generate and return the Type-C port device names. For
example, it is going to be used by the DRM to provide PATH property for
DisplayPort connectors.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/tcpm.c | 14 ++
include/linux/usb/tcpm.h | 2 ++
2
We need a way to generate and return the Type-C port device names. For
example, it is going to be used by the DRM to provide PATH property for
DisplayPort connectors.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/class.c | 14 ++
include/linux/usb/typec.h | 2 ++
2 files
In order to properly identify connectors (in particular, DisplayPort
connectors wrapped into USB-C) allow bridge drivers to specify the value
to be used for connector's PATH property.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 12
Set the bridge's path property to point out that this connector is
wrapped into the Type-C port.
We can not really identify the exact Type-C port because it is
registered separately, by another driver, which is not mandatory and the
corresponding device is not even present on some of platforms,
Setup the of_node and fwnode fields for the DRM connector device,
making respective links to appear in /sys.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_sysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index
In order to notify the userspace about the DRM connector's USB-C port,
export the corresponding port's name as the bridge's path field.
Signed-off-by: Dmitry Baryshkov
---
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 11 +++
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_drm.c | 4
Remove ifdef CONFIG_OF around the drm_bridge::of_node field. This follow
the correponding change to struct device we had since 2.6.39. Having
conditional around the of_node pointers turns out to make driver code
use ugly #ifdef blocks. Drop the conditionals and remove the #ifdef
blocks from the
Implement proper error path in the qcom_pmic_typec_probe(). This makes
sure that we properly disable hardware blocks and do not leak memory.
Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver")
Signed-off-by: Dmitry Baryshkov
---
During discussions regarding USB-C vs native DisplayPort it was pointed
out that other implementations (i915, AMD) are using
DRM_MODE_CONNECTOR_DisplayPort for both native and USB-C-wrapped DP
output. Follow this example and make the pmic_glink_altmode driver also
report DipslayPort connector
Userspace needs to identify whether the DisplayPort connector is a
native one or it is wrapped into the USB-C port. Moreover the userspace
might need to point user to the exact location of this Type-C port on
the laptop case.
Existing USB-C altmode implementations (i915, amdgpu) have used the
The kdev->fwnode pointer is never set in drm_sysfs_connector_add(), so
dev_fwnode() checks never succeed, making the respective commit NOP.
And if drm_sysfs_connector_add() is modified to set kdev->fwnode, it
breaks drivers already using components (as it was pointed at [1]),
resulting in a
During the discussion regarding DisplayPort wrapped in the USB-C
connectors (via the USB-C altmode) it was pointed out that currently
there is no good way to let userspace know if the DRM connector in
question is the 'native' DP connector or if it is the USB-C connector.
An attempt to use
On Tue, 22 Aug 2023 at 17:17, Laurent Pinchart
wrote:
>
> Hi Dmitry,
>
> Thank you for the patches.
>
> On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote:
> > Supporting DP/USB-C can result in a chain of several transparent
> > bridges (PHY, redrivers, mux, etc). This results in
On 2023-08-22 10:42:07, Jessica Zhang wrote:
> DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
> 48 bits of compressed data instead of 24.
>
> Enable this mode whenever DSC is enabled for supported chipsets.
>
> Signed-off-by: Jessica Zhang
> ---
>
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in
On 22/08/2023 20:42, Jessica Zhang wrote:
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data instead of 24.
Enable this mode whenever DSC is enabled for supported chipsets.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi.c | 2
On 22/08/2023 20:42, Jessica Zhang wrote:
DPU supports a data-bus widen mode for DSI INTF.
Enable this mode for all supported chipsets if widebus is enabled for DSI.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +--
41 matches
Mail list logo
