* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Sebastian Reichel @ 2026-04-17 22:24 UTC (permalink / raw)
To: Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Pavel Zhovner, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-clk, Cristian Ciocaltea
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
[-- Attachment #1: Type: text/plain, Size: 6942 bytes --]
Hello Alexey,
On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> Dear all,
>
> Need the help of the collective wisdom of the community.
>
> The problem I'm trying to solve is reliably obtaining the exact pixel
> clock for arbitrary display modes supported by the RK3576 SoC.
>
> Rockchip RK3576 has three display output processors VP0~VP2, each
> supporting different ranges of display modes, roughly as follows:
> - VP0: 4K 120Hz
> - VP1: 2.5k 60Hz
> - VP2: 1080p 60Hz
>
> Each one obviously needs a pixel clock. The required frequencies for the
> pixel clocks vary greatly depending on the display mode, and need to be
> matched within a tight tolerance, or else many displays will refuse to
> work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> be obtained using integer dividers from its default clock source (GPLL
> at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> outside the tolerance of e.g. DP specification, resulting in a blank
> screen on most displays by default.
>
> The clock sources are of course configurable, in particular there are muxes
> connected to each VP for selecting the source of the pixel clock:
> - Each VP can take the clock either from the (single!) HDMI PHY or from
> its dedicated dclk_vpX_src mux
> - The dclk_vpX_src mux can select the clock from a number of system PLLs
> (GPLL, CPLL, VPLL, BPLL, LPLL)
>
> While the system PLLs can be configured to output a wide range of
> frequencies, they are shared between many system components. E.g. on the
> current mainline kernel on one of my RK3576 boards I've got the following:
> GPLL: 1188 MHz, enable count 20
> CPLL: 1000 MHz, enable count 17
> VPLL: 594 MHz, enable count 0 (yaay!)
> BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> predividers, so are less flexible)
>
> So ultimately there is exactly one free fractional PLL (VPLL) which can be
> used to generate arbitrary pixel clocks, but we have up to three consumers
> trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> frequency on the fly to satisfy the requirements of the selected display
> mode.
>
> And this is where I'm stuck. Trying to satisfy the requirements of up to
> three consumers while changing the PLL frequency on the fly sounds like
> a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> HDMI output out of the equation, because it can be driven from the HDMI
> PHY (which is capable of arbitrary rates) instead of the mux, but that
> makes the decision of which dclk source to use for a VP block dependent on
> which downstream consumer is connected to it (HDMI vs. something else).
It becomes more messy: The HDMI PHY cannot be used as clock source
for modes exceeding 4K@60Hz.
> Even then we somehow need two devices to cooperate in picking a PLL
> frequency that satisfies the requirements of both of them, and change to it
> without display corruption. I'm not even sure if the CCF has mechanisms
> for that?..
>
> What follows is a brief set of patches which illustrate a partial solution
> for the case of "I just need 2.5k60Hz on VP1 via DP and don't care about
> the rest". It switches the VP1 unconditionally to use VPLL as the source
> for its dclk mux, allows changing the VPLL frequency on the fly, and also
> changes the frequency calculation logic to allow for nearest-match
> frequencies which are not necessarily rounded down. These are not meant
> to be merged as-is, as I see the following issues:
> - The flag allowing the PLL to change rate is in the clock driver, while
> the reparenting to an unused PLL is in the device tree. If these go out
> of sync, we might end up trying to change the frequency of a PLL which
> is used by other consumers (I presume that could be dangerous)
It is a problem, see e.g. this patch from Heiko removing the flag
for an RK3588 VOP source clock:
https://lore.kernel.org/linux-rockchip/20251008133135.3745785-1-heiko@sntech.de/
Also note, that there is some more general ongoing work regarding
this:
See: https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/
> - If VP0 happens to be driving DP output, it won't be able to produce the
> 2560x1440@60Hz mode for the same reasons as VP1 - then it must also be
> reparented to VPLL and allowed to change its frequency on the fly
There is also the problem that nearest match might be sensible for the
display, but is not generally safe. For other clocks you might
effectively overclock, which shouldn't be done by default.
> It does bring me from a state of "always blank screen on DP output until
> the mode is switched to something magically working" to a state of
> "most monitors work at the default preferred mode" though.
>
> It is tempting to just reparent both VP0 and VP1 to VPLL and allow both of
> them to change its frequency, while leaving VP2 on the default (fixed)
> GPLL and relying on the fact that 148.5 MHz (the required frequency for
> its maximum supported mode of 1920x1080@60Hz) is conveniently 1188/8 MHz -
> just what GPLL can provide. Then also force whichever VP is driving HDMI
> output to use the HDMI PHY as its clock source. But we still have the
> problem of DT vs. driver coordination, and I'm not sure how to define
> the policy for "if you've got HDMI connected, you must use the HDMI PHY
> clock for the respective VP, whichever VP that is".
Sorry, I don't have any complete solutions - except that I can tell
you that the VOP2 driver already automatically switches the clock
source to the HDMI PHY for HDMI outputs if the pixel rates allows it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c#n1757
Greetings,
-- Sebastian
> I would very much appreciate any thoughts on how to approach this.
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> Alexey Charkov (4):
> arm64: dts: rockchip: rk3576: assign dclk_vp1_src to VPLL
> clk: rockchip: pll: use round-nearest in determine_rate
> clk: rockchip: rk3576: allow dclk_vp1_src to propagate rate to parent PLL
> clk: rockchip: rk3576: add ROUND_CLOSEST to dclk_vp1_src divider
>
> arch/arm64/boot/dts/rockchip/rk3576.dtsi | 2 ++
> drivers/clk/rockchip/clk-pll.c | 16 ++++++++--------
> drivers/clk/rockchip/clk-rk3576.c | 4 ++--
> 3 files changed, 12 insertions(+), 10 deletions(-)
> ---
> base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
> change-id: 20260417-rk3576-dclk-4c95bbb67581
>
> Best regards,
> --
> Alexey Charkov <alchark@flipper.net>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: monaco-evk: Enable primary USB controller in host mode
From: Dmitry Baryshkov @ 2026-04-17 22:40 UTC (permalink / raw)
To: Swati Agarwal
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260417152014.3000797-1-swati.agarwal@oss.qualcomm.com>
On Fri, Apr 17, 2026 at 08:50:14PM +0530, Swati Agarwal wrote:
> Enable primary USB controller in host mode on monaco EVK Platform.
>
> Primary USB controller is connected to a Genesys Logic USB HUB GL3590
> having 4 ports. The ports of hub that are present on lemans EVK standalone
> board are used as follows:-
> 1) port-1 is connected to HD3SS3220 Type-C port controller.
> 2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
> for Bluetooth. This port is to be used only if user optionally replaces the
> WiFi card with the NFA765 chip which uses USB for Bluetooth.
>
> Remaining 2 ports will become functional when the interface plus mezzanine
> board is stacked on top of corekit:
>
> 3) port-2 is connected to another hub which is present on the mezz through
> which 4 type-A ports are connected.
> 4) port-3 is used for the M.2 B key for a 5G card when the mezz is
> connected.
>
> Primary USB Controller
> ↓
> GL3590 USB Hub (4 ports)
> |
> |-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
> |
> |-- Port 2 → Mezzanine USB Hub (when mezz attached)
> |
> |-- Port 3 → M.2 B‑Key Slot (when mezz attached)
> |
> |-- Port 4 → M.2 E‑Key Slot
> (Default: BT via UART;
> USB only if NFA765 module is installed)
>
> Mark the primary USB controller as host only capable and add the HD3SS3220
> Type-C port controller along with Type-c connector for controlling vbus
> supply.
>
> In hardware, there are dip switches provided to operate between USB1 port 0
> and port 1 for primary Type-C USB controller. By default, switches will be
> off operating at USB0 port. After bootup to HLOS, it will be operated in
> USB1 port.
Why did you choose this configuration?
> Added support in the software for both HS and SS switches as
> usb1_hs_sel_switch and usb1_ss_sel_switch to avoid manually changing the
> dip switch position for USB1 port to function. Also, added usb1_hub_reset
> pin for USB1 hub to get detected after bootup as USB1 hub will be in
> inactive state before bootup.
Nit: imperative language, please.
> Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
> ---
> .../boot/dts/qcom/monaco-evk-common.dtsi | 173 +++++++++++++++++-
> 1 file changed, 172 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi b/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
> index 12c847c03757..6316a8270f57 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
> @@ -23,6 +23,37 @@ chosen {
> stdout-path = "serial0:115200n8";
> };
>
> + connector-1 {
> + compatible = "usb-c-connector";
> + label = "USB1-Type-C";
> + data-role = "host";
> + power-role = "source";
> +
> + vbus-supply = <&usb1_vbus>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb1_con_hs_ep: endpoint {
> + remote-endpoint = <&usb_hub_2_1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb1_con_ss_ep: endpoint {
> + remote-endpoint = <&hd3ss3220_1_in_ep>;
> + };
> +
> + };
> + };
> + };
> +
> connector-2 {
> compatible = "gpio-usb-b-connector", "usb-b-connector";
> label = "micro-USB";
> @@ -77,6 +108,15 @@ dp1_connector_in: endpoint {
> };
> };
>
> + usb1_vbus: regulator-usb1-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb1_vbus";
> + gpio = <&expander1 3 GPIO_ACTIVE_HIGH>;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + enable-active-high;
> + };
> +
> usb2_vbus: regulator-usb2-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb2_vbus";
> @@ -445,6 +485,39 @@ lt8713sx_dp1_out: endpoint {
> };
> };
> };
> +
> + usb-typec@47 {
> + compatible = "ti,hd3ss3220";
> + reg = <0x47>;
> +
> + interrupts-extended = <&tlmm 45 IRQ_TYPE_EDGE_FALLING>;
> +
> + id-gpios = <&tlmm 13 GPIO_ACTIVE_HIGH>;
> +
> + pinctrl-0 = <&usb1_id>, <&usb1_intr>;
> + pinctrl-names = "default";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + hd3ss3220_1_in_ep: endpoint {
> + remote-endpoint = <&usb1_con_ss_ep>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + hd3ss3220_1_out_ep: endpoint {
> + remote-endpoint = <&usb_hub_3_1>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -556,6 +629,13 @@ expander5: gpio@3d {
> interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
> pinctrl-0 = <&expander5_int>;
> pinctrl-names = "default";
> +
> + gpio5-hog {
> + gpio-hog;
> + gpios = <5 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "usb1_ss_sel_switch";
> + };
> };
>
> expander6: gpio@3e {
> @@ -742,6 +822,28 @@ expander5_int: expander5-int-state {
> bias-pull-up;
> };
>
> + usb1_hub_reset: usb1-hub-reset-state {
> + pins = "gpio7";
> + function = "gpio";
> + output-enable;
> + output-high;
> + bias-disable;
> + };
> +
> + usb1_id: usb1-id-state {
> + pins = "gpio13";
> + function = "gpio";
> + bias-pull-up;
> + };
> +
> + usb1_hs_sel_switch: usb1-hs-sel-switch-state {
> + pins = "gpio14";
> + function = "gpio";
> + output-enable;
> + output-high;
> + bias-disable;
> + };
Why do you use gpio-hog for SS switch, but then you use pinctrl for HS
switch?
> +
> expander1_int: expander1-int-state {
> pins = "gpio16";
> function = "gpio";
> @@ -784,6 +886,12 @@ expander3_int: expander3-int-state {
> bias-pull-up;
> };
>
> + usb1_intr: usb1-intr-state {
> + pins = "gpio45";
> + function = "gpio";
> + bias-pull-up;
> + };
> +
> expander6_int: expander6-int-state {
> pins = "gpio52";
> function = "gpio";
> @@ -863,9 +971,72 @@ &ufs_mem_phy {
> };
>
> &usb_1 {
> - dr_mode = "peripheral";
> + dr_mode = "host";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb1_hub_reset &usb1_hs_sel_switch>;
>
> status = "okay";
> +
> + usb_hub_2_x: hub@1 {
> + compatible = "usb5e3,610";
> + reg = <1>;
> +
> + peer-hub = <&usb_hub_3_x>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_hub_2_1: endpoint {
> + remote-endpoint = <&usb1_con_hs_ep>;
> + };
> + };
> +
> + /*
> + * Port-4 is connected to M.2 E key connector on corekit.
> + */
> + port@4 {
> + reg = <4>;
> +
> + usb_hub_2_4: endpoint {
> + };
> + };
> + };
> + };
> +
> + usb_hub_3_x: hub@2 {
> + compatible = "usb5e3,625";
> + reg = <2>;
> +
> + peer-hub = <&usb_hub_2_x>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_hub_3_1: endpoint {
> + remote-endpoint = <&hd3ss3220_1_out_ep>;
> + };
> + };
> +
> + port@4 {
> + reg = <4>;
> +
> + usb_hub_3_4: endpoint {
> + };
> + };
> + };
> + };
> };
>
> &usb_1_hsphy {
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 13/14] ASoC: rsnd: Support unprefixed DT node names for RZ/G3E
From: John Madieu @ 2026-04-17 22:52 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai, Geert Uytterhoeven,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, linux-sound,
linux-renesas-soc, devicetree, linux-kernel, John Madieu
In-Reply-To: <87h5paz1w6.wl-kuninori.morimoto.gx@renesas.com>
On Fri, Apr 17, 2026 at 03:44:41AM +0000, Kuninori Morimoto wrote:
>
> Hi John
Hi Kuninori,
Thank you for the review.
>
> Thank you for your patch
>
> > ---
> (snip)
> > +struct device_node *rsnd_parse_of_node(struct rsnd_priv *priv, const char *name)
> > +{
> > + struct device_node *np = rsnd_priv_to_dev(priv)->of_node;
> > + struct device_node *node;
> > + const char *unprefixed;
> > +
> > + node = of_get_child_by_name(np, name);
> > + if (node)
> > + return node;
> > +
> > + /*
> > + * RZ/G3E binding uses unprefixed node names (e.g. "ssi" instead
> > + * of "rcar_sound,ssi"). Try stripping the "rcar_sound," prefix.
> > + */
> > + unprefixed = strchr(name, ',');
> > + if (unprefixed)
> > + node = of_get_child_by_name(np, unprefixed + 1);
> > +
> > + return node;
> > +}
>
> I think it is better to have name get function, and use it on parse func ?
>
> char *rsnd_xx_name(node, name)
> {
> char *sub_name;
>
> /* name = "rcar_sound,ssi" */
> ret = of_node_name_eq(node, name);
> if (ret == 0)
> return name;
>
> /* sub_name = "ssi" */
> sub_name = strchr(name, ",");
> ret = of_node_name_eq(node, sub_name);
> if (ret == 0)
> return sub_name;
>
> return NULL;
> }
>
I agree that having the "try prefixed, fall back to unprefixed" rule
spelled out at multiple call sites is a consistency problem, and I'll
fix that in v6.
What I think keeps consistency, and it is to factor out
just the string operation, and have both sites build on it:
/* "rcar_sound,ssi" -> "ssi"; "ssi" -> NULL */
static const char *rsnd_node_name_strip_prefix(const char *name)
{
const char *comma = strchr(name, ',');
return comma ? comma + 1 : NULL;
}
Then rsnd_parse_of_node() uses it in its fallback path:
struct device_node *rsnd_parse_of_node(struct rsnd_priv *priv,
const char *name)
{
struct device_node *np = rsnd_priv_to_dev(priv)->of_node;
struct device_node *node;
const char *unprefixed;
node = of_get_child_by_name(np, name);
if (node)
return node;
unprefixed = rsnd_node_name_strip_prefix(name);
if (unprefixed)
node = of_get_child_by_name(np, unprefixed);
return node;
}
>
> > @@ -1273,7 +1294,8 @@ static int rsnd_dai_of_node(struct rsnd_priv *priv, int *is_graph)
> > of_node_put(node);
> >
> > for_each_child_of_node_scoped(np, node) {
> > - if (!of_node_name_eq(node, RSND_NODE_DAI))
> > + if (!of_node_name_eq(node, RSND_NODE_DAI) &&
> > + !of_node_name_eq(node, "dai"))
> > continue;
>
> If driver is handling almost same things individually and/or randomly in per
> each places, it will eventually lose consistency.
>
> rsnd_xx_name() can keep consistency ?
>
and rsnd_dai_of_node() uses the same helper instead of an open-coded
"dai" literal:
const char *alt = rsnd_node_name_strip_prefix(RSND_NODE_DAI);
for_each_child_of_node_scoped(np, node) {
if (!of_node_name_eq(node, RSND_NODE_DAI) &&
(!alt || !of_node_name_eq(node, alt)))
continue;
...
}
This way the "rcar_sound," prefix convention lives in exactly one
place, and each call site keeps its natural operation (fetch vs.
compare) without redundant lookups.
Does this work for you, or would you still prefer the node-based
getter?
Regards,
--
John Madieu
^ permalink raw reply
* Re: [PATCH v8 08/10] ASoC: mediatek: mt8196: add platform driver
From: Mark Brown @ 2026-04-17 22:52 UTC (permalink / raw)
To: Cyril Chao (钞悦)
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, Darren Ye (叶飞),
linux-sound@vger.kernel.org, conor+dt@kernel.org, tiwai@suse.com,
robh@kernel.org, lgirdwood@gmail.com,
linux-arm-kernel@lists.infradead.org,
Project_Global_Chrome_Upstream_Group, matthias.bgg@gmail.com,
krzk+dt@kernel.org, perex@perex.cz, AngeloGioacchino Del Regno
In-Reply-To: <da5752796e1774b6bbc24f5ef1ab2529e24a384f.camel@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Thu, Apr 16, 2026 at 05:53:25AM +0000, Cyril Chao (钞悦) wrote:
> Thank you for your assistance in reviewing. Could you please also
> review the modifications in the diff? If everything is okay, I will
> include them in v9 in the next update.
That looks OK from a scan through, though it's possible I'd see
something else if I review in full context.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 2/4] clk: rockchip: pll: use round-nearest in determine_rate
From: Heiko Stuebner @ 2026-04-17 22:59 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Michael Turquette,
Stephen Boyd, Alexey Charkov
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-2-26a9d0dcb2de@flipper.net>
Hi Alexey,
Am Freitag, 17. April 2026, 17:11:45 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> rockchip_pll_determine_rate() walks the rate table in descending order
> and picks the first entry <= the requested rate. This floor-rounding
> interacts poorly with consumers that use CLK_SET_RATE_PARENT: a divider
> iterating candidates asks the PLL for rate*div, and a tiny undershoot
> causes the PLL to snap to a much lower entry.
>
> For example, requesting 1991.04 MHz (248.88 MHz * 8) causes the PLL to
> return 1968 MHz instead of 1992 MHz — a 24 MHz table gap that produces
> a 1.2% pixel clock error when divided back down.
>
> Change to round-to-nearest: for each table entry compute the absolute
> distance from the request, and pick the entry with the smallest delta.
> The CCF's divider and composite logic handle over/undershoot preferences
> via their own ROUND_CLOSEST flags.
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
as Sebastian said, this could cause overclocking in a number of areas.
The rate you get should always be lower or equal to the requested rate.
Additionally, such a core behaviour change, would affect 13 years of
SoCs with unknown side-effects.
If you're missing specific clock rates, you can always add them to the
list :-) . The vendor-kernel does have code that can calculate the
rate params itself, so this could give you a hint where to start.
======= just to explain =======
Though I still don't think that code should be in the mainline-kernel,
as a curated PLL rates allows more control, where that algorithm
creates parameters that are programmatically correct, but essentially
untested.
On the two Chromebook projects, they actually measured things like
clock jitter, which got us more specific params for some rates.
Heiko
^ permalink raw reply
* Re: [PATCH v5 05/14] ASoC: rsnd: Add audmacpp clock and reset support for RZ/G3E
From: John Madieu @ 2026-04-17 23:00 UTC (permalink / raw)
To: Mark Brown
Cc: Kuninori Morimoto, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Geert Uytterhoeven, Magnus Damm, Philipp Zabel, Claudiu Beznea,
Biju Das, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, John Madieu
In-Reply-To: <17da3459-9205-4853-af08-5b2863403a9a@sirena.org.uk>
On Thu, Apr 16, 2026 at 07:57:34PM +0100, Mark Brown wrote:
> On Wed, Apr 15, 2026 at 12:47:22PM +0000, John Madieu wrote:
>
Hi Mark,
Thank you for the review.
> > + /*
> > + * Audio DMAC peri-peri clock and reset for RZ/G3E.
> > + * These use optional APIs, so they gracefully return NULL
> > + * (no error) on platforms whose DT does not provide them.
> > + */
> > + dmac->audmapp_rstc =
> > + devm_reset_control_get_optional_exclusive_deasserted(dev, "audmapp");
> > + if (IS_ERR(dmac->audmapp_rstc)) {
> > + return dev_err_probe(dev, PTR_ERR(dmac->audmapp_rstc),
> > + "failed to get audmapp reset\n");
> > + }
> > +
> > + dmac->audmapp_clk = devm_clk_get_optional_enabled(dev, "audmapp");
> > + if (IS_ERR(dmac->audmapp_clk)) {
> > + return dev_err_probe(dev, PTR_ERR(dmac->audmapp_clk),
> > + "failed to get audmapp clock\n");
> > + }
>
> Do we need the clock running before deasserting reset? Usually the flow
> is to get the resources the hardware requires stable before we release,
> that helps everything start up cleanly.
You're right. The clock should be enabled before the reset is deasserted
so the block sees a stable clock on the way out of reset. I'll swap the
order in v6.
Regards,
--
John Madieu
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: qcs6490-rb3gen2: Add WCD headset playback and record for qcs6490-rb3gen2 industrial mezzanine
From: Dmitry Baryshkov @ 2026-04-17 23:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Karthik S, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <6b24255e-b579-4526-8820-6d7330768c50@kernel.org>
On Fri, Apr 17, 2026 at 12:12:46PM +0200, Krzysztof Kozlowski wrote:
> On 17/04/2026 11:42, Krzysztof Kozlowski wrote:
> >
> > And finally:
> >
> > Please run scripts/checkpatch.pl on the patches and fix reported
> > warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> > patches and (probably) fix more warnings. Some warnings can be ignored,
> > especially from --strict run, but the code here looks like it needs a
> > fix. Feel free to get in touch if the warning is not clear.
>
> As you pointed correctly after offline talk, checkpatch does not report
> undocumented compatible for the sound card qcs6490-rb3gen2-ia-snd-card.
>
> Unfortunately this patch did not go through internal toolset fully
> (PatchWise), which could have flag the issue. Let's discuss it
> internally next week.
>
> >
> > Undocumented ABI (without any reference in changelog where to find
> > posted patch).
> You still need to solve the undocumented sound card ABI - new
> compatible. If it is already sent to mailing lists, then provide link in
> patch changelog (---).
Which compatible is new there? I think it is a model and not compatible.
>
> Best regards,
> Krzysztof
--
With best wishes
Dmitry
^ permalink raw reply
* Re: (subset) [PATCH v3 00/21] drm/panel: support Waveshare DSI TOUCH kits
From: Dmitry Baryshkov @ 2026-04-17 23:11 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan, Dmitry Baryshkov
Cc: dri-devel, devicetree, linux-kernel, linux-gpio,
Krzysztof Kozlowski, Riccardo Mereu
In-Reply-To: <20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com>
On Mon, 13 Apr 2026 17:05:23 +0300, Dmitry Baryshkov wrote:
> The Waveshare DSI TOUCH family of DSI panel kits feature different DSI
> video-mode panels, bundled with the separate controlling circuit,
> produing necessary voltages from the 3.3V and 5V supplies. Extend panel
> drivers to support those Waveshare panels and also add GPIO driver for
> the onboard control circuitry.
>
>
> [...]
Applied to drm-misc-next, thanks!
[01/21] dt-bindings: display/panel: himax,hx83102: describe Waveshare panel
commit: 0eb86d3622d20679a4c64606df4e8cd6af5398e6
[02/21] dt-bindings: display/panel: himax,hx8394: describe Waveshare panel
commit: 4a70ba67ee5f8ba3a563611eed6ff41eac2b41ed
[03/21] dt-bindings: display/panel: jadard,jd9365da-h3: describe Waveshare panel
commit: d13d9306acac0a71c567154a4e1b3ca9d5c58cc0
[04/21] dt-bindings: display/panel: ilitek,ili9881c: describe Waveshare panel
(no commit info)
[05/21] dt-bindings: dipslay/panel: describe panels using Focaltech OTA7290B
commit: 17b2ab777384d04cae0e5c1e19287d16369e745d
[06/21] drm/of: add helper to count data-lanes on a remote endpoint
commit: a8c56e00c608d5c70eb89464676ea0b3cdcb1ce6
[07/21] drm/panel: himax-hx83102: support Waveshare 12.3" DSI panel
commit: 1af0feaca130e7fef016184f85f803385de13ba0
[08/21] drm/panel: himax-hx8394: set prepare_prev_first
commit: dd0d0a487172bbe9626efc59a43d5dfbea64cdd4
[09/21] drm/panel: himax-hx8394: simplify hx8394_enable()
commit: 917e888d38fa1e81781da39daceffad41e9d2109
[10/21] drm/panel: himax-hx8394: support Waveshare DSI panels
commit: c3b595b16cd2830bf755b4385b19db41f2c238a8
[11/21] drm/panel: jadard-jd9365da-h3: use drm_connector_helper_get_modes_fixed
commit: 0a26b74898a5d385fa9226475d7d2d3afef1716b
[12/21] drm/panel: jadard-jd9365da-h3: support variable DSI configuration
commit: eb019688f2a97bb95384853072de3a88b981f1f3
[13/21] drm/panel: jadard-jd9365da-h3: set prepare_prev_first
commit: b55a4b5d4769a650f52ea3f1ae680610169d125e
[14/21] drm/panel: jadard-jd9365da-h3: support Waveshare round DSI panels
commit: ba362fb2e7fe5676b388da4fd976c993046e3611
[15/21] drm/panel: jadard-jd9365da-h3: support Waveshare WXGA DSI panels
commit: 5a7770a06f38152e50e3fa8d1acd77d0ef259c3d
[16/21] drm/panel: jadard-jd9365da-h3: support Waveshare 720p DSI panels
commit: 13414cfd4839804b924ad9cdf0337d3c335a1943
[17/21] drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel
(no commit info)
[18/21] drm/panel: add devm_drm_panel_add() helper
commit: e43a8e3ad8fa3c2c2220a06fa46545c7ff82a9b7
[19/21] drm/panel: add driver for Waveshare 8.8" DSI TOUCH-A panel
commit: 07853e95424869059d7ce1cd25c800f88ee03e95
Best regards,
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Heiko Stuebner @ 2026-04-17 23:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <62f51359-9d91-4107-917b-cd722c7321c2@collabora.com>
Hi Cristian,
Am Freitag, 17. April 2026, 18:34:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> On 4/17/26 2:32 PM, Heiko Stuebner wrote:
> > the comments below apply sort of to all patches in that series.
> >
> > Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >> The board exposes the GPIO4_C6 line to control the voltage bias on the
> >> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
> >> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
> >>
> >> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
> >> property and drop the line from the vcc_5v0_hdmi regulator to allow
> >> adjusting the bias when transitioning between TMDS and FRL operating
> >> modes.
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
> >> 1 file changed, 4 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> >> index 749f0a54b478..93ae37699366 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
> >> @@ -140,10 +140,7 @@ regulator-state-mem {
> >>
> >> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
> >> compatible = "regulator-fixed";
> >> - enable-active-high;
> >> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
> >> - pinctrl-names = "default";
> >> - pinctrl-0 = <&hdmi_con_en>;
> >> + regulator-always-on;
> >> regulator-min-microvolt = <5000000>;
> >> regulator-max-microvolt = <5000000>;
> >> regulator-name = "vcc_5v0_hdmi";
> >
> > I think this regulator was sort of a complete hack, to set that
> > gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
> >
> > Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
> > is completely functionless now, the whole thing could be removed?
>
> Ack, let's just drop it.
>
> >
> >
> >> @@ -231,6 +228,8 @@ &gpu {
> >> };
> >>
> >> &hdmi {
> >> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
> >> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
> >
> > this should be sorted the other way around I think.
> >
> > Also please provide a pinctrl-names property too. If for whatever reason
> > the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
> > board DTs are staying in the "old" compatible mode until they are adapted.
>
> Just to make sure I fully understand, the convention is that
>
> pinctrl-names = "default";
>
> should be always provided, even when the node overrides an existing pinctrl-0
> property?
>
> E.g. in rk3576.dtsi we have:
>
> hdmi: hdmi@27da0000 {
> ...
> pinctrl-names = "default";
> pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
> ...
> }
>
> Hence I omitted pinctrl-names which doesn't change and just appended
> &hdmi_frl_en to pinctrl-0's original value.
correct, please always provide a pinctrl-names entry when setting a new
pinctrl-0 .
The background is, imagine you have a base:
pinctrl-names = "default";
pinstrl-0 = <....>;
and override pinctrl-0 in a board.
Now a newer binding introduces a 2nd pinctrl state "foo". Of course
we're backwards compatible, and both are valid and the driver checks
what states are defined.
So the base sets:
pinctrl-names = "default", "foo";
pinctrl-0 = <...>;
pinctrl-1 = <...>;
in your (old) board you override pinctrl-0, but the driver still sees
the new variant with 2 pinctrl states, where it should've stayed with
the legacy 1-state, until the board-dts might get adapted in the future.
And I know, we're likely not doing that everywhere, and also in most
cases it won't really matter, but still it is safer and sets the better
precedent :-) .
> >> status = "okay";
> >> };
> >>
> >> @@ -655,7 +654,7 @@ &pcie0 {
> >>
> >> &pinctrl {
> >> hdmi {
> >> - hdmi_con_en: hdmi-con-en {
> >> + hdmi_frl_en: hdmi-frl-en {
> >
> > pinctrl names should ideally match the naming in schematics, for example the
> > "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to> go from DT
> > to schematics and back.
>
> I opted for a more descriptive name that could be used consistently across all
> boards, given that not all schematics are publicly available.
>
> You make a fair point though, we should probably stick with the pretty terrible
> hdmi[N]_tx_on_h naming instead.
yep, we're doing that everywhere else already too, and sticking to the
schematics naming, also prevents any discussions about how something
should be named ;-) .
Heiko
^ permalink raw reply
* Re: [PATCH v3 0/2] drm/panel: simple: add Waveshare LCD panels
From: Dmitry Baryshkov @ 2026-04-17 23:13 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Dmitry Baryshkov
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260412-ws-lcd-v3-0-db22c2631828@oss.qualcomm.com>
On Sun, 12 Apr 2026 20:32:23 +0300, Dmitry Baryshkov wrote:
> Waveshare have a serie of DSI panel kits with the DPI or LVDS panel
> being attached to the DSI2DPI or DSI2LVDS bridge. Commit 80b0eb11f8e0
> ("dt-bindings: display: panel: Add waveshare DPI panel support")
> described two of them in the bindings and commit 46be11b678e0
> ("drm/panel: simple: Add Waveshare 13.3" panel support") added
> definitions for one of those panels. Add support for the rest of them.
>
> [...]
Applied to drm-misc-next, thanks!
[1/2] dt-bindings: display: waveshare,dsp2dpi: describe DSI2LVDS setup
commit: 7fd2875a932276926052652aaa44fd29a950b015
[2/2] drm/bridge: waveshare-dsi: support DSI LCD kits with LVDS panels
commit: 17394e05b295e4936e0ed50d2f02ed7f08fd4f7d
Best regards,
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v4 0/4] drm/panel: support Waveshare DSI TOUCH kits
From: Dmitry Baryshkov @ 2026-04-17 23:16 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio,
Krzysztof Kozlowski, Conor Dooley, Riccardo Mereu
The Waveshare DSI TOUCH family of DSI panel kits feature different DSI
video-mode panels, bundled with the separate controlling circuit,
produing necessary voltages from the 3.3V and 5V supplies. Extend panel
drivers to support those Waveshare panels and also add GPIO driver for
the onboard control circuitry.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v4:
- Dropped patches applied to drm-misc-next
- Link to v3: https://patch.msgid.link/20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com
Changes in v3:
- Fix another typo in the focaltech,ota7290b schema, sorted out voltage
supplies in the schema and in the driver
- Dropped Ricardo's T-B from bindings patch (Krzysztof)
- In the Waveshare GPIO driver bumped max register to REG_VERSION (Jie
Gan)
- Add a lanes vs config check in the JD9365 driver (Jie Gan)
- Link to v2: https://patch.msgid.link/20260411-waveshare-dsi-touch-v2-0-75cdbeac5156@oss.qualcomm.com
Changes in v2:
- Fixed errors in focaltech,ota7290b and waveshare,dsi-touch-gpio schemas
- Split the JD9365 patch, making the changes more obvious (and
describing panel classes)
- Cleaned up GPIO driver: moved NUM_GPIOS from the enum, switched to
guard(), added regmap error handling, dropped
waveshare_gpio_i2c_read() (Bartosz)
- Link to v1: https://patch.msgid.link/20260401-waveshare-dsi-touch-v1-0-5e9119b5a014@oss.qualcomm.com
---
Dmitry Baryshkov (4):
dt-bindings: display/panel: ilitek,ili9881c: describe Waveshare panel
drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel
dt-bindings: gpio: describe Waveshare GPIO controller
gpio: add GPIO controller found on Waveshare DSI TOUCH panels
.../bindings/display/panel/ilitek,ili9881c.yaml | 2 +
.../bindings/gpio/waveshare,dsi-touch-gpio.yaml | 100 ++++++++
drivers/gpio/Kconfig | 10 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-waveshare-dsi.c | 208 +++++++++++++++++
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 251 ++++++++++++++++++++-
6 files changed, 570 insertions(+), 2 deletions(-)
---
base-commit: 17394e05b295e4936e0ed50d2f02ed7f08fd4f7d
change-id: 20260401-waveshare-dsi-touch-e1717a1ffc40
Best regards,
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: display/panel: ilitek,ili9881c: describe Waveshare panel
From: Dmitry Baryshkov @ 2026-04-17 23:16 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio,
Krzysztof Kozlowski
In-Reply-To: <20260418-waveshare-dsi-touch-v4-0-b249f3e702bd@oss.qualcomm.com>
Describe Waveshare 7" DSI panel which uses ILI9881 as a panel
controller. This panel requires two voltags supplies, so add separate
iovcc supply.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
index d979701a00a8..42e35986fbf6 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
@@ -24,6 +24,7 @@ properties:
- raspberrypi,dsi-7inch
- startek,kd050hdfia020
- tdo,tl050hdv35
+ - waveshare,7.0-dsi-touch-a
- wanchanglong,w552946aaa
- wanchanglong,w552946aba
- const: ilitek,ili9881c
@@ -34,6 +35,7 @@ properties:
backlight: true
port: true
power-supply: true
+ iovcc-supply: true
reset-gpios: true
rotation: true
--
2.47.3
^ permalink raw reply related
* [PATCH v4 2/4] drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel
From: Dmitry Baryshkov @ 2026-04-17 23:16 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260418-waveshare-dsi-touch-v4-0-b249f3e702bd@oss.qualcomm.com>
Enable support for Waveshare 7.0" DSI TOUCH-A panel. It requires
additional voltage regulator, iovcc.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 251 +++++++++++++++++++++++++-
1 file changed, 249 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 947b47841b01..0652cdb57d11 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -52,6 +52,7 @@ struct ili9881c {
const struct ili9881c_desc *desc;
struct regulator *power;
+ struct regulator *iovcc;
struct gpio_desc *reset;
enum drm_panel_orientation orientation;
@@ -1997,6 +1998,205 @@ static const struct ili9881c_instr bsd1218_a101kl68_init[] = {
ILI9881C_COMMAND_INSTR(0xd3, 0x3f),
};
+static const struct ili9881c_instr waveshare_7inch_a_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0x00),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x0a),
+ ILI9881C_COMMAND_INSTR(0x07, 0x00),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x61),
+ ILI9881C_COMMAND_INSTR(0x0a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0c, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0f, 0x61),
+ ILI9881C_COMMAND_INSTR(0x10, 0x61),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x00),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_COMMAND_INSTR(0x18, 0x00),
+ ILI9881C_COMMAND_INSTR(0x19, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1e, 0x40),
+ ILI9881C_COMMAND_INSTR(0x1f, 0x80),
+ ILI9881C_COMMAND_INSTR(0x20, 0x06),
+ ILI9881C_COMMAND_INSTR(0x21, 0x01),
+ ILI9881C_COMMAND_INSTR(0x22, 0x00),
+ ILI9881C_COMMAND_INSTR(0x23, 0x00),
+ ILI9881C_COMMAND_INSTR(0x24, 0x00),
+ ILI9881C_COMMAND_INSTR(0x25, 0x00),
+ ILI9881C_COMMAND_INSTR(0x26, 0x00),
+ ILI9881C_COMMAND_INSTR(0x27, 0x00),
+ ILI9881C_COMMAND_INSTR(0x28, 0x33),
+ ILI9881C_COMMAND_INSTR(0x29, 0x03),
+ ILI9881C_COMMAND_INSTR(0x2a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2f, 0x00),
+ ILI9881C_COMMAND_INSTR(0x30, 0x00),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x32, 0x00),
+ ILI9881C_COMMAND_INSTR(0x33, 0x00),
+ ILI9881C_COMMAND_INSTR(0x34, 0x04),
+ ILI9881C_COMMAND_INSTR(0x35, 0x00),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+ ILI9881C_COMMAND_INSTR(0x37, 0x00),
+ ILI9881C_COMMAND_INSTR(0x38, 0x3c),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3f, 0x00),
+ ILI9881C_COMMAND_INSTR(0x40, 0x00),
+ ILI9881C_COMMAND_INSTR(0x41, 0x00),
+ ILI9881C_COMMAND_INSTR(0x42, 0x00),
+ ILI9881C_COMMAND_INSTR(0x43, 0x00),
+ ILI9881C_COMMAND_INSTR(0x44, 0x00),
+ ILI9881C_COMMAND_INSTR(0x50, 0x10),
+ ILI9881C_COMMAND_INSTR(0x51, 0x32),
+ ILI9881C_COMMAND_INSTR(0x52, 0x54),
+ ILI9881C_COMMAND_INSTR(0x53, 0x76),
+ ILI9881C_COMMAND_INSTR(0x54, 0x98),
+ ILI9881C_COMMAND_INSTR(0x55, 0xba),
+ ILI9881C_COMMAND_INSTR(0x56, 0x10),
+ ILI9881C_COMMAND_INSTR(0x57, 0x32),
+ ILI9881C_COMMAND_INSTR(0x58, 0x54),
+ ILI9881C_COMMAND_INSTR(0x59, 0x76),
+ ILI9881C_COMMAND_INSTR(0x5a, 0x98),
+ ILI9881C_COMMAND_INSTR(0x5b, 0xba),
+ ILI9881C_COMMAND_INSTR(0x5c, 0xdc),
+ ILI9881C_COMMAND_INSTR(0x5d, 0xfe),
+ ILI9881C_COMMAND_INSTR(0x5e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x5f, 0x0e),
+ ILI9881C_COMMAND_INSTR(0x60, 0x0f),
+ ILI9881C_COMMAND_INSTR(0x61, 0x0c),
+ ILI9881C_COMMAND_INSTR(0x62, 0x0d),
+ ILI9881C_COMMAND_INSTR(0x63, 0x06),
+ ILI9881C_COMMAND_INSTR(0x64, 0x07),
+ ILI9881C_COMMAND_INSTR(0x65, 0x02),
+ ILI9881C_COMMAND_INSTR(0x66, 0x02),
+ ILI9881C_COMMAND_INSTR(0x67, 0x02),
+ ILI9881C_COMMAND_INSTR(0x68, 0x02),
+ ILI9881C_COMMAND_INSTR(0x69, 0x01),
+ ILI9881C_COMMAND_INSTR(0x6a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x6b, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6c, 0x15),
+ ILI9881C_COMMAND_INSTR(0x6d, 0x14),
+ ILI9881C_COMMAND_INSTR(0x6e, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6f, 0x02),
+ ILI9881C_COMMAND_INSTR(0x70, 0x02),
+ ILI9881C_COMMAND_INSTR(0x71, 0x02),
+ ILI9881C_COMMAND_INSTR(0x72, 0x02),
+ ILI9881C_COMMAND_INSTR(0x73, 0x02),
+ ILI9881C_COMMAND_INSTR(0x74, 0x02),
+ ILI9881C_COMMAND_INSTR(0x75, 0x0e),
+ ILI9881C_COMMAND_INSTR(0x76, 0x0f),
+ ILI9881C_COMMAND_INSTR(0x77, 0x0c),
+ ILI9881C_COMMAND_INSTR(0x78, 0x0d),
+ ILI9881C_COMMAND_INSTR(0x79, 0x06),
+ ILI9881C_COMMAND_INSTR(0x7a, 0x07),
+ ILI9881C_COMMAND_INSTR(0x7b, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7c, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7d, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7e, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7f, 0x01),
+ ILI9881C_COMMAND_INSTR(0x80, 0x00),
+ ILI9881C_COMMAND_INSTR(0x81, 0x02),
+ ILI9881C_COMMAND_INSTR(0x82, 0x14),
+ ILI9881C_COMMAND_INSTR(0x83, 0x15),
+ ILI9881C_COMMAND_INSTR(0x84, 0x02),
+ ILI9881C_COMMAND_INSTR(0x85, 0x02),
+ ILI9881C_COMMAND_INSTR(0x86, 0x02),
+ ILI9881C_COMMAND_INSTR(0x87, 0x02),
+ ILI9881C_COMMAND_INSTR(0x88, 0x02),
+ ILI9881C_COMMAND_INSTR(0x89, 0x02),
+ ILI9881C_COMMAND_INSTR(0x8a, 0x02),
+
+ ILI9881C_SWITCH_PAGE_INSTR(4),
+ ILI9881C_COMMAND_INSTR(0x38, 0x01),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x6c, 0x15),
+ ILI9881C_COMMAND_INSTR(0x6e, 0x2a),
+ ILI9881C_COMMAND_INSTR(0x6f, 0x33),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x94),
+ ILI9881C_COMMAND_INSTR(0x8d, 0x14),
+ ILI9881C_COMMAND_INSTR(0x87, 0xba),
+ ILI9881C_COMMAND_INSTR(0x26, 0x76),
+ ILI9881C_COMMAND_INSTR(0xb2, 0xd1),
+ ILI9881C_COMMAND_INSTR(0xb5, 0x06),
+ ILI9881C_COMMAND_INSTR(0x3b, 0x98),
+
+ ILI9881C_SWITCH_PAGE_INSTR(1),
+ ILI9881C_COMMAND_INSTR(0x22, 0x0a),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x53, 0x71),
+ ILI9881C_COMMAND_INSTR(0x55, 0x8f),
+ ILI9881C_COMMAND_INSTR(0x40, 0x33),
+ ILI9881C_COMMAND_INSTR(0x50, 0x96),
+ ILI9881C_COMMAND_INSTR(0x51, 0x96),
+ ILI9881C_COMMAND_INSTR(0x60, 0x23),
+ ILI9881C_COMMAND_INSTR(0xa0, 0x08),
+ ILI9881C_COMMAND_INSTR(0xa1, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xa2, 0x2a),
+ ILI9881C_COMMAND_INSTR(0xa3, 0x10),
+ ILI9881C_COMMAND_INSTR(0xa4, 0x15),
+ ILI9881C_COMMAND_INSTR(0xa5, 0x28),
+ ILI9881C_COMMAND_INSTR(0xa6, 0x1c),
+ ILI9881C_COMMAND_INSTR(0xa7, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xa8, 0x7e),
+ ILI9881C_COMMAND_INSTR(0xa9, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xaa, 0x29),
+ ILI9881C_COMMAND_INSTR(0xab, 0x6b),
+ ILI9881C_COMMAND_INSTR(0xac, 0x1a),
+ ILI9881C_COMMAND_INSTR(0xad, 0x18),
+ ILI9881C_COMMAND_INSTR(0xae, 0x4b),
+ ILI9881C_COMMAND_INSTR(0xaf, 0x20),
+ ILI9881C_COMMAND_INSTR(0xb0, 0x27),
+ ILI9881C_COMMAND_INSTR(0xb1, 0x50),
+ ILI9881C_COMMAND_INSTR(0xb2, 0x64),
+ ILI9881C_COMMAND_INSTR(0xb3, 0x39),
+ ILI9881C_COMMAND_INSTR(0xc0, 0x08),
+ ILI9881C_COMMAND_INSTR(0xc1, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xc2, 0x2a),
+ ILI9881C_COMMAND_INSTR(0xc3, 0x10),
+ ILI9881C_COMMAND_INSTR(0xc4, 0x15),
+ ILI9881C_COMMAND_INSTR(0xc5, 0x28),
+ ILI9881C_COMMAND_INSTR(0xc6, 0x1c),
+ ILI9881C_COMMAND_INSTR(0xc7, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xc8, 0x7e),
+ ILI9881C_COMMAND_INSTR(0xc9, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xca, 0x29),
+ ILI9881C_COMMAND_INSTR(0xcb, 0x6b),
+ ILI9881C_COMMAND_INSTR(0xcc, 0x1a),
+ ILI9881C_COMMAND_INSTR(0xcd, 0x18),
+ ILI9881C_COMMAND_INSTR(0xce, 0x4b),
+ ILI9881C_COMMAND_INSTR(0xcf, 0x20),
+ ILI9881C_COMMAND_INSTR(0xd0, 0x27),
+ ILI9881C_COMMAND_INSTR(0xd1, 0x50),
+ ILI9881C_COMMAND_INSTR(0xd2, 0x64),
+ ILI9881C_COMMAND_INSTR(0xd3, 0x39),
+
+ ILI9881C_SWITCH_PAGE_INSTR(0),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x77),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+};
+
static inline struct ili9881c *panel_to_ili9881c(struct drm_panel *panel)
{
return container_of(panel, struct ili9881c, panel);
@@ -2035,9 +2235,19 @@ static int ili9881c_prepare(struct drm_panel *panel)
int ret;
/* Power the panel */
+ if (ctx->iovcc) {
+ ret = regulator_enable(ctx->iovcc);
+ if (ret)
+ return ret;
+ }
+
+ msleep(5);
ret = regulator_enable(ctx->power);
- if (ret)
- return ret;
+ if (ret) {
+ mctx.accum_err = ret;
+ goto disable_iovcc;
+ }
+
msleep(5);
/* And reset it */
@@ -2074,6 +2284,9 @@ static int ili9881c_prepare(struct drm_panel *panel)
disable_power:
regulator_disable(ctx->power);
+disable_iovcc:
+ if (ctx->iovcc)
+ regulator_disable(ctx->iovcc);
return mctx.accum_err;
}
@@ -2085,6 +2298,8 @@ static int ili9881c_unprepare(struct drm_panel *panel)
mipi_dsi_dcs_set_display_off_multi(&mctx);
mipi_dsi_dcs_enter_sleep_mode_multi(&mctx);
regulator_disable(ctx->power);
+ if (ctx->iovcc)
+ regulator_disable(ctx->iovcc);
gpiod_set_value_cansleep(ctx->reset, 1);
return 0;
@@ -2260,6 +2475,23 @@ static const struct drm_display_mode bsd1218_a101kl68_default_mode = {
.height_mm = 170,
};
+static const struct drm_display_mode waveshare_7inch_a_mode = {
+ .clock = 83333,
+
+ .hdisplay = 720,
+ .hsync_start = 720 + 120,
+ .hsync_end = 720 + 120 + 100,
+ .htotal = 720 + 120 + 100 + 100,
+
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 10,
+ .vsync_end = 1280 + 10 + 10,
+ .vtotal = 1280 + 10 + 10 + 10,
+
+ .width_mm = 85,
+ .height_mm = 154,
+};
+
static int ili9881c_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -2329,6 +2561,11 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return dev_err_probe(&dsi->dev, PTR_ERR(ctx->power),
"Couldn't get our power regulator\n");
+ ctx->iovcc = devm_regulator_get_optional(&dsi->dev, "iovcc");
+ if (IS_ERR(ctx->iovcc))
+ return dev_err_probe(&dsi->dev, PTR_ERR(ctx->iovcc),
+ "Couldn't get our iovcc regulator\n");
+
ctx->reset = devm_gpiod_get_optional(&dsi->dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset))
return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
@@ -2454,6 +2691,15 @@ static const struct ili9881c_desc bsd1218_a101kl68_desc = {
.lanes = 4,
};
+static const struct ili9881c_desc waveshare_7inch_a_desc = {
+ .init = waveshare_7inch_a_init,
+ .init_length = ARRAY_SIZE(waveshare_7inch_a_init),
+ .mode = &waveshare_7inch_a_mode,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS,
+ .lanes = 2,
+};
+
static const struct of_device_id ili9881c_of_match[] = {
{ .compatible = "bananapi,lhr050h41", .data = &lhr050h41_desc },
{ .compatible = "bestar,bsd1218-a101kl68", .data = &bsd1218_a101kl68_desc },
@@ -2462,6 +2708,7 @@ static const struct of_device_id ili9881c_of_match[] = {
{ .compatible = "tdo,tl050hdv35", .data = &tl050hdv35_desc },
{ .compatible = "wanchanglong,w552946aaa", .data = &w552946aaa_desc },
{ .compatible = "wanchanglong,w552946aba", .data = &w552946aba_desc },
+ { .compatible = "waveshare,7.0-dsi-touch-a", .data = &waveshare_7inch_a_desc },
{ .compatible = "ampire,am8001280g", .data = &am8001280g_desc },
{ .compatible = "raspberrypi,dsi-5inch", &rpi_5inch_desc },
{ .compatible = "raspberrypi,dsi-7inch", &rpi_7inch_desc },
--
2.47.3
^ permalink raw reply related
* [PATCH v4 3/4] dt-bindings: gpio: describe Waveshare GPIO controller
From: Dmitry Baryshkov @ 2026-04-17 23:16 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Conor Dooley
In-Reply-To: <20260418-waveshare-dsi-touch-v4-0-b249f3e702bd@oss.qualcomm.com>
The Waveshare DSI TOUCH family of panels has separate on-board GPIO
controller, which controls power supplies to the panel and the touch
screen and provides reset pins for both the panel and the touchscreen.
Also it provides a simple PWM controller for panel backlight.
Add bindings for these GPIO controllers. As overall integration might be
not very obvious (and it differs significantly from the bindings used by
the original drivers), provide complete example with the on-board
regulators and the DSI panel.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
.../bindings/gpio/waveshare,dsi-touch-gpio.yaml | 100 +++++++++++++++++++++
1 file changed, 100 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.yaml b/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.yaml
new file mode 100644
index 000000000000..410348fcda25
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/waveshare,dsi-touch-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Waveshare GPIO controller on DSI TOUCH panels
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+
+description:
+ Waveshare DSI TOUCH panel kits contain separate GPIO controller for toggling
+ power supplies and panel / touchscreen resets.
+
+properties:
+ compatible:
+ const: waveshare,dsi-touch-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wsgpio: gpio@45 {
+ compatible = "waveshare,dsi-touch-gpio";
+ reg = <0x45>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ panel_avdd: regulator-panel-avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-avdd";
+ gpios = <&wsgpio 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel_iovcc: regulator-panel-iovcc {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-iovcc";
+ gpios = <&wsgpio 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel_vcc: regulator-panel-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-vcc";
+ gpios = <&wsgpio 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ reg = <0>;
+ compatible = "waveshare,8.0-dsi-touch-a", "jadard,jd9365da-h3";
+ reset-gpios = <&wsgpio 1 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&panel_avdd>;
+ vccio-supply = <&panel_iovcc>;
+ backlight = <&wsgpio>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+
+ port {
+ dsi_out: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+...
--
2.47.3
^ permalink raw reply related
* [PATCH v4 4/4] gpio: add GPIO controller found on Waveshare DSI TOUCH panels
From: Dmitry Baryshkov @ 2026-04-17 23:16 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260418-waveshare-dsi-touch-v4-0-b249f3e702bd@oss.qualcomm.com>
The Waveshare DSI TOUCH family of panels has separate on-board GPIO
controller, which controls power supplies to the panel and the touch
screen and provides reset pins for both the panel and the touchscreen.
Also it provides a simple PWM controller for panel backlight. Add
support for this GPIO controller.
Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpio/Kconfig | 10 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-waveshare-dsi.c | 208 ++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b45fb799e36c..e24ad7e32034 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -804,6 +804,16 @@ config GPIO_VISCONTI
help
Say yes here to support GPIO on Tohisba Visconti.
+config GPIO_WAVESHARE_DSI_TOUCH
+ tristate "Waveshare GPIO controller for DSI panels"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Enable support for the GPIO and PWM controller found on Waveshare DSI
+ TOUCH panel kits. It provides GPIOs (used for regulator control and
+ resets) and backlight support.
+
config GPIO_WCD934X
tristate "Qualcomm Technologies Inc WCD9340/WCD9341 GPIO controller driver"
depends on MFD_WCD934X && OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c05f7d795c43..94f16f0f28d9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -206,6 +206,7 @@ obj-$(CONFIG_GPIO_VIRTUSER) += gpio-virtuser.o
obj-$(CONFIG_GPIO_VIRTIO) += gpio-virtio.o
obj-$(CONFIG_GPIO_VISCONTI) += gpio-visconti.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
+obj-$(CONFIG_GPIO_WAVESHARE_DSI_TOUCH) += gpio-waveshare-dsi.o
obj-$(CONFIG_GPIO_WCD934X) += gpio-wcd934x.o
obj-$(CONFIG_GPIO_WHISKEY_COVE) += gpio-wcove.o
obj-$(CONFIG_GPIO_WINBOND) += gpio-winbond.o
diff --git a/drivers/gpio/gpio-waveshare-dsi.c b/drivers/gpio/gpio-waveshare-dsi.c
new file mode 100644
index 000000000000..38f52351bb58
--- /dev/null
+++ b/drivers/gpio/gpio-waveshare-dsi.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Waveshare International Limited
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/gpio/driver.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+
+/* I2C registers of the microcontroller. */
+#define REG_TP 0x94
+#define REG_LCD 0x95
+#define REG_PWM 0x96
+#define REG_SIZE 0x97
+#define REG_ID 0x98
+#define REG_VERSION 0x99
+
+enum {
+ GPIO_AVDD = 0,
+ GPIO_PANEL_RESET = 1,
+ GPIO_BL_ENABLE = 2,
+ GPIO_IOVCC = 4,
+ GPIO_VCC = 8,
+ GPIO_TS_RESET = 9,
+};
+
+#define NUM_GPIO 16
+
+struct waveshare_gpio {
+ struct mutex dir_lock;
+ struct mutex pwr_lock;
+ struct regmap *regmap;
+ u16 poweron_state;
+
+ struct gpio_chip gc;
+};
+
+static const struct regmap_config waveshare_gpio_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_VERSION,
+};
+
+static int waveshare_gpio_get(struct waveshare_gpio *state, unsigned int offset)
+{
+ u16 pwr_state;
+
+ guard(mutex)(&state->pwr_lock);
+ pwr_state = state->poweron_state & BIT(offset);
+
+ return !!pwr_state;
+}
+
+static int waveshare_gpio_set(struct waveshare_gpio *state, unsigned int offset, int value)
+{
+ u16 last_val;
+ int err;
+
+ guard(mutex)(&state->pwr_lock);
+
+ last_val = state->poweron_state;
+ if (value)
+ last_val |= BIT(offset);
+ else
+ last_val &= ~BIT(offset);
+
+ state->poweron_state = last_val;
+
+ err = regmap_write(state->regmap, REG_TP, last_val >> 8);
+ if (!err)
+ err = regmap_write(state->regmap, REG_LCD, last_val & 0xff);
+
+ return err;
+}
+
+static int waveshare_gpio_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ return GPIO_LINE_DIRECTION_OUT;
+}
+
+static int waveshare_gpio_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct waveshare_gpio *state = gpiochip_get_data(gc);
+
+ return waveshare_gpio_get(state, offset);
+}
+
+static int waveshare_gpio_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
+{
+ struct waveshare_gpio *state = gpiochip_get_data(gc);
+
+ return waveshare_gpio_set(state, offset, value);
+}
+
+static int waveshare_gpio_update_status(struct backlight_device *bl)
+{
+ struct waveshare_gpio *state = bl_get_data(bl);
+ int brightness = backlight_get_brightness(bl);
+
+ waveshare_gpio_set(state, GPIO_BL_ENABLE, brightness);
+
+ return regmap_write(state->regmap, REG_PWM, brightness);
+}
+
+static const struct backlight_ops waveshare_gpio_bl = {
+ .update_status = waveshare_gpio_update_status,
+};
+
+static int waveshare_gpio_probe(struct i2c_client *i2c)
+{
+ struct backlight_properties props = {};
+ struct waveshare_gpio *state;
+ struct device *dev = &i2c->dev;
+ struct backlight_device *bl;
+ struct regmap *regmap;
+ unsigned int data;
+ int ret;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ ret = devm_mutex_init(dev, &state->dir_lock);
+ if (ret)
+ return ret;
+
+ ret = devm_mutex_init(dev, &state->pwr_lock);
+ if (ret)
+ return ret;
+
+ regmap = devm_regmap_init_i2c(i2c, &waveshare_gpio_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "Failed to allocate register map\n");
+
+ state->regmap = regmap;
+ i2c_set_clientdata(i2c, state);
+
+ ret = regmap_read(regmap, REG_ID, &data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read register\n");
+
+ dev_dbg(dev, "waveshare panel hw id = 0x%x\n", data);
+
+ ret = regmap_read(regmap, REG_SIZE, &data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read register\n");
+
+ dev_dbg(dev, "waveshare panel size = %d\n", data);
+
+ ret = regmap_read(regmap, REG_VERSION, &data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read register\n");
+
+ dev_dbg(dev, "waveshare panel mcu version = 0x%x\n", data);
+
+ ret = waveshare_gpio_set(state, GPIO_TS_RESET, 1);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to program GPIOs\n");
+
+ msleep(20);
+
+ state->gc.parent = dev;
+ state->gc.label = i2c->name;
+ state->gc.owner = THIS_MODULE;
+ state->gc.base = -1;
+ state->gc.ngpio = NUM_GPIO;
+
+ /* it is output only */
+ state->gc.get = waveshare_gpio_gpio_get;
+ state->gc.set = waveshare_gpio_gpio_set;
+ state->gc.get_direction = waveshare_gpio_gpio_get_direction;
+ state->gc.can_sleep = true;
+
+ ret = devm_gpiochip_add_data(dev, &state->gc, state);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to create gpiochip\n");
+
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = 255;
+ props.brightness = 255;
+ bl = devm_backlight_device_register(dev, dev_name(dev), dev, state,
+ &waveshare_gpio_bl, &props);
+ return PTR_ERR_OR_ZERO(bl);
+}
+
+static const struct of_device_id waveshare_gpio_dt_ids[] = {
+ { .compatible = "waveshare,dsi-touch-gpio" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, waveshare_gpio_dt_ids);
+
+static struct i2c_driver waveshare_gpio_regulator_driver = {
+ .driver = {
+ .name = "waveshare-regulator",
+ .of_match_table = of_match_ptr(waveshare_gpio_dt_ids),
+ },
+ .probe = waveshare_gpio_probe,
+};
+
+module_i2c_driver(waveshare_gpio_regulator_driver);
+
+MODULE_DESCRIPTION("GPIO controller driver for Waveshare DSI touch panels");
+MODULE_LICENSE("GPL");
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-17 23:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <70e9a8a0-414d-428f-8da8-9b65cc764849@collabora.com>
Hi Cristan,
Am Freitag, 17. April 2026, 19:55:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> On 4/17/26 2:34 PM, Heiko Stuebner wrote:
> > Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >
> > [...]
> >
> >> Cristian Ciocaltea (40):
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> >> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
> >
> > I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
> > sense, because these patches really are mostly identical :-)
>
> Yeah, apologies for the large number of patches, I went this way to allow
> per-board reviews. As previously noted, I tried to identify the GPIO pins from
> multiple sources, so I'm not entirely sure about the accuracy in every case.
>
> Would it be preferable to squash the patches per SoC and board vendor, instead?
I really would just do it per soc .. so 3 patches. That is a size that is
still reviewable for people, who can then check for their board.
If the patch is labeled "Add frl-enable-gpios for all RK3588s boards", I
do expect people to notice it the same as "oh _my_ board gets changed".
("all" could also be "most" :-) ).
Heiko
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: purwa: Add EL2 overlay for purwa-iot-evk
From: Dmitry Baryshkov @ 2026-04-17 23:27 UTC (permalink / raw)
To: Xin Liu
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-kernel, tingwei.zhang, jie.gan
In-Reply-To: <20260417054200.2402281-1-xin.liu@oss.qualcomm.com>
On Thu, Apr 16, 2026 at 10:42:00PM -0700, Xin Liu wrote:
> Add support for building an EL2 combined DTB for the purwa-iot-evk
> in the Qualcomm DTS Makefile.
>
> The new purwa-iot-evk-el2.dtb is generated by combining the base
> purwa-iot-evk.dtb with the x1-el2.dtbo overlay, enabling EL2-specific
> configurations required by the platform.
>
> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5
From: Dmitry Baryshkov @ 2026-04-17 23:29 UTC (permalink / raw)
To: Fenglin Wu
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <48bbcc34-f5bf-4ada-8210-b115f72ee850@oss.qualcomm.com>
On Fri, Apr 17, 2026 at 01:24:07PM +0800, Fenglin Wu wrote:
>
> On 4/2/2026 12:18 PM, Fenglin Wu wrote:
> >
> > On 4/1/2026 7:22 PM, Dmitry Baryshkov wrote:
> > > On Wed, Apr 01, 2026 at 02:41:24AM -0700, Fenglin Wu wrote:
> > > > PMIC arbiter v8.5 is an extension of PMIC arbiter v8 that updated
> > > > the definition of the channel status register bit fields. Add support
> > > > to handle this difference.
> > > >
> > > > Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> > > > ---
> > > > drivers/spmi/spmi-pmic-arb.c | 69
> > > > ++++++++++++++++++++++++++++++++++++++------
> > > > 1 file changed, 60 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/spmi/spmi-pmic-arb.c
> > > > b/drivers/spmi/spmi-pmic-arb.c
> > > > index 69f8d456324a..deeaa39bb647 100644
> > > > --- a/drivers/spmi/spmi-pmic-arb.c
> > > > +++ b/drivers/spmi/spmi-pmic-arb.c
> > > > @@ -28,6 +28,7 @@
> > > > #define PMIC_ARB_VERSION_V5_MIN 0x50000000
> > > > #define PMIC_ARB_VERSION_V7_MIN 0x70000000
> > > > #define PMIC_ARB_VERSION_V8_MIN 0x80000000
> > > > +#define PMIC_ARB_VERSION_V8P5_MIN 0x80050000
> > > > #define PMIC_ARB_INT_EN 0x0004
> > > > #define PMIC_ARB_FEATURES 0x0004
> > > > @@ -63,11 +64,34 @@
> > > > #define SPMI_OWNERSHIP_PERIPH2OWNER(X) ((X) & 0x7)
> > > > /* Channel Status fields */
> > > > -enum pmic_arb_chnl_status {
> > > > - PMIC_ARB_STATUS_DONE = BIT(0),
> > > > - PMIC_ARB_STATUS_FAILURE = BIT(1),
> > > > - PMIC_ARB_STATUS_DENIED = BIT(2),
> > > > - PMIC_ARB_STATUS_DROPPED = BIT(3),
> > > > +struct pmic_arb_chnl_status_mask {
> > > > + u8 done;
> > > > + u8 failure;
> > > > + u8 crc;
> > > > + u8 parity;
> > > > + u8 nack;
> > > > + u8 denied;
> > > > + u8 dropped;
> > > > +};
> > > > +
> > > > +static const struct pmic_arb_chnl_status_mask chnl_status_mask = {
> > > > + .done = BIT(0),
> > > > + .failure = BIT(1),
> > > > + .crc = 0,
> > > > + .parity = 0,
> > > > + .nack = 0,
> > > > + .denied = BIT(2),
> > > > + .dropped = BIT(3),
> > > > +};
> > > > +
> > > > +static const struct pmic_arb_chnl_status_mask
> > > > chnl_status_mask_v8p5 = {
> > > > + .done = BIT(0),
> > > > + .failure = BIT(1),
> > > > + .crc = BIT(2),
> > > > + .parity = BIT(3),
> > > > + .nack = BIT(4),
> > > > + .denied = BIT(5),
> > > > + .dropped = BIT(6),
> > > Would it be better to extract generation-specific callback to decode the
> > > error rather than defining the list of masks?
> >
> > Are you proposing to add a callback in pmic_arb_ver_ops, like
> > '*check_chnl_status', and create separate implementations for PMIC
> > arbiter versions before and after v8.5?
> >
> > This approach would add more extensive code changes with some code
> > duplication, especially for handling common error bits shared across all
> > versions—even if they only print error messages and return an error
> > code. Is that a concern?
> >
> > Fenglin
>
> Hi Dmitry,
>
> Please let me know if this your preferred way and if you are fine with the
> concern that I mentioned.
>
> I can come up with this approach and post a new patch.
Sorry.
Yes, a somewhat duplicate code would be better than having a bitfields
where the individual fields will differ from platform to platform.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 03/10] media: venus: core: Add msm8939 resource struct
From: Dmitry Baryshkov @ 2026-04-17 23:32 UTC (permalink / raw)
To: Erikas Bitovtas
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, André Apitzsch, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd, linux-media, linux-arm-msm,
devicetree, linux-kernel, linux-clk, ~postmarketos/upstreaming,
phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-3-a09fcf2c23df@gmail.com>
On Thu, Apr 16, 2026 at 04:43:50PM +0300, Erikas Bitovtas wrote:
> From: André Apitzsch <git@apitzsch.eu>
>
> Add msm8939 configuration data and related compatible.
> Cores on MSM8939 Venus are used for decoding, not encoding. Move them to
> vcodec0 so they can be enabled accordingly.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> ---
> drivers/media/platform/qcom/venus/core.c | 39 ++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 00/10] media: qcom: venus: add MSM8939 support
From: Dmitry Baryshkov @ 2026-04-17 23:37 UTC (permalink / raw)
To: Erikas Bitovtas
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, André Apitzsch, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd, linux-media, linux-arm-msm,
devicetree, linux-kernel, linux-clk, ~postmarketos/upstreaming,
phone-devel
In-Reply-To: <20260416-msm8939-venus-rfc-v1-0-a09fcf2c23df@gmail.com>
On Thu, Apr 16, 2026 at 04:43:47PM +0300, Erikas Bitovtas wrote:
> This patch series adds support for Venus on MSM8939. It is mostly
> similar to MSM8916 Venus, except it needs two additional cores to be
> powered on before it can start decoding.
>
> This patch series is marked as an RFC. Before submitting a non-RFC
> series, I would like to have some details clarified regarding how Venus
> works in order to improve and eventually upstream support for MSM8939.
>
> 1. In downstream, particularly in LA.BR.1.2.9.1_rb1.5, the buses
> for vcodec0 cores have only decoding bits enabled, as depicted
> by qcom,bus-configs property of qcom,msm-bus-clients children
> in qcom,vidc node. Do I understand correctly that these cores
> are only needed for decoding, and not for encoding?
> 2. Currently in device tree there is a video-decoder subnode for Venus
> node, however, for SDM845-v2 (and newer) chipsets, Venus does not use
> subnodes. Does this mean it should be dropped for MSM8939 as well?
> 3. MSM8939 supports HEVC decoding, however, as the patchset is written
> now, it does not work. It can be enabled, however, it will result in
> breakage of Venus for faulty MSM8916 firmwares, because the code
> disabling HEVC for HFI v1 needs to be removed, and as per commit
> c50cc6dc6c48 ("media: venus: hfi_parser: Ignore HEVC encoding for V1"),
> this would break support for some MSM8916 devices. What could be the
> best way to work around this?
> 4. To attach vcodec0 power domain list to dev_{dec,enc}, I had to move
> vdec_get and venc_get later in the probe. Should this be avoided, and
> is there a better way to attach vcodec power domains?
>
> There may be some other issues with this patchset - this is WIP code, so
> feedback is very appreciated. Thank you!
for the next iteration, could you please also include fluster results
for the codecs supported by it (VP8, H.264) and also v4l2-compliance
results?
>
> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> ---
> André Apitzsch (4):
> media: dt-bindings: venus: Add qcom,msm8939 schema
> media: venus: core: Add msm8939 resource struct
> arm64: dts: qcom: msm8939: Add venus node
> arm64: dts: qcom: msm8939-longcheer-l9100: Enable venus node
>
> Erikas Bitovtas (6):
> media: venus: add pmdomains to the struct based on the purpose of cores
> arm64: dts: qcom: msm8939-asus-z00t: add Venus
> clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled
> media: venus: move getting vdec and venc for later
> media: qcom: venus: Move HFI v3 venc and vdec methods to HFI v1
> media: venus: add power domain enable logic for Venus cores
>
> .../bindings/media/qcom,msm8939-venus.yaml | 104 ++++++++++++
> arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts | 8 +
> .../boot/dts/qcom/msm8939-longcheer-l9100.dts | 8 +
> arch/arm64/boot/dts/qcom/msm8939.dtsi | 24 +++
> drivers/clk/qcom/gcc-msm8939.c | 4 +
> drivers/media/platform/qcom/venus/core.c | 39 +++++
> drivers/media/platform/qcom/venus/core.h | 8 +
> drivers/media/platform/qcom/venus/pm_helpers.c | 187 ++++++++++++++++++---
> drivers/media/platform/qcom/venus/vdec.c | 12 +-
> drivers/media/platform/qcom/venus/venc.c | 12 +-
> 10 files changed, 374 insertions(+), 32 deletions(-)
> ---
> base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
> change-id: 20260416-msm8939-venus-rfc-c025c4c74fae
>
> Best regards,
> --
> Erikas Bitovtas <xerikasxx@gmail.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 06/10] arm64: dts: qcom: msm8939-asus-z00t: add Venus
From: Dmitry Baryshkov @ 2026-04-17 23:40 UTC (permalink / raw)
To: Erikas Bitovtas
Cc: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, André Apitzsch,
Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd,
linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <ad482bdd-2fb5-432f-be1d-dec25d9cbf5b@gmail.com>
On Thu, Apr 16, 2026 at 07:57:30PM +0300, Erikas Bitovtas wrote:
>
>
> On 4/16/26 6:17 PM, Konrad Dybcio wrote:
> > On 4/16/26 3:43 PM, Erikas Bitovtas wrote:
> >> Enable Venus video encoder/decoder for Asus ZenFone 2 Laser/Selfie.
> >>
> >> Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
> >> index 90e966242720..231a3e9c1929 100644
> >> --- a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
> >> +++ b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
> >> @@ -267,6 +267,14 @@ &usb_hs_phy {
> >> extcon = <&usb_id>;
> >> };
> >>
> >> +&venus {
> >> + status = "okay";
> >
> > You need a firmware path here
>
> When I tested Venus on my device, it loaded without one specified -
> msm-firmware-loader creates a symbolic link from modem partition for
> firmware. Additionally, none of the MSM8916 devices seem to include a
> firmware name. Has something changed since then?
Us becoming more strict? Or more caring? The default file paths are
supposed to be used for unfused devices. So if they don't work with
yours (most likely they don't), please add firmware-name:
firmware-name = "qcom/msm8916/Asus/z00t/venus.mbn";
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/4] usb: dwc3: xilinx: Add Versal2 MMI USB 3.2 controller support
From: Thinh Nguyen @ 2026-04-17 23:53 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, michal.simek@amd.com, Thinh Nguyen,
p.zabel@pengutronix.de, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, git@amd.com
In-Reply-To: <20260330190304.1841593-4-radhey.shyam.pandey@amd.com>
On Tue, Mar 31, 2026, Radhey Shyam Pandey wrote:
> Multi-media integrated (MMI) USB3.2 DRD IP is usb3.1 gen2 controller
> which support following speed SSP (10-Gbps), SuperSpeed(5-Gbps),
> high-speed(480-Mbps), full-speed(12-Mbps), and low-speed(1.5-Mbps)
> operation modes.
>
> USB2 and USB3 PHY support Physical connectivity via the Type-C
> connectivity. The MMI USB controller does not have a dedicated wrapper
> register space, so ioremap is skipped via the map_resource config flag.
>
> The driver handles clock and reset initialization. In this initial
> version typec reversibility is not implemented and it is assumed that
> USB3 PHY TCA mux programming is done by MMI configuration data object
> (CDOs) and TI PD controller is configured using external tiva programmer
> on VEK385 evaluation board.
>
> Tested host mode with mass storage device.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> - Introduce xlnx,usb-syscon phandle to access UDH address space
> which is wrapper subsystem IP for USB, DP and HDCP.
Where's xlnx,usb-syscon phandle?
> - Split config struct refactoring into separate patch (2/4).
> - Remove unused regmap/syscon fields and parsing code; defer to
> patch that first consumes them.
> - Fix error message capitalization to lowercase ("reset", "deassert").
> ---
> drivers/usb/dwc3/dwc3-xilinx.c | 50 ++++++++++++++++++++++++++++++----
> 1 file changed, 44 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> index bb59b56726e7..f2dee28bdc65 100644
> --- a/drivers/usb/dwc3/dwc3-xilinx.c
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -46,6 +46,7 @@ struct dwc3_xlnx;
>
> struct dwc3_xlnx_config {
> int (*pltfm_init)(struct dwc3_xlnx *data);
> + bool map_resource;
Perhaps this property should be inversed since the versal2 is unusual
that it doesn't need mapping of resource. How about no_mem_map?
> };
>
> struct dwc3_xlnx {
> @@ -93,6 +94,29 @@ static void dwc3_xlnx_set_coherency(struct dwc3_xlnx *priv_data, u32 coherency_o
> }
> }
>
> +static int dwc3_xlnx_init_versal2(struct dwc3_xlnx *priv_data)
> +{
> + struct device *dev = priv_data->dev;
> + struct reset_control *crst;
> + int ret;
> +
> + crst = devm_reset_control_get_optional_exclusive(dev, NULL);
> + if (IS_ERR(crst))
> + return dev_err_probe(dev, PTR_ERR(crst),
> + "failed to get reset signal\n");
> +
> + /* assert and deassert reset */
> + ret = reset_control_assert(crst);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to assert reset\n");
Any requirement on how long the reset needs to stay asserted?
> +
> + ret = reset_control_deassert(crst);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to deassert reset\n");
> +
> + return 0;
> +}
> +
> static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
> {
> struct device *dev = priv_data->dev;
> @@ -250,10 +274,16 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
>
> static const struct dwc3_xlnx_config zynqmp_config = {
> .pltfm_init = dwc3_xlnx_init_zynqmp,
> + .map_resource = true,
> };
>
> static const struct dwc3_xlnx_config versal_config = {
> .pltfm_init = dwc3_xlnx_init_versal,
> + .map_resource = true,
> +};
> +
> +static const struct dwc3_xlnx_config versal2_config = {
> + .pltfm_init = dwc3_xlnx_init_versal2,
> };
>
> static const struct of_device_id dwc3_xlnx_of_match[] = {
> @@ -265,6 +295,10 @@ static const struct of_device_id dwc3_xlnx_of_match[] = {
> .compatible = "xlnx,versal-dwc3",
> .data = &versal_config,
> },
> + {
> + .compatible = "xlnx,versal2-mmi-dwc3",
> + .data = &versal2_config,
> + },
> { /* Sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, dwc3_xlnx_of_match);
> @@ -299,19 +333,23 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
> struct dwc3_xlnx *priv_data;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - void __iomem *regs;
> int ret;
>
> priv_data = devm_kzalloc(dev, sizeof(*priv_data), GFP_KERNEL);
> if (!priv_data)
> return -ENOMEM;
>
> - regs = devm_platform_ioremap_resource(pdev, 0);
> - if (IS_ERR(regs))
> - return dev_err_probe(dev, PTR_ERR(regs), "failed to map registers\n");
> -
> priv_data->dwc3_config = device_get_match_data(dev);
> - priv_data->regs = regs;
> +
> + if (priv_data->dwc3_config->map_resource) {
> + void __iomem *regs;
> +
> + regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(regs))
> + return dev_err_probe(dev, PTR_ERR(regs),
> + "failed to map registers\n");
> + priv_data->regs = regs;
> + }
> priv_data->dev = dev;
>
> platform_set_drvdata(pdev, priv_data);
> --
> 2.43.0
>
BR,
Thinh
^ permalink raw reply
* Re: [PATCH RFC v3 06/11] RISC-V: QoS: add resctrl setup and domain management
From: guo.wenjia23 @ 2026-04-17 10:52 UTC (permalink / raw)
To: fustini
Cc: pjw, palmer, aou, alex, rkrcmar, samuel.holland, aricciardi,
npitre, mindal, atish.patra, atishp, vasu, ved, conor.dooley,
cuiyunhui, cp0613, zhiwei_liu, liwei1518, gong.shuai, gsh517,
liu.qingtao2, reinette.chatre, tony.luck, babu.moger, peternewman,
fenghua.yu, james.morse, ben.horgan, Dave.Martin, robh, conor+dt,
krzk+dt, rafael, lenb, robert.moore, sunilvl, fustini,
linux-kernel, linux-riscv, x86, linux-acpi, acpica-devel,
devicetree, paul.walmsley
In-Reply-To: <20260414-ssqosid-cbqri-rqsc-v7-0-v3-6-b3b2e7e9847a@kernel.org>
Hi Drew,
On Wed, Apr 15, 2026 at 9:57 AM Drew Fustini <fustini@kernel.org> wrote:
> Add the setup and domain management layer: domain allocation
> (qos_new_domain), controller value initialization
> (qos_init_domain_ctrlval), resource struct initialization for cache and
> bandwidth resources, domain registration with the resctrl filesystem
> (qos_resctrl_add_controller_domain), and the top-level setup function
> (qos_resctrl_setup) that probes all controllers and calls resctrl_init().
>
> Also add qos_resctrl_online_cpu() and qos_resctrl_offline_cpu() for CPU
> hotplug integration.
>
> Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> Signed-off-by: Drew Fustini <fustini@kernel.org>
> ---
> arch/riscv/kernel/qos/qos_resctrl.c | 295 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 294 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/kernel/qos/qos_resctrl.c b/arch/riscv/kernel/qos/qos_resctrl.c
> index a4a120f89840..8d7e3b0abb75 100644
> --- a/arch/riscv/kernel/qos/qos_resctrl.c
> +++ b/arch/riscv/kernel/qos/qos_resctrl.c
> @@ -675,7 +675,23 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_l3_mon_domai
>
> void resctrl_arch_reset_all_ctrls(struct rdt_resource *r)
> {
> - /* not implemented for the RISC-V resctrl implementation */
> + struct cbqri_resctrl_res *hw_res;
> + struct rdt_ctrl_domain *d;
> + enum resctrl_conf_type t;
> + u32 default_ctrl;
> + int i;
> +
> + lockdep_assert_cpus_held();
> +
> + hw_res = container_of(r, struct cbqri_resctrl_res, resctrl_res);
> + default_ctrl = resctrl_get_default_ctrl(r);
> +
> + list_for_each_entry(d, &r->ctrl_domains, hdr.list) {
> + for (i = 0; i < hw_res->max_rcid; i++) {
> + for (t = 0; t < CDP_NUM_TYPES; t++)
> + resctrl_arch_update_one(r, d, i, t, default_ctrl);
For the bw controller, default_ctrl = max_bw, and resctrl_arch_update_one will set the rbwb of all RCIDs to max_bw.
According to the spec: The sum of Rbwb allocated across all rcids must not exceed MRBWB value.
Does this conflict with the spec?
> + }
> + }
> }
>
> void resctrl_arch_pre_mount(void)
> @@ -797,3 +813,280 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> spin_unlock(&ctrl->lock);
> return val;
> }
> +
> +static struct rdt_ctrl_domain *qos_new_domain(struct cbqri_controller *ctrl)
> +{
> + struct cbqri_resctrl_dom *hw_dom;
> + struct rdt_ctrl_domain *domain;
> +
> + hw_dom = kzalloc_obj(*hw_dom, GFP_KERNEL);
> + if (!hw_dom)
> + return NULL;
> +
> + /* associate this cbqri_controller with the domain */
> + hw_dom->hw_ctrl = ctrl;
> +
> + /* the rdt_domain struct from inside the cbqri_resctrl_dom struct */
> + domain = &hw_dom->resctrl_ctrl_dom;
> +
> + INIT_LIST_HEAD(&domain->hdr.list);
> +
> + return domain;
> +}
> +
> +static int qos_init_domain_ctrlval(struct rdt_resource *r, struct rdt_ctrl_domain *d)
> +{
> + struct cbqri_resctrl_res *hw_res;
> + int err = 0;
> + int i;
> +
> + hw_res = container_of(r, struct cbqri_resctrl_res, resctrl_res);
> +
> + for (i = 0; i < hw_res->max_rcid; i++) {
> + err = resctrl_arch_update_one(r, d, i, 0, resctrl_get_default_ctrl(r));
Also set rbwb of all RCIDs to max_bw. Does this also conflict with the spec?
> + if (err)
> + return err;
> + }
> + return 0;
> +}
> +
Thanks,
Wenjia
^ permalink raw reply
* Re: [PATCH v2 4/4] usb: dwc3: xilinx: Add support to program MMI USB TX deemphasis
From: Thinh Nguyen @ 2026-04-18 0:28 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, michal.simek@amd.com, Thinh Nguyen,
p.zabel@pengutronix.de, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, git@amd.com
In-Reply-To: <20260330190304.1841593-5-radhey.shyam.pandey@amd.com>
On Tue, Mar 31, 2026, Radhey Shyam Pandey wrote:
> Introduces support for programming the 18-bit TX Deemphasis value that
> drives the pipe_TxDeemph signal, as defined in the PIPE4 specification.
>
> The configured value is recommended by Synopsys and is intended for
> standard (non-compliance) operation. These Gen2 equalization settings
> have been validated through both internal and external compliance
> testing. By applying this setting, the stability of USB 3.2 enumeration
> is improved and now SuperSpeedPlus devices are consistently recognized as
> USB 3.2 Gen 2 by the MMI USB Host controller.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> Changes for v2:
> - Don't use compatible check for deemphasis programming.
> - Rename property "snps,lcsr_tx_deemph" to "snps,lcsr-tx-deemph"
> (hyphens per kernel convention).
> - Fix double space in LCSR_TX_DEEMPH register comment.
> - Add blank line between register offset define and "Bit fields" section.
> ---
> drivers/usb/dwc3/core.c | 17 +++++++++++++++++
> drivers/usb/dwc3/core.h | 8 ++++++++
> drivers/usb/dwc3/dwc3-xilinx.c | 15 ++++++++++++---
> 3 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 161a4d58b2ce..e678a53a90b3 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -646,6 +646,15 @@ static void dwc3_config_soc_bus(struct dwc3 *dwc)
> reg |= DWC3_GSBUSCFG0_REQINFO(dwc->gsbuscfg0_reqinfo);
> dwc3_writel(dwc, DWC3_GSBUSCFG0, reg);
> }
> +
> + if (dwc->csr_tx_deemph_field_1 != DWC3_LCSR_TX_DEEMPH_UNSPECIFIED) {
> + u32 reg;
> +
> + reg = dwc3_readl(dwc, DWC3_LCSR_TX_DEEMPH);
> + reg &= ~DWC3_LCSR_TX_DEEMPH_MASK(~0);
> + reg |= DWC3_LCSR_TX_DEEMPH_MASK(dwc->csr_tx_deemph_field_1);
> + dwc3_writel(dwc, DWC3_LCSR_TX_DEEMPH, reg);
> + }
> }
>
> static int dwc3_core_ulpi_init(struct dwc3 *dwc)
> @@ -1671,11 +1680,13 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
> static void dwc3_get_software_properties(struct dwc3 *dwc,
> const struct dwc3_properties *properties)
> {
> + u32 csr_tx_deemph_field_1;
> struct device *tmpdev;
> u16 gsbuscfg0_reqinfo;
> int ret;
>
> dwc->gsbuscfg0_reqinfo = DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED;
> + dwc->csr_tx_deemph_field_1 = DWC3_LCSR_TX_DEEMPH_UNSPECIFIED;
>
> if (properties->gsbuscfg0_reqinfo !=
> DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED) {
> @@ -1693,6 +1704,12 @@ static void dwc3_get_software_properties(struct dwc3 *dwc,
> &gsbuscfg0_reqinfo);
> if (!ret)
> dwc->gsbuscfg0_reqinfo = gsbuscfg0_reqinfo;
> +
> + ret = device_property_read_u32(tmpdev,
> + "snps,lcsr-tx-deemph",
> + &csr_tx_deemph_field_1);
> + if (!ret)
> + dwc->csr_tx_deemph_field_1 = csr_tx_deemph_field_1;
> }
> }
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index a35b3db1f9f3..99874ad09730 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -181,6 +181,8 @@
>
> #define DWC3_LLUCTL(n) (0xd024 + ((n) * 0x80))
>
> +#define DWC3_LCSR_TX_DEEMPH 0xd060
> +
This should be DWC3_LCSR_TX_DEEMPH(n) where n is the USB3 port number
> /* Bit fields */
>
> /* Global SoC Bus Configuration INCRx Register 0 */
> @@ -198,6 +200,10 @@
> #define DWC3_GSBUSCFG0_REQINFO(n) (((n) & 0xffff) << 16)
> #define DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED 0xffffffff
>
> +/* LCSR_TX_DEEMPH Register: setting TX deemphasis used in normal operation in gen2 */
> +#define DWC3_LCSR_TX_DEEMPH_MASK(n) ((n) & 0x3ffff)
> +#define DWC3_LCSR_TX_DEEMPH_UNSPECIFIED 0xffffffff
> +
> /* Global Debug LSP MUX Select */
> #define DWC3_GDBGLSPMUX_ENDBC BIT(15) /* Host only */
> #define DWC3_GDBGLSPMUX_HOSTSELECT(n) ((n) & 0x3fff)
> @@ -1180,6 +1186,7 @@ struct dwc3_glue_ops {
> * @wakeup_pending_funcs: Indicates whether any interface has requested for
> * function wakeup in bitmap format where bit position
> * represents interface_id.
> + * @csr_tx_deemph_field_1: stores TX deemphasis used in Gen2 operation.
How do you plan to apply this for the case of multiple USB3 ports. Only
to the first USB3 port0 or all of them? Document how you want to handle
this.
> */
> struct dwc3 {
> struct work_struct drd_work;
> @@ -1417,6 +1424,7 @@ struct dwc3 {
> struct dentry *debug_root;
> u32 gsbuscfg0_reqinfo;
> u32 wakeup_pending_funcs;
> + u32 csr_tx_deemph_field_1;
> };
>
> #define INCRX_BURST_MODE 0
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> index f2dee28bdc65..44008856ee73 100644
> --- a/drivers/usb/dwc3/dwc3-xilinx.c
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -41,11 +41,13 @@
> #define PIPE_CLK_SELECT 0
> #define XLNX_USB_FPD_POWER_PRSNT 0x80
> #define FPD_POWER_PRSNT_OPTION BIT(0)
> +#define XLNX_MMI_USB_TX_DEEMPH_DEF 0x8c45
>
> struct dwc3_xlnx;
>
> struct dwc3_xlnx_config {
> int (*pltfm_init)(struct dwc3_xlnx *data);
> + u32 tx_deemph;
> bool map_resource;
> };
>
> @@ -284,6 +286,7 @@ static const struct dwc3_xlnx_config versal_config = {
>
> static const struct dwc3_xlnx_config versal2_config = {
> .pltfm_init = dwc3_xlnx_init_versal2,
> + .tx_deemph = XLNX_MMI_USB_TX_DEEMPH_DEF,
> };
>
> static const struct of_device_id dwc3_xlnx_of_match[] = {
> @@ -303,10 +306,12 @@ static const struct of_device_id dwc3_xlnx_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, dwc3_xlnx_of_match);
>
> -static int dwc3_set_swnode(struct device *dev)
> +static int dwc3_set_swnode(struct dwc3_xlnx *priv_data)
> {
> + struct device *dev = priv_data->dev;
> + const struct dwc3_xlnx_config *config = priv_data->dwc3_config;
> struct device_node *np = dev->of_node, *dwc3_np;
> - struct property_entry props[2];
> + struct property_entry props[3];
> int prop_idx = 0, ret = 0;
>
> dwc3_np = of_get_compatible_child(np, "snps,dwc3");
> @@ -320,6 +325,10 @@ static int dwc3_set_swnode(struct device *dev)
> if (of_dma_is_coherent(dwc3_np))
> props[prop_idx++] = PROPERTY_ENTRY_U16("snps,gsbuscfg0-reqinfo",
> 0xffff);
> + if (config->tx_deemph)
We should set the tx_deemph to the DWC3_LCSR_TX_DEEMPH_UNSPECIFIED by
default and check against that instead.
> + props[prop_idx++] = PROPERTY_ENTRY_U32("snps,lcsr-tx-deemph",
> + config->tx_deemph);
> +
> of_node_put(dwc3_np);
>
> if (prop_idx)
> @@ -368,7 +377,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
> if (ret)
> goto err_clk_put;
>
> - ret = dwc3_set_swnode(dev);
> + ret = dwc3_set_swnode(priv_data);
> if (ret)
> goto err_clk_put;
>
> --
> 2.43.0
>
BR,
Thinh
^ permalink raw reply
* Re: [PATCH v2 2/4] usb: dwc3: xilinx: Introduce dwc3_xlnx_config for per-platform data
From: Thinh Nguyen @ 2026-04-18 0:32 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, michal.simek@amd.com, Thinh Nguyen,
p.zabel@pengutronix.de, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, git@amd.com
In-Reply-To: <20260330190304.1841593-3-radhey.shyam.pandey@amd.com>
On Tue, Mar 31, 2026, Radhey Shyam Pandey wrote:
> Replace the direct pltfm_init function pointer in struct dwc3_xlnx with
> a const pointer to a new struct dwc3_xlnx_config. This groups
> per-platform configuration in one place and allows future patches to add
> platform-specific fields (e.g. tx_deemph) without growing dwc3_xlnx.
>
> While at it, switch from of_match_node() to device_get_match_data() to
> simplify the match data lookup.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> Changes for v2:
> - New patch, split from "Add Versal2 MMI USB 3.2 controller support".
> - Use device_get_match_data() instead of of_match_node().
> ---
> drivers/usb/dwc3/dwc3-xilinx.c | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> index f41b0da5e89d..bb59b56726e7 100644
> --- a/drivers/usb/dwc3/dwc3-xilinx.c
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -12,6 +12,7 @@
> #include <linux/clk.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/dma-mapping.h>
> #include <linux/gpio/consumer.h>
> #include <linux/of_platform.h>
> @@ -41,12 +42,18 @@
> #define XLNX_USB_FPD_POWER_PRSNT 0x80
> #define FPD_POWER_PRSNT_OPTION BIT(0)
>
> +struct dwc3_xlnx;
> +
> +struct dwc3_xlnx_config {
> + int (*pltfm_init)(struct dwc3_xlnx *data);
> +};
> +
> struct dwc3_xlnx {
> int num_clocks;
> struct clk_bulk_data *clks;
> struct device *dev;
> void __iomem *regs;
> - int (*pltfm_init)(struct dwc3_xlnx *data);
> + const struct dwc3_xlnx_config *dwc3_config;
> struct phy *usb3_phy;
> };
>
> @@ -241,14 +248,22 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> return ret;
> }
>
> +static const struct dwc3_xlnx_config zynqmp_config = {
> + .pltfm_init = dwc3_xlnx_init_zynqmp,
> +};
> +
> +static const struct dwc3_xlnx_config versal_config = {
> + .pltfm_init = dwc3_xlnx_init_versal,
> +};
> +
> static const struct of_device_id dwc3_xlnx_of_match[] = {
> {
> .compatible = "xlnx,zynqmp-dwc3",
> - .data = &dwc3_xlnx_init_zynqmp,
> + .data = &zynqmp_config,
> },
> {
> .compatible = "xlnx,versal-dwc3",
> - .data = &dwc3_xlnx_init_versal,
> + .data = &versal_config,
> },
> { /* Sentinel */ }
> };
> @@ -284,7 +299,6 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
> struct dwc3_xlnx *priv_data;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - const struct of_device_id *match;
> void __iomem *regs;
> int ret;
>
> @@ -296,9 +310,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
> if (IS_ERR(regs))
> return dev_err_probe(dev, PTR_ERR(regs), "failed to map registers\n");
>
> - match = of_match_node(dwc3_xlnx_of_match, pdev->dev.of_node);
> -
> - priv_data->pltfm_init = match->data;
> + priv_data->dwc3_config = device_get_match_data(dev);
> priv_data->regs = regs;
> priv_data->dev = dev;
>
> @@ -314,7 +326,7 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = priv_data->pltfm_init(priv_data);
> + ret = priv_data->dwc3_config->pltfm_init(priv_data);
Though this won't hit now, but we should check if dwc3_config exists
before accessing it.
BR,
Thinh
> if (ret)
> goto err_clk_put;
>
> --
> 2.43.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox