LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Dong, Chuanxiao" <chuanxiao.dong@intel.com>
To: Chris Ball <cjb@laptop.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: RE: [PATCH v3 1/1]mmc: implemented eMMC4.4 enhanced area feature
Date: Fri, 21 Jan 2011 17:12:00 +0800	[thread overview]
Message-ID: <5D8008F58939784290FAB48F549751983539F50558@shsmsx502.ccr.corp.intel.com> (raw)
In-Reply-To: <20110121080422.GA21763@void.printf.net>

Hi Chris,
> 	/sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_size
> > > > +Date:		January 2011
> > > > +Contact:	Chuanxiao Dong <chuanxiao.dong@intel.com>
> > > > +Description:
> > > > +		Enhanced area is a new feature defined in eMMC4.4 standard.
> eMMC4.4
> > > or
> > > > +		later card can support such feature. This kind of area can help to
> > > > +		improve the card performance. If the feature is enabled, this
> attribute
> > > > +		will indicate the size of enhanced data area. If not, this attribute
> > > > +		will be -EINVAL. Unit KByte. Format decimal.
> > >
> > > This is still wrapped at > 80 columns.
> > Sorry for that. I have set the textwidth=80 for vim, not understand why this is still
> wrapped at >80 columns... I know checkpatch.pl can help us to find the style
> problem, and is there some other script which can help find the style problem of
> Document or how can I avoid such errors?
> 
> checkpatch.pl will warn about >80 chars, so that should be fine on its own.
I have used the checkpatch.pl to check this patch, and no error or warning found....

> 
> > > Oh, and let's mention the units of _offset and _size in the comment in
> > > card.h.
> >
> > Chris, you mean the type of _offset and _size? I think the 64bits number for
> _offset is enough, also the 32bits number for _size since the units of _size is Kbytes.
> Any suggestions on that?
> 
> Ah, I wasn't clear -- I meant the bytes/kilobytes units, not the data type
> sizes.  e.g.:
> 
> +   size_t          enhanced_area_size;             /* Units: KB */
I think the units of _offset and _size should be easy for user to understand, so just choose the Byte for _offset and Kbyte for _size...
And as spec said, the _size is (ENH_SIZE_MULT_2 << 16 + ENH_SIZE_MULT_1 << 8 + ENH_SIZE_MULT_0) x HC_WP_GRP_SIZE x HC_ERASE_GPR_SIZE x 512kBytes. It must be Kbytes aligned. That is another reason to choose it.
What do you think?

Thanks
Chuanxiao

  reply	other threads:[~2011-01-21  9:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-20  7:55 Chuanxiao Dong
2011-01-20 16:12 ` Chris Ball
2011-01-21  3:06   ` Dong, Chuanxiao
2011-01-21  8:04     ` Chris Ball
2011-01-21  9:12       ` Dong, Chuanxiao [this message]
2011-01-21 15:27         ` Chris Ball
2011-01-21 17:43           ` Dong, Chuanxiao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5D8008F58939784290FAB48F549751983539F50558@shsmsx502.ccr.corp.intel.com \
    --to=chuanxiao.dong@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=cjb@laptop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --subject='RE: [PATCH v3 1/1]mmc: implemented eMMC4.4 enhanced area feature' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).