Ensure CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX depends on CONFIG_COMMON_CLK to
fix the following link errors when compile testing some random kernel
configurations:
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.o: in function `rk_hdptx_phy_clk_register':
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1031:(.text+0x470): undefined reference to `__clk_get_name'
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1036:(.text+0x4ba): undefined reference to `devm_clk_hw_register'
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1040:(.text+0x4d2): undefined reference to `of_clk_hw_simple_get'
m68k-linux-ld: drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:1040:(.text+0x4da): undefined reference to `devm_of_clk_add_hw_provider'
Fixes: c4b09c5620 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202409180305.53PXymZn-lkp@intel.com/
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240923-sam-hdptx-link-fix-v1-1-8d10d7456305@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The HDMI PHY PLL can be used as an alternative dclk source to RK3588 SoC
CRU. It provides more accurate clock rates required by VOP2 to improve
existing support for display modes handling, which is known to be
problematic when dealing with non-integer refresh rates, among others.
It is worth noting this only works for HDMI 2.0 or below, e.g. cannot be
used to support HDMI 2.1 4K@120Hz mode.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240620-rk3588-hdmiphy-clkprov-v2-4-6a2d2164e508@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
When a new PHY is created via [devm_]phy_create(), the runtime PM for it
is not enabled unless the parent device (which creates the PHY) has its
own runtime PM already enabled.
Move the call to devm_pm_runtime_enable() before devm_phy_create() to
enable runtime PM at PHY core level.
With this change the ->power_on() and ->power_off() callbacks do not
require explicit runtime PM management anymore, since the PHY core
handles that via phy_pm_runtime_{get,put}_sync() when phy_power_on() and
phy_power_off() are invoked.
Hence drop the now unnecessary calls to pm_runtime_resume_and_get() and
pm_runtime_put() helpers.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240620-rk3588-hdmiphy-clkprov-v2-2-6a2d2164e508@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Compile testing configurations without REGMAP support enabled results in
a bunch of errors being reported:
../drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:569:21: error: variable ‘rk_hdptx_phy_regmap_config’ has initializer but incomplete type
569 | static const struct regmap_config rk_hdptx_phy_regmap_config = {
| ^~~~~~~~~~~~~
../drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:570:10: error: ‘const struct regmap_config’ has no member named ‘reg_bits’
570 | .reg_bits = 32,
| ^~~~~~~~
Note that selecting REGMAP alone is not enough, because of the following
liker error:
phy-rockchip-samsung-hdptx.c:(.text+0x10c): undefined reference to `__devm_regmap_init_mmio_clk'
Instead of the obvious fix to enable REGMAP_MMIO, select MFD_SYSCON,
which implicitly enables REGMAP_MMIO as well. The rationale is that the
driver has been already relying on the syscon functionality.
Moreover, without MFD_SYSCON enabled, the test coverage is reduced,
since the linker might not detect any potential undefined references
following syscon_regmap_lookup_by_phandle() invocation in
rk_hdptx_phy_probe() body. That is because the function would
unconditionally return -ENOTSUP, hence the compiler is free to optimize
out any unreachable code.
Finally ensure PHY_ROCKCHIP_SAMSUNG_HDPTX depends on HAS_IOMEM, as
required by MFD_SYSCON.
Fixes: 553be2830c ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20240629-rk-hdptx-compile-test-fix-v1-1-c86675ba8070@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The newly added driver causes a warning about missing dependencies
by selecting CONFIG_TYPEC unconditionally:
WARNING: unmet direct dependencies detected for TYPEC
Depends on [n]: USB_SUPPORT [=n]
Selected by [y]:
- PHY_ROCKCHIP_USBDP [=y] && ARCH_ROCKCHIP [=y] && OF [=y]
WARNING: unmet direct dependencies detected for USB_COMMON
Depends on [n]: USB_SUPPORT [=n]
Selected by [y]:
- EXTCON_RTK_TYPE_C [=y] && EXTCON [=y] && (ARCH_REALTEK [=y] || COMPILE_TEST [=y]) && TYPEC [=y]
Since that is a user-visible option, it should not really be selected
in the first place. Replace the 'select' with a 'depends on' as
we have for similar drivers.
Fixes: 2f70bbddeb ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240415174241.77982-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
>From the RK3588 Technical Reference Manual, Part1,
section 6.19 PCIe3PHY_GRF Register Description:
"rxX_cmn_refclk_mode"
RX common reference clock mode for lane X. This mode should be enabled
only when the far-end and near-end devices are running with a common
reference clock.
The hardware reset value for this field is 0x1 (enabled).
Note that this register field is only available on RK3588, not on RK3568.
The link training either fails or is highly unstable (link state will jump
continuously between L0 and recovery) when this mode is enabled while
using an endpoint running in Separate Reference Clock with No SSC (SRNS)
mode or Separate Reference Clock with SSC (SRIS) mode.
(Which is usually the case when using a real SoC as endpoint, e.g. the
RK3588 PCIe controller can run in both Root Complex and Endpoint mode.)
Add support for the device tree property rockchip,rx-common-refclk-mode,
such that the PCIe PHY can be used in configurations where the Root
Complex and Endpoint are not using a common reference clock.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20240412125818.17052-3-cassel@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This adds a new USBDP combo PHY with Samsung IP block driver.
The driver get lane mux and mapping info in 2 ways, supporting
DisplayPort alternate mode or parsing from DT. When parsing from DT,
the property "rockchip,dp-lane-mux" provide the DP mux and mapping
info. This is needed when the PHY is not used with TypeC Alt-Mode.
For example if the USB3 interface of the PHY is connected to a USB
Type A connector and the DP interface is connected to a DisplayPort
connector.
When do DP link training, need to set lane number, link rate, swing,
and pre-emphasis via PHY configure interface.
Co-developed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Co-developed-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Co-developed-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20240408225109.128953-3-sebastian.reichel@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The pcie1l0_sel and pcie1l1_sel bits in PCIESEL_CON configure the
mux for PCIe1L0 and PCIe1L1 to either the PIPE Combo PHYs or the
PCIe3 PHY. Thus this configuration interfers with the data-lanes
configuration done by the PCIe3 PHY.
RK3588 has three Combo PHYs. The first one has a dedicated PCIe
controller and is not affected by this. For the other two Combo
PHYs, there is one mux for each of them.
pcie1l0_sel selects if PCIe 1L0 is muxed to Combo PHY 1 when
bit is set to 0 or to the PCIe3 PHY when bit is set to 1.
pcie1l1_sel selects if PCIe 1L1 is muxed to Combo PHY 2 when
bit is set to 0 or to the PCIe3 PHY when bit is set to 1.
Currently the code always muxes 1L0 and 1L1 to the Combi PHYs
once one of them is being used in PCIe mode. This is obviously
wrong when at least one of the ports should be muxed to the
PCIe3 PHY.
Fix this by introducing Combo PHY identification and then only
setting up the required bit.
Fixes: a03c442772 ("phy: rockchip: Add naneng combo phy support for RK3588")
Reported-by: Michal Tomek <mtdev79b@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-3-9907136eeafd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
So far all RK3588 boards use fully aggregated PCIe. CM3588 is one
of the few boards using this feature and apparently it is broken.
The PHY offers the following mapping options:
port 0 lane 0 - always mapped to controller 0 (4L)
port 0 lane 1 - to controller 0 or 2 (1L0)
port 1 lane 0 - to controller 0 or 1 (2L)
port 1 lane 1 - to controller 0, 1 or 3 (1L1)
The data-lanes DT property maps these as follows:
0 = no controller (unsupported by the HW)
1 = 4L
2 = 2L
3 = 1L0
4 = 1L1
That allows the following configurations with first column being the
mainline data-lane mapping, second column being the downstream name,
third column being PCIE3PHY_GRF_CMN_CON0 and PHP_GRF_PCIESEL register
values and final column being the user visible lane setup:
<1 1 1 1> = AGGREG = [4 0] = x4 (aggregation)
<1 1 2 2> = NANBNB = [0 0] = x2 x2 (no bif.)
<1 3 2 2> = NANBBI = [1 1] = x2 x1x1 (bif. of port 0)
<1 1 2 4> = NABINB = [2 2] = x1x1 x2 (bif. of port 1)
<1 3 2 4> = NABIBI = [3 3] = x1x1 x1x1 (bif. of both ports)
The driver currently does not program PHP_GRF_PCIESEL correctly, which
is fixed by this patch. As a side-effect the new logic is much simpler
than the old logic.
Fixes: 2e9bffc4f7 ("phy: rockchip: Support PCIe v3")
Signed-off-by: Michal Tomek <mtdev79b@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-1-9907136eeafd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 51a9b2c03d ("phy: rockchip-inno-usb2: Handle ID IRQ") added ID
detection interrupt registers. However the current implementation assumes
that falling and rising edge interrupt are always enabled in registers
spanning over subsequent bits.
That is not the case for RK3128's version of the phy and this
implementation can't be used as-is, since there are bits with different
purpose in between.
This splits up the register definitions for id_det_en, id_det_en and
id_det_clr registers in rising and falling edge variants.
It's required as preparation to support RK3128's Innosilicon usb2 phy as
well in this driver and matches pretty much to what the vendor does, so I'm
not expecting issues for other SoCs with that change.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20231119121340.109025-2-knaerzche@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for drivers/phy/phy-can-transceiver.c
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20230714174841.4061919-1-robh@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This adds a bunch of new pixel clock- and tmds rates to the pre-pll
table which are required to get more VESA and some DMT rates working.
It has been completely re-calculated to match the min- and max-vco of
(750 MHz - 3.2 GHz) requirements. If more than one configuration would
have been possible the lowest fbdiv and refdiv (and therefore lowest
vco rate) has been preferred.
It's important to note, that RK3228 version of the phy does not support
fractional dividers. To support the most possible rates for this version
also in both 8-bit and 10-bit variant, some rates are not exact. The
maximum deviation of the pixel clock is 0.26, which perfectly fits into
VESA DMT recommendation of 0.5%.
I tested all possible rates on several screens from different
manufacturers with both RK3228 and RK3328. Both pre- and post-PLL
locking are slighlty faster now.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20230615171005.2251032-7-jonas@kwiboo.se
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Regular 8-bit and Deep Color video formats mainly differ in TMDS rate and
not in pixel clock rate.
When the hdmiphy clock is configured with the same pixel clock rate using
clk_set_rate() the clock framework do not signal the hdmi phy driver
to set_rate when switching between 8-bit and Deep Color.
This result in pre/post pll not being re-configured when switching between
regular 8-bit and Deep Color video formats.
Fix this by calling set_rate in power_on to force pre pll re-configuration.
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20230615171005.2251032-6-jonas@kwiboo.se
Signed-off-by: Vinod Koul <vkoul@kernel.org>
inno_write is used to configure 0xaa reg, that also hold the
POST_PLL_POWER_DOWN bit.
When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
taken into consideration.
Fix this by keeping the power down bit until configuration is complete.
Also reorder the reg write order for consistency.
Fixes: 53706a1168 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20230615171005.2251032-5-jonas@kwiboo.se
Signed-off-by: Vinod Koul <vkoul@kernel.org>
inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
in the pre pll config table when the fractal divider is used.
This can prevent proper power_on because a tmdsclock for the new rate
is not found in the pre pll config table.
Fix this by saving and returning a rounded pixel rate that exist
in the pre pll config table.
Fixes: 53706a1168 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20230615171005.2251032-3-jonas@kwiboo.se
Signed-off-by: Vinod Koul <vkoul@kernel.org>
On RK3588 some registers need to be tweaked to support waking up from
suspend when a USB device is plugged into a port from a suspended PHY.
Without this change USB devices only work when they are plugged at
boot time.
Apart from that it optimizes settings to avoid devices toggling
between fullspeed and highspeed mode.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20230522170324.61349-5-sebastian.reichel@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
clang with W=1 reports
drivers/phy/rockchip/phy-rockchip-pcie.c:122:19: error:
unused function 'phy_rd_cfg' [-Werror,-Wunused-function]
static inline u32 phy_rd_cfg(struct rockchip_pcie_phy *rk_phy,
^
This function is not used, so remove it.
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230321122503.1783311-1-trix@redhat.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20230307115900.2293120-23-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20230307115900.2293120-22-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20230307115900.2293120-21-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20230307115900.2293120-20-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The existing logic in tcphy_get_mode() can cause the phy to be
incorrectly configured to USB UFP or DisplayPort mode when
extcon_get_state returns an error code.
extcon_get_state() can return 0, 1, or a negative error code.
It is possible to get into the failing state with an extcon driver
which does not support the extcon connector id specified as the
second argument to extcon_get_state().
tcphy_get_mode()
->extcon_get_state()
-->find_cable_index_by_id()
--->return -EINVAL;
Fixes: e96be45cb8 ("phy: Add USB Type-C PHY driver for rk3399")
Signed-off-by: Neill Kapron <nkapron@google.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230126001013.3707873-1-nkapron@google.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The rockchip,pipe-grf property is only used on rk3588, but not on
rk3568. Therefore this property is not present on rk3568 devices,
leading to the following message:
rockchip-snps-pcie3-phy fe8c0000.phy: failed to find rockchip,pipe_grf regmap
Fix that by only looking for this property on rk3588.
Fixes: 2e9bffc4f7 ("phy: rockchip: Support PCIe v3")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Link: https://lore.kernel.org/r/20220927051752.53089-1-aurelien@aurel32.net
Signed-off-by: Vinod Koul <vkoul@kernel.org>
