* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-07-31 10:54 UTC (permalink / raw)
To: Pierre Ossman
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090731122623.254fd0f1@mjolnir.ossman.eu>
On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
>
> [PATCH 0/32] mmc and omap_hsmmc patches
> http://marc.info/?t=124722953900010&r=1&w=2
>
> I haven't looked through these at all. The ones affecting the core
> probably need some thorough reviews.
>
> I did notice the patch to say which cards a controller supports though,
> and I'm very sceptical about that one. The scanning process should work
> anyway, and the performance impact should be negligible as it is only
> on init. So that patch only adds complexity and confusion IMO.
>
How much complexity does it really add? Surely it's better to give the
host controller driver writers the ability to not entertain supporting
some cards if they cannot be used? If they want to avoid the scanning
process for certain cards, why not let them?
^ permalink raw reply
* Re: New MMC maintainer needed
From: Pierre Ossman @ 2009-07-31 10:26 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-linux, ppisa, jarkko.lavinen,
ben, saschasommer, avorontsov, oakad, ian, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <20090728222334.0c543c47@mjolnir.ossman.eu>
[-- Attachment #1: Type: text/plain, Size: 5949 bytes --]
This things are currently lingering in my inbox:
[PATCH 1/1] MMC: SDIO card reset support for Intel Moorestown platform
http://lkml.org/lkml/2009/6/16/269
SDIO cards have a global reset that in theory might be useful. I'm not
sure it is in practice though as it is a very blunt instrument and it
has created some problems in the past.
A PCI equivalent to this reset would be resetting an entire PCI card,
making it and every subfunction fall off the bus and come back again.
The complexity of handling this can be high since every subfunction
needs to be involved.
The patch above adds new callbacks to handle this, but I think it can
proabably be handled as a normal removal/insertion. This reset should
only be used as a last resort anyway.
Lastly, using this reset method might not even be useful. The libertas
guys tried using it to get back a wedged card, but they did not have
much success.
I recommend holding off on this functionality until someone can show
that the added functionality is worth the complexity.
[PATCH 1/2] MMC Agressive clocking framework
http://marc.info/?l=linux-arm-kernel&m=124394660502578&w=2
(and several subsequent versions)
I like this idea and it should be merged. What I didn't like about the
initial versions were that the MMC core was too involved with low level
decisions in drivers. IMO (and the PM guys from what I can tell) the
drivers should automatically do relevant PM stuff, only restricted by
what the MMC core has told the driver should be going on on the bus.
The missing piece here was that the core needed to tell the drivers
when they could turn off the clock on the bus. This can be difficult as
some cards need the clock to drive their internal logic for writes
(although this is in violation of the specs). This means the clock
needs to be left running some time after a request.
There are also a bunch of drivers that tries to do this themselves, and
often without the delay. These should be fixed to leave such decisions
to the core.
[PATCH] mmc: prevent dangling block device from accessing stale queues
http://marc.info/?l=linux-kernel&m=124413857119112
This one is more fun as it requires digging into the block layer. :/
The thread above describes the problem so I'm not going to reiterate it
here. The short summary of why I don't want the patch though is that I
believe it papers over the problem and doesn't solve it. I've been
meaning to look further into the issue, but if someone else has the
time then please go digging.
[PATCH 1/2] atmel-mci: Unified Atmel MCI drivers (AVR32 & AT91)
http://marc.info/?l=linux-arm-kernel&m=124577578729455
This is nice work and it's really up to Nicolas when he wants it merged.
[PATCH] DaVinci: MMC: V5: MMC/SD controller driver for DaVinci family.
(couldn't find an archive)
This driver has undergone some reviews and should be more or less done.
Please check the previous review comments to confirm that everything
has been fixed.
[PATCH] mmc_spi: fail gracefully if host or card do not support the switch command
http://marc.info/?l=linux-kernel&m=124473347118158
This is to work around buggy cards. I'm not convinced the problem is
fully understood yet though so I need to look more at this.
MMC driver for HTC Dream
http://marc.info/?t=124631240200002&r=1&w=2
This is a new driver that needs a review. It seems to make the
classical mistakes, so have a look at my earlier driver reviews to see
what to look for.
[PATCH] MMC Core: Drop initialization frequency floor to 50kHz
http://lkml.org/lkml/2009/7/1/529
The initial patch wasn't very good, but lowering the
speed to 350 kHz should be okay. A new patch is needed and probably
some testing in -next.
[PATCH] MMCI: use AMBA bus accessors
http://marc.info/?t=124689780400003&r=1&w=2
http://marc.info/?t=124689978900001&r=1&w=2
http://marc.info/?t=124689956700005&r=1&w=2
http://marc.info/?t=124689959900002&r=1&w=2
Should probably all be merged.
[PATCH] Add support for debugging MMC channel individually.
http://list.drzeus.cx/pipermail/sdhci-devel/2009-July/002713.html
I agree with Marcel. This kind of fine grained control belongs in
debugfs.
[PATCH] sdio: do not ignore MMC_VDD_165_195
http://marc.info/?t=124764000300001&r=1&w=2
There has already been some discussions around this, and quite
correctly the bit this patch wants to use is undefined.
Restoring back the system state from MMC after a successful hibernation
http://marc.info/?t=124818534700003&r=1&w=2
I don't agree with this approach. The point of the workqueue is so that
the kernel can do things in parallel, so this patch is a step back. The
problem is really with how the kernel doesn't properly cope with
asynchronous disk scanning during bootup. The root_delay parameter was
added for this for the "normal" case, but it seems more work is needed.
move mmci-omap-hs's probe function to .devinit.text
http://marc.info/?t=124734613000001&r=1&w=2
Second patch is probably okay, but the maintainers need to respond.
[PATCH 0/32] mmc and omap_hsmmc patches
http://marc.info/?t=124722953900010&r=1&w=2
I haven't looked through these at all. The ones affecting the core
probably need some thorough reviews.
I did notice the patch to say which cards a controller supports though,
and I'm very sceptical about that one. The scanning process should work
anyway, and the performance impact should be negligible as it is only
on init. So that patch only adds complexity and confusion IMO.
I think that's it, but don't be afraid to search the archives for
anything else that doesn't seem to have been getting any attention.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] Add support for LZO-compressed kernels on x86
From: Sam Ravnborg @ 2009-07-31 9:31 UTC (permalink / raw)
To: Albin Tonnerre
Cc: H. Peter Anvin, linux, alain, linux-kernel, linux-embedded,
Andrew Morton
In-Reply-To: <20090731075119.GB7139@pc-ras4041.res.insa>
On Fri, Jul 31, 2009 at 09:51:19AM +0200, Albin Tonnerre wrote:
> On Wed, Jul 29, 2009 at 11:02:58PM +0200, Sam Ravnborg wrote :
> > On Wed, Jul 29, 2009 at 01:00:36PM -0700, H. Peter Anvin wrote:
> > > On 07/22/2009 07:01 AM, Albin Tonnerre wrote:
> > > > This is the third and last part of the patch, which contains the
> > > > necessary changes to the x86 Kconfig and boot/compressed to allow the
> > > > use of this new compression method
> > > >
> > > > Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> > >
> > > Acked-by: H. Peter Anvin <hpa@zytor.com>
> > >
> > > Since the patchset otherwise isn't really x86-related it probably makes
> > > more sense to pass this through the kbuild tree, or perhaps via akpm,
> > > rather than -tip?
> >
> > I can take it via kbuild if I get a fewsh patch-set with proper
> > ack's added.
> > I've long lost the original patch-set.
>
> Only the x86-specific part of the patch has been acked so far, and it relies on
> 3 other patches which have not been acked. If there's anything I can do to get
> feedback on the remaining patches, please let me know.
Please resend the full serie then I may take a short look at it.
Sam
^ permalink raw reply
* Re: [PATCH 5/5] Add support for LZO-compressed kernels on x86
From: Albin Tonnerre @ 2009-07-31 7:51 UTC (permalink / raw)
To: Sam Ravnborg
Cc: H. Peter Anvin, linux, alain, linux-kernel, linux-embedded,
Andrew Morton
In-Reply-To: <20090729210257.GA22975@merkur.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]
On Wed, Jul 29, 2009 at 11:02:58PM +0200, Sam Ravnborg wrote :
> On Wed, Jul 29, 2009 at 01:00:36PM -0700, H. Peter Anvin wrote:
> > On 07/22/2009 07:01 AM, Albin Tonnerre wrote:
> > > This is the third and last part of the patch, which contains the
> > > necessary changes to the x86 Kconfig and boot/compressed to allow the
> > > use of this new compression method
> > >
> > > Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
> >
> > Acked-by: H. Peter Anvin <hpa@zytor.com>
> >
> > Since the patchset otherwise isn't really x86-related it probably makes
> > more sense to pass this through the kbuild tree, or perhaps via akpm,
> > rather than -tip?
>
> I can take it via kbuild if I get a fewsh patch-set with proper
> ack's added.
> I've long lost the original patch-set.
Only the x86-specific part of the patch has been acked so far, and it relies on
3 other patches which have not been acked. If there's anything I can do to get
feedback on the remaining patches, please let me know.
Regards,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: [PATCH] sdio: add CD disable support
From: Matt Fleming @ 2009-07-30 18:50 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Andrew Morton, Philip Langdale, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
In-Reply-To: <bd5b16740907300855y2ee0f76fv5886606fcee241b7@mail.gmail.com>
On Thu, Jul 30, 2009 at 06:55:14PM +0300, Ohad Ben-Cohen wrote:
> On Thu, Jul 30, 2009 at 3:45 PM, Matt Fleming<matt@console-pimps.org> wrote:
> > Do you have a follow-up patch to make use of this new functionality?
>
> Well, sort of:
>
> The patch sets disable_cd for TI wl1271 embedded wlan sdio device on a
> ZOOM2 platform.
>
> Since the patch is very board/device specific, we first route it via
> internal maintainers, so it is not posted yet.
>
> It's nothing fancy:
>
> diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
> b/arch/arm/mach-omap2/mmc-twl4030.c
> index 5b64bf1..caa8b16 100644
> --- a/arch/arm/mach-omap2/mmc-twl4030.c
> +++ b/arch/arm/mach-omap2/mmc-twl4030.c
> @@ -81,6 +81,7 @@ static struct embedded_sdio_data omap_wifi_emb_data = {
> .wide_bus = 1,
> .high_power = 0,
> .high_speed = 0,
> + .disable_cd = 1,
> },
> .funcs = wifi_func_array,
> .num_funcs = 2,
Ah, that's fair enough then. I just wanted to make sure that a patch
that used this functionality was in the pipeline :-)
As David has already said, both comments need fixing up. It is the host
controller driver that decides whether to disable the DAT[3] pull-up,
not the card. If you make those changes then you can add my Acked-by.
^ permalink raw reply
* Re: [PATCH] sdio: add CD disable support
From: Ohad Ben-Cohen @ 2009-07-30 15:55 UTC (permalink / raw)
To: Matt Fleming
Cc: Andrew Morton, Philip Langdale, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
In-Reply-To: <20090730124543.GF3058@console-pimps.org>
On Thu, Jul 30, 2009 at 3:45 PM, Matt Fleming<matt@console-pimps.org> wrote:
> Do you have a follow-up patch to make use of this new functionality?
Well, sort of:
The patch sets disable_cd for TI wl1271 embedded wlan sdio device on a
ZOOM2 platform.
Since the patch is very board/device specific, we first route it via
internal maintainers, so it is not posted yet.
It's nothing fancy:
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 5b64bf1..caa8b16 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -81,6 +81,7 @@ static struct embedded_sdio_data omap_wifi_emb_data = {
.wide_bus = 1,
.high_power = 0,
.high_speed = 0,
+ .disable_cd = 1,
},
.funcs = wifi_func_array,
.num_funcs = 2,
^ permalink raw reply related
* Re: [PATCH] sdio: add CD disable support
From: David Vrabel @ 2009-07-30 12:54 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Andrew Morton, Philip Langdale, Matt Fleming, ian, pierre,
linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
In-Reply-To: <1248954848.5396.6.camel@localhost>
Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen <ohad@wizery.com>
>
> To save power, the pull-up resistor on CD/DAT[3] (pin 1)
> of the card can be disconnected. This is desired, e.g.,
> with embedded SDIO devices which do not rely on this pin
> for card detection.
Platforms may rely on the card's pull-up and not fit/configure an
external one. There may need to be a way for host controller drivers to
say this and prevent the disabling of the card's DAT3 pull-up.
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/mmc/core/sdio.c | 32 ++++++++++++++++++++++++++++++++
> include/linux/mmc/card.h | 3 ++-
> 2 files changed, 34 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index fb99ccf..4c4c9a9 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -165,6 +165,31 @@ static int sdio_enable_wide(struct mmc_card *card)
> }
>
> /*
> + * Disconnect the pull-up resistor on CD/DAT[3] if requested by the card.
> + * If card detection is not needed, this can save some power.
> + */
The first sentence of this comment doesn't make sense. The decision to
disable the pull-up is for the controller driver to make, not that card.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'
^ permalink raw reply
* Re: [PATCH] sdio: add CD disable support
From: Matt Fleming @ 2009-07-30 12:45 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Andrew Morton, Philip Langdale, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
In-Reply-To: <1248954848.5396.6.camel@localhost>
On Thu, Jul 30, 2009 at 02:54:08PM +0300, Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen <ohad@wizery.com>
>
> To save power, the pull-up resistor on CD/DAT[3] (pin 1)
> of the card can be disconnected. This is desired, e.g.,
> with embedded SDIO devices which do not rely on this pin
> for card detection.
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/mmc/core/sdio.c | 32 ++++++++++++++++++++++++++++++++
> include/linux/mmc/card.h | 3 ++-
> 2 files changed, 34 insertions(+), 1 deletions(-)
>
Do you have a follow-up patch to make use of this new functionality? I
can't see anywhere where disable_cd is set.
^ permalink raw reply
* [PATCH] sdio: add CD disable support
From: Ohad Ben-Cohen @ 2009-07-30 11:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Philip Langdale, Matt Fleming, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
From: Ohad Ben-Cohen <ohad@wizery.com>
To save power, the pull-up resistor on CD/DAT[3] (pin 1)
of the card can be disconnected. This is desired, e.g.,
with embedded SDIO devices which do not rely on this pin
for card detection.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/mmc/core/sdio.c | 32 ++++++++++++++++++++++++++++++++
include/linux/mmc/card.h | 3 ++-
2 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..4c4c9a9 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -165,6 +165,31 @@ static int sdio_enable_wide(struct mmc_card *card)
}
/*
+ * Disconnect the pull-up resistor on CD/DAT[3] if requested by the card.
+ * If card detection is not needed, this can save some power.
+ */
+static int sdio_disable_cd(struct mmc_card *card)
+{
+ int ret;
+ u8 ctrl;
+
+ if (!card->cccr.disable_cd)
+ return 0;
+
+ ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_IF, 0, &ctrl);
+ if (ret)
+ return ret;
+
+ ctrl |= SDIO_BUS_CD_DISABLE;
+
+ ret = mmc_io_rw_direct(card, 1, 0, SDIO_CCCR_IF, ctrl, NULL);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/*
* Test if the card supports high-speed mode and, if so, switch to it.
*/
static int sdio_enable_hs(struct mmc_card *card)
@@ -392,6 +417,13 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
goto remove;
/*
+ * Disconnect card detection pull-up resistor (if requested by card).
+ */
+ err = sdio_disable_cd(card);
+ if (err)
+ goto remove;
+
+ /*
* Initialize (but don't add) all present functions.
*/
for (i = 0;i < funcs;i++) {
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 403aa50..82a8488 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -62,7 +62,8 @@ struct sdio_cccr {
low_speed:1,
wide_bus:1,
high_power:1,
- high_speed:1;
+ high_speed:1,
+ disable_cd:1;
};
struct sdio_cis {
--
1.5.4.3
^ permalink raw reply related
* Re: New MMC maintainer needed
From: Segher Boessenkool @ 2009-07-30 2:36 UTC (permalink / raw)
To: Pierre Ossman
Cc: Ian Molton, Andrew Morton, linux-kernel, linux-embedded, nico,
nicolas.ferre, hskinnemoen, tony, david-b, manuel.lauss,
mirq-linux, ppisa, jarkko.lavinen, ben, saschasommer, avorontsov,
oakad, HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090728222213.2de38c53@mjolnir.ossman.eu>
> I use the public specs from sdcard.org for more or less everything. I
> also have a MMC 4 spec, which was generously donated to me by Nokia.
> Unfortunately I am not allowed to pass that on. I can look things up
> for people if they have specific questions though.
The MMC Association has merged with JEDEC, so now everyone can download
the specs, e.g. http://www.jedec.org/download/search/JESD84-A44.pdf .
Segher
^ permalink raw reply
* Re: [PATCH 5/5] Add support for LZO-compressed kernels on x86
From: Sam Ravnborg @ 2009-07-29 21:02 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Albin Tonnerre, linux, alain, linux-kernel, linux-embedded,
Andrew Morton
In-Reply-To: <4A70AA64.4020301@zytor.com>
On Wed, Jul 29, 2009 at 01:00:36PM -0700, H. Peter Anvin wrote:
> On 07/22/2009 07:01 AM, Albin Tonnerre wrote:
> > This is the third and last part of the patch, which contains the
> > necessary changes to the x86 Kconfig and boot/compressed to allow the
> > use of this new compression method
> >
> > Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
>
> Acked-by: H. Peter Anvin <hpa@zytor.com>
>
> Since the patchset otherwise isn't really x86-related it probably makes
> more sense to pass this through the kbuild tree, or perhaps via akpm,
> rather than -tip?
I can take it via kbuild if I get a fewsh patch-set with proper
ack's added.
I've long lost the original patch-set.
Sam
^ permalink raw reply
* Re: [PATCH 5/5] Add support for LZO-compressed kernels on x86
From: H. Peter Anvin @ 2009-07-29 20:00 UTC (permalink / raw)
To: Albin Tonnerre
Cc: linux, alain, linux-kernel, linux-embedded, Andrew Morton,
Sam Ravnborg
In-Reply-To: <1248271279-9920-5-git-send-email-albin.tonnerre@free-electrons.com>
On 07/22/2009 07:01 AM, Albin Tonnerre wrote:
> This is the third and last part of the patch, which contains the
> necessary changes to the x86 Kconfig and boot/compressed to allow the
> use of this new compression method
>
> Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Since the patchset otherwise isn't really x86-related it probably makes
more sense to pass this through the kbuild tree, or perhaps via akpm,
rather than -tip?
-hpa
^ permalink raw reply
* [PATCH] Add LZO compression support for initramfs and old-style initrd
From: Albin Tonnerre @ 2009-07-29 15:37 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded
In-Reply-To: <1248271279-9920-5-git-send-email-albin.tonnerre@free-electrons.com>
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
lib/Kconfig | 4 ++++
lib/Makefile | 1 +
lib/decompress.c | 5 +++++
usr/Kconfig | 25 ++++++++++++++++++++-----
4 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index bb1326d..8639349 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -117,6 +117,10 @@ config DECOMPRESS_BZIP2
config DECOMPRESS_LZMA
tristate
+config DECOMPRESS_LZO
+ select LZO_DECOMPRESS
+ tristate
+
#
# Generic allocator support is selected if needed
#
diff --git a/lib/Makefile b/lib/Makefile
index b6d1857..cd3d37b 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_LZO_DECOMPRESS) += lzo/
lib-$(CONFIG_DECOMPRESS_GZIP) += decompress_inflate.o
lib-$(CONFIG_DECOMPRESS_BZIP2) += decompress_bunzip2.o
lib-$(CONFIG_DECOMPRESS_LZMA) += decompress_unlzma.o
+lib-$(CONFIG_DECOMPRESS_LZO) += decompress_unlzo.o
obj-$(CONFIG_TEXTSEARCH) += textsearch.o
obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o
diff --git a/lib/decompress.c b/lib/decompress.c
index d2842f5..a760681 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -9,6 +9,7 @@
#include <linux/decompress/bunzip2.h>
#include <linux/decompress/unlzma.h>
#include <linux/decompress/inflate.h>
+#include <linux/decompress/unlzo.h>
#include <linux/types.h>
#include <linux/string.h>
@@ -22,6 +23,9 @@
#ifndef CONFIG_DECOMPRESS_LZMA
# define unlzma NULL
#endif
+#ifndef CONFIG_DECOMPRESS_LZO
+# define unlzo NULL
+#endif
static const struct compress_format {
unsigned char magic[2];
@@ -32,6 +36,7 @@ static const struct compress_format {
{ {037, 0236}, "gzip", gunzip },
{ {0x42, 0x5a}, "bzip2", bunzip2 },
{ {0x5d, 0x00}, "lzma", unlzma },
+ { {0x89, 0x4c}, "lzo", unlzo },
{ {0, 0}, NULL, NULL }
};
diff --git a/usr/Kconfig b/usr/Kconfig
index 1c3039f..04a826e 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -72,6 +72,15 @@ config RD_LZMA
Support loading of a LZMA encoded initial ramdisk or cpio buffer
If unsure, say N.
+config RD_LZO
+ bool "Support initial ramdisks compressed using LZO" if EMBEDDED
+ default !EMBEDDED
+ depends on BLK_DEV_INITRD
+ select DECOMPRESS_LZO
+ help
+ Support loading of a LZO encoded initial ramdisk or cpio buffer
+ If unsure, say N.
+
choice
prompt "Built-in initramfs compression mode" if INITRAMFS_SOURCE!=""
help
@@ -108,16 +117,15 @@ config INITRAMFS_COMPRESSION_GZIP
bool "Gzip"
depends on RD_GZIP
help
- The old and tried gzip compression. Its compression ratio is
- the poorest among the 3 choices; however its speed (both
- compression and decompression) is the fastest.
+ The old and tried gzip compression. It provides a good balance
+ between compression ration and decompression speed.
config INITRAMFS_COMPRESSION_BZIP2
bool "Bzip2"
depends on RD_BZIP2
help
Its compression ratio and speed is intermediate.
- Decompression speed is slowest among the three. The initramfs
+ Decompression speed is slowest among the four. The initramfs
size is about 10% smaller with bzip2, in comparison to gzip.
Bzip2 uses a large amount of memory. For modern kernels you
will need at least 8MB RAM or more for booting.
@@ -128,7 +136,14 @@ config INITRAMFS_COMPRESSION_LZMA
help
The most recent compression algorithm.
Its ratio is best, decompression speed is between the other
- two. Compression is slowest. The initramfs size is about 33%
+ three. Compression is slowest. The initramfs size is about 33%
smaller with LZMA in comparison to gzip.
+config INITRAMFS_COMPRESSION_LZO
+ bool "LZO"
+ depends on RD_LZO
+ help
+ Its compression ratio is the poorest among the four. The kernel
+ size is about about 10% bigger than gzip; however its speed
+
endchoice
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply related
* [PATCH 3/5 v2] Add support for LZO-compressed kernels
From: Albin Tonnerre @ 2009-07-29 13:51 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded
In-Reply-To: <1248271279-9920-3-git-send-email-albin.tonnerre@free-electrons.com>
This is the first part of the lzo patch
The lzo compressor is worse than gzip at compression, but faster at
extraction. Here are some figures for an ARM board I'm working on:
Uncompressed size: 3.24Mo
gzip 1.61Mo 0.72s
lzo 1.75Mo 0.48s
So for a compression ratio that is still relatively close to gzip, it's
much faster to extract, at least in that case.
This version applies to kernel 2.6.31-rc3
This part contains:
- Makefile routine to support lzo compression
- Fixes to the existing lzo compressor so that it can be used in
compressed kernels
- wrapper around the existing lzo1x_decompress, as it only extracts one
block at a time, while we need to extract a whole file here
- config dialog for kernel compression
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
Changelog since v1:
lib/decompress_unlzo.c
- Rename lzo_decompress to unlzo to match the prototype in decompress/unlzo.h
- Use LZO_BLOCK_SIZE instead of BLOCK_SIZE to avoid confusion
- Add support for using the posp, fill and flush arguments
- Reorder includes so that linux/types.h is included before
linux/lzo.h. This prevents issue when not used as bootstrap code, as
lzo.h needs things like size_t
- When we are not using unlzo as part of kernel bootstrap code, we need
linux/slab.h for memory allocation functions.
- ... and we also need a call to set_error_fn so that the provided error
function is used correctly
include/linux/decompress/unlzo.h | 10 ++
init/Kconfig | 18 +++-
lib/decompress_unlzo.c | 206 ++++++++++++++++++++++++++++++++++++++
lib/lzo/lzo1x_decompress.c | 9 +-
scripts/Makefile.lib | 5 +
5 files changed, 241 insertions(+), 7 deletions(-)
create mode 100644 include/linux/decompress/unlzo.h
create mode 100644 lib/decompress_unlzo.c
diff --git a/include/linux/decompress/unlzo.h b/include/linux/decompress/unlzo.h
new file mode 100644
index 0000000..d1925ea
--- /dev/null
+++ b/include/linux/decompress/unlzo.h
@@ -0,0 +1,10 @@
+#ifndef DECOMPRESS_UNLZO_H
+#define DECOMPRESS_UNLZO_H
+
+int unlzo(unsigned char *inbuf, int len,
+ int(*fill)(void*, unsigned int),
+ int(*flush)(void*, unsigned int),
+ unsigned char *output,
+ int *pos,
+ void(*error)(char *x));
+#endif
diff --git a/init/Kconfig b/init/Kconfig
index cb2c092..ada6182 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -115,10 +115,13 @@ config HAVE_KERNEL_BZIP2
config HAVE_KERNEL_LZMA
bool
+config HAVE_KERNEL_LZO
+ bool
+
choice
prompt "Kernel compression mode"
default KERNEL_GZIP
- depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA
+ depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_LZO
help
The linux kernel is a kind of self-extracting executable.
Several compression algorithms are available, which differ
@@ -141,9 +144,8 @@ config KERNEL_GZIP
bool "Gzip"
depends on HAVE_KERNEL_GZIP
help
- The old and tried gzip compression. Its compression ratio is
- the poorest among the 3 choices; however its speed (both
- compression and decompression) is the fastest.
+ The old and tried gzip compression. It provides a good balance
+ between compression ration and decompression speed.
config KERNEL_BZIP2
bool "Bzip2"
@@ -164,6 +166,14 @@ config KERNEL_LZMA
two. Compression is slowest. The kernel size is about 33%
smaller with LZMA in comparison to gzip.
+config KERNEL_LZO
+ bool "LZO"
+ depends on HAVE_KERNEL_LZO
+ help
+ Its compression ratio is the poorest among the 4. The kernel
+ size is about about 10% bigger than gzip; however its speed
+ (both compression and decompression) is the fastest.
+
endchoice
config SWAP
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
new file mode 100644
index 0000000..a18417a
--- /dev/null
+++ b/lib/decompress_unlzo.c
@@ -0,0 +1,206 @@
+/*
+ * LZO decompressor for the Linux kernel. Code borrowed from the lzo
+ * implementation by Markus Franz Xaver Johannes Oberhumer.
+ *
+ * Linux kernel adaptation:
+ * Copyright (C) 2009
+ * Albin Tonnerre, Free Electrons <albin.tonnerre@free-electrons.com>
+ *
+ * Original code:
+ * Copyright (C) 1996-2005 Markus Franz Xaver Johannes Oberhumer
+ * All Rights Reserved.
+ *
+ * lzop and the LZO library are free software; you can redistribute them
+ * and/or modify them under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.
+ * If not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Markus F.X.J. Oberhumer
+ * <markus@oberhumer.com>
+ * http://www.oberhumer.com/opensource/lzop/
+ */
+
+#ifdef STATIC
+#include "lzo/lzo1x_decompress.c"
+#else
+#include <linux/slab.h>
+#endif
+
+#include <linux/types.h>
+#include <linux/lzo.h>
+#include <linux/decompress/mm.h>
+#include <linux/decompress/unlzo.h>
+
+#include <linux/compiler.h>
+#include <asm/unaligned.h>
+
+static const unsigned char lzop_magic[] =
+ { 0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a };
+
+#define LZO_BLOCK_SIZE (256*1024l)
+#define HEADER_HAS_FILTER 0x00000800L
+
+STATIC inline int INIT parse_header(u8 *input, u8 *skip)
+{
+ int l;
+ u8 *parse = input;
+ u8 level = 0;
+ u16 version;
+
+ /* read magic: 9 first bits */
+ for (l = 0; l < 9; l++) {
+ if (*parse++ != lzop_magic[l])
+ return 0;
+ }
+ /* get version (2bytes), skip library version (2),
+ * 'need to be extracted' version (2) and
+ * method (1) */
+ version = get_unaligned_be16(parse);
+ parse += 7;
+ if (version >= 0x0940)
+ level = *parse++;
+ if (get_unaligned_be32(parse) & HEADER_HAS_FILTER)
+ parse += 8; /* flags + filter info */
+ else
+ parse += 4; /* flags */
+
+ /* skip mode and mtime_low */
+ parse += 8;
+ if (version >= 0x0940)
+ parse += 4; /* skip mtime_high */
+
+ l = *parse++;
+ /* don't care about the file name, and skip checksum */
+ parse += l + 4;
+
+ *skip = parse - input;
+ return 1;
+}
+
+STATIC inline int INIT unlzo(u8 *input, int in_len,
+ int (*fill) (void *, unsigned int),
+ int (*flush) (void *, unsigned int),
+ u8 *output, int *posp,
+ void (*error_fn) (char *x))
+{
+ u8 skip = 0, r = 0;
+ u32 src_len, dst_len;
+ size_t tmp;
+ u8 *in_buf, *in_buf_save, *out_buf;
+ int obytes_processed = 0;
+
+ set_error_fn(error_fn);
+
+ if (output)
+ out_buf = output;
+ else if (!flush) {
+ error("NULL output pointer and no flush function provided");
+ goto exit;
+ }
+ else if (!(out_buf = malloc(LZO_BLOCK_SIZE))) {
+ error("Could not allocate output buffer");
+ goto exit;
+ }
+
+ if (input && fill) {
+ error("Both input pointer and fill function provided, don't know what to do");
+ goto exit_1;
+ }
+ else if (input)
+ in_buf = input;
+ else if (!fill || !posp) {
+ error("NULL input pointer and missing position pointer or fill function");
+ goto exit_1;
+ }
+ else if (!(in_buf = malloc(lzo1x_worst_compress(LZO_BLOCK_SIZE)))) {
+ error("Could not allocate input buffer");
+ goto exit_1;
+ }
+ in_buf_save = in_buf;
+
+ if (posp)
+ *posp = 0;
+
+ if (fill)
+ fill(in_buf, lzo1x_worst_compress(LZO_BLOCK_SIZE));
+
+ if (!parse_header(input, &skip)) {
+ error("invalid header");
+ goto exit_2;
+ }
+ in_buf += skip;
+
+ if (posp)
+ *posp = skip;
+
+ for (;;) {
+ /* read uncompressed block size */
+ dst_len = get_unaligned_be32(in_buf);
+ in_buf += 4;
+
+ /* exit if last block */
+ if (dst_len == 0) {
+ if (posp)
+ *posp += 4;
+ break;
+ }
+
+ if (dst_len > LZO_BLOCK_SIZE) {
+ error("dest len longer than block size");
+ goto exit_2;
+ }
+
+ /* read compressed block size, and skip block checksum info */
+ src_len = get_unaligned_be32(in_buf);
+ in_buf += 8;
+
+ if (src_len <= 0 || src_len > dst_len) {
+ error("file corrupted");
+ goto exit_2;
+ }
+
+ /* decompress */
+ tmp = dst_len;
+ r = lzo1x_decompress_safe((u8 *) in_buf, src_len, out_buf, &tmp);
+
+ if (r != LZO_E_OK || dst_len != tmp) {
+ error("Compressed data violation");
+ goto exit_2;
+ }
+
+ obytes_processed += dst_len;
+ if (flush)
+ flush(out_buf, dst_len);
+ if (output)
+ out_buf += dst_len;
+ if (posp)
+ *posp += src_len + 12;
+ if (fill) {
+ in_buf = in_buf_save;
+ fill(in_buf, lzo1x_worst_compress(LZO_BLOCK_SIZE));
+ }
+ else
+ in_buf += src_len;
+ }
+
+exit_2:
+ if (!input)
+ free(in_buf);
+exit_1:
+ if (!output)
+ free(out_buf);
+exit:
+ return obytes_processed;
+}
+
+#define decompress unlzo
diff --git a/lib/lzo/lzo1x_decompress.c b/lib/lzo/lzo1x_decompress.c
index 5dc6b29..f2fd098 100644
--- a/lib/lzo/lzo1x_decompress.c
+++ b/lib/lzo/lzo1x_decompress.c
@@ -11,11 +11,13 @@
* Richard Purdie <rpurdie@openedhand.com>
*/
+#ifndef STATIC
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/lzo.h>
-#include <asm/byteorder.h>
+#endif
+
#include <asm/unaligned.h>
+#include <linux/lzo.h>
#include "lzodefs.h"
#define HAVE_IP(x, ip_end, ip) ((size_t)(ip_end - ip) < (x))
@@ -244,9 +246,10 @@ lookbehind_overrun:
*out_len = op - out;
return LZO_E_LOOKBEHIND_OVERRUN;
}
-
+#ifndef STATIC
EXPORT_SYMBOL_GPL(lzo1x_decompress_safe);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("LZO1X Decompressor");
+#endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7a77787..7b721d1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -230,3 +230,8 @@ quiet_cmd_lzma = LZMA $@
cmd_lzma = (cat $(filter-out FORCE,$^) | \
lzma -9 && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
(rm -f $@ ; false)
+
+quiet_cmd_lzo = LZO $@
+cmd_lzo = (cat $(filter-out FORCE,$^) | \
+ lzop -9 && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+ (rm -f $@ ; false)
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply related
* Re: New MMC maintainer needed
From: Ian Molton @ 2009-07-29 10:35 UTC (permalink / raw)
To: Andrew Morton
Cc: pierre, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <20090728154137.36d68a4e.akpm@linux-foundation.org>
Andrew Morton wrote:
> I expect that Dave Miller can set up linux-mmc@vger.kernel.org in a
> jiffy. A MAINTAINERS patch should be made if this is done.
I've sent him an email, will let you all know what happens.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Sam Ravnborg @ 2009-07-29 6:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Ian Molton, pierre, linux-kernel, linux-embedded, nico,
nicolas.ferre, hskinnemoen, tony, david-b, manuel.lauss,
mirq-linux, ppisa, jarkko.lavinen, ben, saschasommer, avorontsov,
oakad, HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090728154137.36d68a4e.akpm@linux-foundation.org>
On Tue, Jul 28, 2009 at 03:41:37PM -0700, Andrew Morton wrote:
> On Tue, 28 Jul 2009 22:14:40 +0100
> Ian Molton <ian@mnementh.co.uk> wrote:
>
> > Pierre Ossman wrote:
> >
> > > MMC discussions tend to often be very system specific, which makes
> > > lists such as the arm kernel list more appropriate. Also, I've always
> > > tried to steer people to LKML as it allows others to keep a casual eye
> > > on things.
> >
> > I think an MMC list wouldnt be a bad idea now that we have a sort of
> > 'distributed maintainership' thing going on... itd help get people up to
> > speed...
>
> I expect that Dave Miller can set up linux-mmc@vger.kernel.org in a
> jiffy. A MAINTAINERS patch should be made if this is done.
>
> What I am unsure about is whether and how web-based archives of the vger
> lists come into being - is it automatic, or should people be asked?
It was a manual process when I had linux-kbuild created.
I contacted marc and one other place I do not recall right now.
Sam
^ permalink raw reply
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-07-28 22:41 UTC (permalink / raw)
To: Ian Molton
Cc: pierre, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <4A6F6A40.60203@mnementh.co.uk>
On Tue, 28 Jul 2009 22:14:40 +0100
Ian Molton <ian@mnementh.co.uk> wrote:
> Pierre Ossman wrote:
>
> > MMC discussions tend to often be very system specific, which makes
> > lists such as the arm kernel list more appropriate. Also, I've always
> > tried to steer people to LKML as it allows others to keep a casual eye
> > on things.
>
> I think an MMC list wouldnt be a bad idea now that we have a sort of
> 'distributed maintainership' thing going on... itd help get people up to
> speed...
I expect that Dave Miller can set up linux-mmc@vger.kernel.org in a
jiffy. A MAINTAINERS patch should be made if this is done.
What I am unsure about is whether and how web-based archives of the vger
lists come into being - is it automatic, or should people be asked?
^ permalink raw reply
* Re: New MMC maintainer needed
From: Ian Molton @ 2009-07-28 21:14 UTC (permalink / raw)
To: Pierre Ossman
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <20090728222034.78966b3a@mjolnir.ossman.eu>
Pierre Ossman wrote:
> MMC discussions tend to often be very system specific, which makes
> lists such as the arm kernel list more appropriate. Also, I've always
> tried to steer people to LKML as it allows others to keep a casual eye
> on things.
I think an MMC list wouldnt be a bad idea now that we have a sort of
'distributed maintainership' thing going on... itd help get people up to
speed...
^ permalink raw reply
* Re: New MMC maintainer needed
From: Pierre Ossman @ 2009-07-28 20:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-linux, ppisa, jarkko.lavinen,
ben, saschasommer, avorontsov, oakad, ian, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <20090722151744.fffd7bf5.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 389 bytes --]
I'll try to compose a list of outstanding discussions and patches so
that people know what needs attention. I'll try to get that done in the
next few days.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: New MMC maintainer needed
From: Pierre Ossman @ 2009-07-28 20:22 UTC (permalink / raw)
To: Ian Molton
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <4A67A9E8.5080002@mnementh.co.uk>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Thu, 23 Jul 2009 01:08:08 +0100
Ian Molton <ian@mnementh.co.uk> wrote:
> Pierre - do you have a bunch of MMC spec-type docs around? I've lost all
> but the few sparse datasheets for TMIO that I had, so some docs covering
> protocol / commands would be useful. Any references / downloads that you
> know of?
I use the public specs from sdcard.org for more or less everything. I
also have a MMC 4 spec, which was generously donated to me by Nokia.
Unfortunately I am not allowed to pass that on. I can look things up
for people if they have specific questions though.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: New MMC maintainer needed
From: Pierre Ossman @ 2009-07-28 20:20 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-linux, ppisa, jarkko.lavinen,
ben, saschasommer, avorontsov, oakad, ian, HaraldWelte,
JosephChan, adrian.hunter
In-Reply-To: <20090722151744.fffd7bf5.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
On Wed, 22 Jul 2009 15:17:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Thanks, Pierre.
>
> Until and unless someone else steps up I can act as maintainer of last
> resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi,
> gpio, i2o and about 1000 other identifiable subsystems.
>
I'm not falling of the face of the earth here, so people can still cc
me on MMC patches, although I probably cannot answer all of them. I
don't want to be the bottle neck that keeps MMC patches and discussions
moving at a glacial speed, which is the situation we're in today.
> Fortunately, MMC doesn't appear to have its own mailing list so I'll
> actually get to see the patches. I do monitor a couple of
> subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a
> month or two.
MMC discussions tend to often be very system specific, which makes
lists such as the arm kernel list more appropriate. Also, I've always
tried to steer people to LKML as it allows others to keep a casual eye
on things.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: New MMC maintainer needed
From: David Vrabel @ 2009-07-28 12:51 UTC (permalink / raw)
To: Matt Fleming
Cc: Philip Langdale, Andrew Morton, ohad, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l
In-Reply-To: <20090727214001.GK12665@console-pimps.org>
Matt Fleming wrote:
>
> Is the 3.00 spec publicly available?
There does not appear to be a simplified version of the 3.00 specification.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'
^ permalink raw reply
* Re: New MMC maintainer needed
From: Philip Langdale @ 2009-07-28 0:52 UTC (permalink / raw)
To: Matt Fleming
Cc: David Vrabel, Andrew Morton, ohad, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l
In-Reply-To: <20090727214001.GK12665@console-pimps.org>
On Mon, 27 Jul 2009 22:40:01 +0100
Matt Fleming <matt@console-pimps.org> wrote:
> On Mon, Jul 27, 2009 at 01:09:47PM +0100, David Vrabel wrote:
> > Philip Langdale wrote:
> > >
> > > Both the (Simplified) SD and SDIO specifications do not formally
> > > define the 'low voltage' range in the way the MMC spec does. ie:
> > > You won't find anything in the SD specs that even tell you what
> > > the range is - it just says that it exists.
> >
> > Standard SD/SDIO cards only support 2.7-3.6V.
> >
> > 1.8V operation is added in SD physical spec 3.00 and is part of any
> > of the UHS-1 modes (SDR12-SDR104 and DDR50). It has a different
> > timings and requires a different (3.00 compliant) host controller.
>
> Is the 3.00 spec publicly available?
>
Indeed! If the 1.8V operations have conformance requirements beyond
those of MMCplus/MMCmobile, then we can't just remove the current
test as proposed. I've been checking the sdcard.org site periodically
for new specs and haven't seen anything yet.
--phil
^ permalink raw reply
* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-07-27 21:40 UTC (permalink / raw)
To: David Vrabel
Cc: Philip Langdale, Andrew Morton, ohad, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l
In-Reply-To: <4A6D990B.9000005@csr.com>
On Mon, Jul 27, 2009 at 01:09:47PM +0100, David Vrabel wrote:
> Philip Langdale wrote:
> >
> > Both the (Simplified) SD and SDIO specifications do not formally
> > define the 'low voltage' range in the way the MMC spec does. ie: You
> > won't find anything in the SD specs that even tell you what the range
> > is - it just says that it exists.
>
> Standard SD/SDIO cards only support 2.7-3.6V.
>
> 1.8V operation is added in SD physical spec 3.00 and is part of any of
> the UHS-1 modes (SDR12-SDR104 and DDR50). It has a different timings
> and requires a different (3.00 compliant) host controller.
Is the 3.00 spec publicly available?
^ permalink raw reply
* Re: New MMC maintainer needed
From: David Vrabel @ 2009-07-27 12:09 UTC (permalink / raw)
To: Philip Langdale
Cc: Andrew Morton, Matt Fleming, ohad, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l
In-Reply-To: <20090726230630.7598fbe4@fido2.homeip.net>
Philip Langdale wrote:
>
> Both the (Simplified) SD and SDIO specifications do not formally
> define the 'low voltage' range in the way the MMC spec does. ie: You
> won't find anything in the SD specs that even tell you what the range
> is - it just says that it exists.
Standard SD/SDIO cards only support 2.7-3.6V.
1.8V operation is added in SD physical spec 3.00 and is part of any of
the UHS-1 modes (SDR12-SDR104 and DDR50). It has a different timings
and requires a different (3.00 compliant) host controller.
> So we (I wrote the first incarnation of this check for normal SD
> cards) decided to bail if a card requested the low voltage range.
> Now, if there's actually hardware out there that is SD/SDIO and
> operates at 1.8V, we should probably do something more appropriate.
> :-)
The SD/SDIO stack must ignore reserved bits unless a per-card quirk
gives an additional meaning to the reserved bit.
> It's obviously an easy change but I'd feel a lot more comfortable if
> someone can point us to a document that states that the SD/SDIO low
> voltage range is defined to match the MMC one. Maybe one of the NDA
> docs actually states this.
The non-simplified documents don't say anything on this.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox