<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/phy/rockchip, branch v6.6.39</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.39</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.39'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-05-02T14:32:48+00:00</updated>
<entry>
<title>phy: rockchip: naneng-combphy: Fix mux on rk3588</title>
<updated>2024-05-02T14:32:48+00:00</updated>
<author>
<name>Sebastian Reichel</name>
<email>sebastian.reichel@collabora.com</email>
</author>
<published>2024-04-04T17:11:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1da7f6abd3baeeb654f66bec196e5c9feeec3402'/>
<id>urn:sha1:1da7f6abd3baeeb654f66bec196e5c9feeec3402</id>
<content type='text'>
[ Upstream commit d16d4002fea69b6609b852dd8db1f5844c02fbe4 ]

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: a03c44277253 ("phy: rockchip: Add naneng combo phy support for RK3588")
Reported-by: Michal Tomek &lt;mtdev79b@gmail.com&gt;
Signed-off-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-3-9907136eeafd@kernel.org
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: rockchip-snps-pcie3: fix clearing PHP_GRF_PCIESEL_CON bits</title>
<updated>2024-05-02T14:32:48+00:00</updated>
<author>
<name>Sebastian Reichel</name>
<email>sebastian.reichel@collabora.com</email>
</author>
<published>2024-04-04T17:11:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=743cf2f19d96c2ca4cefd4fadd5a31b3681d56ac'/>
<id>urn:sha1:743cf2f19d96c2ca4cefd4fadd5a31b3681d56ac</id>
<content type='text'>
[ Upstream commit 55491a5fa163bf15158f34f3650b3985f25622b9 ]

Currently the PCIe v3 PHY driver only sets the pcie1ln_sel bits, but
does not clear them because of an incorrect write mask. This fixes up
the issue by using a newly introduced constant for the write mask.

While at it also introduces a proper GENMASK based constant for the
PCIE30_PHY_MODE.

Fixes: 2e9bffc4f713 ("phy: rockchip: Support PCIe v3")
Signed-off-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-2-9907136eeafd@kernel.org
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: rockchip-snps-pcie3: fix bifurcation on rk3588</title>
<updated>2024-05-02T14:32:48+00:00</updated>
<author>
<name>Michal Tomek</name>
<email>mtdev79b@gmail.com</email>
</author>
<published>2024-04-04T17:11:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d3d3723d70c1a07872d6235162b140496937d689'/>
<id>urn:sha1:d3d3723d70c1a07872d6235162b140496937d689</id>
<content type='text'>
[ Upstream commit f8020dfb311d2b6cf657668792aaa5fa8863a7dd ]

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:

  &lt;1 1 1 1&gt; = AGGREG = [4 0] = x4 (aggregation)
  &lt;1 1 2 2&gt; = NANBNB = [0 0] = x2 x2 (no bif.)
  &lt;1 3 2 2&gt; = NANBBI = [1 1] = x2 x1x1 (bif. of port 0)
  &lt;1 1 2 4&gt; = NABINB = [2 2] = x1x1 x2 (bif. of port 1)
  &lt;1 3 2 4&gt; = 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: 2e9bffc4f713 ("phy: rockchip: Support PCIe v3")
Signed-off-by: Michal Tomek &lt;mtdev79b@gmail.com&gt;
Signed-off-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/20240404-rk3588-pcie-bifurcation-fixes-v1-1-9907136eeafd@kernel.org
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: rockchip: inno-dsidphy: Add rv1126 support</title>
<updated>2023-08-22T13:58:11+00:00</updated>
<author>
<name>Jagan Teki</name>
<email>jagan@edgeble.ai</email>
</author>
<published>2023-07-31T11:00:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dfe44a1377d81185b8eacf691026d0b160cc0072'/>
<id>urn:sha1:dfe44a1377d81185b8eacf691026d0b160cc0072</id>
<content type='text'>
Add support for Rockchip RV1126 DSI-DPHY.

The existing 2.5GHz phy timing table added for RK3568 is working
as it is for RV1126 as well.

Signed-off-by: Jagan Teki &lt;jagan@edgeble.ai&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Link: https://lore.kernel.org/r/20230731110012.2913742-5-jagan@edgeble.ai
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy: Explicitly include correct DT includes</title>
<updated>2023-07-17T06:22:56+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2023-07-14T17:48:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7559e7572c03e433efec7734af6a674fdd83dd68'/>
<id>urn:sha1:7559e7572c03e433efec7734af6a674fdd83dd68</id>
<content type='text'>
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 &lt;robh@kernel.org&gt;
Acked-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt; # for drivers/phy/phy-can-transceiver.c
Acked-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Acked-by: Sergio Paracuellos &lt;sergio.paracuellos@gmail.com&gt;
Link: https://lore.kernel.org/r/20230714174841.4061919-1-robh@kernel.org
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy/rockchip: inno-hdmi: add more supported pre-pll rates</title>
<updated>2023-07-12T16:57:43+00:00</updated>
<author>
<name>Alex Bee</name>
<email>knaerzche@gmail.com</email>
</author>
<published>2023-06-15T17:10:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d1ea4239a10bf32acb321328e074919fa1eb5468'/>
<id>urn:sha1:d1ea4239a10bf32acb321328e074919fa1eb5468</id>
<content type='text'>
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 &lt;knaerzche@gmail.com&gt;
Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Link: https://lore.kernel.org/r/20230615171005.2251032-7-jonas@kwiboo.se
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy/rockchip: inno-hdmi: force set_rate on power_on</title>
<updated>2023-07-12T16:57:43+00:00</updated>
<author>
<name>Huicong Xu</name>
<email>xhc@rock-chips.com</email>
</author>
<published>2023-06-15T17:10:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f79b812baf21366fae975b29f671258fb38d643b'/>
<id>urn:sha1:f79b812baf21366fae975b29f671258fb38d643b</id>
<content type='text'>
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 &lt;xhc@rock-chips.com&gt;
Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Link: https://lore.kernel.org/r/20230615171005.2251032-6-jonas@kwiboo.se
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write</title>
<updated>2023-07-12T16:57:43+00:00</updated>
<author>
<name>Jonas Karlman</name>
<email>jonas@kwiboo.se</email>
</author>
<published>2023-06-15T17:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=19a1d46bd699940a496d3b0d4e142ef99834988c'/>
<id>urn:sha1:19a1d46bd699940a496d3b0d4e142ef99834988c</id>
<content type='text'>
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: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Link: https://lore.kernel.org/r/20230615171005.2251032-5-jonas@kwiboo.se
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate</title>
<updated>2023-07-12T16:57:43+00:00</updated>
<author>
<name>Jonas Karlman</name>
<email>jonas@kwiboo.se</email>
</author>
<published>2023-06-15T17:10:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b001c27d772e35a3b6736d9ac34e2e1019b1a782'/>
<id>urn:sha1:b001c27d772e35a3b6736d9ac34e2e1019b1a782</id>
<content type='text'>
no_c is not used in any calculation, lets remove it.

Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Link: https://lore.kernel.org/r/20230615171005.2251032-4-jonas@kwiboo.se
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate</title>
<updated>2023-07-12T16:57:43+00:00</updated>
<author>
<name>Zheng Yang</name>
<email>zhengyang@rock-chips.com</email>
</author>
<published>2023-06-15T17:10:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d5ef343c1d62bc4c4c2c393af654a41cb34b449f'/>
<id>urn:sha1:d5ef343c1d62bc4c4c2c393af654a41cb34b449f</id>
<content type='text'>
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: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang &lt;zhengyang@rock-chips.com&gt;
Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Link: https://lore.kernel.org/r/20230615171005.2251032-3-jonas@kwiboo.se
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
</feed>
