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.
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.
Pierre Ossman 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.
Thank you for your time and effort on this subsystem.
I havent done anything 'deep' in MMC for some time (since my initial SD
mem card support), so I dont feel qualified to step up. Hopefully we'll
find someone suitable.
> 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.
What an unfortunate thing.
Franky speaking, I couldn't manage any time to work on Linux
in the last year myself. I had such a great plans for Memstick
and such, yet none advanced.
At this rate, the future of the flash cards on Linux will
become highly uncertain.
:-(
On Tue, 14 Jul 2009 15:36:01 +0200
Pierre Ossman <[email protected]> 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.
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?
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.
On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <[email protected]> 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 ;)
On Wed, Jul 22, 2009 at 11:22:59PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <[email protected]> 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.
Hi Andrew,
On Thu, Jul 23, 2009 at 9:22 AM, Andrew Morton<[email protected]> 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.
Andrew Morton wrote:
> On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming <[email protected]> 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
Hi Andrew,
On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, 23 Jul 2009 17:25:59 +1000 Stephen Rothwell <[email protected]> wrote:
> Hi Andrew,
>
> On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton <[email protected]> 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.
Hi Andrew,
On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton <[email protected]> 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 [email protected]
http://www.canb.auug.org.au/~sfr/
2009/7/23, Matt Fleming <[email protected]>:
> 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
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<[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> ---
> 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 <[email protected]>
Stephen Rothwell <[email protected]> writes:
> Hi Andrew,
>
> On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton <[email protected]> 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
--
[email protected] -- Speaking for myself only.
On Thu, 23 Jul 2009 14:52:09 +0100
Matt Fleming <[email protected]> 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<[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
> > ---
> > 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 :)
On Fri, 24 Jul 2009 15:29:44 -0700
Andrew Morton <[email protected]> wrote:
> On Thu, 23 Jul 2009 14:52:09 +0100
> Matt Fleming <[email protected]> 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<[email protected]> 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 <[email protected]>
> > > 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 <[email protected]>
> > > ---
> > > 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
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'
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?
On Mon, 27 Jul 2009 22:40:01 +0100
Matt Fleming <[email protected]> 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
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'
On Wed, 22 Jul 2009 15:17:44 -0700
Andrew Morton <[email protected]> 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.
On Thu, 23 Jul 2009 01:08:08 +0100
Ian Molton <[email protected]> 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.
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.
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...
On Tue, 28 Jul 2009 22:14:40 +0100
Ian Molton <[email protected]> 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 [email protected] 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?
On Tue, Jul 28, 2009 at 03:41:37PM -0700, Andrew Morton wrote:
> On Tue, 28 Jul 2009 22:14:40 +0100
> Ian Molton <[email protected]> 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 [email protected] 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
Andrew Morton wrote:
> I expect that Dave Miller can set up [email protected] 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.
> 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
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.
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?
On Wed, Jul 15, 2009 at 7:59 AM, Alex Dubov<[email protected]> 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.
>
> What an unfortunate thing.
>
> Franky speaking, I couldn't manage any time to work on Linux
> in the last year myself. I had such a great plans for Memstick
> and such, yet none advanced.
>
> At this rate, the future of the flash cards on Linux will
> become highly uncertain.
> :-(
>
Me too.
I had plans to reverse engineer and then write drivers for my ricoh 5
in one controller
for SD and memstick mode (especialy XD)
Now I know that RE part isn't the hardest probably, but writing the
core support for XD subsystem (your was rejected I see)
I am also an owner of a jmicron controller, and thanks to you memstick
on it is supported.
What to do now?
Best regards,
Maxim Levitsky