From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Biju <biju.das.au@gmail.com>
Cc: Ulf Hansson <ulfh@kernel.org>,
Biju Das <biju.das.jz@bp.renesas.com>,
linux-mmc@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH v24 11/15] mmc: renesas_sdhi: Add RZ/G3L SDHI support
Date: Thu, 3 Sep 2026 14:01:31 +0200 [thread overview]
Message-ID: <aplhlynkb_LUiVhS@shikoro> (raw)
In-Reply-To: <20260820171657.62815-12-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]
Okay, let's start this one high level...
On Thu, Aug 20, 2026 at 06:16:41PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> RZ/G3L (r9a08g046) has an SDHI controller that differs from existing
> platforms in clock divider width, a second HW adjustment register,
> and an extra tuning register.
>
> Add TMIO_MMC_HWADJ to mark controllers with a second HWADJ2 register
> (offset 0x010), programmed by renesas_sdhi_set_hw_adjustment_delay()
> alongside TMPPORT2 (0x3FFF at 3.3V, 0xFF at 1.8V). Clear the new
> HWADJ4 register (0x022) at tuning start when TMIO_MMC_INTERNAL_DIVIDER
> is set.
>
> Update renesas_sdhi_set_clock() to write the clock control register
> with a 32-bit access when max_divider isn't the default, moving bits
> [9:8] of the clock value into bits [17:16] of the register — needed
> to drive RZ/G3L's wider 11-bit divider field via the max_divider/
> clk_div_mask support added earlier in this series.
>
> Add SDHI_VER_RZ_G3L_SDMMC (0xce10) and handle it in
> renesas_sdhi_sdbuf_width(). Add of_data_rzg3l with RZ/G3L's wider
> clk_mask, an 11-bit max_divider of 2048, a dedicated tap table, and
> the relevant flags including TMIO_MMC_INTERNAL_DIVIDER and
> TMIO_MMC_HWADJ. Wire it up via of_rzg3l_compatible (fixed_addr_mode
> quirk) and register the "renesas,sdhi-r9a08g046" compatible string.
After arriving at patch 11, I feel a significant loss in motivation to
read this patch description. It is very wordy, includes a lot of the
WHAT, hiding the WHY. Maybe you can adjust the prompt, but I would
suggest to write it yourself.
> - sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clock);
> + if (host->pdata->max_divider != SDHI_MAX_DIVIDER_DEFAULT) {
> + u64 tmp;
> +
> + tmp = FIELD_GET(RZG3L_CLK_CTL_DIV9_DIV8_SRC, clk);
> + clock |= FIELD_PREP(RZG3L_CLK_CTL_DIV9_DIV8, tmp);
> + clock &= ~RZG3L_CLK_CTL_DIV9_DIV8_SRC;
I am confused. Bit 8+9 are always zero?
> -#define SH_MOBILE_SDHI_SCC_TMPPORT2 0x00E
> +#define SH_MOBILE_SDHI_SCC_TMPPORT2 0x00E /* G3L: SDm_SCC_HS400MODE1 */
> +#define RZG3L_SDHI_SCC_HWADJ2 0x010
Does RZG3L have a dedicated naming? I'd guess *_HWADJ1. I wonder if it
makes sense to have a dedicated define for it. I tend to think so.
> + if (hwadj2)
> + sd_scc_write32(host, priv, RZG3L_SDHI_SCC_HWADJ2, 0x3FFF);
> + } else {
> sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2, 0x1);
> + if (hwadj2)
> + sd_scc_write32(host, priv, RZG3L_SDHI_SCC_HWADJ2, 0xFF);
Magic values?
> if (preserve) {
> card_opt = sd_ctrl_read16(host, CTL_SD_MEM_CARD_OPT);
> - clk_ctrl = sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL);
> + if (host->pdata->flags & TMIO_MMC_INTERNAL_DIVIDER)
> + clk_ctrl_32 = sd_ctrl_read32(host, CTL_SD_CARD_CLK_CTL);
> + else
> + clk_ctrl = sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL);
> +
> if (host->pdata->flags & TMIO_MMC_MIN_RCAR2)
> sdif_mode = sd_ctrl_read16(host, CTL_SDIF_MODE);
> }
> @@ -217,7 +222,11 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host, bool preserve)
>
> if (preserve) {
> sd_ctrl_write16(host, CTL_SD_MEM_CARD_OPT, card_opt);
> - sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk_ctrl);
> + if (host->pdata->flags & TMIO_MMC_INTERNAL_DIVIDER)
> + sd_ctrl_write32(host, CTL_SD_CARD_CLK_CTL, clk_ctrl_32);
> + else
> + sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, clk_ctrl);
> +
We should hide this complexity in a function, I'd say. To make sure
future updates modifying CTL_SD_CARD_CLK_CTL will have it easy.
> +/* Some controllers have hw adjustment delay */
> +#define TMIO_MMC_HWADJ BIT(15)
I wonder how likely it is that a SDHI variant has either only this or
only TUNING_DELAY. Do you know of one? What would you think about
merging the two? You know the RZ SDHI much better...
I will stop reviewing at this patch. There are enough issues to tackle,
I'd think. Once we got this right, we can improve HS400 on top of it.
Makes sense to you?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-09-03 12:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 17:16 [PATCH v24 00/15] Add Renesas RZ/G3L SD/eMMC support Biju
2026-08-20 17:16 ` [PATCH v24 01/15] dt-bindings: mmc: renesas,sdhi: Document RZ/G3L (r9a08g046) SoC Biju
2026-09-02 10:45 ` Wolfram Sang
2026-08-20 17:16 ` [PATCH v24 02/15] mmc: renesas_sdhi: Clean up whitespace and add OF table sentinels Biju
2026-09-02 10:47 ` Wolfram Sang
2026-09-04 6:40 ` Biju Das
2026-08-20 17:16 ` [PATCH v24 03/15] mmc: renesas_sdhi: Add clk_mask field to support flexible clock divider widths Biju
2026-09-02 10:51 ` Wolfram Sang
2026-09-04 10:54 ` Biju Das
2026-09-02 10:54 ` Wolfram Sang
2026-09-04 11:03 ` Biju Das
2026-08-20 17:16 ` [PATCH v24 04/15] mmc: renesas_sdhi: Add max_divider field to support SoC-specific clock ranges Biju
2026-09-02 11:05 ` Wolfram Sang
2026-09-04 12:46 ` Biju Das
2026-08-20 17:16 ` [PATCH v24 05/15] mmc: renesas_sdhi: Add SDHI_SD_CLK_CTL_DIV1 macro for 1/1 option Biju
2026-09-02 11:06 ` Wolfram Sang
2026-08-20 17:16 ` [PATCH v24 06/15] mmc: renesas_sdhi: Make clock divider mask configurable Biju
2026-09-02 11:09 ` Wolfram Sang
2026-09-04 12:48 ` Biju Das
2026-08-20 17:16 ` [PATCH v24 07/15] mmc: renesas_sdhi: Add tuning delay support for RZ/G2L Biju
2026-09-03 9:30 ` Wolfram Sang
2026-09-04 14:47 ` Biju Das
2026-09-03 9:34 ` Wolfram Sang
2026-09-04 15:15 ` Biju Das
2026-08-20 17:16 ` [PATCH v24 08/15] mmc: renesas_sdhi: Add TMIO_MMC_INTERNAL_DIVIDER flag Biju
2026-09-03 9:37 ` Wolfram Sang
2026-09-03 9:43 ` Wolfram Sang
2026-08-20 17:16 ` [PATCH v24 09/15] mmc: renesas_sdhi: Add optional axis/axim reset controls Biju
2026-09-03 9:48 ` Wolfram Sang
2026-08-20 17:16 ` [PATCH v24 10/15] mmc: renesas_sdhi: Add write32_hook for CTL_SD_CARD_CLK_CTL register writes Biju
2026-09-03 10:30 ` Wolfram Sang
2026-09-03 10:32 ` Wolfram Sang
2026-08-20 17:16 ` [PATCH v24 11/15] mmc: renesas_sdhi: Add RZ/G3L SDHI support Biju
2026-09-03 12:01 ` Wolfram Sang [this message]
2026-08-20 17:16 ` [PATCH v24 12/15] mmc: renesas_sdhi: Save and restore IOVS across suspend/resume Biju
2026-08-20 17:16 ` [PATCH v24 13/15] mmc: renesas_sdhi: Make HS400 OSEL bit configurable per SoC Biju
2026-08-20 17:16 ` [PATCH v24 14/15] mmc: renesas_sdhi: Add RZ/G3L HS400 support Biju
2026-08-20 17:16 ` [PATCH v24 15/15] mmc: renesas_sdhi: Add HS400 enhanced strobe support for RZ/G3L Biju
2026-09-01 14:52 ` [PATCH v24 00/15] Add Renesas RZ/G3L SD/eMMC support Wolfram Sang
2026-09-03 20:11 ` Wolfram Sang
2026-09-04 2:24 ` Biju Das
2026-09-04 8:00 ` Geert Uytterhoeven
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=aplhlynkb_LUiVhS@shikoro \
--to=wsa+renesas@sang-engineering.com \
--cc=biju.das.au@gmail.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=geert+renesas@glider.be \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=ulfh@kernel.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
all inboxes | Powered by JetHome®