From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-mmc@vger.kernel.org,
Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
linux-kernel@vger.kernel.org,
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
linux-renesas-soc@vger.kernel.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Rob Herring <robh@kernel.org>,
Biju Das <biju.das.jz@bp.renesas.com>,
Magnus Damm <magnus.damm@gmail.com>,
devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Subject: Re: [RFC PATCH v2 3/3] mmc: renesas_sdhi: Add support for RZ/V2H(P) SoC
Date: Fri, 21 Jun 2024 13:58:20 +0200 [thread overview]
Message-ID: <CAMuHMdXeDTof+aPJVUma78DgxP8vuWjJHoiBTcX_mKjX9WduZA@mail.gmail.com> (raw)
In-Reply-To: <4lypqqf4o2wk22kzpyutlaarare5kurdrlokbm6mb4re3mstam@qo7c3d4tcpll>
Hi all,
On Fri, Jun 21, 2024 at 9:54 AM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > Based on the feedback from Rob I have now changed it to below, i.e.
> > the regulator now probes based on regulator-compatible property value
> > "vqmmc-r9a09g057-regulator" instead of regulator node name as the
> > driver has of_match in regulator_desc.
>
> I like this a lot! One minor comment.
>
> > static struct regulator_desc r9a09g057_vqmmc_regulator = {
> > .of_match = of_match_ptr("vqmmc-r9a09g057-regulator"),
> > .owner = THIS_MODULE,
> > .type = REGULATOR_VOLTAGE,
> > .ops = &r9a09g057_regulator_voltage_ops,
> > .volt_table = r9a09g057_vqmmc_voltages,
> > .n_voltages = ARRAY_SIZE(r9a09g057_vqmmc_voltages),
> > };
> >
> > SoC DTSI:
> > sdhi1: mmc@15c10000 {
> > compatible = "renesas,sdhi-r9a09g057";
> > reg = <0x0 0x15c10000 0 0x10000>;
> > interrupts = <GIC_SPI 737 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 738 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&cpg CPG_MOD 167>,
> > <&cpg CPG_MOD 169>,
> > <&cpg CPG_MOD 168>,
> > <&cpg CPG_MOD 170>;
> > clock-names = "core", "clkh", "cd", "aclk";
> > resets = <&cpg 168>;
> > power-domains = <&cpg>;
> > status = "disabled";
> >
> > vqmmc_sdhi1: vqmmc-regulator {
> > regulator-compatible = "vqmmc-r9a09g057-regulator";
renesas,r9a09g057-vqmmc-regulator?
> > regulator-name = "vqmmc-regulator";
>
> This should have "sdhi<X>" somewhere in the name?
Indeed.
>
> > regulator-min-microvolt = <1800000>;
> > regulator-max-microvolt = <3300000>;
> > status = "disabled";
> > };
> > };
> >
> > Board DTS:
> >
> > &sdhi1 {
> > pinctrl-0 = <&sdhi1_pins>;
> > pinctrl-1 = <&sdhi1_pins>;
> > pinctrl-names = "default", "state_uhs";
> > vmmc-supply = <®_3p3v>;
> > vqmmc-supply = <&vqmmc_sdhi1>;
> > bus-width = <4>;
> > sd-uhs-sdr50;
> > sd-uhs-sdr104;
> > status = "okay";
> > };
> >
> > &vqmmc_sdhi1 {
> > status = "okay";
> > };
>
> Again, I like this. It looks like proper HW description to me.
>
> > Based on the feedback provided Geert ie to use set_pwr callback to set
> > PWEN bit and handle IOVS bit in voltage switch callback by dropping
> > the regulator altogether. In this case we will have to introduce just
> > a single "use-internal-regulator" property and if set make the vqmmc
> > regulator optional?
>
> Let's discuss with Geert. But I am quite convinced of your approach
> above.
>
> > > > Let me know if I have missed something obvious here.
> > >
> > > Nope, all good.
>
> Don't give up, I think we are close...
The above indeed starts looking good to me.
IIUIC, the use of the special vqmmc-r9a09g057-regulator is still
optional, and the subnode can be left disabled? E.g. the board
designer may still use a (different) GPIO to control the regulator,
using "regulator-gpio"?
Which brings me to another question: as both the SDmIOVS and SDmPWEN
pins can be configured as GPIOs, why not ignore the special handling
using the SDm_SD_STATUS register, and use "regulator-gpio" instead?
We usually do the same for CD/WP, using "{cd,wp}-gpios" instead.
Exceptions are old SH/R-Mobile and R-Car Gen1 boards:
arch/arm/boot/dts/renesas/r8a73a4-ape6evm.dts: groups =
"sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd";
arch/arm/boot/dts/renesas/r8a7740-armadillo800eva.dts:
groups = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_wp";
arch/arm/boot/dts/renesas/r8a7778-bockw.dts: groups =
"sdhi0_cd", "sdhi0_wp";
arch/arm/boot/dts/renesas/r8a7779-marzen.dts: groups =
"sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd";
arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts: groups =
"sdhi0_data4", "sdhi0_ctrl", "sdhi0_cd", "sdhi0_wp";
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2024-06-21 11:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 9:17 [RFC PATCH v2 0/3] Add SD/MMC support for Renesas RZ/V2H(P) SoC Prabhakar
2024-06-13 9:17 ` [RFC PATCH v2 1/3] dt-bindings: mmc: renesas,sdhi: Document RZ/V2H(P) support Prabhakar
2024-06-13 9:17 ` [RFC PATCH v2 2/3] mmc: tmio: Use MMC core APIs to control the vqmmc regulator Prabhakar
2024-06-17 7:30 ` Wolfram Sang
2024-06-17 7:37 ` Geert Uytterhoeven
2024-06-13 9:17 ` [RFC PATCH v2 3/3] mmc: renesas_sdhi: Add support for RZ/V2H(P) SoC Prabhakar
2024-06-17 8:31 ` Wolfram Sang
2024-06-19 16:18 ` Lad, Prabhakar
2024-06-20 7:39 ` Wolfram Sang
2024-06-20 9:30 ` Biju Das
2024-06-20 9:43 ` Lad, Prabhakar
2024-06-20 9:49 ` Biju Das
2024-06-20 9:59 ` Lad, Prabhakar
2024-06-20 17:15 ` Lad, Prabhakar
2024-06-21 7:54 ` Wolfram Sang
2024-06-21 11:58 ` Geert Uytterhoeven [this message]
2024-06-21 12:33 ` Lad, Prabhakar
2024-06-28 14:17 ` Lad, Prabhakar
2024-06-20 15:40 ` Geert Uytterhoeven
2024-06-20 15:56 ` Lad, Prabhakar
2024-06-21 7:45 ` Wolfram Sang
2024-06-21 7:47 ` Wolfram Sang
2024-06-21 7:42 ` Wolfram Sang
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=CAMuHMdXeDTof+aPJVUma78DgxP8vuWjJHoiBTcX_mKjX9WduZA@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=biju.das.jz@bp.renesas.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fabrizio.castro.jz@renesas.com \
--cc=geert+renesas@glider.be \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=prabhakar.csengg@gmail.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=wsa+renesas@sang-engineering.com \
/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).