Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Add support for 8-bit, 10-bit, 12-bit and 16-bit color depth setup.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Drop the rate parameter from a bunch of internal helpers and, instead,
make better use of the newly introduced ->hdmi_cfg.tmds_char_rate driver
data.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

The main purpose of the ->rate member of struct rk_hdptx_phy is to
implement rk_hdptx_phy_clk_recalc_rate() by providing the actual rate
programmed in hardware.  Hence the current naming is too generic and
rather ambiguous.

Improve clarity by renaming ->rate to ->hw_rate.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Although, in theory, the clock provider functionality could be enabled
as a standalone driver feature, in practice it is unlikely that it would
be ever needed separately from the common PHY related features, i.e.
making use of the PHY PLL as an alternative and more accurate clock
source for display modes handling.  Which means the PLL will be always
programmed according to the TMDS char rate set via the HDMI PHY
configuration API.

Currently it's possible to freely adjust the rate via the clock API as
well, that is through clk_set_rate().  Making the clock read-only is not
feasible since we need to ensure any rate update done via the PHY
configuration API has been actually programmed into the hardware before
CCF accesses it.  This would be normally done during phy_ops.power_on()
or clk_ops.prepare() callbacks, but it might happen that the former gets
fired too late and the latter only once, hence we need to keep handle it
via clk_ops.set_rate() as a fallback approach.

Prevent changing the TMDS character rate via CCF by letting
rk_hdptx_phy_clk_round_rate() always return the value set via
phy_configure().  To avoid breaking existing users, i.e. RK DW HDMI QP
bridge driver, until the switch to the HDMI PHY config based approach is
completed, introduce a temporary exception to the rule, toggled via the
new ->restrict_rate_change flag, which indicates whether phy_configure()
has been called or not.

Additionally, revert any unlikely rate change that might have occurred
between the calls to ->round_rate() and ->set_rate().

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Implement the phy_ops.validate() callback to allow checking the PHY
configuration parameters without actually applying them.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

The current workaround to setup the TMDS character rate relies on the
unconventional usage of phy_set_bus_width().

Make use of the recently introduced HDMI PHY configuration API to
properly handle the setup.  The workaround will be dropped as soon as
the switch has been completed on both ends.

Rename rk_hdptx_phy_verify_config() to rk_hdptx_phy_verify_dp_config()
and introduce the rk_hdptx_phy_verify_hdmi_config() helper to check the
HDMI parameters during phy_configure().

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

The ropll_tmds_cfg table used to identify the configuration params for
the supported rates expects the search key, i.e. bit_rate member of
struct ropll_config, to be provided in hHz rather than Hz (1 hHz = 100
Hz).  This requires multiple conversions between these units being
performed at runtime.

Improve implementation clarity and efficiency by consistently using the
Hz unit throughout driver's internal data structures and functions.
Also rename the rather misleading struct member.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

The ->cfgs member has been introduced via commit f08d1c08 ("phy:
phy-rockchip-samsung-hdptx: Don't use dt aliases to determine phy-id"),
but it is only used during probe() in order to setup ->phy_id.

Use a probe() local variable to store device match data and remove the
now unnecessary member from struct rk_hdptx_phy.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

There is no usage of phy_cfg in the upstream driver data, nor in the
downstream one, hence remove it.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

This is just a leftover from downstream support for HDMI 2.1.
Remove the unused struct for now.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Ensure rk_hdptx_ropll_tmds_cmn_config() updates hdptx->rate only after
all the other operations have been successful.

Fixes: c4b09c56 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

The switch from 1/10 to 1/40 clock ratio must happen when exceeding the
340 MHz rate limit of HDMI 1.4, i.e. when entering the HDMI 2.0 domain,
and not before.

Therefore, use the correct comparison operator '>' instead of '>=' when
checking the max rate.  While at it, introduce a define for this rate
limit constant.

Fixes: 553be283 ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Extend the HDMI configuration options to allow managing bits per color
channel.  This is required by some PHY drivers such as
rockchip-samsung-hdptx.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Sandor Yu authored 3 months ago and Cristian Ciocaltea committed 4 weeks ago

Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.

The parameters added here are based on HDMI PHY
implementation practices.  The current set of parameters
should cover the potential users.

Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/d1cff6c03ec3732d2244022029245ab2d954d997.1734340233.git.Sandor.yu@nxp.com


Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Nicolas Frattaroli authored 1 month ago and Cristian Ciocaltea committed 4 weeks ago

Despite the compatible already being listed in the bindings, the PHY
driver never gained explicit support for it. This is especially a
problem because the explicitly listed PHY addresses need to be specified
for each SoC.

To solve this, add the compatible, and a PHY config, with the address
gleaned from rk3576.dtsi.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250306-rk3576-hdptx-phy-v1-1-288cc4b0611a@collabora.com


Signed-off-by: Vinod Koul <vkoul@kernel.org>
(cherry picked from commit 4a8463ae)
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

TODO: Implement a generic mechanism to verify supported capabilities at
library consumer level. For now it's just the RK bridge glue layer.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Toggle bpc flag at PHY configuration level and program the necessary
bridge register to allow using the 10bpc color depth and YUV420 color
format.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

TODO: proper colorspace conversion handling

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Take output bits per color into consideration when computing the clock
rate.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Introduce the switch to YUV420 when computing the best output format and
RGB cannot be supported for a given color depth.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Add the missing 'bpc' string to the debug message indicating the
supported format identified within hdmi_try_format_bpc() helper.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Provide the necessary constraints verification in
sink_supports_format_bpc() in order to support handling of YUV420
output format.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Evaluating the requirement to use a limited RGB quantization range
involves a verification of the output format, among others, but this is
currently performed before actually computing the format, hence relying
on the old connector state.

Move the call to hdmi_is_limited_range() after hdmi_compute_config() to
ensure the verification is done on the updated output format.

Fixes: 027d4359 ("drm/connector: hdmi: Add RGB Quantization Range to the connector state")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Enable use of HDMI 2.0 display modes, e.g. 4K@60Hz, by permitting TMDS
character rates above the 340 MHz limit of HDMI 1.4b.

Hence, add the required support for SCDC management, including the high
TMDS clock ratio and scrambling setup.

Additionally, filter out HDMI 2.1 display modes.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

In preparation to provide scrambling support to the HDMI Connector
framework, make use of the more flexible ->detect_ctx() bridge connector
helper hook instead of ->detect().

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Add a ->detect() variant that also provides a drm_modeset_acquire_ctx
reference for greater flexibility in operation, e.g. to support adding
scrambling functionality to drm_bridge_connector.

When both ->detect_ctx() and ->detect() are defined, the latter is
simply ignored.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Stop relying on phy_set_bus_width() workaround to setup the TMDS
character rate and, instead, use the proper HDMI PHY configuration API
for this purpose.

Additionally, move the logic into the ->atomic_check() callback where
the current mode rate is already provided by
drm_connector_hdmi_state->tmds_char_rate.  This allows adding later
support for high color depth and YUV420 output format, rather then being
limited to 8bpc RGB.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Add the necessary DT changes to enable the second HDMI output port on
Rockchip RK3588 EVB1.

While at it, switch the position of &vop_mmu and @vop to maintain the
alphabetical order.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

VOP2 on RK3588 is able to use the HDMI PHY PLL as an alternative and
more accurate pixel clock source to improve handling of display modes up
to 4K@60Hz on video ports 0, 1 and 2.

The HDMI1 PHY PLL clock source cannot be added directly to vop node in
rk3588-base.dtsi, along with the HDMI0 related one, because HDMI1 is an
optional feature and its PHY node belongs to a separate (extra) DT file.

Therefore, add the HDMI1 PHY PLL clock source to VOP2 by overwriting its
clocks & clock-names properties in the extra DT file.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Since commit c4b09c56 ("phy: phy-rockchip-samsung-hdptx: Add clock
provider support"), the HDMI PHY PLL can be used as an alternative and
more accurate pixel clock source for VOP2 to improve display modes
handling on RK3588 SoC.

Add the missing #clock-cells property to allow using the clock provider
functionality of HDMI1 PHY.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Replace drm_err() calls in vop2_bind() and vop2_create_crtcs() with
dev_err_probe(), to simplify error handling and improve consistency.

Additionally, ensure the already existing dev_err_probe() invocations
pass drm->dev instead of dev as their first argument, so that we get the
actual reason in case of -EPROBE_DEFER errors:

  platform display-subsystem: deferred probe pending: (reason unknown)
    vs.
  platform display-subsystem: deferred probe pending: rockchip-drm: <actual reason>

While at it, add the missing '\n' to some of the message strings.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

The RK3588 specific implementation is currently quite limited in terms
of handling the full range of display modes supported by the connected
screens, e.g. 2560x1440@75Hz, 2048x1152@60Hz, 1024x768@60Hz are just a
few of them.

Additionally, it doesn't cope well with non-integer refresh rates like
59.94, 29.97, 23.98, etc.

Make use of HDMI1 PHY PLL as a more accurate DCLK source to handle
all display modes up to 4K@60Hz.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Heiko Stuebner authored 1 month ago and Cristian Ciocaltea committed 1 month ago

of_clk_get_hw_from_clkspec checks all available clock-providers by
compairing their of-nodes to the one from the clkspec. If no matching
clock-provider is found, the function returns EPROBE_DEFER to cause a
re-check at a later date.

If a matching clock-provider is found, an authoritative answer can be
retrieved from it whether the clock exists or not.

This does not take into account that the clock-provider may never appear,
because it's node is disabled. This can happen for example when a clock
is optional, provided by a separate block which just never gets enabled.

One example of this happening is the rk3588's VOP, which has optional
additional display-clock-supplies coming from PLLs inside the hdmiphy
blocks. These can be used for better rates, but the system will also
work without them.

The problem around that is described in the followups to:
https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/



As we already know the of-node of the presumed clock-provider, just add
a check via of_device_is_available whether this is a "valid" device node.
This prevents eternal defer-loops.

Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250222223733.2990179-1-heiko@sntech.de


Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Ricardo Ribalda authored 2 months ago and Cristian Ciocaltea committed 1 month ago

When running cocci in report mode, eg:
$make coccicheck M="$dir" MODE=report

It returns this error:
virtual rule report not supported
coccicheck failed
make: *** [Makefile:251: __sub-make] Error 2

Create a dummy rule to avoid this error and run the other cocci scripts.

Fixes: 551dbd1e ("coccinelle: misc: add secs_to_jiffies script")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Link: https://lore.kernel.org/r/20250129-secs_to_jiffles-v1-1-35a5e16b9f03@chromium.org


Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>