diff options
| author | Patrick Wildt <patrick@cvs.openbsd.org> | 2024-08-06 15:03:37 +0000 |
|---|---|---|
| committer | Patrick Wildt <patrick@cvs.openbsd.org> | 2024-08-06 15:03:37 +0000 |
| commit | 56aab025d4bc0d4ea3bcedd4817ec22df6a4a14c (patch) | |
| tree | 8250fa2544ed1cd151ff255a8a5dc3c3a83944e4 /sys/dev/sdmmc | |
| parent | f2ccebed1730f06a44dde31bfca337451402a7fc (diff) | |
On the RK3588 eMMC controller it appears that after a failed command a
completion signal shows up some time after the error signal. This can
lead to the case that when the next command is being executed, the old
completion signal is still recorded and the driver may think the command
already executed. Resetting the status before executing a new command
makes sense, albeit it's technically still possible that the controller
issues another completion signal. It shouldn't happen because a reset
was issued and we're also waiting for the command and data inhibit bits
to be cleared, but who knows. This makes the eMMC come up reliably.
ok kettenis@
Diffstat (limited to 'sys/dev/sdmmc')
| -rw-r--r-- | sys/dev/sdmmc/sdhc.c | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/sys/dev/sdmmc/sdhc.c b/sys/dev/sdmmc/sdhc.c index eb0a8e5374b..badd60d9fba 100644 --- a/sys/dev/sdmmc/sdhc.c +++ b/sys/dev/sdmmc/sdhc.c @@ -1,4 +1,4 @@ -/* $OpenBSD: sdhc.c,v 1.76 2023/10/01 08:56:24 kettenis Exp $ */ +/* $OpenBSD: sdhc.c,v 1.77 2024/08/06 15:03:36 patrick Exp $ */ /* * Copyright (c) 2006 Uwe Stuehler <uwe@openbsd.org> @@ -1057,6 +1057,9 @@ sdhc_start_command(struct sdhc_host *hp, struct sdmmc_command *cmd) DPRINTF(1,("%s: cmd=%#x mode=%#x blksize=%d blkcount=%d\n", DEVNAME(hp->sc), command, mode, blksize, blkcount)); + /* We're starting a new command, reset state. */ + hp->intr_status = 0; + /* * Start a CPU data transfer. Writing to the high order byte * of the SDHC_COMMAND register triggers the SD command. (1.5) |