On 4/17/26 12:51, Christian Speich wrote:
This patch series improves the performance of read/write/erase operations
on sdcards.
This is done by increasing the maximum buffer size that is worked on.
From 1 byte (master) to 512 bytes (commit 1-3) to larger than 512
(adma commit).
...
Christian Speich (7):
hw/sd: Switch read/write primitive to buf+len
hw/sd/sd: Allow multi-byte read/write for generic paths
hw/sd/sd: Use multi-byte/block writes for block path
hw/sd/sdhci: Don't use bounce buffer for ADMA
hw/sd/sdcard: Add erase-blocks-as-zero option.
hw/sd/sdcard: Optimize erase blocks as zero.
hw/sd: Update trace events for buf+len data
3 changes from this series landed in the master branch for v11.1.0
release:
468fa450a7e0c hw/sd: Switch read/write primitive to buf+len
eff58d3d9681a hw/sd/sd: Allow multi-byte read/write for generic paths
d7f3ab9d5a186 hw/sd: Update trace events for buf+len data
I don't see discussion about the other 4 changes, why these weren't
applied at the time, but ok.
Currently I'm picking up another change:
b5424abaf8e9a hw/sd/sdcard: Keep high-capacity memory blocks at 512 bytes
to the current stable qemu series, and it touches the same area.
But the mentioned-above 3 changes are not included in 10.0 release,
while 10.0.x is an LTS stable series. And without the first change
(switch to buf+len), things in 10.0.x are quite different.
So I can either pick the above 3 changes for 10.0.x, or I can omit
b5424abaf8e9a for 10.0.x.
To me it feels like picking up the above 3 optimization changes is the
way to go for 10.0.x.
What do you think?
BTW, doesn't b5424abaf8e9a actually fix 468fa450a7e0c, not 2d7adea4fe57?
Thanks,
/mjt
