devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).