On Tue, Jan 17, 2012 at 10:40 PM, S, Venkatraman <svenkatr@xxxxxx> wrote: > On Mon, Jan 16, 2012 at 6:39 PM, Kyungmin Park <kmpark@xxxxxxxxxxxxx> wrote: >> On Mon, Jan 16, 2012 at 7:37 PM, S, Venkatraman <svenkatr@xxxxxx> wrote: >>> On Fri, Jan 13, 2012 at 3:40 PM, Kyungmin Park <kmpark@xxxxxxxxxxxxx> wrote: >>>> On 1/13/12, Chris Ball <cjb@xxxxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> On Thu, Jan 12 2012, S, Venkatraman wrote: >>>>>> On Wed, Dec 21, 2011 at 1:09 PM, Saugata Das <saugata.das@xxxxxxxxxxxxxx> >>>>>> wrote: >>>>>>> From: Saugata Das <saugata.das@xxxxxxxxxx> >>>>>>> >>>>>>> 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@xxxxxxxxxx> >>>>>> >>>>>> I tested this on a device which supports a data tag unit size of 8K. >>>>>> Tested-by: Venkatraman S <svenkatr@xxxxxx> >>>>> >>>>> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
