mmc: support BKOPS feature for eMMC
PATCH 1/1 mmc: support BKOPS feature for eMMC
Background operation(BKOPS) is one of eMMC's features.
If set the URGENT_BKOPS in response, we can notify that card nedd the BKOPS. And all I/O request is done, then run background operation.
If request read/write operation during BKOPS, issue HPI interrupt.
If you want to use this feature, should be set MMC_CAP2_BKOPS.
--- drivers/mmc/card/block.c | 13 +++++++- drivers/mmc/card/queue.c | 1 + drivers/mmc/core/core.c | 77 ++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/core/mmc.c | 21 ++++++++++++ drivers/mmc/core/mmc_ops.c | 4 ++ include/linux/mmc/card.h | 11 ++++++ include/linux/mmc/core.h | 2 + include/linux/mmc/host.h | 1 + include/linux/mmc/mmc.h | 4 ++ 9 files changed, 133 insertions(+), 1 deletions(-)
drivers/mmc/card/block.c +12 -1
@@ -1185,14 +1185,25 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) type =rq_data_dir (req) ==READ ?MMC_BLK_READ :MMC_BLK_WRITE ;mmc_queue_bounce_post (mq_rq); +if (mmc_card_doing_bkops (card)) { +if (mmc_interrupt_bkops (card)) + goto cmd_abort; + } +switch (status) {case MMC_BLK_SUCCESS :case MMC_BLK_PARTIAL : +spin_lock_irq (&md->lock); +/* +* Check BKOPS urgency from each R1 response +*/ +if (mmc_card_mmc (card) && + (brq->cmd.resp[0 ] &R1_URGENT_BKOPS )) +mmc_card_set_need_bkops (card);/* * A block was successfully transferred. */ mmc_blk_reset_success (md, type); -spin_lock_irq (&md->lock); ret =__blk_end_request (req,0 , brq->data.bytes_xfered);spin_unlock_irq (&md->lock);
drivers/mmc/card/queue.c +1 -0
@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d)set_current_state (TASK_RUNNING );break ; } +mmc_start_bkops (mq->card);up (&mq->thread_sem);schedule ();down (&mq->thread_sem);
drivers/mmc/core/core.c +77 -0
89 lines not on this page · raw message
drivers/mmc/core/mmc.c +21 -0
@@ -448,6 +448,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) }if (card->ext_csd.rev >=5 ) { +/* check whether the eMMC card support BKOPS */ +if (ext_csd[EXT_CSD_BKOPS_SUPPORT ] &0x1 ) + card->ext_csd.bkops =1 ; +/* check whether the eMMC card supports HPI */ if (ext_csd[EXT_CSD_HPI_FEATURES ] &0x1 ) { card->ext_csd.hpi =1 ;
@@ -909,6 +913,23 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, }/* +* enable BKOPS feature (if supported) +*/ +if (card->ext_csd.bkops) { + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_EN ,1 ,0 ); +if (err && err != -EBADMSG ) + goto free_card; + +if (err) { +pr_warning ("%s: Enabling BKOPS failed\n" , +mmc_hostname (card->host)); + err =0 ; + }else + card->ext_csd.bkops_en =1 ; + } + +/* * Enable HPI feature (if supported) */ if (card->ext_csd.hpi) {
drivers/mmc/core/mmc_ops.c +4 -0
@@ -398,6 +398,10 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,if (err)return err; +/* No need to check card status in case of BKOPS switch*/ +if (index ==EXT_CSD_BKOPS_START ) +return 0 ; +/* Must check status to be sure of no errors */ do { err = mmc_send_status(card, &status);
include/linux/mmc/card.h +11 -0
@@ -71,6 +71,8 @@ struct mmc_ext_csd {bool hpi_en;/* HPI enablebit */ bool hpi;/* HPI support bit */ unsigned int hpi_cmd;/* cmd used as HPI */ +bool bkops;/* background support bit */ +bool bkops_en;/* background enable bit */ u8 raw_partition_support;/* 160 */ u8 raw_erased_mem_count;/* 181 */ u8 raw_ext_csd_structure;/* 194 */
@@ -206,6 +208,8 @@ struct mmc_card {#define MMC_STATE_HIGHSPEED_DDR (1<<4)/* card is in high speed mode */ #define MMC_STATE_ULTRAHIGHSPEED (1<<5)/* card is in ultra high speed mode */ #define MMC_CARD_SDXC (1<<6)/* card is SDXC */ +#define MMC_STATE_NEED_BKOPS (1<<7)/* card need to do BKOPS */ +#define MMC_STATE_DOING_BKOPS (1<<8)/* card is doing BKOPS */ unsigned int quirks;/* card quirks */ #define MMC_QUIRK_LENIENT_FN0 (1<<0)/* allow SDIO FN0 writes outside of the VS CCCR range */ #define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (1<<1)/* use func->cur_blksize */
@@ -365,6 +369,8 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)#define mmc_card_ddr_mode (c) ((c)->state & MMC_STATE_HIGHSPEED_DDR)#define mmc_sd_card_uhs (c) ((c)->state & MMC_STATE_ULTRAHIGHSPEED)#define mmc_card_ext_capacity (c) ((c)->state & MMC_CARD_SDXC) +#define mmc_card_need_bkops (c) ((c)->state & MMC_STATE_NEED_BKOPS) +#define mmc_card_doing_bkops (c) ((c)->state & MMC_STATE_DOING_BKOPS)#define mmc_card_set_present (c) ((c)->state |= MMC_STATE_PRESENT)#define mmc_card_set_readonly (c) ((c)->state |= MMC_STATE_READONLY)
@@ -373,6 +379,11 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)#define mmc_card_set_ddr_mode (c) ((c)->state |= MMC_STATE_HIGHSPEED_DDR)#define mmc_sd_card_set_uhs (c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED)#define mmc_card_set_ext_capacity (c) ((c)->state |= MMC_CARD_SDXC) +#define mmc_card_set_need_bkops (c) ((c)->state |= MMC_STATE_NEED_BKOPS) +#define mmc_card_set_doing_bkops (c) ((c)->state |= MMC_STATE_DOING_BKOPS) + +#define mmc_card_clr_need_bkops (c) ((c)->state &= ~MMC_STATE_NEED_BKOPS) +#define mmc_card_clr_doing_bkops (c) ((c)->state &= ~MMC_STATE_DOING_BKOPS)/* * Quirk add/remove for MMC products.
include/linux/mmc/core.h +2 -0
@@ -134,6 +134,7 @@ struct mmc_host;struct mmc_card ;struct mmc_async_req ; +extern int mmc_interrupt_bkops (struct mmc_card *);extern struct mmc_async_req *mmc_start_req (struct mmc_host *,struct mmc_async_req *,int *);extern int mmc_interrupt_hpi (struct mmc_card *);
@@ -163,6 +164,7 @@ extern int mmc_can_sanitize(struct mmc_card *card);extern int mmc_can_secure_erase_trim (struct mmc_card *card);extern int mmc_erase_group_aligned (struct mmc_card *card,unsigned int from,unsigned int nr); +extern void mmc_start_bkops (struct mmc_card *card);extern unsigned int mmc_calc_max_discard (struct mmc_card *card);extern int mmc_set_blocklen (struct mmc_card *card,unsigned int blocklen);
include/linux/mmc/host.h +1 -0
@@ -242,6 +242,7 @@ struct mmc_host {#define MMC_CAP2_CACHE_CTRL (1 << 1)/* Allow cache control */ #define MMC_CAP2_POWEROFF_NOTIFY (1 << 2)/* Notify poweroff supported */ #define MMC_CAP2_NO_MULTI_READ (1 << 3)/* Multiblock reads don't work */ +#define MMC_CAP2_BKOPS (1 << 4)/* BKOPS supported */ mmc_pm_flag_t pm_caps;/* supported pm features */ unsigned int power_notify_type;
include/linux/mmc/mmc.h +4 -0
@@ -138,6 +138,7 @@ static inline bool mmc_op_multi(u32 opcode)#define R1_CURRENT_STATE (x) ((x & 0x00001E00) >> 9)/* sx, b (4 bits) */ #define R1_READY_FOR_DATA (1 << 8)/* sx, a */ #define R1_SWITCH_ERROR (1 << 7)/* sx, c */ +#define R1_URGENT_BKOPS (1 << 6)/* sx, a */ #define R1_APP_CMD (1 << 5)/* sr, c */ #define R1_STATE_IDLE 0
@@ -278,6 +279,8 @@ struct _mmc_csd {#define EXT_CSD_PARTITION_SUPPORT 160/* RO */ #define EXT_CSD_HPI_MGMT 161/* R/W */ #define EXT_CSD_RST_N_FUNCTION 162/* R/W */ +#define EXT_CSD_BKOPS_EN 163/* R/W */ +#define EXT_CSD_BKOPS_START 164/* W */ #define EXT_CSD_SANITIZE_START 165/* W */ #define EXT_CSD_WR_REL_PARAM 166/* RO */ #define EXT_CSD_ERASE_GROUP_DEF 175/* R/W */
@@ -313,6 +316,7 @@ struct _mmc_csd {#define EXT_CSD_POWER_OFF_LONG_TIME 247/* RO */ #define EXT_CSD_GENERIC_CMD6_TIME 248/* RO */ #define EXT_CSD_CACHE_SIZE 249/* RO, 4 bytes */ +#define EXT_CSD_BKOPS_SUPPORT 502/* RO */ #define EXT_CSD_HPI_FEATURES 503/* RO */ /*
Quoted 71 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jaehoon Chung
Sent: Thursday, October 27, 2011 7:10 PM
To: linux-mmc
Cc: Chris Ball; Kyungmin Park; Hanumath Prasad
Subject: [PATCH] mmc: support BKOPS feature for eMMCBackground operation(BKOPS) is one of eMMC's features.
If set the
URGENT_BKOPSin response, we can notify that card nedd the BKOPS. And all I/O request is done, then run background operation.
If request read/write operation during BKOPS, issue HPI interrupt.If you want to use this feature, should be set
MMC_CAP2_BKOPS.Signed-off-by Jaehoon Chung <[email protected]>Signed-off-by Kyungmin Park <[email protected]>CC Hanumath Prasad <[email protected]>--- drivers/mmc/card/block.c | 13 +++++++- drivers/mmc/card/queue.c | 1 + drivers/mmc/core/core.c | 77 ++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/core/mmc.c | 21 ++++++++++++ drivers/mmc/core/mmc_ops.c | 4 ++ include/linux/mmc/card.h | 11 ++++++ include/linux/mmc/core.h | 2 + include/linux/mmc/host.h | 1 + include/linux/mmc/mmc.h | 4 ++ 9 files changed, 133 insertions(+), 1 deletions(-)drivers/mmc/card/block.c +12
-1@@ -1185,14 +1185,25 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) type =rq_data_dir (req) ==READ ?MMC_BLK_READ :MMC_BLK_WRITE ;mmc_queue_bounce_post (mq_rq); +if (mmc_card_doing_bkops (card)) { +if (mmc_interrupt_bkops (card)) + goto cmd_abort; + } +switch (status) {case MMC_BLK_SUCCESS :case MMC_BLK_PARTIAL : +spin_lock_irq (&md->lock); +/* +* Check BKOPS urgency from each R1 response +*/ +if (mmc_card_mmc (card) && + (brq->cmd.resp[0 ] &R1_URGENT_BKOPS )) +mmc_card_set_need_bkops (card);/* * A block was successfully transferred. */ mmc_blk_reset_success (md, type); -spin_lock_irq (&md->lock); ret =__blk_end_request (req,0 , brq->data.bytes_xfered);drivers/mmc/card/block.c +0
-0spin_unlock_irq (&md->lock);drivers/mmc/card/queue.c +0
-0
drivers/mmc/card/queue.c static int mmc_queue_thread(void *d) · line 74
Quoted 7 lines
drivers/mmc/card/queue.c +1
-0@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d)set_current_state (TASK_RUNNING );break ; } +mmc_start_bkops (mq->card);up (&mq->thread_sem);schedule ();down (&mq->thread_sem);
Maybe put mmc_interrupt_bkops(card) here is better, I think.
Quoted 69 lines
drivers/mmc/core/core.c +44
-0@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) host->ops->request(host, mrq); } +/** +* mmc_start_bkops - start BKOPS for supported cards +* @card: MMC card to start BKOPS +* +* Start background operations whenever requested. +* when the urgent BKOPS bit is set in a R1 command response +* then background operations should be started immediately. +*/ +void mmc_start_bkops (struct mmc_card *card) +{ +int err; +unsigned long flags; + +if ((!card || !card->ext_csd.bkops_en) && + !(card->host->caps2 &MMC_CAP2_BKOPS )) +return ; + +/* +* If card is already doing bkops or need for +* bkops flag is not set, then do nothing just +* return +*/ +if (mmc_card_doing_bkops (card) + || !mmc_card_need_bkops (card)) +return ; + +mmc_claim_host (card->host); + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_START ,1 ,0 ); +if (err) { +pr_warning ("error %d starting bkops\n" , err); +mmc_card_clr_need_bkops (card); + goto out; + } +spin_lock_irqsave (&card->host->lock, flags); +mmc_card_clr_need_bkops (card); +mmc_card_set_doing_bkops (card); +spin_unlock_irqrestore (&card->host->lock, flags); +out: +mmc_release_host (card->host); +} +EXPORT_SYMBOL (mmc_start_bkops); + +static void mmc_wait_done (struct mmc_request *mrq) {drivers/mmc/core/core.c +0
-0complete (&mrq->completion);@@ -466,6 +510,39 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct
mmc_command*cmd, int retries
EXPORT_SYMBOL(mmc_wait_for_cmd);/**
+ *mmc_interrupt_bkops- interrupt ongoing BKOPS
+ * @card: MMC card to check BKOPS
+ *
+ * Send HPI command to interrupt ongoing background operations,
+ * to allow rapid servicing of foreground operations,e.g. read/
+ * writes. Wait until the card comes out of the programming state
+ * to avoid errors in servicing read/write requests.
+ */
drivers/mmc/core/core.c int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retries · line 530
Quoted 10 lines
drivers/mmc/core/core.c +10
-0+int mmc_interrupt_bkops (struct mmc_card *card) +{ +int err; +unsigned long flags; +u32 status; + +BUG_ON (!card); + +/* send HPI to interrupt BKOPS. */ + err =mmc_send_hpi_cmd (card, &status);
What will be happened if eMMC card only support BKOPS but not support HPI?
Quoted 43 lines
drivers/mmc/core/core.c +15
-0+if (err ||R1_CURRENT_STATE (status) ==7 ) { +do { + err =mmc_send_status (card, &status); +if (err) +return err; + }while (R1_CURRENT_STATE (status) ==7 ); + } +spin_lock_irqsave (&card->host->lock, flags); +mmc_card_clr_doing_bkops (card); +spin_unlock_irqrestore (&card->host->lock, flags); +return 0 ; +} +EXPORT_SYMBOL (mmc_interrupt_bkops); + +/** * mmc_set_data_timeout - set the timeout for a data command * @data: data phase for command * @card: the MMC card associated with the data transfer drivers/mmc/core/mmc.c +4
-0@@ -448,6 +448,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) }if (card->ext_csd.rev >=5 ) { +/* check whether the eMMC card support BKOPS */ +if (ext_csd[EXT_CSD_BKOPS_SUPPORT ] &0x1 ) + card->ext_csd.bkops =1 ; +/* check whether the eMMC card supports HPI */ if (ext_csd[EXT_CSD_HPI_FEATURES ] &0x1 ) {drivers/mmc/core/mmc.c +5
-0card->ext_csd.hpi =1 ;@@ -909,6 +913,23 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, }/* +* enable BKOPS feature (if supported) +*/ +if (card->ext_csd.bkops) { + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_EN ,1 ,0 );
drivers/mmc/core/mmc.c static int mmc_init_card(struct mmc_host *host, u32 ocr, · line 930
Quoted 10 lines
drivers/mmc/core/mmc.c +10
-0+if (err && err != -EBADMSG ) + goto free_card; + +if (err) { +pr_warning ("%s: Enabling BKOPS failed\n" , +mmc_hostname (card->host)); + err =0 ; + }else + card->ext_csd.bkops_en =1 ; + }
Just found this bit is one time programmable, so that is to say this bit is not suitable for driver to change.
Quoted 141 lines
drivers/mmc/core/mmc.c +2
-0+ +/* * Enable HPI feature (if supported) */ if (card->ext_csd.hpi) {drivers/mmc/core/mmc_ops.c +4
-0@@ -398,6 +398,10 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, if (err) return err; +/* No need to check card status in case of BKOPS switch*/ +if (index ==EXT_CSD_BKOPS_START ) +return 0 ; +/* Must check status to be sure of no errors */ do {drivers/mmc/core/mmc_ops.c +0
-0err =mmc_send_status (card, &status);include/linux/mmc/card.h +2
-0@@ -71,6 +71,8 @@ struct mmc_ext_csd {bool hpi_en;/* HPI enablebit */ bool hpi;/* HPI support bit */ unsigned int hpi_cmd;/* cmd used as HPI */ +bool bkops;/* background support bit */ +bool bkops_en;/* background enable bit */ u8 raw_partition_support;/* 160 */ u8 raw_erased_mem_count;/* 181 */ u8 raw_ext_csd_structure;/* 194 */ @@ -206,6 +208,8 @@ struct mmc_card {#define MMC_STATE_HIGHSPEED_DDR (1<<4)/* card is in high speed mode */ #define MMC_STATE_ULTRAHIGHSPEED (1<<5)/* card is in ultra high speed mode */
#defineMMC_CARD_SDXC(1<<6) /* card is SDXC */include/linux/mmc/card.h +2
-0+#define MMC_STATE_NEED_BKOPS (1<<7)/* card need to do BKOPS */ +#define MMC_STATE_DOING_BKOPS (1<<8)/* card is doing BKOPS */ unsigned int quirks;/* card quirks */ #define MMC_QUIRK_LENIENT_FN0 (1<<0)/* allow SDIO FN0 writes outside of the VS CCCR range */
#defineMMC_QUIRK_BLKSZ_FOR_BYTE_MODE(1<<1) /* usefunc->cur_blksize
*/include/linux/mmc/card.h +2
-0@@ -365,6 +369,8 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data) #define mmc_card_ddr_mode(c) ((c)->state & MMC_STATE_HIGHSPEED_DDR) #define mmc_sd_card_uhs(c) ((c)->state & MMC_STATE_ULTRAHIGHSPEED) #define mmc_card_ext_capacity(c) ((c)->state & MMC_CARD_SDXC) +#define mmc_card_need_bkops(c) ((c)->state & MMC_STATE_NEED_BKOPS) +#define mmc_card_doing_bkops(c) ((c)->state & MMC_STATE_DOING_BKOPS) #define mmc_card_set_present(c) ((c)->state |= MMC_STATE_PRESENT)#define
mmc_card_set_readonly(c)((c)->state |=MMC_STATE_READONLY)include/linux/mmc/card.h +2
-0@@ -373,6 +379,11 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data) #define mmc_card_set_ddr_mode(c) ((c)->state |= MMC_STATE_HIGHSPEED_DDR) #define mmc_sd_card_set_uhs(c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED) #define mmc_card_set_ext_capacity(c) ((c)->state |= MMC_CARD_SDXC) +#define mmc_card_set_need_bkops(c) ((c)->state |= MMC_STATE_NEED_BKOPS) +#define mmc_card_set_doing_bkops(c) ((c)->state |=
MMC_STATE_DOING_BKOPS)include/linux/mmc/card.h +3
-0+ +#define mmc_card_clr_need_bkops (c) ((c)->state &= ~MMC_STATE_NEED_BKOPS) +#define mmc_card_clr_doing_bkops (c) ((c)->state &=~MMC_STATE_DOING_BKOPS)
/*
* Quirk add/remove for MMC products.include/linux/mmc/core.h +2
-0@@ -134,6 +134,7 @@ struct mmc_host;struct mmc_card ;struct mmc_async_req ; +extern int mmc_interrupt_bkops (struct mmc_card *);extern struct mmc_async_req *mmc_start_req (struct mmc_host *,struct mmc_async_req *,int *);extern int mmc_interrupt_hpi (struct mmc_card *);@@ -163,6 +164,7 @@ extern int mmc_can_sanitize(struct mmc_card *card);extern int mmc_can_secure_erase_trim (struct mmc_card *card);extern int mmc_erase_group_aligned (struct mmc_card *card,unsigned int from,unsigned int nr); +extern void mmc_start_bkops (struct mmc_card *card);extern unsigned int mmc_calc_max_discard (struct mmc_card *card);extern int mmc_set_blocklen (struct mmc_card *card,unsigned int blocklen);include/linux/mmc/host.h +0
-0@@ -242,6 +242,7 @@ struct mmc_host {#define MMC_CAP2_CACHE_CTRL (1 << 1)/* Allow cache control */ #define MMC_CAP2_POWEROFF_NOTIFY (1 << 2)/* Notify poweroff supported */ #define MMC_CAP2_NO_MULTI_READ (1 << 3)/* Multiblock reads don't work */
include/linux/mmc/host.h +1
-0+#define MMC_CAP2_BKOPS (1 << 4)/* BKOPS supported */ mmc_pm_flag_t pm_caps;/* supported pm features */ unsigned int power_notify_type;include/linux/mmc/mmc.h +4
-1@@ -138,6 +138,7 @@ static inline bool mmc_op_multi(u32 opcode)#define R1_CURRENT_STATE (x) ((x & 0x00001E00) >> 9)/* sx, b (4 bits) */ #define R1_READY_FOR_DATA (1 << 8)/* sx, a */ #define R1_SWITCH_ERROR (1 << 7)/* sx, c */ +#define R1_URGENT_BKOPS (1 << 6)/* sx, a */ #define R1_APP_CMD (1 << 5)/* sr, c */ #define R1_STATE_IDLE 0@@ -278,6 +279,8 @@ struct _mmc_csd {#define EXT_CSD_PARTITION_SUPPORT 160/* RO */ #define EXT_CSD_HPI_MGMT 161/* R/W */ #define EXT_CSD_RST_N_FUNCTION 162/* R/W */ +#define EXT_CSD_BKOPS_EN 163/* R/W */ +#define EXT_CSD_BKOPS_START 164/* W */ #define EXT_CSD_SANITIZE_START 165/* W */ #define EXT_CSD_WR_REL_PARAM 166/* RO */ #define EXT_CSD_ERASE_GROUP_DEF 175/* R/W */ @@ -313,6 +316,7 @@ struct _mmc_csd {#define EXT_CSD_POWER_OFF_LONG_TIME 247/* RO */ #define EXT_CSD_GENERIC_CMD6_TIME 248/* RO */ #define EXT_CSD_CACHE_SIZE 249/* RO, 4 bytes */ +#define EXT_CSD_BKOPS_SUPPORT 502/* RO */ #define EXT_CSD_HPI_FEATURES 503/* RO */ /* -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 152 lines · Chuanxiao
Quoted 71 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jaehoon Chung
Sent: Thursday, October 27, 2011 7:10 PM
To: linux-mmc
Cc: Chris Ball; Kyungmin Park; Hanumath Prasad
Subject: [PATCH] mmc: support BKOPS feature for eMMCBackground operation(BKOPS) is one of eMMC's features.
If set the
URGENT_BKOPSin response, we can notify that card nedd the BKOPS. And all I/O request is done, then run background operation.
If request read/write operation during BKOPS, issue HPI interrupt.If you want to use this feature, should be set
MMC_CAP2_BKOPS.Signed-off-by Jaehoon Chung <[email protected]>Signed-off-by Kyungmin Park <[email protected]>CC Hanumath Prasad <[email protected]>---
drivers/mmc/card/block.c | 13 +++++++-
drivers/mmc/card/queue.c | 1 +
drivers/mmc/core/core.c | 77
++++++++++++++++++++++++++++++++++++++++++++
drivers/mmc/core/mmc.c | 21 ++++++++++++
drivers/mmc/core/mmc_ops.c | 4 ++include/linux/mmc/card.h | 11 ++++++ include/linux/mmc/core.h | 2 + include/linux/mmc/host.h | 1 + include/linux/mmc/mmc.h | 4 ++ 9 files changed, 133 insertions(+), 1 deletions(-)drivers/mmc/card/block.c +5
-0@@ -1185,14 +1185,25 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) type = rq_data_dir(req) == READ ? MMC_BLK_READ : MMC_BLK_WRITE; mmc_queue_bounce_post(mq_rq); + if (mmc_card_doing_bkops(card)) { + if (mmc_interrupt_bkops(card)) + goto cmd_abort; + } + switch (status) {case
MMC_BLK_SUCCESS:
caseMMC_BLK_PARTIAL:
+spin_lock_irq(&md->lock);
+ /*
+ * Check BKOPS urgency from each R1 response
+ */
+ if (mmc_card_mmc(card)&&
+ (brq->cmd.resp[0] &R1_URGENT_BKOPS))
+mmc_card_set_need_bkops(card); /*
* A block was successfully transferred. */
mmc_blk_reset_success(md, type);
-spin_lock_irq(&md->lock);
ret =__blk_end_request(req, 0, brq->data.bytes_xfered);spin_unlock_irq(&md->lock);drivers/mmc/card/queue.c +0
-0drivers/mmc/card/queue.c static int mmc_queue_thread(void *d) · line 74
Quoted 7 lines
drivers/mmc/card/queue.c +1
-0@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d) set_current_state(TASK_RUNNING); break; } + mmc_start_bkops(mq->card); up(&mq->thread_sem); schedule(); down(&mq->thread_sem);Maybe put
mmc_interrupt_bkops(card)here is better, I think.Quoted 72 lines
drivers/mmc/core/core.c +44
-0@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) host->ops->request(host, mrq); } +/** +* mmc_start_bkops - start BKOPS for supported cards +* @card: MMC card to start BKOPS +* +* Start background operations whenever requested. +* when the urgent BKOPS bit is set in a R1 command response +* then background operations should be started immediately. +*/ +void mmc_start_bkops (struct mmc_card *card) +{ + int err; + unsigned long flags; + + if ((!card || !card->ext_csd.bkops_en) && + !(card->host->caps2 & MMC_CAP2_BKOPS)) + return; + + /* + * If card is already doing bkops or need for + * bkops flag is not set, then do nothing just + * return + */ + if (mmc_card_doing_bkops(card) + || !mmc_card_need_bkops(card)) + return; + + mmc_claim_host(card->host); + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, + EXT_CSD_BKOPS_START, 1, 0); + if (err) { + pr_warning("error %d starting bkops\n", err); + mmc_card_clr_need_bkops(card); + goto out; + } + spin_lock_irqsave(&card->host->lock, flags); + mmc_card_clr_need_bkops(card); + mmc_card_set_doing_bkops(card); + spin_unlock_irqrestore(&card->host->lock, flags); +out: + mmc_release_host(card->host); +} +EXPORT_SYMBOL (mmc_start_bkops); + + static void mmc_wait_done(struct mmc_request *mrq) {
complete(&mrq->completion);drivers/mmc/core/core.c +0
-0@@ -466,6 +510,39 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct
mmc_command*cmd, int retries
EXPORT_SYMBOL(mmc_wait_for_cmd);/**
+ *mmc_interrupt_bkops- interrupt ongoing BKOPS
+ * @card: MMC card to check BKOPS
+ *
+ * Send HPI command to interrupt ongoing background operations,
+ * to allow rapid servicing of foreground operations,e.g. read/
+ * writes. Wait until the card comes out of the programming state
+ * to avoid errors in servicing read/write requests.
+ */drivers/mmc/core/core.c +3
-0+int mmc_interrupt_bkops (struct mmc_card *card) +{ + int err;
Quoted 8 lines
drivers/mmc/core/core.c int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retries · line 530
Quoted 7 lines
+ unsigned long flags;
+ u32 status;drivers/mmc/core/core.c +5
-0+ + BUG_ON(!card); + + /* send HPI to interrupt BKOPS. */ + err = mmc_send_hpi_cmd(card, &status);What will be happened if eMMC card only support BKOPS but not support HPI?
Basically v4.41 and v4.5 doesn't mentioned the BKOPS timeout so if there's no HPI command, it should wait until BKOPS is done. It seems to be shown system hang.
Quoted 47 lines
Quoted 47 lines
+ if (err ||
R1_CURRENT_STATE(status)== 7) {
+ do {
+ err =mmc_send_status(card, &status);
+ if (err)
+ return err;
+ } while (R1_CURRENT_STATE(status)== 7);
+ }
+spin_lock_irqsave(&card->host->lock, flags);
+mmc_card_clr_doing_bkops(card);
+spin_unlock_irqrestore(&card->host->lock, flags);
+ return 0;drivers/mmc/core/core.c +4
-0+} +EXPORT_SYMBOL (mmc_interrupt_bkops); + +/** *
mmc_set_data_timeout- set the timeout for a data command
* @data: data phase for command
* @card: the MMC card associated with the data transferdrivers/mmc/core/mmc.c +4
-0@@ -448,6 +448,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) } if (card->ext_csd.rev >= 5) { + /* check whether the eMMC card support BKOPS */ + if (ext_csd[EXT_CSD_BKOPS_SUPPORT] & 0x1) + card->ext_csd.bkops = 1; + /* check whether the eMMC card supports HPI */ if (ext_csd[EXT_CSD_HPI_FEATURES] & 0x1) {
card->ext_csd.hpi= 1;drivers/mmc/core/mmc.c +8
-0@@ -909,6 +913,23 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, } /* + * enable BKOPS feature (if supported) + */ + if (card->ext_csd.bkops) { + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, + EXT_CSD_BKOPS_EN, 1, 0); + if (err && err != -EBADMSG) + goto free_card; +
Quoted 8 lines
drivers/mmc/core/mmc.c static int mmc_init_card(struct mmc_host *host, u32 ocr, · line 930
Quoted 7 lines
drivers/mmc/core/mmc.c +7
-0+ if (err) { + pr_warning("%s: Enabling BKOPS failed\n", + mmc_hostname(card->host)); + err = 0; + } else + card->ext_csd.bkops_en = 1; + }Just found this bit is one time programmable, so that is to say this bit is not suitable for driver to change.
You mean require the BKOPS_EN_FORCE config if user want to use at kernel?
Quoted 147 lines
Quoted 139 lines
drivers/mmc/core/mmc.c +2
-0+ + /* * Enable HPI feature (if supported) */ if (card->ext_csd.hpi) {drivers/mmc/core/mmc_ops.c +4
-0@@ -398,6 +398,10 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index,u8 value, if (err) return err; + /* No need to check card status in case of BKOPS switch*/ + if (index == EXT_CSD_BKOPS_START) + return 0; + /* Must check status to be sure of no errors */ do {err =
mmc_send_status(card, &status);include/linux/mmc/card.h +0
-0@@ -71,6 +71,8 @@ struct mmc_ext_csd {bool hpi_en; /* HPI enablebit */ bool hpi; /* HPI support bit */ unsigned int hpi_cmd; /* cmd used as HPI */
+ bool bkops; /* background support bit */
+ bool bkops_en; /* background enable bit */ u8 raw_partition_support; /* 160 */ u8 raw_erased_mem_count; /* 181 */ u8 raw_ext_csd_structure; /* 194 */include/linux/mmc/card.h +0
-0@@ -206,6 +208,8 @@ struct mmc_card { #define MMC_STATE_HIGHSPEED_DDR (1<<4) /* card is in high speed mode*/ #define MMC_STATE_ULTRAHIGHSPEED (1<<5) /* card is in ultra high speedmode */
#defineMMC_CARD_SDXC(1<<6) /* card is SDXC */include/linux/mmc/card.h +2
-0+#define MMC_STATE_NEED_BKOPS (1<<7)/* card need to do BKOPS */ +#define MMC_STATE_DOING_BKOPS (1<<8)/* card is doing BKOPS */ unsigned int quirks; /* card quirks */ #define
MMC_QUIRK_LENIENT_FN0(1<<0) /* allow SDIO FN0 writes outside of the VS CCCR range */
#defineMMC_QUIRK_BLKSZ_FOR_BYTE_MODE(1<<1) /* usefunc->cur_blksize*/include/linux/mmc/card.h +2
-0@@ -365,6 +369,8 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data) #define mmc_card_ddr_mode(c) ((c)->state & MMC_STATE_HIGHSPEED_DDR) #define mmc_sd_card_uhs(c) ((c)->state & MMC_STATE_ULTRAHIGHSPEED) #define mmc_card_ext_capacity(c) ((c)->state & MMC_CARD_SDXC) +#define mmc_card_need_bkops(c) ((c)->state & MMC_STATE_NEED_BKOPS) +#define mmc_card_doing_bkops(c) ((c)->state & MMC_STATE_DOING_BKOPS) #define mmc_card_set_present(c) ((c)->state |= MMC_STATE_PRESENT)#define
mmc_card_set_readonly(c)((c)->state |=MMC_STATE_READONLY)include/linux/mmc/card.h +2
-0@@ -373,6 +379,11 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data) #define mmc_card_set_ddr_mode(c) ((c)->state |= MMC_STATE_HIGHSPEED_DDR) #define mmc_sd_card_set_uhs(c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED) #define mmc_card_set_ext_capacity(c) ((c)->state |= MMC_CARD_SDXC) +#define mmc_card_set_need_bkops(c) ((c)->state |= MMC_STATE_NEED_BKOPS) +#define mmc_card_set_doing_bkops(c) ((c)->state |=
MMC_STATE_DOING_BKOPS)include/linux/mmc/card.h +3
-0+ +#define mmc_card_clr_need_bkops (c) ((c)->state &= ~MMC_STATE_NEED_BKOPS) +#define mmc_card_clr_doing_bkops (c) ((c)->state &=~MMC_STATE_DOING_BKOPS)
/*
* Quirk add/remove for MMC products.include/linux/mmc/core.h +2
-0@@ -134,6 +134,7 @@ struct mmc_host; struct mmc_card; struct mmc_async_req; +extern int mmc_interrupt_bkops (struct mmc_card *); extern struct mmc_async_req *mmc_start_req(struct mmc_host *, struct mmc_async_req *, int *); extern int mmc_interrupt_hpi(struct mmc_card *);@@ -163,6 +164,7 @@ extern int mmc_can_sanitize(struct mmc_card *card); extern int mmc_can_secure_erase_trim(struct mmc_card *card); extern int mmc_erase_group_aligned(struct mmc_card *card, unsigned int from, unsigned int nr); +extern void mmc_start_bkops (struct mmc_card *card); extern unsigned int mmc_calc_max_discard(struct mmc_card *card); extern int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen);include/linux/mmc/host.h +0
-0@@ -242,6 +242,7 @@ struct mmc_host { #define MMC_CAP2_CACHE_CTRL (1 << 1) /* Allow cache control */ #define MMC_CAP2_POWEROFF_NOTIFY (1 << 2) /* Notify poweroff supported*/ #define MMC_CAP2_NO_MULTI_READ (1 << 3) /* Multiblock reads don'twork */
+#defineMMC_CAP2_BKOPS(1 << 4) /* BKOPS supported */
mmc_pm_flag_tpm_caps; /* supported pm features */ unsigned int power_notify_type;include/linux/mmc/mmc.h +4
-1@@ -138,6 +138,7 @@ static inline bool mmc_op_multi(u32 opcode) #define R1_CURRENT_STATE(x) ((x & 0x00001E00) >> 9) /* sx, b (4 bits) */ #define R1_READY_FOR_DATA (1 << 8) /* sx, a */ #define R1_SWITCH_ERROR (1 << 7) /* sx, c */ +#define R1_URGENT_BKOPS (1 << 6)/* sx, a */ #define R1_APP_CMD (1 << 5) /* sr, c */ #define R1_STATE_IDLE 0@@ -278,6 +279,8 @@ struct _mmc_csd { #define EXT_CSD_PARTITION_SUPPORT 160 /* RO */ #define EXT_CSD_HPI_MGMT 161 /* R/W */ #define EXT_CSD_RST_N_FUNCTION 162 /* R/W */ +#define EXT_CSD_BKOPS_EN 163/* R/W */ +#define EXT_CSD_BKOPS_START 164/* W */ #define EXT_CSD_SANITIZE_START 165 /* W */ #define EXT_CSD_WR_REL_PARAM 166 /* RO */ #define EXT_CSD_ERASE_GROUP_DEF 175 /* R/W */@@ -313,6 +316,7 @@ struct _mmc_csd { #define EXT_CSD_POWER_OFF_LONG_TIME 247 /* RO */ #define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */ #define EXT_CSD_CACHE_SIZE 249 /* RO, 4 bytes */ +#define EXT_CSD_BKOPS_SUPPORT 502/* RO */ #define EXT_CSD_HPI_FEATURES 503 /* RO */ /* -- Quoted 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
Quoted 2 lines
Just found this bit is one time programmable, so that is to say this bit is not suitable for driver to change.
You mean require the
BKOPS_EN_FORCEconfig if user want to use at kernel?
What do you refer to when you write BKOPS_EN_FORCE config? It doesn't seem like the OPs patch contains such a config.
/ Sebastian
Quoted 9 lines
drivers/mmc/card/queue.c static int mmc_queue_thread(void *d) · line 74
Quoted 8 lines
drivers/mmc/card/queue.c +1
-0@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d)set_current_state (TASK_RUNNING );break ; } +mmc_start_bkops (mq->card);up (&mq->thread_sem);schedule ();down (&mq->thread_sem);Maybe put
mmc_interrupt_bkops(card)here is better, I think.
And the reason being that one already knows at this point that there is a new request to be processed and so BKOPS may just as well be interrupted at this point as later inside mq->issue_fn()?
Quoted 3 lines
drivers/mmc/core/core.c int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retries · line 530
Quoted 2 lines
drivers/mmc/core/core.c +2
-0+/* send HPI to interrupt BKOPS. */ + err =mmc_send_hpi_cmd (card, &status);What will be happened if eMMC card only support BKOPS but not support HPI?
For eMMC 4.41 this is actually a valid, but possibly unlikely, scenario. For eMMC 4.5 both BKOPS and HPI are mandatory as I read the spec.
As far as I can understand is that card->ext_csd.hpi_cmd == 0 (as card->ext_csd.hpi == 0 due toe EXT_CSD_HPI_FEATURES being 0). Inside mmc_send_hpi_cmd() this means that cmd.opcode not going to be either MMC_STOP_TRANSMISSION or MMC_SEND_STATUS but the command is still sent. As far as I understand the card will is that case not responde, but only set it's ILLEGAL_COMMAND bit in the status register and mmc_send_hpi_cmd() will be stuck in mmc_wait_for_cmd().
Basically you are trying to say that BKOPS should only be enabled if HPI is also supported and enabled. Unfortunately it may be the case that someone has enabled BKOPS through the one-time programmable BKOPS_EN for an eMMC which does not support HPI. If the MMC framework discovers such a card I suggest bailing out early, because such a card is obviously misconfigured.
Quoted 6 lines
drivers/mmc/core/mmc.c static int mmc_init_card(struct mmc_host *host, u32 ocr, · line 920
Quoted 5 lines
drivers/mmc/core/mmc.c +5
-0+* enable BKOPS feature (if supported) +*/ +if (card->ext_csd.bkops) { + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_EN ,1 ,0 );Just found this bit is one time programmable, so that is to say this bit is not suitable for driver to change.
Agreed, my suggestion was to read BKOPS_EN and if BKOPS then use that to determine if the framework should call mmc_start_bkops().
/ Sebastian
Quoted 17 lines
-----Original Message-----
From: Sebastian Rasmussen [mailto:[email protected]]
Sent: Friday, October 28, 2011 4:31 AM
To: Dong, Chuanxiao
Cc: Jaehoon Chung; linux-mmc; Chris Ball; Kyungmin Park; Hanumath Prasad
Subject: Re: [PATCH] mmc: support BKOPS feature for eMMCQuoted 9 lines
drivers/mmc/card/queue.c static int mmc_queue_thread(void *d) · line 74
Quoted 8 lines
drivers/mmc/card/queue.c +1
-0@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d)set_current_state (TASK_RUNNING );break ; } +mmc_start_bkops (mq->card);up (&mq->thread_sem);schedule ();down (&mq->thread_sem);Maybe put
mmc_interrupt_bkops(card)here is better, I think.
Quoted 3 lines
And the reason being that one already knows at this point that there is a new request to be processed and so BKOPS may just as well be interrupted at this point as later inside
mq->issue_fn()?
Yes. To me, that is the reason. Since once schedule back here, means block driver will handle mmc request then. No matter what kind of request, that will need to use eMMC card. So I think here is an proper position to interrupt background operations.
Quoted 16 lines
Quoted 4 lines
drivers/mmc/core/core.c int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retries · line 530
Quoted 3 lines
drivers/mmc/core/core.c +2
-0+/* send HPI to interrupt BKOPS. */ + err =mmc_send_hpi_cmd (card, &status);What will be happened if eMMC card only support BKOPS but not support HPI?
For eMMC 4.41 this is actually a valid, but possibly unlikely, scenario. For eMMC 4.5 both BKOPS and HPI are mandatory as I read the spec.
As far as I can understand is that
card->ext_csd.hpi_cmd== 0 (ascard->ext_csd.hpi== 0 due toeEXT_CSD_HPI_FEATURESbeing 0). Insidemmc_send_hpi_cmd()this means that cmd.opcode not going to be eitherMMC_STOP_TRANSMISSIONorMMC_SEND_STATUSbut the command is still sent. As far as I understand the card will is that case not responde, but only set it'sILLEGAL_COMMANDbit in the status register andmmc_send_hpi_cmd()will be stuck inmmc_wait_for_cmd().
Quoted 6 lines
Basically you are trying to say that BKOPS should only be enabled if HPI is also supported and enabled. Unfortunately it may be the case that someone has enabled BKOPS through the one-time programmable
BKOPS_ENfor an eMMC which does not support HPI. If the MMC framework discovers such a card I suggest bailing out early, because such a card is obviously misconfigured.
Yes, basically that is what I mean. Seems you know a lot of about me ;).
Maybe if the eMMC card only support BKOPS, then mmc_interrupt_bkops can send CMD13 to poll the card status instead of sending HPI command directly.
Just as we mentioned below, BKOPS_EN is one time programmable, thus this bit should be programmed by eMMC device vendor or some product provider. They can choose whether to enable this from a device performance point of view. If there device have a performance improvement even without a HPI support, then go forward. If not, just leave this bit along. So what driver does is only to do the right things. If he has HPI, using HPI to stop BKOPS. If not, he has to poll the card status.
Thanks
Chuanxiao
Quoted 7 lines
Background operation(BKOPS) is one of eMMC's features.
If set the
URGENT_BKOPSin response, we can notify that card nedd the BKOPS. And all I/O request is done, then run background operation.
If request read/write operation during BKOPS, issue HPI interrupt.If you want to use this feature, should be set
MMC_CAP2_BKOPS.
Enable eMMC background operations (BKOPS) feature.
If URGENT_BKOPS is set after a response, note that BKOPS are required. After all I/O requests are finished, run BKOPS if required. Should read/write operations be requested during BKOPS, first issue HPI to interrupt the ongoing BKOPS and then service the request.
If you want to enable this feature, set MMC_CAP2_BKOPS.
Quoted 29 lines
Signed-off-by Jaehoon Chung <[email protected]>Signed-off-by Kyungmin Park <[email protected]>CC Hanumath Prasad <[email protected]>--- drivers/mmc/card/block.c | 13 +++++++- drivers/mmc/card/queue.c | 1 + drivers/mmc/core/core.c | 77 ++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/core/mmc.c | 21 ++++++++++++ drivers/mmc/core/mmc_ops.c | 4 ++ include/linux/mmc/card.h | 11 ++++++ include/linux/mmc/core.h | 2 + include/linux/mmc/host.h | 1 + include/linux/mmc/mmc.h | 4 ++ 9 files changed, 133 insertions(+), 1 deletions(-)drivers/mmc/card/block.c +5
-0@@ -1185,14 +1185,25 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) type =rq_data_dir (req) ==READ ?MMC_BLK_READ :MMC_BLK_WRITE ;mmc_queue_bounce_post (mq_rq); +if (mmc_card_doing_bkops (card)) { +if (mmc_interrupt_bkops (card)) + goto cmd_abort; + } +
drivers/mmc/card/block.c static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) · line 1202
Quoted 10 lines
drivers/mmc/card/block.c +7
-0switch (status) {case MMC_BLK_SUCCESS :case MMC_BLK_PARTIAL : +spin_lock_irq (&md->lock); +/* +* Check BKOPS urgency from each R1 response +*/ +if (mmc_card_mmc (card) && + (brq->cmd.resp[0 ] &R1_URGENT_BKOPS )) +mmc_card_set_need_bkops (card);
First of all, R1_URGENT_BKOPS is fine to check in cmd->resp[0], but it is only valid if cmd->resp contains an R1 or an R1b response. Granted, commands that do not have R1/R1b responses are few, but I still believe you need to check that with mmc_resp_type().
Moreover in the eMMC 4.41 spec it was ok to check bit 6 of the status (which is what you do above) as that bit corresponded to URGENT_BKOPS. However for eMMC 4.5 this bit has been combined with other kinds of of exceptional situations. The bit has been renamed EXCEPTION_EVENT and if it is set you then need to read (using CMD8) bytes 55:54 in EXT_CSD named EXCEPTION_EVENTS_STATUS where bit 0 indicates URGENT_BKOPS.
So I you need to check card->ext_csd.rev here to know what method you need to apply to determine if BKOPS are urgent or not.
Quoted 120 lines
drivers/mmc/card/block.c +0
-1/* * A block was successfully transferred. */ mmc_blk_reset_success (md, type); -spin_lock_irq (&md->lock); ret =__blk_end_request (req,0 , brq->data.bytes_xfered);spin_unlock_irq (&md->lock);drivers/mmc/card/queue.c +1
-0@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d)set_current_state (TASK_RUNNING );break ; } +mmc_start_bkops (mq->card);up (&mq->thread_sem);schedule ();down (&mq->thread_sem);drivers/mmc/core/core.c +77
-0@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) host->ops->request (host, mrq); } +/** +* mmc_start_bkops - start BKOPS for supported cards +* @card: MMC card to start BKOPS +* +* Start background operations whenever requested. +* when the urgent BKOPS bit is set in a R1 command response +* then background operations should be started immediately. +*/ +void mmc_start_bkops (struct mmc_card *card) +{ +int err; +unsigned long flags; + +if ((!card || !card->ext_csd.bkops_en) && + !(card->host->caps2 &MMC_CAP2_BKOPS )) +return ; + +/* +* If card is already doing bkops or need for +* bkops flag is not set, then do nothing just +* return +*/ +if (mmc_card_doing_bkops (card) + || !mmc_card_need_bkops (card)) +return ; + +mmc_claim_host (card->host); + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_START ,1 ,0 ); +if (err) { +pr_warning ("error %d starting bkops\n" , err); +mmc_card_clr_need_bkops (card); + goto out; + } +spin_lock_irqsave (&card->host->lock, flags); +mmc_card_clr_need_bkops (card); +mmc_card_set_doing_bkops (card); +spin_unlock_irqrestore (&card->host->lock, flags); +out: +mmc_release_host (card->host); +} +EXPORT_SYMBOL (mmc_start_bkops); + +static void mmc_wait_done (struct mmc_request *mrq) {complete (&mrq->completion);@@ -466,6 +510,39 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retriesEXPORT_SYMBOL (mmc_wait_for_cmd);/** +* mmc_interrupt_bkops - interrupt ongoing BKOPS +* @card: MMC card to check BKOPS +* +* Send HPI command to interrupt ongoing background operations, +* to allow rapid servicing of foreground operations,e.g. read/ +* writes. Wait until the card comes out of the programming state +* to avoid errors in servicing read/write requests. +*/ +int mmc_interrupt_bkops (struct mmc_card *card) +{ +int err; +unsigned long flags; +u32 status; + +BUG_ON (!card); + +/* send HPI to interrupt BKOPS. */ + err =mmc_send_hpi_cmd (card, &status); +if (err ||R1_CURRENT_STATE (status) ==7 ) { +do { + err =mmc_send_status (card, &status); +if (err) +return err; + }while (R1_CURRENT_STATE (status) ==7 ); + } +spin_lock_irqsave (&card->host->lock, flags); +mmc_card_clr_doing_bkops (card); +spin_unlock_irqrestore (&card->host->lock, flags); +return 0 ; +} +EXPORT_SYMBOL (mmc_interrupt_bkops); + +/** * mmc_set_data_timeout - set the timeout for a data command * @data: data phase for command * @card: the MMC card associated with the data transfer drivers/mmc/core/mmc.c +0
-0
drivers/mmc/core/mmc.c static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) · line 453
Quoted 6 lines
drivers/mmc/core/mmc.c +3
-0@@ -448,6 +448,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) }if (card->ext_csd.rev >=5 ) { +/* check whether the eMMC card support BKOPS */ +if (ext_csd[EXT_CSD_BKOPS_SUPPORT ] &0x1 ) + card->ext_csd.bkops =1 ;
How about this to include/linux/mmc/mmc.h and using it here?
#define EXT_CSD_BKOPS_SUPPORTED BIT(0)
BTW, this is required starting from eMMC 4.5.
drivers/mmc/core/mmc.c static int mmc_init_card(struct mmc_host *host, u32 ocr, · line 920
Quoted 13 lines
drivers/mmc/core/mmc.c +6
-0+/* check whether the eMMC card supports HPI */ if (ext_csd[EXT_CSD_HPI_FEATURES ] &0x1 ) { card->ext_csd.hpi =1 ;@@ -909,6 +913,23 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, }/* +* enable BKOPS feature (if supported) +*/ +if (card->ext_csd.bkops) { + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_EN ,1 ,0 );
The BKOPS_EN property in EXT_CSD is labelled R/W which means that it is one time programmable. Therefore it makes no sense to write this every time you are initializing an eMMC. What you could do is to read BKOPS_EN to determine if BKOPS should, according to the eMMC, be enabled in the MMC framework.
According to other discussions here it seems to me as if Chris and others are wary of having sysfs-files enable users to write to one-time programmable registers. So therefore I guess the only option is to use the generic MMC command passthrough in mmc_blk_ioctl() to do such things.
Quoted 20 lines
drivers/mmc/core/mmc.c +12
-0+if (err && err != -EBADMSG ) + goto free_card; + +if (err) { +pr_warning ("%s: Enabling BKOPS failed\n" , +mmc_hostname (card->host)); + err =0 ; + }else + card->ext_csd.bkops_en =1 ; + } + +/* * Enable HPI feature (if supported) */ if (card->ext_csd.hpi) {drivers/mmc/core/mmc_ops.c +0
-0
drivers/mmc/core/mmc_ops.c int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, · line 403
Quoted 6 lines
drivers/mmc/core/mmc_ops.c +3
-0@@ -398,6 +398,10 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,if (err)return err; +/* No need to check card status in case of BKOPS switch*/ +if (index ==EXT_CSD_BKOPS_START ) +return 0 ;
Why is this not needed? I can see why you wouldn't want to wait until the card is no longer busy (as it will stay busy until BKOPS are no longer needed), but the bits indicating errors must surely be interesting to check?
Quoted 113 lines
drivers/mmc/core/mmc_ops.c +1
-0+/* Must check status to be sure of no errors */ do { err = mmc_send_status(card, &status);include/linux/mmc/card.h +11
-0@@ -71,6 +71,8 @@ struct mmc_ext_csd {bool hpi_en;/* HPI enablebit */ bool hpi;/* HPI support bit */ unsigned int hpi_cmd;/* cmd used as HPI */ +bool bkops;/* background support bit */ +bool bkops_en;/* background enable bit */ u8 raw_partition_support;/* 160 */ u8 raw_erased_mem_count;/* 181 */ u8 raw_ext_csd_structure;/* 194 */ @@ -206,6 +208,8 @@ struct mmc_card {#define MMC_STATE_HIGHSPEED_DDR (1<<4)/* card is in high speed mode */ #define MMC_STATE_ULTRAHIGHSPEED (1<<5)/* card is in ultra high speed mode */ #define MMC_CARD_SDXC (1<<6)/* card is SDXC */ +#define MMC_STATE_NEED_BKOPS (1<<7)/* card need to do BKOPS */ +#define MMC_STATE_DOING_BKOPS (1<<8)/* card is doing BKOPS */ unsigned int quirks;/* card quirks */ #define MMC_QUIRK_LENIENT_FN0 (1<<0)/* allow SDIO FN0 writes outside of the VS CCCR range */ #define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (1<<1)/* use func->cur_blksize */ @@ -365,6 +369,8 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)#define mmc_card_ddr_mode (c) ((c)->state & MMC_STATE_HIGHSPEED_DDR)#define mmc_sd_card_uhs (c) ((c)->state & MMC_STATE_ULTRAHIGHSPEED)#define mmc_card_ext_capacity (c) ((c)->state & MMC_CARD_SDXC) +#define mmc_card_need_bkops (c) ((c)->state & MMC_STATE_NEED_BKOPS) +#define mmc_card_doing_bkops (c) ((c)->state & MMC_STATE_DOING_BKOPS)#define mmc_card_set_present (c) ((c)->state |= MMC_STATE_PRESENT)#define mmc_card_set_readonly (c) ((c)->state |= MMC_STATE_READONLY)@@ -373,6 +379,11 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)#define mmc_card_set_ddr_mode (c) ((c)->state |= MMC_STATE_HIGHSPEED_DDR)#define mmc_sd_card_set_uhs (c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED)#define mmc_card_set_ext_capacity (c) ((c)->state |= MMC_CARD_SDXC) +#define mmc_card_set_need_bkops (c) ((c)->state |= MMC_STATE_NEED_BKOPS) +#define mmc_card_set_doing_bkops (c) ((c)->state |= MMC_STATE_DOING_BKOPS) + +#define mmc_card_clr_need_bkops (c) ((c)->state &= ~MMC_STATE_NEED_BKOPS) +#define mmc_card_clr_doing_bkops (c) ((c)->state &= ~MMC_STATE_DOING_BKOPS)/* * Quirk add/remove for MMC products. include/linux/mmc/core.h +2
-0@@ -134,6 +134,7 @@ struct mmc_host;struct mmc_card ;struct mmc_async_req ; +extern int mmc_interrupt_bkops (struct mmc_card *);extern struct mmc_async_req *mmc_start_req (struct mmc_host *,struct mmc_async_req *,int *);extern int mmc_interrupt_hpi (struct mmc_card *);@@ -163,6 +164,7 @@ extern int mmc_can_sanitize(struct mmc_card *card);extern int mmc_can_secure_erase_trim (struct mmc_card *card);extern int mmc_erase_group_aligned (struct mmc_card *card,unsigned int from,unsigned int nr); +extern void mmc_start_bkops (struct mmc_card *card);extern unsigned int mmc_calc_max_discard (struct mmc_card *card);extern int mmc_set_blocklen (struct mmc_card *card,unsigned int blocklen);include/linux/mmc/host.h +1
-0@@ -242,6 +242,7 @@ struct mmc_host {#define MMC_CAP2_CACHE_CTRL (1 << 1)/* Allow cache control */ #define MMC_CAP2_POWEROFF_NOTIFY (1 << 2)/* Notify poweroff supported */ #define MMC_CAP2_NO_MULTI_READ (1 << 3)/* Multiblock reads don't work */ +#define MMC_CAP2_BKOPS (1 << 4)/* BKOPS supported */ mmc_pm_flag_t pm_caps;/* supported pm features */ unsigned int power_notify_type;include/linux/mmc/mmc.h +4
-1@@ -138,6 +138,7 @@ static inline bool mmc_op_multi(u32 opcode)#define R1_CURRENT_STATE (x) ((x & 0x00001E00) >> 9)/* sx, b (4 bits) */ #define R1_READY_FOR_DATA (1 << 8)/* sx, a */ #define R1_SWITCH_ERROR (1 << 7)/* sx, c */ +#define R1_URGENT_BKOPS (1 << 6)/* sx, a */ #define R1_APP_CMD (1 << 5)/* sr, c */ #define R1_STATE_IDLE 0@@ -278,6 +279,8 @@ struct _mmc_csd {#define EXT_CSD_PARTITION_SUPPORT 160/* RO */ #define EXT_CSD_HPI_MGMT 161/* R/W */ #define EXT_CSD_RST_N_FUNCTION 162/* R/W */ +#define EXT_CSD_BKOPS_EN 163/* R/W */ +#define EXT_CSD_BKOPS_START 164/* W */ #define EXT_CSD_SANITIZE_START 165/* W */ #define EXT_CSD_WR_REL_PARAM 166/* RO */ #define EXT_CSD_ERASE_GROUP_DEF 175/* R/W */ @@ -313,6 +316,7 @@ struct _mmc_csd {#define EXT_CSD_POWER_OFF_LONG_TIME 247/* RO */ #define EXT_CSD_GENERIC_CMD6_TIME 248/* RO */ #define EXT_CSD_CACHE_SIZE 249/* RO, 4 bytes */ +#define EXT_CSD_BKOPS_SUPPORT 502/* RO */ #define EXT_CSD_HPI_FEATURES 503/* RO */ /* -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sebastian.
Quoted 54 lines · Sebastian Rasmussen
Quoted 7 lines
Background operation(BKOPS) is one of eMMC's features.
If set the
URGENT_BKOPSin response, we can notify that card nedd the BKOPS. And all I/O request is done, then run background operation.
If request read/write operation during BKOPS, issue HPI interrupt.If you want to use this feature, should be set
MMC_CAP2_BKOPS.Enable eMMC background operations (BKOPS) feature.
If
URGENT_BKOPSis set after a response, note that BKOPS are required. After all I/O requests are finished, run BKOPS if required. Should read/write operations be requested during BKOPS, first issue HPI to interrupt the ongoing BKOPS and then service the request.If you want to enable this feature, set
MMC_CAP2_BKOPS.Quoted 36 lines
Signed-off-by Jaehoon Chung <[email protected]>Signed-off-by Kyungmin Park <[email protected]>CC Hanumath Prasad <[email protected]>--- drivers/mmc/card/block.c | 13 +++++++- drivers/mmc/card/queue.c | 1 + drivers/mmc/core/core.c | 77 ++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/core/mmc.c | 21 ++++++++++++ drivers/mmc/core/mmc_ops.c | 4 ++ include/linux/mmc/card.h | 11 ++++++ include/linux/mmc/core.h | 2 + include/linux/mmc/host.h | 1 + include/linux/mmc/mmc.h | 4 ++ 9 files changed, 133 insertions(+), 1 deletions(-)drivers/mmc/card/block.c +9
-0@@ -1185,14 +1185,25 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) type =rq_data_dir (req) ==READ ?MMC_BLK_READ :MMC_BLK_WRITE ;mmc_queue_bounce_post (mq_rq); +if (mmc_card_doing_bkops (card)) { +if (mmc_interrupt_bkops (card)) + goto cmd_abort; + } +switch (status) {case MMC_BLK_SUCCESS :case MMC_BLK_PARTIAL : +spin_lock_irq (&md->lock); +/* +* Check BKOPS urgency from each R1 response +*/
Quoted 8 lines
drivers/mmc/card/block.c static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc) · line 1202
Quoted 3 lines
drivers/mmc/card/block.c +3
-0+if (mmc_card_mmc (card) && + (brq->cmd.resp[0 ] &R1_URGENT_BKOPS )) +mmc_card_set_need_bkops (card);First of all,
R1_URGENT_BKOPSis fine to check in cmd->resp[0], but it is only valid ifcmd->respcontains an R1 or an R1b response. Granted, commands that do not have R1/R1b responses are few, but I still believe you need to check that withmmc_resp_type().
Ok...i will add to check for mmc_resp_type().
Quoted 7 lines
Moreover in the eMMC 4.41 spec it was ok to check bit 6 of the status (which is what you do above) as that bit corresponded to
URGENT_BKOPS. However for eMMC 4.5 this bit has been combined with other kinds of of exceptional situations. The bit has been renamedEXCEPTION_EVENTand if it is set you then need to read (using CMD8) bytes 55:54 inEXT_CSDnamedEXCEPTION_EVENTS_STATUSwhere bit 0 indicatesURGENT_BKOPS.
Right..eMMC4.5 is modified them. So host need to check EXCEPTION_EVENTS_STATUS and whenever need to check, host should read the ext_csd register. right? I will modify also this point..(actually..this patch is based on eMMC4.41)
Quoted 133 lines
So I you need to check
card->ext_csd.revhere to know what method you need to apply to determine if BKOPS are urgent or not.Quoted 120 lines
drivers/mmc/card/block.c +0
-1/* * A block was successfully transferred. */ mmc_blk_reset_success (md, type); -spin_lock_irq (&md->lock); ret =__blk_end_request (req,0 , brq->data.bytes_xfered);spin_unlock_irq (&md->lock);drivers/mmc/card/queue.c +1
-0@@ -68,6 +68,7 @@ static int mmc_queue_thread(void *d)set_current_state (TASK_RUNNING );break ; } +mmc_start_bkops (mq->card);up (&mq->thread_sem);schedule ();down (&mq->thread_sem);drivers/mmc/core/core.c +77
-0@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) host->ops->request (host, mrq); } +/** +* mmc_start_bkops - start BKOPS for supported cards +* @card: MMC card to start BKOPS +* +* Start background operations whenever requested. +* when the urgent BKOPS bit is set in a R1 command response +* then background operations should be started immediately. +*/ +void mmc_start_bkops (struct mmc_card *card) +{ +int err; +unsigned long flags; + +if ((!card || !card->ext_csd.bkops_en) && + !(card->host->caps2 &MMC_CAP2_BKOPS )) +return ; + +/* +* If card is already doing bkops or need for +* bkops flag is not set, then do nothing just +* return +*/ +if (mmc_card_doing_bkops (card) + || !mmc_card_need_bkops (card)) +return ; + +mmc_claim_host (card->host); + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_START ,1 ,0 ); +if (err) { +pr_warning ("error %d starting bkops\n" , err); +mmc_card_clr_need_bkops (card); + goto out; + } +spin_lock_irqsave (&card->host->lock, flags); +mmc_card_clr_need_bkops (card); +mmc_card_set_doing_bkops (card); +spin_unlock_irqrestore (&card->host->lock, flags); +out: +mmc_release_host (card->host); +} +EXPORT_SYMBOL (mmc_start_bkops); + +static void mmc_wait_done (struct mmc_request *mrq) {complete (&mrq->completion);@@ -466,6 +510,39 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd, int retriesEXPORT_SYMBOL (mmc_wait_for_cmd);/** +* mmc_interrupt_bkops - interrupt ongoing BKOPS +* @card: MMC card to check BKOPS +* +* Send HPI command to interrupt ongoing background operations, +* to allow rapid servicing of foreground operations,e.g. read/ +* writes. Wait until the card comes out of the programming state +* to avoid errors in servicing read/write requests. +*/ +int mmc_interrupt_bkops (struct mmc_card *card) +{ +int err; +unsigned long flags; +u32 status; + +BUG_ON (!card); + +/* send HPI to interrupt BKOPS. */ + err =mmc_send_hpi_cmd (card, &status); +if (err ||R1_CURRENT_STATE (status) ==7 ) { +do { + err =mmc_send_status (card, &status); +if (err) +return err; + }while (R1_CURRENT_STATE (status) ==7 ); + } +spin_lock_irqsave (&card->host->lock, flags); +mmc_card_clr_doing_bkops (card); +spin_unlock_irqrestore (&card->host->lock, flags); +return 0 ; +} +EXPORT_SYMBOL (mmc_interrupt_bkops); + +/** * mmc_set_data_timeout - set the timeout for a data command * @data: data phase for command * @card: the MMC card associated with the data transfer drivers/mmc/core/mmc.c +0
-0drivers/mmc/core/mmc.c static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) · line 453
Quoted 6 lines
drivers/mmc/core/mmc.c +3
-0@@ -448,6 +448,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) }if (card->ext_csd.rev >=5 ) { +/* check whether the eMMC card support BKOPS */ +if (ext_csd[EXT_CSD_BKOPS_SUPPORT ] &0x1 ) + card->ext_csd.bkops =1 ;How about this to
include/linux/mmc/mmc.hand using it here?
Quoted 3 lines
#define
EXT_CSD_BKOPS_SUPPORTEDBIT(0)BTW, this is required starting from eMMC 4.5.
Consider your opinion..:)
Quoted 8 lines
Quoted 8 lines
drivers/mmc/core/mmc.c +1
-0+/* check whether the eMMC card supports HPI */ if (ext_csd[EXT_CSD_HPI_FEATURES ] &0x1 ) { card->ext_csd.hpi =1 ;@@ -909,6 +913,23 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, }
Quoted 12 lines
drivers/mmc/core/mmc.c static int mmc_init_card(struct mmc_host *host, u32 ocr, · line 920
Quoted 6 lines
drivers/mmc/core/mmc.c +5
-0/* +* enable BKOPS feature (if supported) +*/ +if (card->ext_csd.bkops) { + err =mmc_switch (card,EXT_CSD_CMD_SET_NORMAL , +EXT_CSD_BKOPS_EN ,1 ,0 );The
BKOPS_ENproperty inEXT_CSDis labelled R/W which means that it is one time programmable. Therefore it makes no sense to write this every time you are initializing an eMMC. What you could do is to readBKOPS_ENto determine if BKOPS should, according to the eMMC, be enabled in the MMC framework.
Then this code is unnecessary..because card supported bkops, EXT_CSD_BKOPS_EN is set by default. And if user want to use BKOPS,user can use IOCTL like you mentioned.
Quoted 30 lines
According to other discussions here it seems to me as if Chris and others are wary of having sysfs-files enable users to write to one-time programmable registers. So therefore I guess the only option is to use the generic MMC command passthrough in
mmc_blk_ioctl()to do such things.Quoted 23 lines
drivers/mmc/core/mmc.c +12
-0+if (err && err != -EBADMSG ) + goto free_card; + +if (err) { +pr_warning ("%s: Enabling BKOPS failed\n" , +mmc_hostname (card->host)); + err =0 ; + }else + card->ext_csd.bkops_en =1 ; + } + +/* * Enable HPI feature (if supported) */ if (card->ext_csd.hpi) {drivers/mmc/core/mmc_ops.c +0
-0@@ -398,6 +398,10 @@ int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value,if (err)return err;
Quoted 8 lines
drivers/mmc/core/mmc_ops.c int mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, · line 403
Quoted 3 lines
drivers/mmc/core/mmc_ops.c +3
-0+/* No need to check card status in case of BKOPS switch*/ +if (index ==EXT_CSD_BKOPS_START ) +return 0 ;Why is this not needed? I can see why you wouldn't want to wait until the card is no longer busy (as it will stay busy until BKOPS are no longer needed), but the bits indicating errors must surely be interesting to check?
I think that didn't need to check because just write any value in EXT_CSD_BKOPS_START.
Quoted 119 lines
Quoted 110 lines
drivers/mmc/core/mmc_ops.c +1
-0+/* Must check status to be sure of no errors */ do { err = mmc_send_status(card, &status);include/linux/mmc/card.h +11
-0@@ -71,6 +71,8 @@ struct mmc_ext_csd {bool hpi_en;/* HPI enablebit */ bool hpi;/* HPI support bit */ unsigned int hpi_cmd;/* cmd used as HPI */ +bool bkops;/* background support bit */ +bool bkops_en;/* background enable bit */ u8 raw_partition_support;/* 160 */ u8 raw_erased_mem_count;/* 181 */ u8 raw_ext_csd_structure;/* 194 */ @@ -206,6 +208,8 @@ struct mmc_card {#define MMC_STATE_HIGHSPEED_DDR (1<<4)/* card is in high speed mode */ #define MMC_STATE_ULTRAHIGHSPEED (1<<5)/* card is in ultra high speed mode */ #define MMC_CARD_SDXC (1<<6)/* card is SDXC */ +#define MMC_STATE_NEED_BKOPS (1<<7)/* card need to do BKOPS */ +#define MMC_STATE_DOING_BKOPS (1<<8)/* card is doing BKOPS */ unsigned int quirks;/* card quirks */ #define MMC_QUIRK_LENIENT_FN0 (1<<0)/* allow SDIO FN0 writes outside of the VS CCCR range */ #define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (1<<1)/* use func->cur_blksize */ @@ -365,6 +369,8 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)#define mmc_card_ddr_mode (c) ((c)->state & MMC_STATE_HIGHSPEED_DDR)#define mmc_sd_card_uhs (c) ((c)->state & MMC_STATE_ULTRAHIGHSPEED)#define mmc_card_ext_capacity (c) ((c)->state & MMC_CARD_SDXC) +#define mmc_card_need_bkops (c) ((c)->state & MMC_STATE_NEED_BKOPS) +#define mmc_card_doing_bkops (c) ((c)->state & MMC_STATE_DOING_BKOPS)#define mmc_card_set_present (c) ((c)->state |= MMC_STATE_PRESENT)#define mmc_card_set_readonly (c) ((c)->state |= MMC_STATE_READONLY)@@ -373,6 +379,11 @@ static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)#define mmc_card_set_ddr_mode (c) ((c)->state |= MMC_STATE_HIGHSPEED_DDR)#define mmc_sd_card_set_uhs (c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED)#define mmc_card_set_ext_capacity (c) ((c)->state |= MMC_CARD_SDXC) +#define mmc_card_set_need_bkops (c) ((c)->state |= MMC_STATE_NEED_BKOPS) +#define mmc_card_set_doing_bkops (c) ((c)->state |= MMC_STATE_DOING_BKOPS) + +#define mmc_card_clr_need_bkops (c) ((c)->state &= ~MMC_STATE_NEED_BKOPS) +#define mmc_card_clr_doing_bkops (c) ((c)->state &= ~MMC_STATE_DOING_BKOPS)/* * Quirk add/remove for MMC products. include/linux/mmc/core.h +2
-0@@ -134,6 +134,7 @@ struct mmc_host;struct mmc_card ;struct mmc_async_req ; +extern int mmc_interrupt_bkops (struct mmc_card *);extern struct mmc_async_req *mmc_start_req (struct mmc_host *,struct mmc_async_req *,int *);extern int mmc_interrupt_hpi (struct mmc_card *);@@ -163,6 +164,7 @@ extern int mmc_can_sanitize(struct mmc_card *card);extern int mmc_can_secure_erase_trim (struct mmc_card *card);extern int mmc_erase_group_aligned (struct mmc_card *card,unsigned int from,unsigned int nr); +extern void mmc_start_bkops (struct mmc_card *card);extern unsigned int mmc_calc_max_discard (struct mmc_card *card);extern int mmc_set_blocklen (struct mmc_card *card,unsigned int blocklen);include/linux/mmc/host.h +1
-0@@ -242,6 +242,7 @@ struct mmc_host {#define MMC_CAP2_CACHE_CTRL (1 << 1)/* Allow cache control */ #define MMC_CAP2_POWEROFF_NOTIFY (1 << 2)/* Notify poweroff supported */ #define MMC_CAP2_NO_MULTI_READ (1 << 3)/* Multiblock reads don't work */ +#define MMC_CAP2_BKOPS (1 << 4)/* BKOPS supported */ mmc_pm_flag_t pm_caps;/* supported pm features */ unsigned int power_notify_type;include/linux/mmc/mmc.h +4
-1@@ -138,6 +138,7 @@ static inline bool mmc_op_multi(u32 opcode)#define R1_CURRENT_STATE (x) ((x & 0x00001E00) >> 9)/* sx, b (4 bits) */ #define R1_READY_FOR_DATA (1 << 8)/* sx, a */ #define R1_SWITCH_ERROR (1 << 7)/* sx, c */ +#define R1_URGENT_BKOPS (1 << 6)/* sx, a */ #define R1_APP_CMD (1 << 5)/* sr, c */ #define R1_STATE_IDLE 0@@ -278,6 +279,8 @@ struct _mmc_csd {#define EXT_CSD_PARTITION_SUPPORT 160/* RO */ #define EXT_CSD_HPI_MGMT 161/* R/W */ #define EXT_CSD_RST_N_FUNCTION 162/* R/W */ +#define EXT_CSD_BKOPS_EN 163/* R/W */ +#define EXT_CSD_BKOPS_START 164/* W */ #define EXT_CSD_SANITIZE_START 165/* W */ #define EXT_CSD_WR_REL_PARAM 166/* RO */ #define EXT_CSD_ERASE_GROUP_DEF 175/* R/W */ @@ -313,6 +316,7 @@ struct _mmc_csd {#define EXT_CSD_POWER_OFF_LONG_TIME 247/* RO */ #define EXT_CSD_GENERIC_CMD6_TIME 248/* RO */ #define EXT_CSD_CACHE_SIZE 249/* RO, 4 bytes */ +#define EXT_CSD_BKOPS_SUPPORT 502/* RO */ #define EXT_CSD_HPI_FEATURES 503/* RO */ /* -- Quoted 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Review mmc_start_request(struct mmc_host *host, struct
Quoted 2 lines · Jaehoon Chung <jh80.chung <at> samsung.com> writes:
+++
b/drivers/mmc/core/core.c(quoted diff) +0
-0@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
drivers/mmc/core/core.c mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) · line 248
Quoted 11 lines
drivers/mmc/core/core.c +8
-0host->ops->request (host, mrq); } +/** +* mmc_start_bkops - start BKOPS for supported cards +* @card: MMC card to start BKOPS +* +* Start background operations whenever requested. +* when the urgent BKOPS bit is set in a R1 command response +* then background operations should be started immediately. +*/
This patch only starts BKOPS if it's urgent or critical. I would be preferable to run bkops periodically and only when the card is idle to minimize the risk of reaching URGENT.
The specs says:
-----
Hosts shall still read the full status from the BKOPS_STATUS byte periodically and start background operations as needed.
-----
I'm thinking of checking BKOPS_STATUS when the card is idle and then run bkops even if level is only 1 (Operations outstanding – non critical). Would this make sense?
Regards,
Per
Hi!
Quoted 1 line
This patch only starts BKOPS if it's urgent or critical.
Almost, it starts BKOPS when it is urgent, which per spec means level 2 or 3, i.e. when performance is impacted or when it is critical. Better use the specs terminology as far as possible to relieve everyone of confusion.
Quoted 2 lines
I would be preferable to run bkops periodically and only when the card is idle to minimize the risk of reaching URGENT.
Well, you kind of need both. If the eMMC is kept busy to such an extent that the block device is never idling then you would definitely require this patch, right? Otherwise you may end up wasting the time between the last command sent and when the device has been deemed to be idle for long enough.
So basically the OP's patch fixes the case where, e.g. sustained (re-)writing, keeps the block device busy until and after it reaches the critical BKOPS level, while your proposal takes care of the other case where the block device is not accessed all the time.
Quoted 5 lines
The specs says:
-----
Hosts shall still read the full status from theBKOPS_STATUSbyte periodically and start background operations as needed.
-----
Sure, if there is idle time to do it, then why not.
If there is no idle time and URGENT_BKOPS is asserted, then the framework can not wait until the next idle period, but should issue BKOPS as soon as possible after the current command is finished.
Quoted 3 lines
I'm thinking of checking
BKOPS_STATUSwhen the card is idle and then run bkops even if level is only 1 (Operations outstanding – non critical). Would this make sense?
I guess this boils down to how you define idle..? Does it mean immediately after the current command has been fully serviced, or does it mean some arbitrary time after the last sent command has been fully serviced? My assumption is that you are refering to the latter, in which case certain access patterns may cause problems. So, how do _you_ define idle? :)
/ Sebastian
Hi Sebastian,
Quoted 9 lines · Sebastian Rasmussen
Hi!
Quoted 1 line
This patch only starts BKOPS if it's urgent or critical.
Almost, it starts BKOPS when it is urgent, which per spec means level 2 or 3, i.e. when performance is impacted or when it is critical. Better use the specs terminology as far as possible to relieve everyone of confusion.
Quoted 4 lines
Quoted 2 lines
I would be preferable to run bkops periodically and only when the card is idle to minimize the risk of reaching URGENT.
Well, you kind of need both.
Yes, this is what I mean. If the URGENT_BKOPS is set meaning (status 2 or 3) there is no escape, current solution will do fine. Periodical check is a complement, not a replacement. Must BKOPS always be deferred until performance is impacted?
About starvation.
What happens if the BKOPS never have time to finish because new writes are coming in all the time. Is it possible to starve the BKOPS-operation?
Will it come to a point when BKOPS must run without interruption?
Quoted 25 lines
extent that the block device is never idling then you would definitely require this patch, right? Otherwise you may end up wasting the time between the last command sent and when the device has been deemed to be idle for long enough.
So basically the OP's patch fixes the case where, e.g. sustained (re-)writing, keeps the block device busy until and after it reaches the critical BKOPS level, while your proposal takes care of the other case where the block device is not accessed all the time.
Quoted 5 lines
The specs says:
-----
Hosts shall still read the full status from theBKOPS_STATUSbyte periodically and start background operations as needed.
-----Sure, if there is idle time to do it, then why not.
If there is no idle time andURGENT_BKOPSis asserted, then the framework can not wait until the next idle period, but should issue BKOPS as soon as possible after the current command is finished.Quoted 3 lines
I'm thinking of checking
BKOPS_STATUSwhen the card is idle and then run bkops even if level is only 1 (Operations outstanding – non critical). Would this make sense?
Quoted 6 lines
I guess this boils down to how you define idle..? Does it mean immediately after the current command has been fully serviced, or does it mean some arbitrary time after the last sent command has been fully serviced? My assumption is that you are refering to the latter, in which case certain access patterns may cause problems. So, how do _you_ define idle? :)
My first point was just to raise my concern and start a discussion about this. If this turns out to be a good idea I be happy to look more into the details.
One question is:
Is it worth running BKOPS if the BKOPS_STATUS is only 1? I could run some tests comparing write performance when status is 0,1,2.
I don't know what the best place would be for a BKOPS_STATUS check. What comes to my mind is to use the same credentials that are used for power save. I need to look more closely into this in order to propose a patch.
Suspend? if suspend is requested one might check BKOPS_STATUS and return -EBUSY if BKOPS needs to be started.
Regards,
Per
Hi!
Quoted 2 lines
Quoted 1 line
Well, you kind of need both.
Periodical check is a complement, not a replacement.
Then we are indeed in agreement.
Quoted 1 line
Must BKOPS always be deferred until performance is impacted?
No, of course not. As you say doing BKOPS too late is not good, but also doing them too often is probably not wise either (will cause latency for interrupting BKOPS for too many requests in that case).
Quoted 5 lines
About starvation.
What happens if the BKOPS never have time to finish because new writes are coming in all the time. Is it possible to starve the BKOPS-operation?
Will it come to a point when BKOPS must run without interruption?
The 4.5 spec says that if the level is at critical then some operations may extend beyond their original timeouts due to undelayable maintenance operations. So I can not forsee that an eMMC might stop working because the level reached critical and the host did not start BKOPS periodically. So as far as I understand it you may HPI interrupt BKOPS at critical level in order to issue CMD25 (WRITE_MULTIPLE_BLOCK), but there is a good chance that this write will take a long time to complete.
Quoted 3 lines
One question is:
Is it worth running BKOPS if theBKOPS_STATUSis only 1? I could run some tests comparing write performance when status is 0,1,2.
The spec is likely intentionally arbitrary about what these levels mean in order to allow vendors to implement those differently.
Quoted 3 lines
I don't know what the best place would be for a
BKOPS_STATUScheck. What comes to my mind is to use the same credentials that are used for power save.
That seems like a good option, yes.
Quoted 2 lines
Suspend? if suspend is requested one might check
BKOPS_STATUSand return-EBUSYif BKOPS needs to be started.
Maybe, one could also choose to do this based on the level of course.
However now that I'm thinking about it, I don't think Jaehoon has taken care of the case where suspend happens while BKOPS are running in the background. I guess one has to issue HPI in that case to stop the BKOPS before going in to suspend, otherwise one risks cutting power to the card while BKOPS are running.
/ Sebastian
Quoted 44 lines · Sebastian Rasmussen
Hi!
Quoted 2 lines
Quoted 1 line
Well, you kind of need both.
Periodical check is a complement, not a replacement.
Then we are indeed in agreement.
Quoted 1 line
Must BKOPS always be deferred until performance is impacted?
No, of course not. As you say doing BKOPS too late is not good, but also doing them too often is probably not wise either (will cause latency for interrupting BKOPS for too many requests in that case).
Quoted 5 lines
About starvation.
What happens if the BKOPS never have time to finish because new writes are coming in all the time. Is it possible to starve the BKOPS-operation?
Will it come to a point when BKOPS must run without interruption?The 4.5 spec says that if the level is at critical then some operations may extend beyond their original timeouts due to undelayable maintenance operations. So I can not forsee that an eMMC might stop working because the level reached critical and the host did not start BKOPS periodically. So as far as I understand it you may HPI interrupt BKOPS at critical level in order to issue CMD25 (
WRITE_MULTIPLE_BLOCK), but there is a good chance that this write will take a long time to complete.Quoted 3 lines
One question is:
Is it worth running BKOPS if theBKOPS_STATUSis only 1? I could run some tests comparing write performance when status is 0,1,2.The spec is likely intentionally arbitrary about what these levels mean in order to allow vendors to implement those differently.
Quoted 3 lines
I don't know what the best place would be for a
BKOPS_STATUScheck. What comes to my mind is to use the same credentials that are used for power save.That seems like a good option, yes.
Quoted 2 lines
Suspend? if suspend is requested one might check
BKOPS_STATUSand return-EBUSYif BKOPS needs to be started.
Quoted 7 lines
Maybe, one could also choose to do this based on the level of course.
However now that I'm thinking about it, I don't think Jaehoon has taken care of the case where suspend happens while BKOPS are running in the background. I guess one has to issue HPI in that case to stop the BKOPS before going in to suspend, otherwise one risks cutting power to the card while BKOPS are running.
Sebastian,
Would you recommend to _not_ cut power while BKOPS? Is this documented anywhere? Or is it so that the BKOPS will resume when the card is powered up again?
Thanks,
Per
Hi Sebastian.
I have some question..
Maybe i think that my-patch should be worked only level-2/3..right?
Because URGENT_BKOPS bit in the EXCEPTION_EVENTS_STATUS is set whenever is either 2 or 3. In this case, host control with R1-type response.
But in level-0/1 case, need to check BKOPS_STATUS periodically. How did you understand that "periodically" means?
If host need to get BKOPS_STATUS periodically, maybe send CMD8 periodically. How periodically?
Best Regards,
Jaehoon Chung
Quoted 52 lines · Sebastian Rasmussen
Hi!
Quoted 1 line
This patch only starts BKOPS if it's urgent or critical.
Almost, it starts BKOPS when it is urgent, which per spec means level 2 or 3, i.e. when performance is impacted or when it is critical. Better use the specs terminology as far as possible to relieve everyone of confusion.
Quoted 2 lines
I would be preferable to run bkops periodically and only when the card is idle to minimize the risk of reaching URGENT.
Well, you kind of need both. If the eMMC is kept busy to such an extent that the block device is never idling then you would definitely require this patch, right? Otherwise you may end up wasting the time between the last command sent and when the device has been deemed to be idle for long enough.
So basically the OP's patch fixes the case where, e.g. sustained (re-)writing, keeps the block device busy until and after it reaches the critical BKOPS level, while your proposal takes care of the other case where the block device is not accessed all the time.
Quoted 5 lines
The specs says:
-----
Hosts shall still read the full status from theBKOPS_STATUSbyte periodically and start background operations as needed.
-----Sure, if there is idle time to do it, then why not.
If there is no idle time andURGENT_BKOPSis asserted, then the framework can not wait until the next idle period, but should issue BKOPS as soon as possible after the current command is finished.Quoted 3 lines
I'm thinking of checking
BKOPS_STATUSwhen the card is idle and then run bkops even if level is only 1 (Operations outstanding – non critical). Would this make sense?I guess this boils down to how you define idle..? Does it mean immediately after the current command has been fully serviced, or does it mean some arbitrary time after the last sent command has been fully serviced? My assumption is that you are refering to the latter, in which case certain access patterns may cause problems. So, how do _you_ define idle? :)
/ Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
Maybe i think that my-patch should be worked only level-2/3..right?
BecauseURGENT_BKOPSbit in theEXCEPTION_EVENTS_STATUSis set whenever is either 2 or 3. In this case, host control with R1-type response.
For 4.41 your patch is fine. For 4.5 I think it starts BKOPS too often.
For 4.5 devices the R1 response indicates that there is an exception event which may be have several different causes: PACKED_FAILURE, SYSPOOL_EXHAUSTED, DYNCAP_NEEDED or URGENT_BKOPS. But if the R1 response indicates an exception event it may be becuase of a cause which is not URGENT_BKOPS. So for 4.5 you must read EXCEPTION_EVENTS_STATUS to determine what the cause was.
Quoted 4 lines
But in level-0/1 case, need to check
BKOPS_STATUSperiodically. How did you understand that "periodically" means?
If host need to getBKOPS_STATUSperiodically, maybe send CMD8 periodically. How periodically?
Good question, I don't know yet. Problem this should be done when the system is otherwise idling, to not interfere with normal accesses (if you do I would expect you to get worse performance).
/ Sebastian
Quoted 13 lines · Sebastian Rasmussen
Quoted 3 lines
Maybe i think that my-patch should be worked only level-2/3..right?
BecauseURGENT_BKOPSbit in theEXCEPTION_EVENTS_STATUSis set whenever is either 2 or 3. In this case, host control with R1-type response.For 4.41 your patch is fine. For 4.5 I think it starts BKOPS too often.
For 4.5 devices the R1 response indicates that there is an exception event which may be have several different causes:
PACKED_FAILURE,SYSPOOL_EXHAUSTED,DYNCAP_NEEDEDorURGENT_BKOPS. But if the R1 response indicates an exception event it may be becuase of a cause which is notURGENT_BKOPS. So for 4.5 you must readEXCEPTION_EVENTS_STATUSto determine what the cause was.
Quoted 9 lines
Quoted 4 lines
But in level-0/1 case, need to check
BKOPS_STATUSperiodically. How did you understand that "periodically" means?
If host need to getBKOPS_STATUSperiodically, maybe send CMD8 periodically. How periodically?Good question, I don't know yet. Problem this should be done when the system is otherwise idling, to not interfere with normal accesses (if you do I would expect you to get worse performance).
I think there is a need for a 'mmc_maintenance' timer of some sort, which should run while idle. When it expires, all pending maintenance operations can be executed.. (Sanitize, Cache flush, BKOPS and RealTime Clock). This aligns also with
the update frequency requirements for RTC.
This would reduce the need for running such plumbing operations on the hot path.
Quoted 26 lines · Per Forlin
Review mmc_start_request(struct mmc_host *host, struct
Quoted 2 lines · Jaehoon Chung <jh80.chung <at> samsung.com> writes:
+++
b/drivers/mmc/core/core.c(quoted diff) +0
-0@@ -238,6 +238,50 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request*mrq)drivers/mmc/core/core.c mmc_start_request(struct mmc_host *host, struct mmc_request *mrq) · line 248
Quoted 11 lines
drivers/mmc/core/core.c +8
-0host->ops->request (host, mrq); } +/** +* mmc_start_bkops - start BKOPS for supported cards +* @card: MMC card to start BKOPS +* +* Start background operations whenever requested. +* when the urgent BKOPS bit is set in a R1 command response +* then background operations should be started immediately. +*/ This patch only starts BKOPS if it's urgent or critical. I would be preferable to run bkops periodically and only when the card is idle to minimize the risk of reaching URGENT.
The specs says:
-----
Hosts shall still read the full status from theBKOPS_STATUSbyte periodically and start background operations as needed.
-----
Quoted 4 lines
I'm thinking of checking
BKOPS_STATUSwhen the card is idle and then run bkops even if level is only 1 (Operations outstanding – non critical). Would this make sense?
host shall check the BKOPS_STATUS periodically..i will add this point.. (i think that need to check EXT_CSD register periodically.)
Thanks,
Jaehoon Chung
Quoted 9 lines
Regards,
Per--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html