[PATCH] MMC-4.5 Data Tag Support

[PATCH] MMC-4.5 Data Tag Support

[Saugata Das]

From: Saugata Das <saugata.das@linaro.org>

MMC-4.5 data tag feature will be used to store the file system meta-data in the
tagged region of eMMC. This will improve the write and subsequent read transfer
time for the meta data.

Signed-off-by: Saugata Das <saugata.das@linaro.org>
---
 drivers/mmc/card/block.c |   17 +++++++++++++++--
 drivers/mmc/core/mmc.c   |   14 ++++++++++++++
 include/linux/mmc/card.h |    2 ++
 include/linux/mmc/mmc.h  |    3 +++
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a1cb21f..af3b6c3 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 	struct mmc_blk_request *brq = &mqrq->brq;
 	struct request *req = mqrq->req;
 	struct mmc_blk_data *md = mq->data;
+	bool do_data_tag;
 
 	/*
 	 * Reliable writes are used to implement Forced Unit Access and
@@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 		mmc_apply_rel_rw(brq, card, req);
 
 	/*
+	 * Data tag is used only during writing meta data to speed
+	 * up write and any subsequent read of this meta data
+	 */
+	do_data_tag = (card->ext_csd.data_tag_unit_size) &&
+		(req->cmd_flags & REQ_META) &&
+		(rq_data_dir(req) == WRITE) &&
+		((brq->data.blocks * brq->data.blksz) >=
+		card->ext_csd.data_tag_unit_size) ;
+
+	/*
 	 * Pre-defined multi-block transfers are preferable to
 	 * open ended-ones (and necessary for reliable writes).
 	 * However, it is not sufficient to just send CMD23,
@@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 
 	if ((md->flags & MMC_BLK_CMD23) &&
 	    mmc_op_multi(brq->cmd.opcode) &&
-	    (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
+	    (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
+		do_data_tag)) {
 		brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
 		brq->sbc.arg = brq->data.blocks |
-			(do_rel_wr ? (1 << 31) : 0);
+			(do_rel_wr ? (1 << 31) : 0) |
+			(do_data_tag ? (1 << 29) : 0);
 		brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
 		brq->mrq.sbc = &brq->sbc;
 	}
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index dbf421a..244049b 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
 			ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
 			ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
 			ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
+
+		if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
+			card->ext_csd.data_sector_size = 4096;
+		else
+			card->ext_csd.data_sector_size = 512;
+
+		if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
+			(ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
+			card->ext_csd.data_tag_unit_size =
+			((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
+			(card->ext_csd.data_sector_size);
+		} else {
+			card->ext_csd.data_tag_unit_size = 0;
+		}
 	}
 
 out:
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 415f2db..a55668d 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -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 */
+	unsigned int		data_sector_size;	/* 512Bytes or 4KB */
+	unsigned int		data_tag_unit_size;	/* DATA TAG UNIT size */
 	u8			raw_partition_support;	/* 160 */
 	u8			raw_erased_mem_count;	/* 181 */
 	u8			raw_ext_csd_structure;	/* 194 */
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index 0e71356..e076f7f 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -273,6 +273,7 @@ struct _mmc_csd {
 #define EXT_CSD_FLUSH_CACHE		32      /* W */
 #define EXT_CSD_CACHE_CTRL		33      /* R/W */
 #define EXT_CSD_POWER_OFF_NOTIFICATION	34	/* R/W */
+#define EXT_CSD_DATA_SECTOR_SIZE	61	/* R */
 #define EXT_CSD_GP_SIZE_MULT		143	/* R/W */
 #define EXT_CSD_PARTITION_ATTRIBUTE	156	/* R/W */
 #define EXT_CSD_PARTITION_SUPPORT	160	/* RO */
@@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE		498	/* RO */
+#define EXT_CSD_DATA_TAG_SUPPORT	499	/* RO */
 #define EXT_CSD_HPI_FEATURES		503	/* RO */
 
 /*
-- 
1.7.4.3

Re: [PATCH] MMC-4.5 Data Tag Support

[S, Venkatraman]

On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com> wrote:
> From: Saugata Das <saugata.das@linaro.org>
>
> MMC-4.5 data tag feature will be used to store the file system meta-data in the
> tagged region of eMMC. This will improve the write and subsequent read transfer
> time for the meta data.
>
> Signed-off-by: Saugata Das <saugata.das@linaro.org>
> ---
>  drivers/mmc/card/block.c |   17 +++++++++++++++--
>  drivers/mmc/core/mmc.c   |   14 ++++++++++++++
>  include/linux/mmc/card.h |    2 ++
>  include/linux/mmc/mmc.h  |    3 +++
>  4 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index a1cb21f..af3b6c3 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>        struct mmc_blk_request *brq = &mqrq->brq;
>        struct request *req = mqrq->req;
>        struct mmc_blk_data *md = mq->data;
> +       bool do_data_tag;
>
>        /*
>         * Reliable writes are used to implement Forced Unit Access and
> @@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>                mmc_apply_rel_rw(brq, card, req);
>
>        /*
> +        * Data tag is used only during writing meta data to speed
> +        * up write and any subsequent read of this meta data
> +        */
> +       do_data_tag = (card->ext_csd.data_tag_unit_size) &&
> +               (req->cmd_flags & REQ_META) &&
> +               (rq_data_dir(req) == WRITE) &&
> +               ((brq->data.blocks * brq->data.blksz) >=
> +               card->ext_csd.data_tag_unit_size) ;
> +
> +       /*
>         * Pre-defined multi-block transfers are preferable to
>         * open ended-ones (and necessary for reliable writes).
>         * However, it is not sufficient to just send CMD23,
> @@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>
>        if ((md->flags & MMC_BLK_CMD23) &&
>            mmc_op_multi(brq->cmd.opcode) &&
> -           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
> +           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
> +               do_data_tag)) {
>                brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
>                brq->sbc.arg = brq->data.blocks |
> -                       (do_rel_wr ? (1 << 31) : 0);
> +                       (do_rel_wr ? (1 << 31) : 0) |
> +                       (do_data_tag ? (1 << 29) : 0);
>                brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>                brq->mrq.sbc = &brq->sbc;
>        }
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index dbf421a..244049b 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>                        ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
>                        ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
>                        ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> +
> +               if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
> +                       card->ext_csd.data_sector_size = 4096;
> +               else
> +                       card->ext_csd.data_sector_size = 512;
> +
> +               if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
> +                       (ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
> +                       card->ext_csd.data_tag_unit_size =
> +                       ((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
> +                       (card->ext_csd.data_sector_size);
> +               } else {
> +                       card->ext_csd.data_tag_unit_size = 0;
> +               }
>        }
>
>  out:
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 415f2db..a55668d 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -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 */
> +       unsigned int            data_sector_size;       /* 512Bytes or 4KB */
> +       unsigned int            data_tag_unit_size;     /* DATA TAG UNIT size */
>        u8                      raw_partition_support;  /* 160 */
>        u8                      raw_erased_mem_count;   /* 181 */
>        u8                      raw_ext_csd_structure;  /* 194 */
> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
> index 0e71356..e076f7f 100644
> --- a/include/linux/mmc/mmc.h
> +++ b/include/linux/mmc/mmc.h
> @@ -273,6 +273,7 @@ struct _mmc_csd {
>  #define EXT_CSD_FLUSH_CACHE            32      /* W */
>  #define EXT_CSD_CACHE_CTRL             33      /* R/W */
>  #define EXT_CSD_POWER_OFF_NOTIFICATION 34      /* R/W */
> +#define EXT_CSD_DATA_SECTOR_SIZE       61      /* R */
>  #define EXT_CSD_GP_SIZE_MULT           143     /* R/W */
>  #define EXT_CSD_PARTITION_ATTRIBUTE    156     /* R/W */
>  #define EXT_CSD_PARTITION_SUPPORT      160     /* RO */
> @@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE          498     /* RO */
> +#define EXT_CSD_DATA_TAG_SUPPORT       499     /* RO */
>  #define EXT_CSD_HPI_FEATURES           503     /* RO */
>
>  /*
> --
> 1.7.4.3
>

I agree..
Reviewed-by: Venkatraman S <svenkatr@ti.com>

Re: [PATCH] MMC-4.5 Data Tag Support

[Girish K S]

On 21 December 2011 13:09, Saugata Das <saugata.das@stericsson.com> wrote:
> From: Saugata Das <saugata.das@linaro.org>
>
> MMC-4.5 data tag feature will be used to store the file system meta-data in the
> tagged region of eMMC. This will improve the write and subsequent read transfer
> time for the meta data.
>
> Signed-off-by: Saugata Das <saugata.das@linaro.org>
> ---
>  drivers/mmc/card/block.c |   17 +++++++++++++++--
>  drivers/mmc/core/mmc.c   |   14 ++++++++++++++
>  include/linux/mmc/card.h |    2 ++
>  include/linux/mmc/mmc.h  |    3 +++
>  4 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index a1cb21f..af3b6c3 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>        struct mmc_blk_request *brq = &mqrq->brq;
>        struct request *req = mqrq->req;
>        struct mmc_blk_data *md = mq->data;
> +       bool do_data_tag;
>
>        /*
>         * Reliable writes are used to implement Forced Unit Access and
> @@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>                mmc_apply_rel_rw(brq, card, req);
>
>        /*
> +        * Data tag is used only during writing meta data to speed
> +        * up write and any subsequent read of this meta data
> +        */
> +       do_data_tag = (card->ext_csd.data_tag_unit_size) &&
> +               (req->cmd_flags & REQ_META) &&
> +               (rq_data_dir(req) == WRITE) &&
> +               ((brq->data.blocks * brq->data.blksz) >=
> +               card->ext_csd.data_tag_unit_size) ;
> +
> +       /*
>         * Pre-defined multi-block transfers are preferable to
>         * open ended-ones (and necessary for reliable writes).
>         * However, it is not sufficient to just send CMD23,
> @@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>
>        if ((md->flags & MMC_BLK_CMD23) &&
>            mmc_op_multi(brq->cmd.opcode) &&
> -           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
> +           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
> +               do_data_tag)) {
>                brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
>                brq->sbc.arg = brq->data.blocks |
> -                       (do_rel_wr ? (1 << 31) : 0);
> +                       (do_rel_wr ? (1 << 31) : 0) |
> +                       (do_data_tag ? (1 << 29) : 0);
>                brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>                brq->mrq.sbc = &brq->sbc;
>        }
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index dbf421a..244049b 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>                        ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
>                        ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
>                        ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> +
> +               if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
> +                       card->ext_csd.data_sector_size = 4096;
> +               else
> +                       card->ext_csd.data_sector_size = 512;
> +
> +               if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
> +                       (ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
> +                       card->ext_csd.data_tag_unit_size =
> +                       ((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
> +                       (card->ext_csd.data_sector_size);
> +               } else {
> +                       card->ext_csd.data_tag_unit_size = 0;
> +               }
>        }
>
>  out:
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 415f2db..a55668d 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -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 */
> +       unsigned int            data_sector_size;       /* 512Bytes or 4KB */
> +       unsigned int            data_tag_unit_size;     /* DATA TAG UNIT size */
>        u8                      raw_partition_support;  /* 160 */
>        u8                      raw_erased_mem_count;   /* 181 */
>        u8                      raw_ext_csd_structure;  /* 194 */
> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
> index 0e71356..e076f7f 100644
> --- a/include/linux/mmc/mmc.h
> +++ b/include/linux/mmc/mmc.h
> @@ -273,6 +273,7 @@ struct _mmc_csd {
>  #define EXT_CSD_FLUSH_CACHE            32      /* W */
>  #define EXT_CSD_CACHE_CTRL             33      /* R/W */
>  #define EXT_CSD_POWER_OFF_NOTIFICATION 34      /* R/W */
> +#define EXT_CSD_DATA_SECTOR_SIZE       61      /* R */
>  #define EXT_CSD_GP_SIZE_MULT           143     /* R/W */
>  #define EXT_CSD_PARTITION_ATTRIBUTE    156     /* R/W */
>  #define EXT_CSD_PARTITION_SUPPORT      160     /* RO */
> @@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE          498     /* RO */
> +#define EXT_CSD_DATA_TAG_SUPPORT       499     /* RO */
>  #define EXT_CSD_HPI_FEATURES           503     /* RO */
>
>  /*

TAG_RES_SIZE in the extended csd register mentions about the resource
size utilised by the device to keep data tag.
This can be used to avoid the data exhaustion case.

> --
> 1.7.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MMC-4.5 Data Tag Support

[Saugata Das]

On 21 December 2011 16:23, Girish K S <girish.shivananjappa@linaro.org> wrote:
> On 21 December 2011 13:09, Saugata Das <saugata.das@stericsson.com> wrote:
>> From: Saugata Das <saugata.das@linaro.org>
>>
>> MMC-4.5 data tag feature will be used to store the file system meta-data in the
>> tagged region of eMMC. This will improve the write and subsequent read transfer
>> time for the meta data.
>>
>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>> ---
>>  drivers/mmc/card/block.c |   17 +++++++++++++++--
>>  drivers/mmc/core/mmc.c   |   14 ++++++++++++++
>>  include/linux/mmc/card.h |    2 ++
>>  include/linux/mmc/mmc.h  |    3 +++
>>  4 files changed, 34 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index a1cb21f..af3b6c3 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>        struct mmc_blk_request *brq = &mqrq->brq;
>>        struct request *req = mqrq->req;
>>        struct mmc_blk_data *md = mq->data;
>> +       bool do_data_tag;
>>
>>        /*
>>         * Reliable writes are used to implement Forced Unit Access and
>> @@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>                mmc_apply_rel_rw(brq, card, req);
>>
>>        /*
>> +        * Data tag is used only during writing meta data to speed
>> +        * up write and any subsequent read of this meta data
>> +        */
>> +       do_data_tag = (card->ext_csd.data_tag_unit_size) &&
>> +               (req->cmd_flags & REQ_META) &&
>> +               (rq_data_dir(req) == WRITE) &&
>> +               ((brq->data.blocks * brq->data.blksz) >=
>> +               card->ext_csd.data_tag_unit_size) ;
>> +
>> +       /*
>>         * Pre-defined multi-block transfers are preferable to
>>         * open ended-ones (and necessary for reliable writes).
>>         * However, it is not sufficient to just send CMD23,
>> @@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>
>>        if ((md->flags & MMC_BLK_CMD23) &&
>>            mmc_op_multi(brq->cmd.opcode) &&
>> -           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
>> +           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
>> +               do_data_tag)) {
>>                brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
>>                brq->sbc.arg = brq->data.blocks |
>> -                       (do_rel_wr ? (1 << 31) : 0);
>> +                       (do_rel_wr ? (1 << 31) : 0) |
>> +                       (do_data_tag ? (1 << 29) : 0);
>>                brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>                brq->mrq.sbc = &brq->sbc;
>>        }
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index dbf421a..244049b 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>>                        ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
>>                        ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
>>                        ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
>> +
>> +               if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
>> +                       card->ext_csd.data_sector_size = 4096;
>> +               else
>> +                       card->ext_csd.data_sector_size = 512;
>> +
>> +               if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
>> +                       (ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
>> +                       card->ext_csd.data_tag_unit_size =
>> +                       ((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
>> +                       (card->ext_csd.data_sector_size);
>> +               } else {
>> +                       card->ext_csd.data_tag_unit_size = 0;
>> +               }
>>        }
>>
>>  out:
>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>> index 415f2db..a55668d 100644
>> --- a/include/linux/mmc/card.h
>> +++ b/include/linux/mmc/card.h
>> @@ -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 */
>> +       unsigned int            data_sector_size;       /* 512Bytes or 4KB */
>> +       unsigned int            data_tag_unit_size;     /* DATA TAG UNIT size */
>>        u8                      raw_partition_support;  /* 160 */
>>        u8                      raw_erased_mem_count;   /* 181 */
>>        u8                      raw_ext_csd_structure;  /* 194 */
>> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
>> index 0e71356..e076f7f 100644
>> --- a/include/linux/mmc/mmc.h
>> +++ b/include/linux/mmc/mmc.h
>> @@ -273,6 +273,7 @@ struct _mmc_csd {
>>  #define EXT_CSD_FLUSH_CACHE            32      /* W */
>>  #define EXT_CSD_CACHE_CTRL             33      /* R/W */
>>  #define EXT_CSD_POWER_OFF_NOTIFICATION 34      /* R/W */
>> +#define EXT_CSD_DATA_SECTOR_SIZE       61      /* R */
>>  #define EXT_CSD_GP_SIZE_MULT           143     /* R/W */
>>  #define EXT_CSD_PARTITION_ATTRIBUTE    156     /* R/W */
>>  #define EXT_CSD_PARTITION_SUPPORT      160     /* RO */
>> @@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE          498     /* RO */
>> +#define EXT_CSD_DATA_TAG_SUPPORT       499     /* RO */
>>  #define EXT_CSD_HPI_FEATURES           503     /* RO */
>>
>>  /*
>
> TAG_RES_SIZE in the extended csd register mentions about the resource
> size utilised by the device to keep data tag.
> This can be used to avoid the data exhaustion case.
>

Once the tag resource is exhausted, the further tag data writes will
be ignored by eMMC and those will be written to the non-tagged or
default area of eMMC (ref to section 6.6.25 in 4.5 spec : "The data
shall still be written to the device regardless of the resources
exhaustion; however, it may not have the improved characteristics").
So, host driver need not do additional tracking of the amount of data
written using tag option.


>> --
>> 1.7.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MMC-4.5 Data Tag Support

[Girish K S]

On 21 December 2011 16:42, Saugata Das <saugata.das@linaro.org> wrote:
> On 21 December 2011 16:23, Girish K S <girish.shivananjappa@linaro.org> wrote:
>> On 21 December 2011 13:09, Saugata Das <saugata.das@stericsson.com> wrote:
>>> From: Saugata Das <saugata.das@linaro.org>
>>>
>>> MMC-4.5 data tag feature will be used to store the file system meta-data in the
>>> tagged region of eMMC. This will improve the write and subsequent read transfer
>>> time for the meta data.
>>>
>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>> ---
>>>  drivers/mmc/card/block.c |   17 +++++++++++++++--
>>>  drivers/mmc/core/mmc.c   |   14 ++++++++++++++
>>>  include/linux/mmc/card.h |    2 ++
>>>  include/linux/mmc/mmc.h  |    3 +++
>>>  4 files changed, 34 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>>> index a1cb21f..af3b6c3 100644
>>> --- a/drivers/mmc/card/block.c
>>> +++ b/drivers/mmc/card/block.c
>>> @@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>>        struct mmc_blk_request *brq = &mqrq->brq;
>>>        struct request *req = mqrq->req;
>>>        struct mmc_blk_data *md = mq->data;
>>> +       bool do_data_tag;
>>>
>>>        /*
>>>         * Reliable writes are used to implement Forced Unit Access and
>>> @@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>>                mmc_apply_rel_rw(brq, card, req);
>>>
>>>        /*
>>> +        * Data tag is used only during writing meta data to speed
>>> +        * up write and any subsequent read of this meta data
>>> +        */
>>> +       do_data_tag = (card->ext_csd.data_tag_unit_size) &&
>>> +               (req->cmd_flags & REQ_META) &&
>>> +               (rq_data_dir(req) == WRITE) &&
>>> +               ((brq->data.blocks * brq->data.blksz) >=
>>> +               card->ext_csd.data_tag_unit_size) ;
>>> +
>>> +       /*
>>>         * Pre-defined multi-block transfers are preferable to
>>>         * open ended-ones (and necessary for reliable writes).
>>>         * However, it is not sufficient to just send CMD23,
>>> @@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>>
>>>        if ((md->flags & MMC_BLK_CMD23) &&
>>>            mmc_op_multi(brq->cmd.opcode) &&
>>> -           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
>>> +           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
>>> +               do_data_tag)) {
>>>                brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
>>>                brq->sbc.arg = brq->data.blocks |
>>> -                       (do_rel_wr ? (1 << 31) : 0);
>>> +                       (do_rel_wr ? (1 << 31) : 0) |
>>> +                       (do_data_tag ? (1 << 29) : 0);
>>>                brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>>                brq->mrq.sbc = &brq->sbc;
>>>        }
>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>>> index dbf421a..244049b 100644
>>> --- a/drivers/mmc/core/mmc.c
>>> +++ b/drivers/mmc/core/mmc.c
>>> @@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>>>                        ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
>>>                        ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
>>>                        ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
>>> +
>>> +               if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
>>> +                       card->ext_csd.data_sector_size = 4096;
>>> +               else
>>> +                       card->ext_csd.data_sector_size = 512;
>>> +
>>> +               if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
>>> +                       (ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
>>> +                       card->ext_csd.data_tag_unit_size =
>>> +                       ((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
>>> +                       (card->ext_csd.data_sector_size);
>>> +               } else {
>>> +                       card->ext_csd.data_tag_unit_size = 0;
>>> +               }
>>>        }
>>>
>>>  out:
>>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>>> index 415f2db..a55668d 100644
>>> --- a/include/linux/mmc/card.h
>>> +++ b/include/linux/mmc/card.h
>>> @@ -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 */
>>> +       unsigned int            data_sector_size;       /* 512Bytes or 4KB */
>>> +       unsigned int            data_tag_unit_size;     /* DATA TAG UNIT size */
>>>        u8                      raw_partition_support;  /* 160 */
>>>        u8                      raw_erased_mem_count;   /* 181 */
>>>        u8                      raw_ext_csd_structure;  /* 194 */
>>> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
>>> index 0e71356..e076f7f 100644
>>> --- a/include/linux/mmc/mmc.h
>>> +++ b/include/linux/mmc/mmc.h
>>> @@ -273,6 +273,7 @@ struct _mmc_csd {
>>>  #define EXT_CSD_FLUSH_CACHE            32      /* W */
>>>  #define EXT_CSD_CACHE_CTRL             33      /* R/W */
>>>  #define EXT_CSD_POWER_OFF_NOTIFICATION 34      /* R/W */
>>> +#define EXT_CSD_DATA_SECTOR_SIZE       61      /* R */
>>>  #define EXT_CSD_GP_SIZE_MULT           143     /* R/W */
>>>  #define EXT_CSD_PARTITION_ATTRIBUTE    156     /* R/W */
>>>  #define EXT_CSD_PARTITION_SUPPORT      160     /* RO */
>>> @@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE          498     /* RO */
>>> +#define EXT_CSD_DATA_TAG_SUPPORT       499     /* RO */
>>>  #define EXT_CSD_HPI_FEATURES           503     /* RO */
>>>
>>>  /*
>>
>> TAG_RES_SIZE in the extended csd register mentions about the resource
>> size utilised by the device to keep data tag.
>> This can be used to avoid the data exhaustion case.
>>
>
> Once the tag resource is exhausted, the further tag data writes will
> be ignored by eMMC and those will be written to the non-tagged or
> default area of eMMC (ref to section 6.6.25 in 4.5 spec : "The data
> shall still be written to the device regardless of the resources
> exhaustion; however, it may not have the improved characteristics").
> So, host driver need not do additional tracking of the amount of data
> written using tag option.
It also says
The host should manage the tag operation counting in order to avoid
resources exhaustion. If it happens
the host should executes operations having the final effect of freeing
some of the resources (for instance
by issuing a Trim command on some of the addresses containing System Data).

>
>
>>> --
>>> 1.7.4.3
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MMC-4.5 Data Tag Support

[Saugata Das]

On 21 December 2011 17:01, Girish K S <girish.shivananjappa@linaro.org> wrote:
> On 21 December 2011 16:42, Saugata Das <saugata.das@linaro.org> wrote:
>> On 21 December 2011 16:23, Girish K S <girish.shivananjappa@linaro.org> wrote:
>>> On 21 December 2011 13:09, Saugata Das <saugata.das@stericsson.com> wrote:
>>>> From: Saugata Das <saugata.das@linaro.org>
>>>>
>>>> MMC-4.5 data tag feature will be used to store the file system meta-data in the
>>>> tagged region of eMMC. This will improve the write and subsequent read transfer
>>>> time for the meta data.
>>>>
>>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>>> ---
>>>>  drivers/mmc/card/block.c |   17 +++++++++++++++--
>>>>  drivers/mmc/core/mmc.c   |   14 ++++++++++++++
>>>>  include/linux/mmc/card.h |    2 ++
>>>>  include/linux/mmc/mmc.h  |    3 +++
>>>>  4 files changed, 34 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>>>> index a1cb21f..af3b6c3 100644
>>>> --- a/drivers/mmc/card/block.c
>>>> +++ b/drivers/mmc/card/block.c
>>>> @@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>>>        struct mmc_blk_request *brq = &mqrq->brq;
>>>>        struct request *req = mqrq->req;
>>>>        struct mmc_blk_data *md = mq->data;
>>>> +       bool do_data_tag;
>>>>
>>>>        /*
>>>>         * Reliable writes are used to implement Forced Unit Access and
>>>> @@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>>>                mmc_apply_rel_rw(brq, card, req);
>>>>
>>>>        /*
>>>> +        * Data tag is used only during writing meta data to speed
>>>> +        * up write and any subsequent read of this meta data
>>>> +        */
>>>> +       do_data_tag = (card->ext_csd.data_tag_unit_size) &&
>>>> +               (req->cmd_flags & REQ_META) &&
>>>> +               (rq_data_dir(req) == WRITE) &&
>>>> +               ((brq->data.blocks * brq->data.blksz) >=
>>>> +               card->ext_csd.data_tag_unit_size) ;
>>>> +
>>>> +       /*
>>>>         * Pre-defined multi-block transfers are preferable to
>>>>         * open ended-ones (and necessary for reliable writes).
>>>>         * However, it is not sufficient to just send CMD23,
>>>> @@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>>>>
>>>>        if ((md->flags & MMC_BLK_CMD23) &&
>>>>            mmc_op_multi(brq->cmd.opcode) &&
>>>> -           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
>>>> +           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
>>>> +               do_data_tag)) {
>>>>                brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
>>>>                brq->sbc.arg = brq->data.blocks |
>>>> -                       (do_rel_wr ? (1 << 31) : 0);
>>>> +                       (do_rel_wr ? (1 << 31) : 0) |
>>>> +                       (do_data_tag ? (1 << 29) : 0);
>>>>                brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>>>                brq->mrq.sbc = &brq->sbc;
>>>>        }
>>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>>>> index dbf421a..244049b 100644
>>>> --- a/drivers/mmc/core/mmc.c
>>>> +++ b/drivers/mmc/core/mmc.c
>>>> @@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>>>>                        ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
>>>>                        ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
>>>>                        ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
>>>> +
>>>> +               if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
>>>> +                       card->ext_csd.data_sector_size = 4096;
>>>> +               else
>>>> +                       card->ext_csd.data_sector_size = 512;
>>>> +
>>>> +               if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
>>>> +                       (ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
>>>> +                       card->ext_csd.data_tag_unit_size =
>>>> +                       ((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
>>>> +                       (card->ext_csd.data_sector_size);
>>>> +               } else {
>>>> +                       card->ext_csd.data_tag_unit_size = 0;
>>>> +               }
>>>>        }
>>>>
>>>>  out:
>>>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>>>> index 415f2db..a55668d 100644
>>>> --- a/include/linux/mmc/card.h
>>>> +++ b/include/linux/mmc/card.h
>>>> @@ -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 */
>>>> +       unsigned int            data_sector_size;       /* 512Bytes or 4KB */
>>>> +       unsigned int            data_tag_unit_size;     /* DATA TAG UNIT size */
>>>>        u8                      raw_partition_support;  /* 160 */
>>>>        u8                      raw_erased_mem_count;   /* 181 */
>>>>        u8                      raw_ext_csd_structure;  /* 194 */
>>>> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
>>>> index 0e71356..e076f7f 100644
>>>> --- a/include/linux/mmc/mmc.h
>>>> +++ b/include/linux/mmc/mmc.h
>>>> @@ -273,6 +273,7 @@ struct _mmc_csd {
>>>>  #define EXT_CSD_FLUSH_CACHE            32      /* W */
>>>>  #define EXT_CSD_CACHE_CTRL             33      /* R/W */
>>>>  #define EXT_CSD_POWER_OFF_NOTIFICATION 34      /* R/W */
>>>> +#define EXT_CSD_DATA_SECTOR_SIZE       61      /* R */
>>>>  #define EXT_CSD_GP_SIZE_MULT           143     /* R/W */
>>>>  #define EXT_CSD_PARTITION_ATTRIBUTE    156     /* R/W */
>>>>  #define EXT_CSD_PARTITION_SUPPORT      160     /* RO */
>>>> @@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE          498     /* RO */
>>>> +#define EXT_CSD_DATA_TAG_SUPPORT       499     /* RO */
>>>>  #define EXT_CSD_HPI_FEATURES           503     /* RO */
>>>>
>>>>  /*
>>>
>>> TAG_RES_SIZE in the extended csd register mentions about the resource
>>> size utilised by the device to keep data tag.
>>> This can be used to avoid the data exhaustion case.
>>>
>>
>> Once the tag resource is exhausted, the further tag data writes will
>> be ignored by eMMC and those will be written to the non-tagged or
>> default area of eMMC (ref to section 6.6.25 in 4.5 spec : "The data
>> shall still be written to the device regardless of the resources
>> exhaustion; however, it may not have the improved characteristics").
>> So, host driver need not do additional tracking of the amount of data
>> written using tag option.
> It also says
> The host should manage the tag operation counting in order to avoid
> resources exhaustion. If it happens
> the host should executes operations having the final effect of freeing
> some of the resources (for instance
> by issuing a Trim command on some of the addresses containing System Data).
>

Trim will happen when some blocks are unmapped by file system and it
will take care of the tagged region as well. We do not need to modify
anything for this.

Assume, host does the tracking of tagged writes. When it crosses
TAG_RES_SIZE or when the SYSPOOL_EXHAUSTED event is received, it stops
using tagged write and use default area instead for writing. This same
objective is achieved by just letting eMMC to do the tracking of the
tagged area usage which is simpler from host driver perspective. The
specification does not say that using tagged flag  when the tagged
resource is exhausted is disallowed.


>>
>>
>>>> --
>>>> 1.7.4.3
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> 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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MMC-4.5 Data Tag Support

[S, Venkatraman]

On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com> wrote:
> From: Saugata Das <saugata.das@linaro.org>
>
> MMC-4.5 data tag feature will be used to store the file system meta-data in the
> tagged region of eMMC. This will improve the write and subsequent read transfer
> time for the meta data.
>
> Signed-off-by: Saugata Das <saugata.das@linaro.org>

I tested this on a device which supports a data tag unit size of 8K.
Tested-by: Venkatraman S <svenkatr@ti.com>

Chris,
  Can this go into 3.3 ?

> ---
>  drivers/mmc/card/block.c |   17 +++++++++++++++--
>  drivers/mmc/core/mmc.c   |   14 ++++++++++++++
>  include/linux/mmc/card.h |    2 ++
>  include/linux/mmc/mmc.h  |    3 +++
>  4 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index a1cb21f..af3b6c3 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -995,6 +995,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>        struct mmc_blk_request *brq = &mqrq->brq;
>        struct request *req = mqrq->req;
>        struct mmc_blk_data *md = mq->data;
> +       bool do_data_tag;
>
>        /*
>         * Reliable writes are used to implement Forced Unit Access and
> @@ -1071,6 +1072,16 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>                mmc_apply_rel_rw(brq, card, req);
>
>        /*
> +        * Data tag is used only during writing meta data to speed
> +        * up write and any subsequent read of this meta data
> +        */
> +       do_data_tag = (card->ext_csd.data_tag_unit_size) &&
> +               (req->cmd_flags & REQ_META) &&
> +               (rq_data_dir(req) == WRITE) &&
> +               ((brq->data.blocks * brq->data.blksz) >=
> +               card->ext_csd.data_tag_unit_size) ;
> +
> +       /*
>         * Pre-defined multi-block transfers are preferable to
>         * open ended-ones (and necessary for reliable writes).
>         * However, it is not sufficient to just send CMD23,
> @@ -1091,10 +1102,12 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
>
>        if ((md->flags & MMC_BLK_CMD23) &&
>            mmc_op_multi(brq->cmd.opcode) &&
> -           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23))) {
> +           (do_rel_wr || !(card->quirks & MMC_QUIRK_BLK_NO_CMD23) ||
> +               do_data_tag)) {
>                brq->sbc.opcode = MMC_SET_BLOCK_COUNT;
>                brq->sbc.arg = brq->data.blocks |
> -                       (do_rel_wr ? (1 << 31) : 0);
> +                       (do_rel_wr ? (1 << 31) : 0) |
> +                       (do_data_tag ? (1 << 29) : 0);
>                brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>                brq->mrq.sbc = &brq->sbc;
>        }
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index dbf421a..244049b 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -488,6 +488,20 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>                        ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
>                        ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
>                        ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> +
> +               if (ext_csd[EXT_CSD_DATA_SECTOR_SIZE] == 1)
> +                       card->ext_csd.data_sector_size = 4096;
> +               else
> +                       card->ext_csd.data_sector_size = 512;
> +
> +               if ((ext_csd[EXT_CSD_DATA_TAG_SUPPORT] & 1) &&
> +                       (ext_csd[EXT_CSD_TAG_UNIT_SIZE] <= 8)) {
> +                       card->ext_csd.data_tag_unit_size =
> +                       ((unsigned int) 1 << ext_csd[EXT_CSD_TAG_UNIT_SIZE]) *
> +                       (card->ext_csd.data_sector_size);
> +               } else {
> +                       card->ext_csd.data_tag_unit_size = 0;
> +               }
>        }
>
>  out:
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 415f2db..a55668d 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -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 */
> +       unsigned int            data_sector_size;       /* 512Bytes or 4KB */
> +       unsigned int            data_tag_unit_size;     /* DATA TAG UNIT size */
>        u8                      raw_partition_support;  /* 160 */
>        u8                      raw_erased_mem_count;   /* 181 */
>        u8                      raw_ext_csd_structure;  /* 194 */
> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
> index 0e71356..e076f7f 100644
> --- a/include/linux/mmc/mmc.h
> +++ b/include/linux/mmc/mmc.h
> @@ -273,6 +273,7 @@ struct _mmc_csd {
>  #define EXT_CSD_FLUSH_CACHE            32      /* W */
>  #define EXT_CSD_CACHE_CTRL             33      /* R/W */
>  #define EXT_CSD_POWER_OFF_NOTIFICATION 34      /* R/W */
> +#define EXT_CSD_DATA_SECTOR_SIZE       61      /* R */
>  #define EXT_CSD_GP_SIZE_MULT           143     /* R/W */
>  #define EXT_CSD_PARTITION_ATTRIBUTE    156     /* R/W */
>  #define EXT_CSD_PARTITION_SUPPORT      160     /* RO */
> @@ -313,6 +314,8 @@ 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_TAG_UNIT_SIZE          498     /* RO */
> +#define EXT_CSD_DATA_TAG_SUPPORT       499     /* RO */
>  #define EXT_CSD_HPI_FEATURES           503     /* RO */
>
>  /*
> --
> 1.7.4.3
>
> --

Re: [PATCH] MMC-4.5 Data Tag Support

[Chris Ball]

Hi,

On Thu, Jan 12 2012, S, Venkatraman wrote:
> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com> wrote:
>> From: Saugata Das <saugata.das@linaro.org>
>>
>> MMC-4.5 data tag feature will be used to store the file system
>> meta-data in the
>> tagged region of eMMC. This will improve the write and subsequent
>> read transfer
>> time for the meta data.
>>
>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>
> I tested this on a device which supports a data tag unit size of 8K.
> Tested-by: Venkatraman S <svenkatr@ti.com>

Thanks for testing!  I've pushed it to mmc-next.

> Chris,
>   Can this go into 3.3 ?

I think 3.4 would be better after a full round of linux-next testing,
since this sounds like it could expose card-dependent quirks that could
destroy filesystems.  Better to be safe.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH] MMC-4.5 Data Tag Support

[Kyungmin Park]

On 1/13/12, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> On Thu, Jan 12 2012, S, Venkatraman wrote:
>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com>
>> wrote:
>>> From: Saugata Das <saugata.das@linaro.org>
>>>
>>> MMC-4.5 data tag feature will be used to store the file system
>>> meta-data in the
>>> tagged region of eMMC. This will improve the write and subsequent
>>> read transfer
>>> time for the meta data.
>>>
>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>
>> I tested this on a device which supports a data tag unit size of 8K.
>> Tested-by: Venkatraman S <svenkatr@ti.com>
>
> Thanks for testing!  I've pushed it to mmc-next.
>
>> Chris,
>>   Can this go into 3.3 ?
>
> I think 3.4 would be better after a full round of linux-next testing,
> since this sounds like it could expose card-dependent quirks that could
> destroy filesystems.  Better to be safe.
I'm afraid it that it's really required since some features. data tag,
context id, and packed command, are not mutual exclusive. so I hope to
make it select. I mean it's not measured the real performance gain
and/or other feature. so hope to enable/disable by platform data.

How do you think?

Thank you,
Kyungmin Park
>
> Thanks,
>
> - Chris.
> --
> Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> One Laptop Per Child
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] MMC-4.5 Data Tag Support

[S, Venkatraman]

On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park <kmpark@infradead.org> wrote:
> On 1/13/12, Chris Ball <cjb@laptop.org> wrote:
>> Hi,
>>
>> On Thu, Jan 12 2012, S, Venkatraman wrote:
>>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com>
>>> wrote:
>>>> From: Saugata Das <saugata.das@linaro.org>
>>>>
>>>> MMC-4.5 data tag feature will be used to store the file system
>>>> meta-data in the
>>>> tagged region of eMMC. This will improve the write and subsequent
>>>> read transfer
>>>> time for the meta data.
>>>>
>>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>>
>>> I tested this on a device which supports a data tag unit size of 8K.
>>> Tested-by: Venkatraman S <svenkatr@ti.com>
>>
>> Thanks for testing!  I've pushed it to mmc-next.
>>
>>> Chris,
>>>   Can this go into 3.3 ?
>>
>> I think 3.4 would be better after a full round of linux-next testing,
>> since this sounds like it could expose card-dependent quirks that could
>> destroy filesystems.  Better to be safe.
> I'm afraid it that it's really required since some features. data tag,
> context id, and packed command, are not mutual exclusive. so I hope to
> make it select. I mean it's not measured the real performance gain
> and/or other feature. so hope to enable/disable by platform data.
>
> How do you think?
>
> Thank you,
> Kyungmin Park

I don't understand your comment on them not being mutually exclusive.
As it is, these are core features and they don't belong in platform data.
Can you explain a bit more ?

Thanks,
Venkat.

Re: [PATCH] MMC-4.5 Data Tag Support

[Kyungmin Park]

On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman <svenkatr@ti.com> wrote:
> On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park <kmpark@infradead.org> wrote:
>> On 1/13/12, Chris Ball <cjb@laptop.org> wrote:
>>> Hi,
>>>
>>> On Thu, Jan 12 2012, S, Venkatraman wrote:
>>>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com>
>>>> wrote:
>>>>> From: Saugata Das <saugata.das@linaro.org>
>>>>>
>>>>> MMC-4.5 data tag feature will be used to store the file system
>>>>> meta-data in the
>>>>> tagged region of eMMC. This will improve the write and subsequent
>>>>> read transfer
>>>>> time for the meta data.
>>>>>
>>>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>>>
>>>> I tested this on a device which supports a data tag unit size of 8K.
>>>> Tested-by: Venkatraman S <svenkatr@ti.com>
>>>
>>> Thanks for testing!  I've pushed it to mmc-next.
>>>
>>>> Chris,
>>>>   Can this go into 3.3 ?
>>>
>>> I think 3.4 would be better after a full round of linux-next testing,
>>> since this sounds like it could expose card-dependent quirks that could
>>> destroy filesystems.  Better to be safe.
>> I'm afraid it that it's really required since some features. data tag,
>> context id, and packed command, are not mutual exclusive. so I hope to
>> make it select. I mean it's not measured the real performance gain
>> and/or other feature. so hope to enable/disable by platform data.
>>
>> How do you think?
>>
>> Thank you,
>> Kyungmin Park
>
> I don't understand your comment on them not being mutually exclusive.
> As it is, these are core features and they don't belong in platform data.
> Can you explain a bit more ?
To get the gain these features, data tag, context ID, it requires the
firmware support.
But currently there's no idea to support these feature at firmware. So
we can't get the valuable performance gain.
and now there's no data if it enables the both, data tag, packed
command or other combination, e.g., cache and so on.

So I suggest make it enable/disable these features at platform data,
similarly support pre-defined op by MMC_CAP_CMD23.
and I saw the Saugata's active regards with Context ID.  so it's also
make it configurable.

Thank you,
Kyungmin Park

Re: [PATCH] MMC-4.5 Data Tag Support

[S, Venkatraman]

On Mon, Jan 16, 2012 at 6:39 PM, Kyungmin Park <kmpark@infradead.org> wrote:
> On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>> On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park <kmpark@infradead.org> wrote:
>>> On 1/13/12, Chris Ball <cjb@laptop.org> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Jan 12 2012, S, Venkatraman wrote:
>>>>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com>
>>>>> wrote:
>>>>>> From: Saugata Das <saugata.das@linaro.org>
>>>>>>
>>>>>> MMC-4.5 data tag feature will be used to store the file system
>>>>>> meta-data in the
>>>>>> tagged region of eMMC. This will improve the write and subsequent
>>>>>> read transfer
>>>>>> time for the meta data.
>>>>>>
>>>>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>>>>
>>>>> I tested this on a device which supports a data tag unit size of 8K.
>>>>> Tested-by: Venkatraman S <svenkatr@ti.com>
>>>>
>>>> Thanks for testing!  I've pushed it to mmc-next.
>>>>
>>>>> Chris,
>>>>>   Can this go into 3.3 ?
>>>>
>>>> I think 3.4 would be better after a full round of linux-next testing,
>>>> since this sounds like it could expose card-dependent quirks that could
>>>> destroy filesystems.  Better to be safe.
>>> I'm afraid it that it's really required since some features. data tag,
>>> context id, and packed command, are not mutual exclusive. so I hope to
>>> make it select. I mean it's not measured the real performance gain
>>> and/or other feature. so hope to enable/disable by platform data.
>>>
>>> How do you think?
>>>
>>> Thank you,
>>> Kyungmin Park
>>
>> I don't understand your comment on them not being mutually exclusive.
>> As it is, these are core features and they don't belong in platform data.
>> Can you explain a bit more ?
> To get the gain these features, data tag, context ID, it requires the
> firmware support.
> But currently there's no idea to support these feature at firmware. So
> we can't get the valuable performance gain.

But that's neither a kernel issue, nor is a 'regression'. At worst,
the card should behave like a 4.41 standard card for an unoptimized firmware.

The platform data is the wrong location to indicate what are
essentially standards
driven features.
I am wondering already the need for CAPS2_BKOPS_SUPPORT and the like,
when the feature has nothing to do with the host controller.

> and now there's no data if it enables the both, data tag, packed
> command or other combination, e.g., cache and so on.
>
> So I suggest make it enable/disable these features at platform data,
> similarly support pre-defined op by MMC_CAP_CMD23.
> and I saw the Saugata's active regards with Context ID.  so it's also
> make it configurable.
>
> Thank you,
> Kyungmin Park

Re: [PATCH] MMC-4.5 Data Tag Support

[Kyungmin Park]

On Tue, Jan 17, 2012 at 10:40 PM, S, Venkatraman <svenkatr@ti.com> wrote:
> On Mon, Jan 16, 2012 at 6:39 PM, Kyungmin Park <kmpark@infradead.org> wrote:
>> On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>>> On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park <kmpark@infradead.org> wrote:
>>>> On 1/13/12, Chris Ball <cjb@laptop.org> wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Jan 12 2012, S, Venkatraman wrote:
>>>>>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com>
>>>>>> wrote:
>>>>>>> From: Saugata Das <saugata.das@linaro.org>
>>>>>>>
>>>>>>> MMC-4.5 data tag feature will be used to store the file system
>>>>>>> meta-data in the
>>>>>>> tagged region of eMMC. This will improve the write and subsequent
>>>>>>> read transfer
>>>>>>> time for the meta data.
>>>>>>>
>>>>>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>>>>>
>>>>>> I tested this on a device which supports a data tag unit size of 8K.
>>>>>> Tested-by: Venkatraman S <svenkatr@ti.com>
>>>>>
>>>>> Thanks for testing!  I've pushed it to mmc-next.
>>>>>
>>>>>> Chris,
>>>>>>   Can this go into 3.3 ?
>>>>>
>>>>> I think 3.4 would be better after a full round of linux-next testing,
>>>>> since this sounds like it could expose card-dependent quirks that could
>>>>> destroy filesystems.  Better to be safe.
>>>> I'm afraid it that it's really required since some features. data tag,
>>>> context id, and packed command, are not mutual exclusive. so I hope to
>>>> make it select. I mean it's not measured the real performance gain
>>>> and/or other feature. so hope to enable/disable by platform data.
>>>>
>>>> How do you think?
>>>>
>>>> Thank you,
>>>> Kyungmin Park
>>>
>>> I don't understand your comment on them not being mutually exclusive.
>>> As it is, these are core features and they don't belong in platform data.
>>> Can you explain a bit more ?
>> To get the gain these features, data tag, context ID, it requires the
>> firmware support.
>> But currently there's no idea to support these feature at firmware. So
>> we can't get the valuable performance gain.
>
> But that's neither a kernel issue, nor is a 'regression'. At worst,
> the card should behave like a 4.41 standard card for an unoptimized firmware.
Basically I agree that implement the codes by Spec. but it doesn't
mean all features are required for eMMC.
At some condition. frequent suspend & resume test, power off
notification makes chip lifespan worse.
So we decides that don't use this feature for our product. At that
time, make a spec. they only consider it at power off case. but we
implement it at suspend & resume.
Like similarly they think the data tag seems interesting but it also
uses the some special area at eMMC internally.
Yes it's firmware dependent. at least. we can't measured it properly
so we have to verify it at real condition.
That's reason make it configurable.

Kyungmin Park
>
> The platform data is the wrong location to indicate what are
> essentially standards
> driven features.
> I am wondering already the need for CAPS2_BKOPS_SUPPORT and the like,
> when the feature has nothing to do with the host controller.
>
>> and now there's no data if it enables the both, data tag, packed
>> command or other combination, e.g., cache and so on.
>>
>> So I suggest make it enable/disable these features at platform data,
>> similarly support pre-defined op by MMC_CAP_CMD23.
>> and I saw the Saugata's active regards with Context ID.  so it's also
>> make it configurable.
>>
>> Thank you,
>> Kyungmin Park
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MMC-4.5 Data Tag Support

[Saugata Das]

On 18 January 2012 18:45, Kyungmin Park <kmpark@infradead.org> wrote:
> On Tue, Jan 17, 2012 at 10:40 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>> On Mon, Jan 16, 2012 at 6:39 PM, Kyungmin Park <kmpark@infradead.org> wrote:
>>> On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman <svenkatr@ti.com> wrote:
>>>> On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park <kmpark@infradead.org> wrote:
>>>>> On 1/13/12, Chris Ball <cjb@laptop.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Jan 12 2012, S, Venkatraman wrote:
>>>>>>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@stericsson.com>
>>>>>>> wrote:
>>>>>>>> From: Saugata Das <saugata.das@linaro.org>
>>>>>>>>
>>>>>>>> MMC-4.5 data tag feature will be used to store the file system
>>>>>>>> meta-data in the
>>>>>>>> tagged region of eMMC. This will improve the write and subsequent
>>>>>>>> read transfer
>>>>>>>> time for the meta data.
>>>>>>>>
>>>>>>>> Signed-off-by: Saugata Das <saugata.das@linaro.org>
>>>>>>>
>>>>>>> I tested this on a device which supports a data tag unit size of 8K.
>>>>>>> Tested-by: Venkatraman S <svenkatr@ti.com>
>>>>>>
>>>>>> Thanks for testing!  I've pushed it to mmc-next.
>>>>>>
>>>>>>> Chris,
>>>>>>>   Can this go into 3.3 ?
>>>>>>
>>>>>> I think 3.4 would be better after a full round of linux-next testing,
>>>>>> since this sounds like it could expose card-dependent quirks that could
>>>>>> destroy filesystems.  Better to be safe.
>>>>> I'm afraid it that it's really required since some features. data tag,
>>>>> context id, and packed command, are not mutual exclusive. so I hope to
>>>>> make it select. I mean it's not measured the real performance gain
>>>>> and/or other feature. so hope to enable/disable by platform data.
>>>>>
>>>>> How do you think?
>>>>>
>>>>> Thank you,
>>>>> Kyungmin Park
>>>>
>>>> I don't understand your comment on them not being mutually exclusive.
>>>> As it is, these are core features and they don't belong in platform data.
>>>> Can you explain a bit more ?
>>> To get the gain these features, data tag, context ID, it requires the
>>> firmware support.
>>> But currently there's no idea to support these feature at firmware. So
>>> we can't get the valuable performance gain.
>>
>> But that's neither a kernel issue, nor is a 'regression'. At worst,
>> the card should behave like a 4.41 standard card for an unoptimized firmware.
> Basically I agree that implement the codes by Spec. but it doesn't
> mean all features are required for eMMC.
> At some condition. frequent suspend & resume test, power off
> notification makes chip lifespan worse.
> So we decides that don't use this feature for our product. At that
> time, make a spec. they only consider it at power off case. but we
> implement it at suspend & resume.
> Like similarly they think the data tag seems interesting but it also
> uses the some special area at eMMC internally.
> Yes it's firmware dependent. at least. we can't measured it properly
> so we have to verify it at real condition.
> That's reason make it configurable.
>

Power OFF notification should help in improving the device lifespan.
The implementation of using power OFF notification during
suspend/resume was wrong and Girish is working on it to improve it.

The data tag does not cause any additional write which could impact
device lifetime. It should improve throughput if eMMC firmware
implements the feature. Otherwise, it should be just harmless.

But I will still take your recommendation to keep some host specific
configuration to enable any of the MMC-4.5 features.

> Kyungmin Park
>>
>> The platform data is the wrong location to indicate what are
>> essentially standards
>> driven features.
>> I am wondering already the need for CAPS2_BKOPS_SUPPORT and the like,
>> when the feature has nothing to do with the host controller.
>>
>>> and now there's no data if it enables the both, data tag, packed
>>> command or other combination, e.g., cache and so on.
>>>
>>> So I suggest make it enable/disable these features at platform data,
>>> similarly support pre-defined op by MMC_CAP_CMD23.
>>> and I saw the Saugata's active regards with Context ID.  so it's also
>>> make it configurable.
>>>
>>> Thank you,
>>> Kyungmin Park
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html