headers
Andrei Warkentin | 1 Apr 2011 01:40
Gravatar

[PATCH] MMC: Reliable write support.

Allows reliable writes to be used for MMC writes. Reliable writes are used
to service write REQ_FUA/REQ_META requests. Handles both the legacy and
the enhanced reliable write support in MMC cards.

Reviewed-by: Arnd Bergmann <arnd <at> arndb.de>
Signed-off-by: Andrei Warkentin <andreiw <at> motorola.com>
---
 drivers/mmc/card/block.c |   81 +++++++++++++++++++++++++++++++++++++++++++--
 drivers/mmc/core/mmc.c   |    5 +++
 include/linux/mmc/card.h |    2 +
 include/linux/mmc/mmc.h  |    4 ++
 4 files changed, 88 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 61d233a..91a6767 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
 <at>  <at>  -48,6 +48,10  <at>  <at>  MODULE_ALIAS("mmc:block");
 #endif
 #define MODULE_PARAM_PREFIX "mmcblk."

+#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) &&	\
+    (((card)->ext_csd.rel_param & EXT_CSD_WR_REL_PARAM_EN) ||	\
+     ((card)->ext_csd.rel_sectors)))
+
 static DEFINE_MUTEX(block_mutex);

 /*
 <at>  <at>  -331,6 +335,57  <at>  <at>  out:
 	return err ? 0 : 1;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Ball | 1 Apr 2011 02:47
Favicon
Gravatar

Re: [PATCH] MMC: Reliable write support.

Hi,

On Thu, Mar 31 2011, Andrei Warkentin wrote:
> Allows reliable writes to be used for MMC writes. Reliable writes are used
> to service write REQ_FUA/REQ_META requests. Handles both the legacy and
> the enhanced reliable write support in MMC cards.
>
> Reviewed-by: Arnd Bergmann <arnd <at> arndb.de>
> Signed-off-by: Andrei Warkentin <andreiw <at> motorola.com>

Thanks, Andrei, pushed to mmc-next for .40.

- Chris.
--

-- 
Chris Ball   <cjb <at> 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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Shawn Guo | 1 Apr 2011 08:18
Favicon

Re: [PATCH 4/5] mmc: sdhci: consolidate sdhci-of-esdhc and sdhci-esdhc-imx

On Thu, Mar 31, 2011 at 09:53:12AM -0600, Grant Likely wrote:
> On Fri, Mar 25, 2011 at 04:48:50PM +0800, Shawn Guo wrote:
> > This patch is to consolidate SDHCI driver for Freescale eSDHC
> > controller found on both MPCxxx and i.MX platforms.  It turns
> > sdhci-of-esdhc.c and sdhci-esdhc-imx.c into one sdhci-esdhc.c,
> > which gets the same pair of .probe and .remove serving two cases.
> > 
> > Signed-off-by: Shawn Guo <shawn.guo <at> linaro.org>
> > ---
> >  drivers/mmc/host/Kconfig           |   38 ++--
> >  drivers/mmc/host/Makefile          |    3 +-
> >  drivers/mmc/host/sdhci-esdhc-imx.c |  210 ------------------
> >  drivers/mmc/host/sdhci-esdhc.c     |  413 ++++++++++++++++++++++++++++++++++++
> >  drivers/mmc/host/sdhci-of-esdhc.c  |  162 --------------
> 
> This patch would be easier to review if it was split into two patches;
> first rename sdhci-esdhc-imx.c to sdhci-esdhc.c without any changes to
> the .c code, and then a second patch to merge the ppc bits into the
> imx version.
> 
OK.

> > +#if defined(CONFIG_OF)
> > +#include <linux/of_device.h>
> > +static const struct of_device_id sdhci_esdhc_dt_ids[] = {
> > +#ifdef CONFIG_MMC_SDHCI_ESDHC_IMX
> > +	{ .compatible = "fsl,imx-esdhc", .data = &sdhci_esdhc_imx_pdata },
> > +#endif
> > +#ifdef CONFIG_MMC_SDHCI_ESDHC_MPC
> > +	{ .compatible = "fsl,mpc8379-esdhc", .data = &sdhci_esdhc_mpc_pdata },
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnd Bergmann | 1 Apr 2011 11:21
Picon
Gravatar

Re: [PATCHv4] MMC: MMC boot partitions support.

On Thursday 31 March 2011, Andrei Warkentin wrote:
> Plus what if you do intend to have a file system there? Other than
> complexity and non-obvious usage, I don't see
> anything gained by this. I wouldn't worry about ways of misusing this.
> As I've said, in the only case it matters (some embedded device
> booting from the boot partition), the user would have to gain root
> access, build a kernel giving access to the boot partitions and be
> able to boot into it.

The character device (or sysfs_bin_file actually) would only make
sense if we know that there is no reason to put a file system on it.
The idea of that is that we intentionally treat it like a firmware
flash, not like a block device because that is how it's used.

If there is a reasonable chance that people actually want to have
a file system in the boot partition, it should by all means be 
a block device.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Arnd Bergmann | 1 Apr 2011 11:23
Picon
Gravatar

Re: [PATCHv4] MMC: MMC boot partitions support.

On Thursday 31 March 2011, Andrei Warkentin wrote:
> > Another strawman, after brainstorming a bit on IRC -- how about
> > the block device itself comes up read-only, until you use a module
> > parameter/sysfs entry to make it read-write.  As a strawman:
> >
> > echo 1 > /sys/module/mmc_block/boot_partitions_are_writeable
> >
> > (That way people who write to it regularly can throw the module parameter
> > in their boot environment, and the rooting enthusiasts who didn't compile
> > the kernel are safe until they learn enough to be really dangerous..)
> 
> Sure, I like this, I'll do it.

I don't think it's even needed, but it sounds much more useful than
a Kconfig option, so no objections from me.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Arnd Bergmann | 1 Apr 2011 12:38
Picon
Gravatar

Re: [PATCHv4] MMC: MMC boot partitions support.

On Thursday 31 March 2011, Andrei Warkentin wrote:
> On Thu, Mar 31, 2011 at 6:17 AM, Arnd Bergmann <arnd <at> arndb.de> wrote:
> >
> > My feeling is that these should be separate from the boot partition.
> > It could probably be done using a new fs/partitions/mmc.c file
> > that directly interacts with the mmc layer instead of looking
> > at the MS-DOS master boot record. That way, you could define the
> > same partitions (mmcblk0p1, ...) using a different method.
>
> Nope. The device partitions are one time programmable (partition
> once), so you definitely don't want to expose them as regular
> partitions. The point
> behind the GP partitions is that they can be implemented with enhanced
> features (such as better reliability), and so like the enhanced area,
> are meant as a complement, not a replacement for file system
> partitions.
> 
> I don't think there is a need to over complicate this. It's just going
> to get more confusing and involve more changes. The device
> partitioning support is pretty orthogonal right now.

Even if they are write-once, wouldn't we still need to provide an
interface to write them once?

The question if GP should be used together or instead of MS-DOS
partitions depends on the possible use cases. If you don't want
to partition a GP any further in software, exposing them directly
as mmcblk0pX would be a very nice and simple interface, but
it completely prevents you from creating subpartitions.
(Continue reading)

Permalink | Reply | 36 comments |
headers
Chris Ball | 1 Apr 2011 16:52
Favicon
Gravatar

Re: [PATCHv4] MMC: MMC boot partitions support.

Hi,

On Fri, Apr 01 2011, Arnd Bergmann wrote:
> I don't think it's even needed, but it sounds much more useful than
> a Kconfig option, so no objections from me.

Cool, thanks.  By the way, I'm pretty neutral on whether there need
to be any Kconfig entries for any of this at all after the module
parameter goes in, so feel free to take them out of the patch.

- Chris.
--

-- 
Chris Ball   <cjb <at> 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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Russ Knize | 1 Apr 2011 17:58

[PATCH] mmc: power class support

Hello,

I've been propagating this patch around internally, so I thought I'd
post it here too in case someone might be interested.  Basically, I've
been testing recent samples of new eMMC cards from our vendors.  These
cards have support for "card power class".  Cards are becoming more
powerful and as such are drawing more current.  This feature provides
a means to limit the maximum current consumption of a particular card.
 We need to support this because these new cards start off in power
class 0, which leads to dismal performance.  At present, this only
seems to impact 8-bit buses.

The patch is simple, but the card firmware implementations for this
feature have been a bit buggy.   Though recent samples from two of our
vendors are much more promising.  Also, the JEDEC spec is littered
with vagueness on many of the details of how this is supposed to work.
 This led to some of the firmware issues.  I've done my best to
interpret the spec and got at least one of our vendors to agree on the
interpretation.  :)  So far it has been validated on Sandisk and
Toshiba parts.

Some caveats with this patch:

1) This patch doesn't quite apply as nicely to mmc-next as it does our
older kernels.  One of the details that ended being tricky for the
card firmware was the sequence.  The spec indicates that the power
class switch command should be sent after the host has determined the
bus width, but *before* sending the bus width switch command.  I see a
new "trial and error" loop in mmc_init_card() that we don't have in
our older kernel.  For this to work and if my interpretation of the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrei Warkentin | 1 Apr 2011 20:42
Gravatar

Re: [PATCHv4] MMC: MMC boot partitions support.

On Fri, Apr 1, 2011 at 5:38 AM, Arnd Bergmann <arnd <at> arndb.de> wrote:
>
> Even if they are write-once, wouldn't we still need to provide an
> interface to write them once?
>

True. I first wanted to provide access to them. It would have to be a
special ioctl. There are a number of interesting MMC operations that
don't fit any other way - for example, password protection.

> The question if GP should be used together or instead of MS-DOS
> partitions depends on the possible use cases. If you don't want
> to partition a GP any further in software, exposing them directly
> as mmcblk0pX would be a very nice and simple interface, but
> it completely prevents you from creating subpartitions.
>
> The other alternative is to allow each GP to contain a partition
> table, but then you need a either a three-level naming (mmcblk0gp1p2)
> or make each GP a device by itself (mmcblk0, mmcblk1) that can in
> turn be partitioned.
>

Right now they are exposed as separate devices. This lets the user
pick whatever usage they
see fit (can format it directly, or can partition it), while the
naming (mmcblk0boot0, mmcblk0boot1, mmcblkgp0p1 for first partition on
gp0, for example) conveys that the entries are for device partitions.

>> > Regarding the naming, I would not use a trailing zero, but it's probably
>> > a subjective thing. The other names I could imagine for the boot partition
(Continue reading)

Permalink | Reply | 35 comments |
headers
Arnd Bergmann | 1 Apr 2011 21:25
Picon
Gravatar

Re: [PATCHv4] MMC: MMC boot partitions support.

On Friday 01 April 2011 20:42:36 Andrei Warkentin wrote:
> Right now they are exposed as separate devices. This lets the user
> pick whatever usage they
> see fit (can format it directly, or can partition it), while the
> naming (mmcblk0boot0, mmcblk0boot1, mmcblkgp0p1 for first partition on
> gp0, for example) conveys that the entries are for device partitions.

Ok, sounds good. How do they show up in sysfs then? I think ideally
a gp device should be a child of the regular device, just like a partition,
and then it can have further children. That way, a user application can
easily find out which ones belong together.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 34 comments |

Gmane