| Message ID | 20240825074141.3171549-1-avri.altman@wdc.com |
|---|---|
| Headers | show |
| Series | Add SDUC Support | expand |
On 25/08/24 10:41, Avri Altman wrote: > Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. Those > cards support capacity larger than 2TB and up to including 128TB. Thus, > the address range of the card expands beyond the 32-bit command > argument. To that end, a new command - CMD22 is defined, to carry the > extra 6-bit upper part of the 38-bit block address that enable access to > 128TB memory space. > > SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – Same > as SDXC. > > The spec defines several extensions/modifications to the current SDXC > cards, which we address in patches 1 - 10. Otherwise requirements are > out-of-scope of this change. Specifically, CMDQ (CMD44+CMD45), and > Extension for Video Speed Class (CMD20). > > First publication of SDUC was in [1]. This series was developed and > tested separately from [1] and does not borrow from it. > > [1] https://lwn.net/Articles/982566/ Perhaps add support for mmc_test, and it would be better if enabling SDUC was the last patch, so bisecting doesn't leave a kernel that half-supports SDUC. > > --- > Changes in v4: > - Squash patches 1 & 2 (Ulf) > - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf) > - Use card state instead of caps2 (Ricky & Ulf) > - Switch patches 5 & 6 (Ulf) > > Changes in v3: > - Some more kernel test robot fixes > - Fix a typo in a commit log (Ricky WU) > - Fix ACMD22 returned value > - Add 'Tested-by' tag for the whole series (Ricky WU) > > Changes in v2: > - Attend kernel test robot warnings > > --- > > Avri Altman (9): > mmc: sd: SDUC Support Recognition > mmc: sd: Add Extension memory addressing > mmc: core: Add open-ended Ext memory addressing > mmc: core: Add close-ended Ext memory addressing > mmc: host: Always use manual-cmd23 in SDUC > mmc: host: Add close-ended Ext memory addressing > mmc: core: Allow mmc erase to carry large addresses > mmc: core: Add Ext memory addressing for erase > mmc: core: Adjust ACMD22 to SDUC > > drivers/mmc/core/block.c | 56 ++++++++++++++++++++++++++++------ > drivers/mmc/core/bus.c | 4 ++- > drivers/mmc/core/card.h | 3 ++ > drivers/mmc/core/core.c | 63 ++++++++++++++++++++++++++++----------- > drivers/mmc/core/core.h | 14 +++++++-- > drivers/mmc/core/queue.h | 1 + > drivers/mmc/core/sd.c | 36 ++++++++++++++-------- > drivers/mmc/core/sd.h | 2 +- > drivers/mmc/core/sd_ops.c | 16 ++++++++++ > drivers/mmc/core/sd_ops.h | 1 + > drivers/mmc/core/sdio.c | 2 +- > drivers/mmc/host/sdhci.c | 40 +++++++++++++++++++++---- > include/linux/mmc/card.h | 2 +- > include/linux/mmc/core.h | 1 + > include/linux/mmc/sd.h | 4 +++ > 15 files changed, 195 insertions(+), 50 deletions(-) >
> > On 25/08/24 10:41, Avri Altman wrote: > > Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. Those > > cards support capacity larger than 2TB and up to including 128TB. > > Thus, the address range of the card expands beyond the 32-bit command > > argument. To that end, a new command - CMD22 is defined, to carry the > > extra 6-bit upper part of the 38-bit block address that enable access > > to 128TB memory space. > > > > SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – > > Same as SDXC. > > > > The spec defines several extensions/modifications to the current SDXC > > cards, which we address in patches 1 - 10. Otherwise requirements are > > out-of-scope of this change. Specifically, CMDQ (CMD44+CMD45), and > > Extension for Video Speed Class (CMD20). > > > > First publication of SDUC was in [1]. This series was developed and > > tested separately from [1] and does not borrow from it. > > > > [1] https://lwn.net/Articles/982566/ > > Perhaps add support for mmc_test, and it would be better if enabling SDUC > was the last patch, so bisecting doesn't leave a kernel that half-supports SDUC. Done. Thanks, Avri > > > > > --- > > Changes in v4: > > - Squash patches 1 & 2 (Ulf) > > - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf) > > - Use card state instead of caps2 (Ricky & Ulf) > > - Switch patches 5 & 6 (Ulf) > > > > Changes in v3: > > - Some more kernel test robot fixes > > - Fix a typo in a commit log (Ricky WU) > > - Fix ACMD22 returned value > > - Add 'Tested-by' tag for the whole series (Ricky WU) > > > > Changes in v2: > > - Attend kernel test robot warnings > > > > --- > > > > Avri Altman (9): > > mmc: sd: SDUC Support Recognition > > mmc: sd: Add Extension memory addressing > > mmc: core: Add open-ended Ext memory addressing > > mmc: core: Add close-ended Ext memory addressing > > mmc: host: Always use manual-cmd23 in SDUC > > mmc: host: Add close-ended Ext memory addressing > > mmc: core: Allow mmc erase to carry large addresses > > mmc: core: Add Ext memory addressing for erase > > mmc: core: Adjust ACMD22 to SDUC > > > > drivers/mmc/core/block.c | 56 ++++++++++++++++++++++++++++------ > > drivers/mmc/core/bus.c | 4 ++- > > drivers/mmc/core/card.h | 3 ++ > > drivers/mmc/core/core.c | 63 ++++++++++++++++++++++++++++--------- > -- > > drivers/mmc/core/core.h | 14 +++++++-- > > drivers/mmc/core/queue.h | 1 + > > drivers/mmc/core/sd.c | 36 ++++++++++++++-------- > > drivers/mmc/core/sd.h | 2 +- > > drivers/mmc/core/sd_ops.c | 16 ++++++++++ drivers/mmc/core/sd_ops.h > > | 1 + > > drivers/mmc/core/sdio.c | 2 +- > > drivers/mmc/host/sdhci.c | 40 +++++++++++++++++++++---- > > include/linux/mmc/card.h | 2 +- include/linux/mmc/core.h | 1 + > > include/linux/mmc/sd.h | 4 +++ > > 15 files changed, 195 insertions(+), 50 deletions(-) > >
> > + /* > > + * SD cards, specifically high volume cards, expect to be allowed with the > > + * full 500msec busy period post write. Otherwise, they may not indicate > > + * correctly the number of bytes written. > > + */ > > + if (mmc_card_ult_capacity(card)) > > + mmc_delay(500); > > To get here, it should have had to go through: > > /* Try to get back to "tran" state */ > if (!mmc_host_is_spi(mq->card->host) && > (err || !mmc_ready_for_data(status))) > err = mmc_blk_fix_state(mq->card, req); > > which would mean the card is not indicating "busy". > Either that is not working, or it seems like an issue with the card, in which case > it could be a card quirk perhaps. I was getting here on a setup with micro-to-SD adapter - I guess because of phy errors on one of the early card versions. On my other setups, the recovery flow wasn't triggered. What was happening is: mmc_blk_mq_req_done mmc_blk_mq_complete_prev_req mmc_blk_mq_poll_completion CMD13: 0: 00080900 00000000 00000000 00000000 = READY_FOR_DATA + ERROR mmc_blk_mq_rw_recovery mmc_sd_num_wr_blocks - bytes_xfered = 0 Consulting with our SD system guys, the 500msec must-have write timeout brought up, And fixed that. Shawn was interested in this as well - see the discussion in V3. Thanks, Avri
On 26/08/24 10:26, Avri Altman wrote: >>> + /* >>> + * SD cards, specifically high volume cards, expect to be allowed with the >>> + * full 500msec busy period post write. Otherwise, they may not indicate >>> + * correctly the number of bytes written. >>> + */ >>> + if (mmc_card_ult_capacity(card)) >>> + mmc_delay(500); >> >> To get here, it should have had to go through: >> >> /* Try to get back to "tran" state */ >> if (!mmc_host_is_spi(mq->card->host) && >> (err || !mmc_ready_for_data(status))) >> err = mmc_blk_fix_state(mq->card, req); >> >> which would mean the card is not indicating "busy". >> Either that is not working, or it seems like an issue with the card, in which case >> it could be a card quirk perhaps. > I was getting here on a setup with micro-to-SD adapter - I guess because of phy errors on one of the early card versions. > On my other setups, the recovery flow wasn't triggered. > What was happening is: > mmc_blk_mq_req_done > mmc_blk_mq_complete_prev_req > mmc_blk_mq_poll_completion > CMD13: 0: 00080900 00000000 00000000 00000000 = READY_FOR_DATA + ERROR > mmc_blk_mq_rw_recovery > mmc_sd_num_wr_blocks - bytes_xfered = 0 > > Consulting with our SD system guys, the 500msec must-have write timeout brought up, > And fixed that. > Shawn was interested in this as well - see the discussion in V3. The spec reads like the timeout is for card busy. If the card is not indicating busy when it is busy, then that is an issue with the card.
> On 26/08/24 10:26, Avri Altman wrote: > >>> + /* > >>> + * SD cards, specifically high volume cards, expect to be allowed with > the > >>> + * full 500msec busy period post write. Otherwise, they may not > indicate > >>> + * correctly the number of bytes written. > >>> + */ > >>> + if (mmc_card_ult_capacity(card)) > >>> + mmc_delay(500); > >> > >> To get here, it should have had to go through: > >> > >> /* Try to get back to "tran" state */ > >> if (!mmc_host_is_spi(mq->card->host) && > >> (err || !mmc_ready_for_data(status))) > >> err = mmc_blk_fix_state(mq->card, req); > >> > >> which would mean the card is not indicating "busy". > >> Either that is not working, or it seems like an issue with the card, > >> in which case it could be a card quirk perhaps. > > I was getting here on a setup with micro-to-SD adapter - I guess because of > phy errors on one of the early card versions. > > On my other setups, the recovery flow wasn't triggered. > > What was happening is: > > mmc_blk_mq_req_done > > mmc_blk_mq_complete_prev_req > > mmc_blk_mq_poll_completion > > CMD13: 0: 00080900 00000000 00000000 00000000 = > READY_FOR_DATA + ERROR > > mmc_blk_mq_rw_recovery > > mmc_sd_num_wr_blocks - bytes_xfered = 0 > > > > Consulting with our SD system guys, the 500msec must-have write > > timeout brought up, And fixed that. > > Shawn was interested in this as well - see the discussion in V3. > > The spec reads like the timeout is for card busy. If the card is not indicating > busy when it is busy, then that is an issue with the card. Will remove it. Thanks, Avri
> > On 25/08/24 10:41, Avri Altman wrote: > > > Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. > > > Those cards support capacity larger than 2TB and up to including 128TB. > > > Thus, the address range of the card expands beyond the 32-bit > > > command argument. To that end, a new command - CMD22 is defined, to > > > carry the extra 6-bit upper part of the 38-bit block address that > > > enable access to 128TB memory space. > > > > > > SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – > > > Same as SDXC. > > > > > > The spec defines several extensions/modifications to the current > > > SDXC cards, which we address in patches 1 - 10. Otherwise > > > requirements are out-of-scope of this change. Specifically, CMDQ > > > (CMD44+CMD45), and Extension for Video Speed Class (CMD20). > > > > > > First publication of SDUC was in [1]. This series was developed and > > > tested separately from [1] and does not borrow from it. > > > > > > [1] https://lwn.net/Articles/982566/ > > > > Perhaps add support for mmc_test Actually, I am not sure what should be added to mmc_test as far as SDUC indication: from dmesg we have: [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at address d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB Additionally, we have the card size sysfs entry: # cat /sys/block/mmcblk0/size 7999258624 As well as the csd which implies its capacity: # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd 800e0032db79007732bf7f800a404001 What test did you had in mind? Thanks, Avri >>, and it would be better if enabling > > SDUC was the last patch, so bisecting doesn't leave a kernel that half-supports > SDUC. > Done. > > Thanks, > Avri > > > > > > > > > --- > > > Changes in v4: > > > - Squash patches 1 & 2 (Ulf) > > > - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf) > > > - Use card state instead of caps2 (Ricky & Ulf) > > > - Switch patches 5 & 6 (Ulf) > > > > > > Changes in v3: > > > - Some more kernel test robot fixes > > > - Fix a typo in a commit log (Ricky WU) > > > - Fix ACMD22 returned value > > > - Add 'Tested-by' tag for the whole series (Ricky WU) > > > > > > Changes in v2: > > > - Attend kernel test robot warnings > > > > > > --- > > > > > > Avri Altman (9): > > > mmc: sd: SDUC Support Recognition > > > mmc: sd: Add Extension memory addressing > > > mmc: core: Add open-ended Ext memory addressing > > > mmc: core: Add close-ended Ext memory addressing > > > mmc: host: Always use manual-cmd23 in SDUC > > > mmc: host: Add close-ended Ext memory addressing > > > mmc: core: Allow mmc erase to carry large addresses > > > mmc: core: Add Ext memory addressing for erase > > > mmc: core: Adjust ACMD22 to SDUC > > > > > > drivers/mmc/core/block.c | 56 ++++++++++++++++++++++++++++------ > > > drivers/mmc/core/bus.c | 4 ++- > > > drivers/mmc/core/card.h | 3 ++ > > > drivers/mmc/core/core.c | 63 ++++++++++++++++++++++++++++--------- > > -- > > > drivers/mmc/core/core.h | 14 +++++++-- > > > drivers/mmc/core/queue.h | 1 + > > > drivers/mmc/core/sd.c | 36 ++++++++++++++-------- > > > drivers/mmc/core/sd.h | 2 +- > > > drivers/mmc/core/sd_ops.c | 16 ++++++++++ > > > drivers/mmc/core/sd_ops.h > > > | 1 + > > > drivers/mmc/core/sdio.c | 2 +- > > > drivers/mmc/host/sdhci.c | 40 +++++++++++++++++++++---- > > > include/linux/mmc/card.h | 2 +- include/linux/mmc/core.h | 1 + > > > include/linux/mmc/sd.h | 4 +++ > > > 15 files changed, 195 insertions(+), 50 deletions(-) > > >
On 27/08/24 10:45, Avri Altman wrote: >>> On 25/08/24 10:41, Avri Altman wrote: >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. >>>> Those cards support capacity larger than 2TB and up to including 128TB. >>>> Thus, the address range of the card expands beyond the 32-bit >>>> command argument. To that end, a new command - CMD22 is defined, to >>>> carry the extra 6-bit upper part of the 38-bit block address that >>>> enable access to 128TB memory space. >>>> >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – >>>> Same as SDXC. >>>> >>>> The spec defines several extensions/modifications to the current >>>> SDXC cards, which we address in patches 1 - 10. Otherwise >>>> requirements are out-of-scope of this change. Specifically, CMDQ >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20). >>>> >>>> First publication of SDUC was in [1]. This series was developed and >>>> tested separately from [1] and does not borrow from it. >>>> >>>> [1] https://lwn.net/Articles/982566/ >>> >>> Perhaps add support for mmc_test > Actually, I am not sure what should be added to mmc_test as far as SDUC indication: > from dmesg we have: > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at address d555 > [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB > > Additionally, we have the card size sysfs entry: > # cat /sys/block/mmcblk0/size > 7999258624 > > As well as the csd which implies its capacity: > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd > 800e0032db79007732bf7f800a404001 > > What test did you had in mind? Doesn't all the I/O need CMD22 first? > > Thanks, > Avri > >>> , and it would be better if enabling >>> SDUC was the last patch, so bisecting doesn't leave a kernel that half-supports >> SDUC. >> Done. >> >> Thanks, >> Avri >> >>> >>>> >>>> --- >>>> Changes in v4: >>>> - Squash patches 1 & 2 (Ulf) >>>> - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf) >>>> - Use card state instead of caps2 (Ricky & Ulf) >>>> - Switch patches 5 & 6 (Ulf) >>>> >>>> Changes in v3: >>>> - Some more kernel test robot fixes >>>> - Fix a typo in a commit log (Ricky WU) >>>> - Fix ACMD22 returned value >>>> - Add 'Tested-by' tag for the whole series (Ricky WU) >>>> >>>> Changes in v2: >>>> - Attend kernel test robot warnings >>>> >>>> --- >>>> >>>> Avri Altman (9): >>>> mmc: sd: SDUC Support Recognition >>>> mmc: sd: Add Extension memory addressing >>>> mmc: core: Add open-ended Ext memory addressing >>>> mmc: core: Add close-ended Ext memory addressing >>>> mmc: host: Always use manual-cmd23 in SDUC >>>> mmc: host: Add close-ended Ext memory addressing >>>> mmc: core: Allow mmc erase to carry large addresses >>>> mmc: core: Add Ext memory addressing for erase >>>> mmc: core: Adjust ACMD22 to SDUC >>>> >>>> drivers/mmc/core/block.c | 56 ++++++++++++++++++++++++++++------ >>>> drivers/mmc/core/bus.c | 4 ++- >>>> drivers/mmc/core/card.h | 3 ++ >>>> drivers/mmc/core/core.c | 63 ++++++++++++++++++++++++++++--------- >>> -- >>>> drivers/mmc/core/core.h | 14 +++++++-- >>>> drivers/mmc/core/queue.h | 1 + >>>> drivers/mmc/core/sd.c | 36 ++++++++++++++-------- >>>> drivers/mmc/core/sd.h | 2 +- >>>> drivers/mmc/core/sd_ops.c | 16 ++++++++++ >>>> drivers/mmc/core/sd_ops.h >>>> | 1 + >>>> drivers/mmc/core/sdio.c | 2 +- >>>> drivers/mmc/host/sdhci.c | 40 +++++++++++++++++++++---- >>>> include/linux/mmc/card.h | 2 +- include/linux/mmc/core.h | 1 + >>>> include/linux/mmc/sd.h | 4 +++ >>>> 15 files changed, 195 insertions(+), 50 deletions(-) >>>> >
> On 27/08/24 10:45, Avri Altman wrote: > >>> On 25/08/24 10:41, Avri Altman wrote: > >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. > >>>> Those cards support capacity larger than 2TB and up to including 128TB. > >>>> Thus, the address range of the card expands beyond the 32-bit > >>>> command argument. To that end, a new command - CMD22 is defined, to > >>>> carry the extra 6-bit upper part of the 38-bit block address that > >>>> enable access to 128TB memory space. > >>>> > >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – > >>>> Same as SDXC. > >>>> > >>>> The spec defines several extensions/modifications to the current > >>>> SDXC cards, which we address in patches 1 - 10. Otherwise > >>>> requirements are out-of-scope of this change. Specifically, CMDQ > >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20). > >>>> > >>>> First publication of SDUC was in [1]. This series was developed > >>>> and tested separately from [1] and does not borrow from it. > >>>> > >>>> [1] https://lwn.net/Articles/982566/ > >>> > >>> Perhaps add support for mmc_test > > Actually, I am not sure what should be added to mmc_test as far as SDUC > indication: > > from dmesg we have: > > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at address > > d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB > > > > Additionally, we have the card size sysfs entry: > > # cat /sys/block/mmcblk0/size > > 7999258624 > > > > As well as the csd which implies its capacity: > > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd > > 800e0032db79007732bf7f800a404001 > > > > What test did you had in mind? > > Doesn't all the I/O need CMD22 first? Oops - Right. Thanks a lot, Avri > > > > > Thanks, > > Avri > > > >>> , and it would be better if enabling SDUC was the last patch, so > >>> bisecting doesn't leave a kernel that half-supports > >> SDUC. > >> Done. > >> > >> Thanks, > >> Avri > >> > >>> > >>>> > >>>> --- > >>>> Changes in v4: > >>>> - Squash patches 1 & 2 (Ulf) > >>>> - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf) > >>>> - Use card state instead of caps2 (Ricky & Ulf) > >>>> - Switch patches 5 & 6 (Ulf) > >>>> > >>>> Changes in v3: > >>>> - Some more kernel test robot fixes > >>>> - Fix a typo in a commit log (Ricky WU) > >>>> - Fix ACMD22 returned value > >>>> - Add 'Tested-by' tag for the whole series (Ricky WU) > >>>> > >>>> Changes in v2: > >>>> - Attend kernel test robot warnings > >>>> > >>>> --- > >>>> > >>>> Avri Altman (9): > >>>> mmc: sd: SDUC Support Recognition > >>>> mmc: sd: Add Extension memory addressing > >>>> mmc: core: Add open-ended Ext memory addressing > >>>> mmc: core: Add close-ended Ext memory addressing > >>>> mmc: host: Always use manual-cmd23 in SDUC > >>>> mmc: host: Add close-ended Ext memory addressing > >>>> mmc: core: Allow mmc erase to carry large addresses > >>>> mmc: core: Add Ext memory addressing for erase > >>>> mmc: core: Adjust ACMD22 to SDUC > >>>> > >>>> drivers/mmc/core/block.c | 56 ++++++++++++++++++++++++++++------ > >>>> drivers/mmc/core/bus.c | 4 ++- > >>>> drivers/mmc/core/card.h | 3 ++ > >>>> drivers/mmc/core/core.c | 63 ++++++++++++++++++++++++++++--------- > >>> -- > >>>> drivers/mmc/core/core.h | 14 +++++++-- > >>>> drivers/mmc/core/queue.h | 1 + > >>>> drivers/mmc/core/sd.c | 36 ++++++++++++++-------- > >>>> drivers/mmc/core/sd.h | 2 +- > >>>> drivers/mmc/core/sd_ops.c | 16 ++++++++++ > >>>> drivers/mmc/core/sd_ops.h > >>>> | 1 + > >>>> drivers/mmc/core/sdio.c | 2 +- > >>>> drivers/mmc/host/sdhci.c | 40 +++++++++++++++++++++---- > >>>> include/linux/mmc/card.h | 2 +- include/linux/mmc/core.h | 1 + > >>>> include/linux/mmc/sd.h | 4 +++ > >>>> 15 files changed, 195 insertions(+), 50 deletions(-) > >>>> > >
> > On 27/08/24 10:45, Avri Altman wrote: > > >>> On 25/08/24 10:41, Avri Altman wrote: > > >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. > > >>>> Those cards support capacity larger than 2TB and up to including 128TB. > > >>>> Thus, the address range of the card expands beyond the 32-bit > > >>>> command argument. To that end, a new command - CMD22 is defined, > > >>>> to carry the extra 6-bit upper part of the 38-bit block address > > >>>> that enable access to 128TB memory space. > > >>>> > > >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II > > >>>> – Same as SDXC. > > >>>> > > >>>> The spec defines several extensions/modifications to the current > > >>>> SDXC cards, which we address in patches 1 - 10. Otherwise > > >>>> requirements are out-of-scope of this change. Specifically, CMDQ > > >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20). > > >>>> > > >>>> First publication of SDUC was in [1]. This series was developed > > >>>> and tested separately from [1] and does not borrow from it. > > >>>> > > >>>> [1] https://lwn.net/Articles/982566/ > > >>> > > >>> Perhaps add support for mmc_test > > > Actually, I am not sure what should be added to mmc_test as far as > > > SDUC > > indication: > > > from dmesg we have: > > > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at > > > address > > > d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB > > > > > > Additionally, we have the card size sysfs entry: > > > # cat /sys/block/mmcblk0/size > > > 7999258624 > > > > > > As well as the csd which implies its capacity: > > > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd > > > 800e0032db79007732bf7f800a404001 > > > > > > What test did you had in mind? > > > > Doesn't all the I/O need CMD22 first? So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable mmc_test for sduc. How about disable it for now, planning to ameliorate it in the very near future? Thanks, Avri > Oops - Right. > > Thanks a lot, > Avri > > > > > > > > > Thanks, > > > Avri > > > > > >>> , and it would be better if enabling SDUC was the last patch, so > > >>> bisecting doesn't leave a kernel that half-supports > > >> SDUC. > > >> Done. > > >> > > >> Thanks, > > >> Avri > > >> > > >>> > > >>>> > > >>>> --- > > >>>> Changes in v4: > > >>>> - Squash patches 1 & 2 (Ulf) > > >>>> - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf) > > >>>> - Use card state instead of caps2 (Ricky & Ulf) > > >>>> - Switch patches 5 & 6 (Ulf) > > >>>> > > >>>> Changes in v3: > > >>>> - Some more kernel test robot fixes > > >>>> - Fix a typo in a commit log (Ricky WU) > > >>>> - Fix ACMD22 returned value > > >>>> - Add 'Tested-by' tag for the whole series (Ricky WU) > > >>>> > > >>>> Changes in v2: > > >>>> - Attend kernel test robot warnings > > >>>> > > >>>> --- > > >>>> > > >>>> Avri Altman (9): > > >>>> mmc: sd: SDUC Support Recognition > > >>>> mmc: sd: Add Extension memory addressing > > >>>> mmc: core: Add open-ended Ext memory addressing > > >>>> mmc: core: Add close-ended Ext memory addressing > > >>>> mmc: host: Always use manual-cmd23 in SDUC > > >>>> mmc: host: Add close-ended Ext memory addressing > > >>>> mmc: core: Allow mmc erase to carry large addresses > > >>>> mmc: core: Add Ext memory addressing for erase > > >>>> mmc: core: Adjust ACMD22 to SDUC > > >>>> > > >>>> drivers/mmc/core/block.c | 56 ++++++++++++++++++++++++++++------ > > >>>> drivers/mmc/core/bus.c | 4 ++- > > >>>> drivers/mmc/core/card.h | 3 ++ > > >>>> drivers/mmc/core/core.c | 63 ++++++++++++++++++++++++++++-------- > - > > >>> -- > > >>>> drivers/mmc/core/core.h | 14 +++++++-- > > >>>> drivers/mmc/core/queue.h | 1 + > > >>>> drivers/mmc/core/sd.c | 36 ++++++++++++++-------- > > >>>> drivers/mmc/core/sd.h | 2 +- > > >>>> drivers/mmc/core/sd_ops.c | 16 ++++++++++ > > >>>> drivers/mmc/core/sd_ops.h > > >>>> | 1 + > > >>>> drivers/mmc/core/sdio.c | 2 +- > > >>>> drivers/mmc/host/sdhci.c | 40 +++++++++++++++++++++---- > > >>>> include/linux/mmc/card.h | 2 +- include/linux/mmc/core.h | 1 + > > >>>> include/linux/mmc/sd.h | 4 +++ > > >>>> 15 files changed, 195 insertions(+), 50 deletions(-) > > >>>> > > >
On 27/08/24 13:58, Avri Altman wrote: >>> On 27/08/24 10:45, Avri Altman wrote: >>>>>> On 25/08/24 10:41, Avri Altman wrote: >>>>>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. >>>>>>> Those cards support capacity larger than 2TB and up to including 128TB. >>>>>>> Thus, the address range of the card expands beyond the 32-bit >>>>>>> command argument. To that end, a new command - CMD22 is defined, >>>>>>> to carry the extra 6-bit upper part of the 38-bit block address >>>>>>> that enable access to 128TB memory space. >>>>>>> >>>>>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II >>>>>>> – Same as SDXC. >>>>>>> >>>>>>> The spec defines several extensions/modifications to the current >>>>>>> SDXC cards, which we address in patches 1 - 10. Otherwise >>>>>>> requirements are out-of-scope of this change. Specifically, CMDQ >>>>>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20). >>>>>>> >>>>>>> First publication of SDUC was in [1]. This series was developed >>>>>>> and tested separately from [1] and does not borrow from it. >>>>>>> >>>>>>> [1] https://lwn.net/Articles/982566/ >>>>>> >>>>>> Perhaps add support for mmc_test >>>> Actually, I am not sure what should be added to mmc_test as far as >>>> SDUC >>> indication: >>>> from dmesg we have: >>>> [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at >>>> address >>>> d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB >>>> >>>> Additionally, we have the card size sysfs entry: >>>> # cat /sys/block/mmcblk0/size >>>> 7999258624 >>>> >>>> As well as the csd which implies its capacity: >>>> # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd >>>> 800e0032db79007732bf7f800a404001 >>>> >>>> What test did you had in mind? >>> >>> Doesn't all the I/O need CMD22 first? > So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable mmc_test for sduc. > How about disable it for now, planning to ameliorate it in the very near future? Ok by me.
On Tue, 27 Aug 2024 at 12:58, Avri Altman <Avri.Altman@wdc.com> wrote: > > > > On 27/08/24 10:45, Avri Altman wrote: > > > >>> On 25/08/24 10:41, Avri Altman wrote: > > > >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. > > > >>>> Those cards support capacity larger than 2TB and up to including 128TB. > > > >>>> Thus, the address range of the card expands beyond the 32-bit > > > >>>> command argument. To that end, a new command - CMD22 is defined, > > > >>>> to carry the extra 6-bit upper part of the 38-bit block address > > > >>>> that enable access to 128TB memory space. > > > >>>> > > > >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II > > > >>>> – Same as SDXC. > > > >>>> > > > >>>> The spec defines several extensions/modifications to the current > > > >>>> SDXC cards, which we address in patches 1 - 10. Otherwise > > > >>>> requirements are out-of-scope of this change. Specifically, CMDQ > > > >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20). > > > >>>> > > > >>>> First publication of SDUC was in [1]. This series was developed > > > >>>> and tested separately from [1] and does not borrow from it. > > > >>>> > > > >>>> [1] https://lwn.net/Articles/982566/ > > > >>> > > > >>> Perhaps add support for mmc_test > > > > Actually, I am not sure what should be added to mmc_test as far as > > > > SDUC > > > indication: > > > > from dmesg we have: > > > > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at > > > > address > > > > d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB > > > > > > > > Additionally, we have the card size sysfs entry: > > > > # cat /sys/block/mmcblk0/size > > > > 7999258624 > > > > > > > > As well as the csd which implies its capacity: > > > > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd > > > > 800e0032db79007732bf7f800a404001 > > > > > > > > What test did you had in mind? > > > > > > Doesn't all the I/O need CMD22 first? > So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable mmc_test for sduc. > How about disable it for now, planning to ameliorate it in the very near future? Don't get me wrong, I am fine by this too, as Adrian. However, the purpose of adding support for SDUC to mmc_test would also be to help us test while developing the new code too. [...] Kind regards Uffe
> > > > > What test did you had in mind? > > > > > > > > Doesn't all the I/O need CMD22 first? > > So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable > mmc_test for sduc. > > How about disable it for now, planning to ameliorate it in the very near future? > > Don't get me wrong, I am fine by this too, as Adrian. > > However, the purpose of adding support for SDUC to mmc_test would also be to > help us test while developing the new code too. Thanks. Its on my very next to-do list. Right after properly documenting mmc_test. Thanks, Avri > > [...] > > Kind regards > Uffe