From: Yao Zi <ziyao@disroot.org>
To: Jonas Karlman <jonas@kwiboo.se>, Chukun Pan <amadeus@jmu.edu.cn>
Cc: conor+dt@kernel.org, cristian.ciocaltea@collabora.com,
detlev.casanova@collabora.com, devicetree@vger.kernel.org,
heiko@sntech.de, krzk+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2 7/8] arm64: dts: rockchip: Add SDMMC/SDIO controllers for RK3528
Date: Fri, 7 Mar 2025 05:54:27 +0000 [thread overview]
Message-ID: <Z8qKEzmTFxhHKApG@pie> (raw)
In-Reply-To: <3d3db030-26e6-4fe1-9158-85f8cebef89c@kwiboo.se>
On Fri, Mar 07, 2025 at 12:05:16AM +0100, Jonas Karlman wrote:
> On 2025-03-06 17:43, Yao Zi wrote:
> > On Thu, Mar 06, 2025 at 10:00:09PM +0800, Chukun Pan wrote:
> >> Hi,
> >>
> >>> + sdio0: mmc@ffc10000 {
> >>> + compatible = "rockchip,rk3528-dw-mshc",
> >>> + "rockchip,rk3288-dw-mshc";
> >>> + reg = <0x0 0xffc10000 0x0 0x4000>;
> >>> + clocks = <&cru HCLK_SDIO0>,
> >>> + <&cru CCLK_SRC_SDIO0>,
> >>> + <&cru SCLK_SDIO0_DRV>,
> >>> + <&cru SCLK_SDIO0_SAMPLE>;
> >>> + clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> >>> + fifo-depth = <0x100>;
> >>> + interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
> >>> + max-frequency = <150000000>;
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&sdio0_bus4>, <&sdio0_clk>, <&sdio0_cmd>,
> >>> + <&sdio0_det>, <&sdio0_pwren>;
> >>
> >> The sdio module is usually "non-removable", no need det,
> >> and pwren may be other gpio (use mmc-pwrseq). So it should
> >> be `pinctrl-0 = <&sdio0_bus4>, <&sdio0_clk>, <&sdio0_cmd>;`
> >
> > This doesn't affect the fact that these two pins are assigned as
> > functional pins for SDIO0, as pointed out by the datasheet[1].
> >
> > But with more digging, I found the reference design[2] of Rockchip
> > actually uses the two pins as normal GPIOs. This is more obvious in
> > downstream devicetree of an EVB[3]. Most of the existing boards (Radxa
> > 2A, ArmSOM Sige 1) follow the reference design.
> >
> > For me, it's kind of surprising that the SDIO IP functions with two
> > functional pins assigned as different modes. I'm not sure whether we
> > should apply pin configuration for these two pins in the SoC devicetree.
> > Jonas, what do you think about it?
>
> I think it make sense to match the pins used by reference boards, i.e.
> the pinconf most likely to be used by majority of boards that will use
> the sdio interface.
Thanks, will take it.
> Of my RK3528 boards, only ArmSoM Sige1 use sdio for onboard wifi and
> there I currently have following in my work-in-progress board DT [4]:
>
> pinctrl-names = "default";
> pinctrl-0 = <&sdio0_bus4>, <&sdio0_clk>, <&sdio0_cmd>, <&clkm1_32k_out>;
>
> The Radxa ROCK 2A/2F seem to use USB for wifi/bt.
>
> [4] https://github.com/Kwiboo/linux-rockchip/blob/next-20250305-rk3528/arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
>
> Regards,
> Jonas
>
> >
> >>> + resets = <&cru SRST_H_SDIO0>;
> >>> + reset-names = "reset";
> >>> + status = "disabled";
> >>> + };
> >>> +
> >>> + sdio1: mmc@ffc20000 {
> >>> + compatible = "rockchip,rk3528-dw-mshc",
> >>> + "rockchip,rk3288-dw-mshc";
> >>> + reg = <0x0 0xffc20000 0x0 0x4000>;
> >>> + clocks = <&cru HCLK_SDIO1>,
> >>> + <&cru CCLK_SRC_SDIO1>,
> >>> + <&cru SCLK_SDIO1_DRV>,
> >>> + <&cru SCLK_SDIO1_SAMPLE>;
> >>> + clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> >>> + fifo-depth = <0x100>;
> >>> + interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
> >>> + max-frequency = <150000000>;
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&sdio1_bus4>, <&sdio1_clk>, <&sdio1_cmd>,
> >>> + <&sdio1_det>, <&sdio1_pwren>;
> >>
> >> Same here.
> >>
> >>> + resets = <&cru SRST_H_SDIO1>;
> >>> + reset-names = "reset";
> >>> + status = "disabled";
> >>> + };
> >>
> >> Thanks,
> >> Chukun
> >>
> >> --
> >> 2.25.1
> >>
> >
> > Best regards,
> > Yao Zi
> >
> > [1]: https://github.com/DeciHD/rockchip_docs/blob/main/rk3528/Rockchip%C2%A0RK3528%C2%A0Datasheet%C2%A0V1.0-20230522.pdf
> > [2]: https://github.com/DeciHD/rockchip_docs/blob/main/rk3528/RK3528_BOX_REF_V10_20230525.pdf
> > [3]: https://github.com/rockchip-linux/kernel/blob/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3528-evb1-ddr4-v10.dtsi#L128
>
Best regards,
Yao Zi
next prev parent reply other threads:[~2025-03-07 5:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 19:42 [PATCH v2 0/8] Support SD/SDIO controllers on RK3528 Yao Zi
2025-03-05 19:42 ` [PATCH v2 1/8] dt-bindings: soc: rockchip: Add RK3528 VO GRF syscon Yao Zi
2025-03-05 19:42 ` [PATCH v2 2/8] dt-bindings: soc: rockchip: Add RK3528 VPU " Yao Zi
2025-03-05 19:42 ` [PATCH v2 3/8] dt-bindings: mmc: rockchip-dw-mshc: Add compatible string for RK3528 Yao Zi
2025-03-05 19:42 ` [PATCH v2 4/8] dt-bindings: clock: Add GRF clock definition " Yao Zi
2025-03-06 8:40 ` Krzysztof Kozlowski
2025-03-05 19:45 ` [PATCH v2 5/8] clk: rockchip: Support MMC clocks in GRF region Yao Zi
2025-03-05 19:45 ` [PATCH v2 6/8] clk: rockchip: rk3528: Add SD/SDIO tuning " Yao Zi
2025-03-05 19:46 ` [PATCH v2 7/8] arm64: dts: rockchip: Add SDMMC/SDIO controllers for RK3528 Yao Zi
2025-03-06 14:00 ` Chukun Pan
2025-03-06 16:43 ` Yao Zi
2025-03-06 23:05 ` Jonas Karlman
2025-03-07 5:54 ` Yao Zi [this message]
2025-03-07 23:22 ` Jonas Karlman
2025-03-08 14:05 ` Yao Zi
2025-03-05 19:46 ` [PATCH v2 8/8] arm64: dts: rockchip: Enable SD-card interface on Radxa E20C Yao Zi
2025-03-07 3:35 ` Chukun Pan
2025-03-07 5:52 ` Yao Zi
2025-03-07 6:45 ` Jonas Karlman
2025-03-07 7:10 ` Chukun Pan
2025-03-07 7:26 ` Yao Zi
2025-03-08 15:27 ` Yao Zi
2025-03-08 17:23 ` Jonas Karlman
2025-03-06 13:36 ` (subset) [PATCH v2 0/8] Support SD/SDIO controllers on RK3528 Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z8qKEzmTFxhHKApG@pie \
--to=ziyao@disroot.org \
--cc=amadeus@jmu.edu.cn \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).