* 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
* Re: New MMC maintainer needed
From: Philip Langdale @ 2009-07-27 6:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Fleming, ohad, ian, pierre, linux-kernel, linux-embedded,
nico, nicolas.ferre, hskinnemoen, tony, david-b, manuel.lauss,
mirq-l
In-Reply-To: <20090724152944.51402e87.akpm@linux-foundation.org>
On Fri, 24 Jul 2009 15:29:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 23 Jul 2009 14:52:09 +0100
> Matt Fleming <matt@console-pimps.org> wrote:
>
> > On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> > > Hi Andrew,
> > >
> > > On Thu, Jul 23, 2009 at 9:22 AM, Andrew
> > > Morton<akpm@linux-foundation.org> wrote:
> > > > I actually already have a little pile of MMC things queued:
> > >
> > > Please also consider queuing up the attached patch as well.
> > >
> > > The patch is removing the current SDIO cards 1.8V limit, which is
> > > needed for embedded
> > > SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers
> > > like we have on the ZOOM2 boards for example).
> > >
> > > Thank you,
> > > Ohad.
> >
> > > From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00
> > > 2001 From: Ohad Ben-Cohen <ohad@bencohen.org>
> > > Date: Wed, 15 Jul 2009 09:21:41 +0300
> > > Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
> > >
> > > This is needed for 1.8V embedded SDIO devices and supporting host
> > > controllers (e.g. TI 127x and ZOOM2 boards)
> > >
> > > Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> > > ---
> > > drivers/mmc/core/sdio.c | 7 -------
> > > 1 files changed, 0 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> > > index fb99ccf..6f221dc 100644
> > > --- a/drivers/mmc/core/sdio.c
> > > +++ b/drivers/mmc/core/sdio.c
> > > @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host,
> > > u32 ocr) ocr &= ~0x7F;
> > > }
> > >
> > > - if (ocr & MMC_VDD_165_195) {
> > > - printk(KERN_WARNING "%s: SDIO card claims to
> > > support the "
> > > - "incompletely defined 'low voltage
> > > range'. This "
> > > - "will be ignored.\n", mmc_hostname(host));
> > > - ocr &= ~MMC_VDD_165_195;
> > > - }
> > > -
> > > host->ocr = mmc_select_voltage(host, ocr);
> > >
> > > /*
> > > --
> > > 1.5.4.3
> > >
> >
> > Looks OK to me, I'm unaware of a reason to not allow a card to use
> > MMC_VDD_165_195 if that's what it wants.
> >
>
> Yes, that code was there from day #1, via Pierre's original commit.
> There is no indication in either the code comments or the changelog
> why it was done this way.
>
> Other ways of finding out why this code is there include:
>
> a) search the mailing list for review discussion. I can't find it
> in my lkml archive.
>
> b) ask Pierre :)
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.
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. :-)
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.
Andrew - I'm also willing to be cc'ed on MMC changes and I'll respond
to the best of my (limited) abilities.
--phil
^ permalink raw reply
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-07-24 22:29 UTC (permalink / raw)
To: Matt Fleming
Cc: ohad, ian, 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: <20090723135209.GD6570@console-pimps.org>
On Thu, 23 Jul 2009 14:52:09 +0100
Matt Fleming <matt@console-pimps.org> wrote:
> On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> > Hi Andrew,
> >
> > On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<akpm@linux-foundation.org> wrote:
> > > I actually already have a little pile of MMC things queued:
> >
> > Please also consider queuing up the attached patch as well.
> >
> > The patch is removing the current SDIO cards 1.8V limit, which is
> > needed for embedded
> > SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
> > have on the ZOOM2 boards for example).
> >
> > Thank you,
> > Ohad.
>
> > From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
> > From: Ohad Ben-Cohen <ohad@bencohen.org>
> > Date: Wed, 15 Jul 2009 09:21:41 +0300
> > Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
> >
> > This is needed for 1.8V embedded SDIO devices and supporting host controllers
> > (e.g. TI 127x and ZOOM2 boards)
> >
> > Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> > ---
> > drivers/mmc/core/sdio.c | 7 -------
> > 1 files changed, 0 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> > index fb99ccf..6f221dc 100644
> > --- a/drivers/mmc/core/sdio.c
> > +++ b/drivers/mmc/core/sdio.c
> > @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
> > ocr &= ~0x7F;
> > }
> >
> > - if (ocr & MMC_VDD_165_195) {
> > - printk(KERN_WARNING "%s: SDIO card claims to support the "
> > - "incompletely defined 'low voltage range'. This "
> > - "will be ignored.\n", mmc_hostname(host));
> > - ocr &= ~MMC_VDD_165_195;
> > - }
> > -
> > host->ocr = mmc_select_voltage(host, ocr);
> >
> > /*
> > --
> > 1.5.4.3
> >
>
> Looks OK to me, I'm unaware of a reason to not allow a card to use
> MMC_VDD_165_195 if that's what it wants.
>
Yes, that code was there from day #1, via Pierre's original commit. There
is no indication in either the code comments or the changelog why it was done
this way.
Other ways of finding out why this code is there include:
a) search the mailing list for review discussion. I can't find it
in my lkml archive.
b) ask Pierre :)
^ permalink raw reply
* elinux.org now requires a valid email for editing
From: Bill Traynor @ 2009-07-24 14:59 UTC (permalink / raw)
To: linux-embedded, celinux-dev
Due to an increased amount of vandalism on the Embedded Linux Wiki
(http://www.elinux.org) a policy has been instituted requiring a valid
email address to edit wiki pages. At your convenience, please log
into your account and validate your email address. The link to
generate a validation email can be found in the Email section of your
'my preferences' page:
http://elinux.org/Special:Preferences
Thank you for your patience.
Bill
^ permalink raw reply
* Re: [PATCH 4/5] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-07-23 17:11 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded
In-Reply-To: <1248271279-9920-4-git-send-email-albin.tonnerre@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
On Wed, Jul 22, 2009 at 04:01:18PM +0200, Albin Tonnerre wrote :
> This is the second part of patch. This part includes:
> - changes to ach/arch/boot/Makefile to make it easier to add new
> compression types
> - new piggy.lzo.S necessary for lzo compression
> - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
> gzip, depending on the config
> - Kconfig support
>
I failed to mention this in the first place, but for proper crediting it should
be noted that the ARM part of the patch is based on Alain Knaff's work on the
LZMA/Bzip compression patch for ARM.
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: New MMC maintainer needed
From: Andi Kleen @ 2009-07-23 16:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Matt Fleming, Ian Molton, Pierre Ossman,
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: <20090723173852.119c04c2.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Andrew,
>
> On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> It gets easy if I remove linux-next.patch from -mm. Maybe I'll do that.
>
> At that point we could add the "stable" part of -mm to linux-next :-)
I think that would be a great idea. It always bugged me that
if Andrew pulls something in it's not automatically tested in -next.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-07-23 13:52 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Andrew Morton, Ian Molton, Pierre Ossman, 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: <bd5b16740907222350w54ca7b21w6b47ed94c1d7d16e@mail.gmail.com>
On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
> Hi Andrew,
>
> On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<akpm@linux-foundation.org> wrote:
> > I actually already have a little pile of MMC things queued:
>
> Please also consider queuing up the attached patch as well.
>
> The patch is removing the current SDIO cards 1.8V limit, which is
> needed for embedded
> SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
> have on the ZOOM2 boards for example).
>
> Thank you,
> Ohad.
> From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
> From: Ohad Ben-Cohen <ohad@bencohen.org>
> Date: Wed, 15 Jul 2009 09:21:41 +0300
> Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
>
> This is needed for 1.8V embedded SDIO devices and supporting host controllers
> (e.g. TI 127x and ZOOM2 boards)
>
> Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
> ---
> drivers/mmc/core/sdio.c | 7 -------
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
> index fb99ccf..6f221dc 100644
> --- a/drivers/mmc/core/sdio.c
> +++ b/drivers/mmc/core/sdio.c
> @@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
> ocr &= ~0x7F;
> }
>
> - if (ocr & MMC_VDD_165_195) {
> - printk(KERN_WARNING "%s: SDIO card claims to support the "
> - "incompletely defined 'low voltage range'. This "
> - "will be ignored.\n", mmc_hostname(host));
> - ocr &= ~MMC_VDD_165_195;
> - }
> -
> host->ocr = mmc_select_voltage(host, ocr);
>
> /*
> --
> 1.5.4.3
>
Looks OK to me, I'm unaware of a reason to not allow a card to use
MMC_VDD_165_195 if that's what it wants.
Acked-by: Matt Fleming <matt@console-pimps.org>
^ permalink raw reply
* Re: New MMC maintainer needed
From: Roberto A. Foglietta @ 2009-07-23 10:57 UTC (permalink / raw)
To: Matt Fleming
Cc: Ian Molton, Andrew Morton, Pierre Ossman, 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: <20090723055447.GA12211@console-pimps.org>
2009/7/23, Matt Fleming <matt@console-pimps.org>:
> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> > Andrew Morton wrote:
> >
> >> 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.
> >
> > If no-one else is helping out, Im happy to also be CC'd on MMC patches.
> >
>
I am new in maintaining a kernel driver into community but I would help.
--
Roberto A. Foglietta,
Linux Embedded Consultant
mobile: (+39) 349.33.30.697
^ permalink raw reply
* Re: New MMC maintainer needed
From: Stephen Rothwell @ 2009-07-23 7:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Fleming, Ian Molton, Pierre Ossman, 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: <20090723003228.fc0ec34b.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
Hi Andrew,
On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> It gets easy if I remove linux-next.patch from -mm. Maybe I'll do that.
At that point we could add the "stable" part of -mm to linux-next :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-07-23 7:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Matt Fleming, Ian Molton, Pierre Ossman, 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: <20090723172559.e7aebbb5.sfr@canb.auug.org.au>
On Thu, 23 Jul 2009 17:25:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > I actually already have a little pile of MMC things queued:
> >
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> > http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
> >
> > I guess we own them now ;)
>
> So how about, as an experiment, you put all those (at least those that are
> "stable") into a git tree (or quilt series) based on Linus' tree and I
> could replace the current linux-next mmc tree (which is empty) with that.
>
I haven't worked out how to do that yet :( (Well, I have, but it's all
complex).
It gets easy if I remove linux-next.patch from -mm. Maybe I'll do that.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Stephen Rothwell @ 2009-07-23 7:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Fleming, Ian Molton, Pierre Ossman, 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: <20090722232259.d0ff3495.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Hi Andrew,
On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I actually already have a little pile of MMC things queued:
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
>
> I guess we own them now ;)
So how about, as an experiment, you put all those (at least those that are
"stable") into a git tree (or quilt series) based on Linus' tree and I
could replace the current linux-next mmc tree (which is empty) with that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: New MMC maintainer needed
From: Adrian Hunter @ 2009-07-23 7:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Fleming, Ian Molton, Pierre Ossman,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
nico@cam.org, nicolas.ferre@rfo.atmel.com, hskinnemoen@atmel.com,
tony@atomide.com, david-b@pacbell.net, manuel.lauss@gmail.com,
mirq-linux@rere.qmqm.pl, ppisa@pikron.com,
Lavinen Jarkko (Nokia-D/Helsinki), ben@fluff.org,
saschasommer@freenet.de, avorontsov@ru.mvista.com,
oakad@yahoo.com, "HaraldWelte@viatech.com" <Haral>
In-Reply-To: <20090722232259.d0ff3495.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:
>
>> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
>>> Andrew Morton wrote:
>>>
>>>> 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.
>>> If no-one else is helping out, Im happy to also be CC'd on MMC patches.
>>>
>> Ditto.
>
> Thanks, guys.
>
> I actually already have a little pile of MMC things queued:
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
>
> I guess we own them now ;)
>
There are also 32 patches starting here:
http://marc.info/?l=linux-kernel&m=124722949501844&w=2
^ permalink raw reply
* Re: New MMC maintainer needed
From: Ohad Ben-Cohen @ 2009-07-23 6:50 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Fleming, Ian Molton, Pierre Ossman, 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: <20090722232259.d0ff3495.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Hi Andrew,
On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<akpm@linux-foundation.org> wrote:
> I actually already have a little pile of MMC things queued:
Please also consider queuing up the attached patch as well.
The patch is removing the current SDIO cards 1.8V limit, which is
needed for embedded
SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
have on the ZOOM2 boards for example).
Thank you,
Ohad.
[-- Attachment #2: 0001-sdio-do-not-ignore-MMC_VDD_165_195.patch --]
[-- Type: text/x-diff, Size: 1014 bytes --]
From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@bencohen.org>
Date: Wed, 15 Jul 2009 09:21:41 +0300
Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
This is needed for 1.8V embedded SDIO devices and supporting host controllers
(e.g. TI 127x and ZOOM2 boards)
Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
---
drivers/mmc/core/sdio.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..6f221dc 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
ocr &= ~0x7F;
}
- if (ocr & MMC_VDD_165_195) {
- printk(KERN_WARNING "%s: SDIO card claims to support the "
- "incompletely defined 'low voltage range'. This "
- "will be ignored.\n", mmc_hostname(host));
- ocr &= ~MMC_VDD_165_195;
- }
-
host->ocr = mmc_select_voltage(host, ocr);
/*
--
1.5.4.3
^ permalink raw reply related
* Re: New MMC maintainer needed
From: Paul Mundt @ 2009-07-23 6:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Matt Fleming, Ian Molton, Pierre Ossman, 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: <20090722232259.d0ff3495.akpm@linux-foundation.org>
On Wed, Jul 22, 2009 at 11:22:59PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:
>
> > On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> > > Andrew Morton wrote:
> > >
> > >> 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.
> > >
> > > If no-one else is helping out, Im happy to also be CC'd on MMC patches.
> > >
> >
> > Ditto.
>
> Thanks, guys.
>
> I actually already have a little pile of MMC things queued:
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
> http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
>
> I guess we own them now ;)
While you're in MMC collection mode:
http://lkml.org/lkml/2009/7/17/75
wants to be queued, too. Presumably Ian will get to it at some point,
though.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-07-23 6:22 UTC (permalink / raw)
To: Matt Fleming
Cc: Ian Molton, Pierre Ossman, 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: <20090723055447.GA12211@console-pimps.org>
On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <matt@console-pimps.org> wrote:
> On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> > Andrew Morton wrote:
> >
> >> 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.
> >
> > If no-one else is helping out, Im happy to also be CC'd on MMC patches.
> >
>
> Ditto.
Thanks, guys.
I actually already have a little pile of MMC things queued:
http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch
http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch
I guess we own them now ;)
^ permalink raw reply
* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-07-23 5:54 UTC (permalink / raw)
To: Ian Molton
Cc: Andrew Morton, Pierre Ossman, 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>
On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote:
> Andrew Morton wrote:
>
>> 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.
>
> If no-one else is helping out, Im happy to also be CC'd on MMC patches.
>
Ditto.
^ permalink raw reply
* Re: New MMC maintainer needed
From: Ian Molton @ 2009-07-23 0:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Pierre Ossman, 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: <20090722151744.fffd7bf5.akpm@linux-foundation.org>
Andrew Morton wrote:
> 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.
If no-one else is helping out, Im happy to also be CC'd on MMC patches.
I've been out of the loop, as I mentioned, but I dont mind helping out.
I'm currently helping someone bring a PCI based TMIO type device online
via email.
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?
^ permalink raw reply
* Re: New MMC maintainer needed
From: Andrew Morton @ 2009-07-22 22:17 UTC (permalink / raw)
To: Pierre Ossman
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: <20090714153601.6dfe70ff@mjolnir.ossman.eu>
On Tue, 14 Jul 2009 15:36:01 +0200
Pierre Ossman <pierre@ossman.eu> wrote:
> I'm afraid the time has come for me to step down as maintainer for the
> MMC/SD/SDIO subsystem and for someone else to take over the rudder. It
> is no secret that I haven't been able to give the maintainer role the
> resources it required, and as a result it has gone from being a fun
> hobby to a burdensome chore. I was hoping it was a temporary slump, but
> this has been the norm for over a year now, so it's time for me to
> throw in the towel.
>
> I don't have any clear nominees for a replacement, but if you feel that
> you are in a position to take over the maintainer role then please
> raise your hand.
>
> I only have a few patches in my queue right now and I can push those
> off to Linus before I quit. There are however a lot of unhandled
> messages that need attention. I can provide a list once a successor has
> been named.
>
> I realise that you have put a lot of time and effort into the patches
> you send me and I am truly sorry that I haven't been able to handle
> them better. Hopefully me stepping down means that we get someone who
> can actually take care of everything in a timely manner.
>
> I haven't decided what to do with the sdhci maintainership yet. Right
> now I only know I need a break and freeing myself from the MMC
> maintainer role is the first step. Hopefully I can return as a
> developer in the future.
>
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.
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.
When it comes to subsystems about which I have little knowledge I tend
to work as follows:
- scan the patch to see if anything stands out to my inexperienced eye
- if possible, comment on it to make a bit of noise and to let the
submitter and others know that a) someone has looked at it and b)
there's a chance that it'll be merged.
- try to identify some people who might have an interest in the patch
and/or who might have related experience which would help them review
this one effectively.
So if someone finds themselves cc'ed on an MMC email from myself,
please do take a bit of time to pass an eye across it, and let us know
that you have done so - it really helps.
^ permalink raw reply
* Re: [PATCH 3/5] Add support for LZO-compressed kernels
From: Albin Tonnerre @ 2009-07-22 16:50 UTC (permalink / raw)
To: kevin.granade; +Cc: linux, hpa, alain, linux-kernel, linux-embedded
In-Reply-To: <0022152d7fe9b6dbcf046f4d04a6@google.com>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
On Wed, Jul 22, 2009 at 03:28:09PM +0000, kevin.granade@gmail.com wrote :
> On Jul 22, 2009 9:01am, Albin Tonnerre <albin.tonnerre@free-electrons.com>
> wrote:
> > 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.
>
> Is that "time to run the extraction algorithm", or "time to read in image from
> media and extract"? I think the time to read from the media would tend to
> dominate the decompression time.
> Either way, could you provide the other time for each algorithm in order to
> give a sense of how this might scale to other CPU speeds/media read speeds?
>
That's the time to run the extraction algorithm. As H. Peter Anvin pointed out,
you can have a fast media and a somewhat slow CPU, for which lzo makes sense.
As for other data, I don't have all the figures handy, but:
- LZMA: compressed size 1.19Mo, decompression time: several *seconds* (that's
on a 180MHz ARM9 board, using a patch to implement LZMA compression similar
to this one)
- Bzip2 eats a lot of RAM, and head.S only gives 64Ko of malloc() space on
ARM, so I didn't try.
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 3/5] Add support for LZO-compressed kernels
From: H. Peter Anvin @ 2009-07-22 16:08 UTC (permalink / raw)
To: kevin.granade; +Cc: Albin Tonnerre, linux, alain, linux-kernel, linux-embedded
In-Reply-To: <0022152d7fe9b6dbcf046f4d04a6@google.com>
kevin.granade@gmail.com wrote:
> >
> > So for a compression ratio that is still relatively close to gzip, it's
> > much faster to extract, at least in that case.
>
> Is that "time to run the extraction algorithm", or "time to read in
> image from media and extract"? I think the time to read from the media
> would tend to dominate the decompression time.
> Either way, could you provide the other time for each algorithm in order
> to give a sense of how this might scale to other CPU speeds/media read
> speeds?
>
If you have very slow media, you probably want to use LZMA. If you have
a very slow CPU and comparatively fast media, LZO might be a good
option... I have heard people asking for *uncompressed* kernels for this
reason, but LZO runs at a significant fraction of memcpy() speed.
-hpa
^ permalink raw reply
* [PATCH 5/5] Add support for LZO-compressed kernels on x86
From: Albin Tonnerre @ 2009-07-22 14:01 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded, Albin Tonnerre
In-Reply-To: <1248271279-9920-4-git-send-email-albin.tonnerre@free-electrons.com>
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>
---
arch/x86/Kconfig | 1 +
arch/x86/boot/compressed/Makefile | 5 ++++-
arch/x86/boot/compressed/misc.c | 4 ++++
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 738bdc6..49974d3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -48,6 +48,7 @@ config X86
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZMA
+ select HAVE_KERNEL_LZO
select HAVE_ARCH_KMEMCHECK
config OUTPUT_FORMAT
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index e2ff504..95bfe0e 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -4,7 +4,7 @@
# create a compressed vmlinux image from the original vmlinux
#
-targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma head_$(BITS).o misc.o piggy.o
+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.lzo head_$(BITS).o misc.o piggy.o
KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
KBUILD_CFLAGS += -fno-strict-aliasing -fPIC
@@ -48,10 +48,13 @@ $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
$(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lzma)
+$(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
+ $(call if_changed,lzo)
suffix-$(CONFIG_KERNEL_GZIP) := gz
suffix-$(CONFIG_KERNEL_BZIP2) := bz2
suffix-$(CONFIG_KERNEL_LZMA) := lzma
+suffix-$(CONFIG_KERNEL_LZO) := lzo
quiet_cmd_mkpiggy = MKPIGGY $@
cmd_mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false )
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 842b2a3..3b22fe8 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -162,6 +162,10 @@ static int lines, cols;
#include "../../../../lib/decompress_unlzma.c"
#endif
+#ifdef CONFIG_KERNEL_LZO
+#include "../../../../lib/decompress_unlzo.c"
+#endif
+
static void scroll(void)
{
int i;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/5] Add support for LZO-compressed kernels for ARM
From: Albin Tonnerre @ 2009-07-22 14:01 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded, Albin Tonnerre
In-Reply-To: <1248271279-9920-3-git-send-email-albin.tonnerre@free-electrons.com>
This is the second part of patch. This part includes:
- changes to ach/arch/boot/Makefile to make it easier to add new
compression types
- new piggy.lzo.S necessary for lzo compression
- changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or
gzip, depending on the config
- Kconfig support
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
arch/arm/Kconfig | 2 +
arch/arm/boot/compressed/Makefile | 16 +++--
arch/arm/boot/compressed/misc.c | 110 ++++++++------------------------
arch/arm/boot/compressed/piggy.S | 6 --
arch/arm/boot/compressed/piggy.gzip.S | 6 ++
arch/arm/boot/compressed/piggy.lzo.S | 6 ++
6 files changed, 52 insertions(+), 94 deletions(-)
delete mode 100644 arch/arm/boot/compressed/piggy.S
create mode 100644 arch/arm/boot/compressed/piggy.gzip.S
create mode 100644 arch/arm/boot/compressed/piggy.lzo.S
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index aef63c8..ea71c0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -18,6 +18,8 @@ config ARM
select HAVE_KRETPROBES if (HAVE_KPROBES)
select HAVE_FUNCTION_TRACER if (!XIP_KERNEL)
select HAVE_GENERIC_DMA_COHERENT
+ select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZO
help
The ARM series is a line of low-power-consumption RISC chip designs
licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index ce39dc5..4ea8f25 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -63,8 +63,12 @@ endif
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/BSS_START/$(ZBSSADDR)/
-targets := vmlinux vmlinux.lds piggy.gz piggy.o font.o font.c \
- head.o misc.o $(OBJS)
+suffix_$(CONFIG_KERNEL_GZIP) = gzip
+suffix_$(CONFIG_KERNEL_LZO) = lzo
+
+targets := vmlinux vmlinux.lds \
+ piggy.$(suffix_y) piggy.$(suffix_y).o \
+ font.o font.c head.o misc.o $(OBJS)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
ORIG_CFLAGS := $(KBUILD_CFLAGS)
@@ -94,15 +98,15 @@ LDFLAGS_vmlinux += -p --no-undefined -X \
# would otherwise mess up our GOT table
CFLAGS_misc.o := -Dstatic=
-$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
+$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
$(addprefix $(obj)/, $(OBJS)) FORCE
$(call if_changed,ld)
@:
-$(obj)/piggy.gz: $(obj)/../Image FORCE
- $(call if_changed,gzip)
+$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
+ $(call if_changed,$(suffix_y))
-$(obj)/piggy.o: $(obj)/piggy.gz FORCE
+$(obj)/piggy.$(suffix_y).o: $(obj)/piggy.$(suffix_y) FORCE
CFLAGS_font.o := -Dstatic=
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 9e6e512..c4ec564 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -18,11 +18,15 @@
unsigned int __machine_arch_type;
+#define _LINUX_STRING_H_
+
#include <linux/compiler.h> /* for inline */
#include <linux/types.h> /* for size_t */
#include <linux/stddef.h> /* for NULL */
#include <asm/string.h>
+#include <asm/unaligned.h>
+
#ifdef STANDALONE_DEBUG
#define putstr printf
#else
@@ -189,34 +193,8 @@ static inline __ptr_t memcpy(__ptr_t __dest, __const __ptr_t __src,
/*
* gzip delarations
*/
-#define OF(args) args
#define STATIC static
-typedef unsigned char uch;
-typedef unsigned short ush;
-typedef unsigned long ulg;
-
-#define WSIZE 0x8000 /* Window size must be at least 32k, */
- /* and a power of two */
-
-static uch *inbuf; /* input buffer */
-static uch window[WSIZE]; /* Sliding window buffer */
-
-static unsigned insize; /* valid bytes in inbuf */
-static unsigned inptr; /* index of next byte to be processed in inbuf */
-static unsigned outcnt; /* bytes in output buffer */
-
-/* gzip flag byte */
-#define ASCII_FLAG 0x01 /* bit 0 set: file probably ascii text */
-#define CONTINUATION 0x02 /* bit 1 set: continuation of multi-part gzip file */
-#define EXTRA_FIELD 0x04 /* bit 2 set: extra field present */
-#define ORIG_NAME 0x08 /* bit 3 set: original file name present */
-#define COMMENT 0x10 /* bit 4 set: file comment present */
-#define ENCRYPTED 0x20 /* bit 5 set: file is encrypted */
-#define RESERVED 0xC0 /* bit 6,7: reserved */
-
-#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())
-
/* Diagnostic functions */
#ifdef DEBUG
# define Assert(cond,msg) {if(!(cond)) error(msg);}
@@ -234,24 +212,20 @@ static unsigned outcnt; /* bytes in output buffer */
# define Tracecv(c,x)
#endif
-static int fill_inbuf(void);
-static void flush_window(void);
static void error(char *m);
extern char input_data[];
extern char input_data_end[];
-static uch *output_data;
-static ulg output_ptr;
-static ulg bytes_out;
+static unsigned char *output_data;
+static unsigned long output_ptr;
static void error(char *m);
static void putstr(const char *);
-extern int end;
-static ulg free_mem_ptr;
-static ulg free_mem_end_ptr;
+static unsigned long free_mem_ptr;
+static unsigned long free_mem_end_ptr;
#ifdef STANDALONE_DEBUG
#define NO_INFLATE_MALLOC
@@ -259,46 +233,13 @@ static ulg free_mem_end_ptr;
#define ARCH_HAS_DECOMP_WDOG
-#include "../../../../lib/inflate.c"
-
-/* ===========================================================================
- * Fill the input buffer. This is called only when the buffer is empty
- * and at least one byte is really needed.
- */
-int fill_inbuf(void)
-{
- if (insize != 0)
- error("ran out of input data");
-
- inbuf = input_data;
- insize = &input_data_end[0] - &input_data[0];
-
- inptr = 1;
- return inbuf[0];
-}
+#ifdef CONFIG_KERNEL_GZIP
+#include "../../../../lib/decompress_inflate.c"
+#endif
-/* ===========================================================================
- * Write the output window window[0..outcnt-1] and update crc and bytes_out.
- * (Used for the decompressed data only.)
- */
-void flush_window(void)
-{
- ulg c = crc;
- unsigned n;
- uch *in, *out, ch;
-
- in = window;
- out = &output_data[output_ptr];
- for (n = 0; n < outcnt; n++) {
- ch = *out++ = *in++;
- c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
- }
- crc = c;
- bytes_out += (ulg)outcnt;
- output_ptr += (ulg)outcnt;
- outcnt = 0;
- putstr(".");
-}
+#ifdef CONFIG_KERNEL_LZO
+#include "../../../../lib/decompress_unlzo.c"
+#endif
#ifndef arch_error
#define arch_error(x)
@@ -317,20 +258,26 @@ static void error(char *x)
#ifndef STANDALONE_DEBUG
-ulg
-decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
- int arch_id)
+unsigned long
+decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
+ unsigned long free_mem_ptr_end_p,
+ int arch_id)
{
- output_data = (uch *)output_start; /* Points to kernel start */
+ unsigned char *tmp;
+
+ output_data = (unsigned char *)output_start;
free_mem_ptr = free_mem_ptr_p;
free_mem_end_ptr = free_mem_ptr_end_p;
__machine_arch_type = arch_id;
arch_decomp_setup();
- makecrc();
+ tmp = (unsigned char *) (((unsigned long)input_data_end) - 4);
+ output_ptr = get_unaligned_le32(tmp);
+
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_data_end - input_data,
+ NULL, NULL, output_data, NULL, error);
putstr(" done, booting the kernel.\n");
return output_ptr;
}
@@ -342,11 +289,10 @@ int main()
{
output_data = output_buffer;
- makecrc();
putstr("Uncompressing Linux...");
- gunzip();
+ decompress(input_data, input_data_end - input_data,
+ NULL, NULL, output_data, NULL, error);
putstr("done.\n");
return 0;
}
#endif
-
diff --git a/arch/arm/boot/compressed/piggy.S b/arch/arm/boot/compressed/piggy.S
deleted file mode 100644
index 54c9518..0000000
--- a/arch/arm/boot/compressed/piggy.S
+++ /dev/null
@@ -1,6 +0,0 @@
- .section .piggydata,#alloc
- .globl input_data
-input_data:
- .incbin "arch/arm/boot/compressed/piggy.gz"
- .globl input_data_end
-input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.gzip.S b/arch/arm/boot/compressed/piggy.gzip.S
new file mode 100644
index 0000000..a68adf9
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.gzip.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.gzip"
+ .globl input_data_end
+input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.lzo.S b/arch/arm/boot/compressed/piggy.lzo.S
new file mode 100644
index 0000000..a425ad9
--- /dev/null
+++ b/arch/arm/boot/compressed/piggy.lzo.S
@@ -0,0 +1,6 @@
+ .section .piggydata,#alloc
+ .globl input_data
+input_data:
+ .incbin "arch/arm/boot/compressed/piggy.lzo"
+ .globl input_data_end
+input_data_end:
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/5] Add support for LZO-compressed kernels
From: Albin Tonnerre @ 2009-07-22 14:01 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded, Albin Tonnerre
In-Reply-To: <1248271279-9920-2-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>
---
include/linux/decompress/unlzo.h | 10 +++
init/Kconfig | 18 ++++-
lib/decompress_unlzo.c | 138 ++++++++++++++++++++++++++++++++++++++
lib/lzo/lzo1x_decompress.c | 9 ++-
scripts/Makefile.lib | 5 ++
5 files changed, 173 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 1ce05a4..66281fb 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..d908b35
--- /dev/null
+++ b/lib/decompress_unlzo.c
@@ -0,0 +1,138 @@
+/*
+ * 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"
+#endif
+
+#include <linux/lzo.h>
+#include <linux/decompress/mm.h>
+#include <linux/decompress/unlzo.h>
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+#include <asm/unaligned.h>
+
+static const unsigned char lzop_magic[] =
+ { 0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a };
+
+#define 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 lzo_decompress(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 = input;
+ u8 *out_buf = output;
+ int obytes_processed = 0;
+
+ if (!parse_header(input, &skip))
+ error("invalid header");
+
+ in_buf += skip;
+ for (;;) {
+ /* read uncompressed block size */
+ dst_len = get_unaligned_be32(in_buf);
+ in_buf += 4;
+
+ /* exit if last block */
+ if (dst_len == 0)
+ break;
+
+ if (dst_len > BLOCK_SIZE)
+ error("dest len longer than block size");
+
+ /* 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");
+
+ /* 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");
+
+ obytes_processed += dst_len;
+ in_buf += src_len;
+ out_buf += dst_len;
+ }
+ return obytes_processed;
+}
+
+#define decompress lzo_decompress
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)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/5] include/linux/unaligned/{l,b}e_byteshift.h: Fix usage for compressed kernels
From: Albin Tonnerre @ 2009-07-22 14:01 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded, Albin Tonnerre
In-Reply-To: <1248271279-9920-1-git-send-email-albin.tonnerre@free-electrons.com>
When unaligned accesses are required for uncompressing a kernel (such as
for LZO decompression on ARM in a patch that follows), including
<linux/kernel.h> causes issues as it brings in a lot of things that are
not available in the decompression environment.
However, those files apparently use nothing from <linux/kernel.h>, all
they need is the declaration of types such as u32 or u64, so
<linux/types.h> should be enough
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
include/linux/unaligned/be_byteshift.h | 2 +-
include/linux/unaligned/le_byteshift.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/unaligned/be_byteshift.h b/include/linux/unaligned/be_byteshift.h
index 46dd12c..9356b24 100644
--- a/include/linux/unaligned/be_byteshift.h
+++ b/include/linux/unaligned/be_byteshift.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_UNALIGNED_BE_BYTESHIFT_H
#define _LINUX_UNALIGNED_BE_BYTESHIFT_H
-#include <linux/kernel.h>
+#include <linux/types.h>
static inline u16 __get_unaligned_be16(const u8 *p)
{
diff --git a/include/linux/unaligned/le_byteshift.h b/include/linux/unaligned/le_byteshift.h
index 59777e9..be376fb 100644
--- a/include/linux/unaligned/le_byteshift.h
+++ b/include/linux/unaligned/le_byteshift.h
@@ -1,7 +1,7 @@
#ifndef _LINUX_UNALIGNED_LE_BYTESHIFT_H
#define _LINUX_UNALIGNED_LE_BYTESHIFT_H
-#include <linux/kernel.h>
+#include <linux/types.h>
static inline u16 __get_unaligned_le16(const u8 *p)
{
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/5] lib/decompress_*: only include <linux/slab.h> if STATIC is not defined
From: Albin Tonnerre @ 2009-07-22 14:01 UTC (permalink / raw)
To: linux, hpa; +Cc: alain, linux-kernel, linux-embedded, Albin Tonnerre
These includes were added by 079effb6933f34b9b1b67b08bd4fd7fb672d16ef to
fix the build when using kmemtrace. However this is not necessary when
used to create a compressed kernel, and actually creates issues (brings
a lot of things unavailable in the decompression environment), so don't
include it if STATIC is defined.
Signed-off-by: Albin Tonnerre <albin.tonnerre@free-electrons.com>
---
lib/decompress_bunzip2.c | 2 +-
lib/decompress_inflate.c | 2 +-
lib/decompress_unlzma.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/decompress_bunzip2.c b/lib/decompress_bunzip2.c
index 708e2a8..14b0c7d 100644
--- a/lib/decompress_bunzip2.c
+++ b/lib/decompress_bunzip2.c
@@ -47,10 +47,10 @@
#ifndef STATIC
#include <linux/decompress/bunzip2.h>
+#include <linux/slab.h>
#endif /* !STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#ifndef INT_MAX
#define INT_MAX 0x7fffffff
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index e36b296..fc30d50 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -19,11 +19,11 @@
#include "zlib_inflate/inflate.h"
#include "zlib_inflate/infutil.h"
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define INBUF_LEN (16*1024)
diff --git a/lib/decompress_unlzma.c b/lib/decompress_unlzma.c
index 32123a1..f078c88 100644
--- a/lib/decompress_unlzma.c
+++ b/lib/decompress_unlzma.c
@@ -31,10 +31,10 @@
#ifndef STATIC
#include <linux/decompress/unlzma.h>
+#include <linux/slab.h>
#endif /* STATIC */
#include <linux/decompress/mm.h>
-#include <linux/slab.h>
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
--
1.6.0.4
^ permalink raw reply related
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