Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yao Zi <me@ziyao.cc>
To: Michael Opdenacker <michael.opdenacker@rootcommit.com>,
	Yixun Lan <dlan@gentoo.org>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
	Binbin Zhou <zhoubinbin@loongson.cn>,
	linux-riscv@lists.infradead.org, spacemit@lists.linux.dev
Subject: Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2
Date: Tue, 16 Dec 2025 05:37:18 +0000	[thread overview]
Message-ID: <aUDwDkd8k_4gD1yc@pie> (raw)
In-Reply-To: <4acfc5d8-d8d9-4c9b-99eb-09c7b82ddd04@rootcommit.com>

On Mon, Dec 15, 2025 at 03:00:52PM +0000, Michael Opdenacker wrote:
> Hi Yao
> 
> Thanks for your helpful questions!
> 
> On 12/15/25 13:58, Yao Zi wrote:
> > On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote:
> > > The OrangePi RV2 board exposes i2c2 and i2c8 buses
> > > from the Spacemit K1 SoC.
> > > 
> > > This declares devices present on such buses, in particular
> > > the at24 eeprom to store MAC addresses and the regulators
> > > attached to the PMIC on i2c8.
> > This series is named as "Attempt to enable MMC on SpacemiT K1 boards",
> > what's the relationship between MMC and PMIC/I2C bus? You didn't make
> > use of any regulators in the second patch, either (which seems wrong to
> > me).
> 
> I expected that declaring the regulators under the PMIC on i2c8 was enough
> to enable them, but I'm happy to be corrected.

Declaring them doesn't mean enable them. Regulator subsystem maintains a
enable reference count, and when it downcounts to zero, the regulator
gets disabled.

If no driver acquires one regulator, it gets disabled after 30s since
the regulator subsystem is initialized, see regulator_init_complete()
and regulator_init_complete_work_function.

On BPI F3, SD is supplied by buck4 of the PMIC. It's marked as
regulator-always-on, so wouldn't be disabled and then cause issues for
the SD card, but this doesn't mean it's okay to omit the correct
regulator supplier of SD.

> > 
> > vmmc-supply specifies the card's power supply. And if you want to enable
> > SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary
> > for switching between 1.8v and 3.3v.
> 
> 
> I was thinking to get started without the SDR modes first, to make sure
> basic operation works first. Would that work?

Yes.

FYI, for SDR104 mode, you may need to implement some tuning logic[1] as
indicated by vendor driver,

	/*
	 * Tuning is required for SDR50/SDR104, HS200/HS400 cards and
	 * if clock frequency is greater than 100MHz in these modes.
	 */

Though in mainline the eMMC on BPI-F3 already makes use of HS400 mode
without tuning. No idea what happened here, or it just happens to work
well.

Also, the pin controller on K1 SoC seems to have some undocumented
registers to select the IO voltage of SD pins, which should be adjusted
when switching IO voltage[2].

I think these pins should be implemented in the pinctrl driver, then you
could create two pinctrl states, one for 1.8v operation, one for 3.3v,
and switch between them through pinctrl_lookup_state() when changing IO
voltage.

The last thing to mention is that the three MMC controllers on K1 aren't
same, The one used for eMMC is the only one that has a phy (both SD and
SDIO controllers are marked as SDHCI_QUIRK2_BROKEN_PHY_MODULE[3]), thus
have different reset and tuning logics.

You probably need to create new compatibles for the SD and SDIO
controllers instead of re-using spacemit,k1-sdhci, and write correct
sdhci_spacemit_reset() for controllers without phy. This is probably
necessary even if you don't implement SDR modes.

> Would you have board examples to recommend, with an MMC controller operating
> in a way similar to the one on SpacemiT K1?

All sd/emmc controllers work similarly... you may want to take a look at
mmc-controller-common.yaml for common properties.

> Thanks again
> Michael.

That's it! I've struggled for hours with the MMC driver, and these are
all strange points which I've figured out. Hope it's helpful, and feel
free to ask me if I am not clear.

Regards,
Yao Zi

[1]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/drivers/mmc/host/sdhci-of-k1x.c#L1203
[2]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/drivers/mmc/host/sdhci-of-k1x.c#L923
[3]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/arch/riscv/boot/dts/spacemit/k1-x_deb1.dts#L670

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-12-16  5:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15 10:10 [PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards Michael Opdenacker
2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker
2025-12-15 12:58   ` Yao Zi
2025-12-15 15:00     ` Michael Opdenacker
2025-12-16  5:37       ` Yao Zi [this message]
2025-12-16 21:05         ` Michael Opdenacker
2025-12-17 15:26           ` Iker Pedrosa
2025-12-17 16:27             ` Michael Opdenacker
2025-12-17 22:10               ` Johannes Erdfelt
2025-12-18  5:19                 ` Michael Opdenacker
2025-12-18  5:25                   ` Michael Opdenacker
2025-12-18  9:49                     ` Iker Pedrosa
2025-12-19 11:29                       ` Yixun Lan
2025-12-20  2:22                         ` Yao Zi
2025-12-17 20:25             ` Javier Martinez Canillas
2025-12-16  8:58   ` Javier Martinez Canillas
2025-12-24 14:00   ` Chukun Pan
2025-12-15 10:10 ` [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and " Michael Opdenacker
2025-12-15 12:46   ` Yao Zi
2025-12-15 13:58     ` Michael Opdenacker
2025-12-24 15:00   ` Chukun Pan
2025-12-29 10:14     ` Javier Martinez Canillas

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=aUDwDkd8k_4gD1yc@pie \
    --to=me@ziyao.cc \
    --cc=dan.carpenter@linaro.org \
    --cc=dlan@gentoo.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=michael.opdenacker@rootcommit.com \
    --cc=spacemit@lists.linux.dev \
    --cc=zhoubinbin@loongson.cn \
    /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