When adding support for some of the platforms (sc7180, sc8180x, sdm845,
sm8[1234]50), we added USB PHYs for the combo USB+DP QMP PHYs. Now all
such usecases were migrated to use USB+DP Combo driver. To simplify the
qcom-qmp-usb PHY driver split the legacy USB+dp_com support into a
separate driver.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20230531023415.1209301-6-dmitry.baryshkov@linaro.org
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>
Instead of a 3D matrix use a key:value pair table for link_cmn_vals,
xcvr_diag_vals, pcs_cmn_vals, phy_pma_cmn_vals, cmn_vals,
tx_ln_vals and rx_ln_vals. This makes it scaleable for multiple
reference clocks.
Wherever both CDNS and TI use the same settings, reuse the same data.
Introduce CLK_ANY and ANY_SSC enums which are used if the setting
is independent of clock rate or SSC type.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Link: https://lore.kernel.org/r/20230530143853.26571-3-sjakhade@cadence.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Pull phy updates from Vinod Koul:
"New Support:
- Debugfs support for phy core and mediatek driver
- Hisilicon inno-usb2-phy driver supporting Hi3798MV100
- Qualcomm SGMII SerDes PHY driver, SM6115 & QCM2290 QMP-USB support,
SA8775P USB PHY & USB3 UNI support, QUSB2 support for IPQ9574,
IPQ9574 USB3 PHY
UpdatesL
- Sparx5 serdes phy power optimzation
- cadence salvo usb properties and updates and torrent DP with PCIe &
USB support
- Yaml conversion for Broadcom kona USB bindings and MXS USB binding"
* tag 'phy-for-6.5_v2' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (67 commits)
dt-bindings: phy: brcm,brcmstb-usb-phy: Fix error in "compatible" conditional schema
dt-bindings: phy: mixel,mipi-dsi-phy: Remove assigned-clock* properties
dt-bindings: phy: intel,combo-phy: restrict node name suffixes
dt-bindings: phy: qcom,usb-hs-phy: Add compatible
phy: tegra: xusb: check return value of devm_kzalloc()
phy: qcom: qmp-combo: fix Display Port PHY configuration for SM8550
phy: qcom: add the SGMII SerDes PHY driver
dt-bindings: phy: describe the Qualcomm SGMII PHY
phy: qualcomm: fix indentation in Makefile
phy: usb: suppress OC condition for 7439b2
phy: usb: Turn off phy when port is in suspend
phy: tegra: xusb: Clear the driver reference in usb-phy dev
dt-bindings: phy: mxs-usb-phy: add imx8ulp and imx8qm compatible
dt-bindings: phy: mxs-usb-phy: convert to DT schema format
dt-bindings: phy: qcom,qmp-usb: fix bindings error
dt-bindings: phy: qcom,qmp-ufs: fix the sc8180x regs
dt-bindings: phy: qcom,qmp-pcie: fix the sc8180x regs
phy: mediatek: tphy: add debugfs files
phy: core: add debugfs files
phy: fsl-imx8mp-usb: add support for phy tuning
...
Pull media updates from Mauro Carvalho Chehab:
- Lots of improvement at atomisp driver, which is starting to look in
good shape
- Mediatek vcodec driver has gained support for av1 and hevc stateless
codecs
- New sensor driver: ov01a10
- verisilicon driver has gained AV1 entropy helpers
- tegra-video has gained support for Tegra20 parallel input
- dvb core has gained an extra property to better support DVB-S2X
- as usual, lots of cleanups, fixes and improvements on media drivers
* tag 'media/v6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (253 commits)
media: wl128x: fix a clang warning
media: dvb: mb86a20s: get rid of a clang-15 warning
media: cec: i2c: ch7322: also select REGMAP
media: add HAS_IOPORT dependencies
media: tc358746: select CONFIG_GENERIC_PHY
media: mediatek: vcodec: Add dbgfs help function
media: mediatek: vcodec: Add encode to support dbgfs
media: mediatek: vcodec: Change dbgfs interface to support encode
media: mediatek: vcodec: Get each instance format type
media: mediatek: vcodec: Get each context resolution information
media: mediatek: vcodec: Add a debugfs file to get different useful information
media: mediatek: vcodec: Add debug params to control different log level
media: mediatek: vcodec: Add debugfs interface to get debug information
media: mediatek: vcodec: support stateless AV1 decoder
media: verisilicon: Conditionally ignore native formats
media: verisilicon: Enable AV1 decoder on rk3588
media: verisilicon: Add film grain feature to AV1 driver
media: verisilicon: Add Rockchip AV1 decoder
media: verisilicon: Add AV1 entropy helpers
media: verisilicon: Compute motion vectors size for AV1 frames
...
Pull clk updates from Stephen Boyd:
"This batch of clk driver updates contains almost no new SoC support.
Instead there's a treewide patch series from Maxime that makes
clk_ops::determine_rate mandatory for muxes.
Beyond that core framework change we have the usual pile of clk driver
updates such as migrating i2c drivers to use .probe() again or
YAMLfication of clk DT bindings so we can validate DTBs.
Overall the SoCs that got the most updates this time around in terms
of diffstat are the Amlogic and Mediatek drivers because they added
new SoC support or fixed up various drivers to have proper data.
In general things look kinda quiet. I suspect the core framework
change may still shake out some problems after the merge window,
mostly because not everyone tests linux-next where that series has
been for some number of weeks. I saw that there's at least one pending
fix for Tegra that needs to be wrapped up into a proper patch. I'll
try to catch those bits before the window closes so that -rc1 is
bootable. More details below.
Core:
- Make clk_ops::determine_rate mandatory for muxes
New Drivers:
- Add amlogic a1 SoC family PLL and peripheral clock controller support
Updates:
- Handle allocation failures from kasprintf() and friends
- Migrate platform clk drivers to .remove_new()
- Migrate i2c clk drivers to .probe() instead of .probe_new()
- Remove CLK_SET_PARENT from all Mediatek MSDC core clocks
- Add infra_ao reset support for Mediatek MT8188 SoCs
- Align driver_data to i2c_device_id tables in some i2c clk drivers
- Use device_get_match_data() in vc5 clk driver
- New Kconfig symbol name (SOC_MICROCHIP_POLARFIRE) for Microchip
FPGA clock drivers
- Use of_property_read_bool() to read "microchip,pic32mzda-sosc"
boolean DT property in clk-pic32mzda
- Convert AT91 clock dt-bindings to YAML
- Remove CLK_SET_RATE_PARENT flag from LDB clocks on i.MX6SX
- Keep i.MX UART clocks enabled during kernel boot if earlycon is set
- Drop imx_unregister_clocks() as there are no users anymore
- Switch to _safe iterator on imx_clk_scu_unregister() to avoid use
after free
- Add determine_rate op to the imx8m composite clock
- Use device managed API for iomap and kzalloc for i.MXRT1050,
i.MX8MN, i.MX8MP and i.MX93 clock controller drivers
- Add missing interrupt DT property for the i.MX8M clock controller
- Re-add support for Exynos4212 clock controller because we are
re-introducing the SoC in the mainline
- Add CONFIG_OF dependency to Samsung clk Kconfig symbols to solve
some objtool warnings
- Preselect PLL MIPI as TCON0 parent for Allwinner A64 SoC
- Convert the Renesas clock drivers to readl_poll_timeout_atomic()
- Add PWM clock on Renesas R-Car V3U
- Fix PLL5 on Renesas RZ/G2L and RZ/V2L"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (149 commits)
clk: fix typo in clk_hw_register_fixed_rate_parent_data() macro
clk: Fix memory leak in devm_clk_notifier_register()
clk: mvebu: Iterate over possible CPUs instead of DT CPU nodes
clk: mvebu: Use of_get_cpu_hwid() to read CPU ID
MAINTAINERS: Add Marvell mvebu clock drivers
clk: clocking-wizard: check return value of devm_kasprintf()
clk: ti: clkctrl: check return value of kasprintf()
clk: keystone: sci-clk: check return value of kasprintf()
clk: si5341: free unused memory on probe failure
clk: si5341: check return value of {devm_}kasprintf()
clk: si5341: return error if one synth clock registration fails
clk: cdce925: check return value of kasprintf()
clk: vc5: check memory returned by kasprintf()
clk: mediatek: clk-mt8173-apmixedsys: Fix iomap not released issue
clk: mediatek: clk-mt8173-apmixedsys: Fix return value for of_iomap() error
clk: mediatek: clk-mtk: Grab iomem pointer for divider clocks
clk: keystone: syscon-clk: Add support for audio refclk
dt-bindings: clock: Add binding documentation for TI Audio REFCLK
dt-bindings: clock: ehrpwm: Remove unneeded syscon compatible
clk: keystone: syscon-clk: Allow the clock node to not be of type syscon
...
The tc358746 driver selects CONFIG_GENERIC_PHY_MIPI_DPHY and links to
that, but this fails when CONFIG_GENERIC_PHY is disabled, because Kbuild
then never enters the drivers/phy directory for building object files:
ERROR: modpost: "phy_mipi_dphy_get_default_config_for_hsclk" [drivers/media/i2c/tc358746.ko] undefined!
Add an explicit 'select GENERIC_PHY' here to ensure that the directory
is entered, and add another dependency on that symbol so make it
more obvious what is going on if another driver has the same problem,
as this will produce a Kconfig warning.
Link: https://lore.kernel.org/linux-media/20230623152318.2276816-1-arnd@kernel.org
Fixes: 80a21da360 ("media: tc358746: add Toshiba TC358746 Parallel to CSI-2 bridge driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The COMMONONN bit turns off the PHY when the host controller puts it
into suspend state. This can happen during the following...
- Nothing is connected to the port
- The host controller goes into low power mode whatever due to auto
suspend or system suspend.
With COMMONONN we also must unset U2_FREECLK_EXISTS since the UTMI
clock is fed by the PHY.
With these changes we see a power savings of ~12mW when port is in
suspend.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Link: https://lore.kernel.org/r/1686859578-45242-2-git-send-email-justin.chen@broadcom.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The TI J721e Wiz clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems
unlikely.
Cc: Kishon Vijay Abraham I <kishon@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: linux-phy@lists.infradead.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-44-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The TI AM654 SerDes clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems
unlikely.
Cc: Kishon Vijay Abraham I <kishon@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: linux-phy@lists.infradead.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-43-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The Cadence Torrent refclk clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems
unlikely.
Cc: Kishon Vijay Abraham I <kishon@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: linux-phy@lists.infradead.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-42-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The Cadence Sierra PLL clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to clk_set_rate(), with
determine_rate() figuring out which parent is the best suited for a
given rate.
The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().
The latter case would be equivalent to setting the flag
CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook
to __clk_mux_determine_rate(). Indeed, if no determine_rate
implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.
And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems
unlikely.
Cc: Kishon Vijay Abraham I <kishon@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: linux-phy@lists.infradead.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-41-971d5077e7d2@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The QMP combo PHY sits in an of_graph connected between the DisplayPort
controller and a USB Type-C connector (or possibly a redriver).
The TCPM needs to be able to convey the HPD signal to the DisplayPort
controller, but no directly link is provided by DeviceTree so the signal
needs to "pass through" the QMP combo phy.
Handle this by introducing a drm_bridge which upon initialization finds
the next bridge (i.e. the usb-c-connector) and chain this together. This
way HPD changes in the connector will propagate to the DisplayPort
driver.
The connector bridge is resolved lazily, as the TCPM is expected to be
able to resolve the typec mux and switch at probe time, so the QMP combo
phy will probe before the TCPM.
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Abel Vesa <abel.vesa@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450
Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Link: https://lore.kernel.org/r/20230515032743.400170-7-quic_bjorande@quicinc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The data lanes of the QMP PHY is swapped in order to handle changing
orientation of the USB Type-C cable. Register a typec_switch device to
allow a TCPM to configure the orientation.
The newly introduced orientation variable is adjusted based on the
request, and the initialized components are brought down and up again.
To keep track of what parts needs to be cycled new variables to keep
track of the individual init_count is introduced.
Both the USB and the DisplayPort altmode signals are properly switched.
For DisplayPort the controller will after the TCPM having established
orientation power on the PHY, so this is not done implicitly, but for
USB the PHY typically is kept initialized across the switch, and must
therefore then be reinitialized.
This is based on initial work by Wesley Cheng.
Link: https://lore.kernel.org/r/20201009082843.28503-3-wcheng@codeaurora.org/
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Abel Vesa <abel.vesa@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on HDK8450
Tested-by: Johan Hovold <johan+linaro@kernel.org> # X13s
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Link: https://lore.kernel.org/r/20230515032743.400170-6-quic_bjorande@quicinc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For NXP platform design, the PHY can't know VBUS well, it causes the FSM
in controller seeing the disconnection at L1 use case. With .set_mode API
introduced, the controller driver could force PHY seeing B Session VALID
when it is at the device mode (VBUS is there), and keep FSM working well.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20230517161646.3418250-5-Frank.Li@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Very limited parts may fail to work on full speed mode (both host and
device modes) for USB3 port due to higher threshold in full speed receiver
of USB2.0 PHY.
One example failure symptom is, the enumeration is failed when connecting
full speed USB mouse to USB3 port, especially under high temperature.
The workaround is to configure threshold voltage value of single ended
receiver by setting USB2.0 PHY register AFE_RX_REG5[2:0] to 3'b101.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20230517161646.3418250-4-Frank.Li@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For USB2 L1 use cases, some hosts may start transferring less than 20us
after End of Resume, it causes the host seeing corrupt packet from the
device side. The reason is the delay time between PHY powers up and
txvalid is 20us. To fix it, we change the delay value as 0us.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20230517161646.3418250-3-Frank.Li@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add support for the new qcm2290 / sm6115 binding.
The USB QMP phy on these devices supports 2 lanes. Note that the
binding now does not describe every register subregion and instead
the driver holds the corresponding offsets.
While at it also include support for PCS_MISC region which was left
out earlier.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Link: https://lore.kernel.org/r/20230516150511.2346357-3-bhupesh.sharma@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
