On Mon, Jul 20, 2026 at 7:54 PM Kathpalia, Tanmay
<[email protected]> wrote:
>
> Hi Eric,
>
> On 7/20/2026 4:14 PM, Eric Chung wrote:
> > On Mon, Jul 20, 2026 at 6:42 PM Eric Chung <[email protected]> wrote:
> >> On Mon, Jul 20, 2026 at 1:13 AM Yao Zi <[email protected]> wrote:
> >>> On Tue, Jul 07, 2026 at 11:21:44PM +0800, Eric Chung wrote:
> >>>> Enable the support for the CMD23 (SET_BLOCK_COUNT) command to
> >>>> manage multi-block read/write operations. This allows the MMC
> >>>> core to use CMD23 in preference to the legacy CMD18/CMD25 plus
> >>>> CMD12 sequence, reducing command overhead and improving I/O
> >>>> performance on multi-block transfers.
> >>>  From the description, it seems CMD23 support isn't essential for MMC
> >>> support on SpacemiT K1? If so, it might be helpful to separate MMC
> >>> core changes into another series, and focus on basic support only. A
> >>> smaller series is easier to track and review.
> >>>
> >> Actually CMD23 is necessary for Spacemit K1. So I can't split it from
> >> this series.
> >>
> > If I use ADMA mode, CMD23 is required. If I'm using PIO mode, CMD23 isn't
> > required. So I prefer it go through this series.
> >
> > If the reason isn't solid, I can split it into another patch set.
> >
> Both CMD23 and CMD12 are valid mechanisms to terminate a
> multi-block transfer: CMD23 (SET_BLOCK_COUNT) is issued before
> the transfer so the card auto-terminates, while CMD12
> (STOP_TRANSMISSION) is issued after the last block. The u-boot
> MMC core already has CMD12 support in place, so multi-block
> transfers work today without CMD23.
>
> Given that, I agree with Yao Zi's suggestion - splitting the CMD23
> changes into a separate series would make both series easier to review
> and merge.
>
> That said, Is there a specific hardware issue on the K1 board where
> CMD12 does not work correctly?

I don't think it's a hardware issue. The ADMA just depends on CMD23.

Reply via email to