MMC Driver RFC

MMC Driver RFC

[Richard Purdie]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

I've been working on enabling the MMC/SD card slot on the Sharp SL-C7xx 
series. I've come across the following issues and would appreciate comments:

1. Card Detection Interrupts

The MMC code completely misses card removals on my test hardware as when the 
interrupt triggers electrical contact is still fully functional.

The PXA code calls mmc_detect_change() whenever an interrupt is detected. 
The MMC core then does a schedule_work(&host->detect). The problem is that 
when the interrupt is generated, the card may not be 100% inserted or 100% 
removed. Given the mechanical nature of insertions and removals, electrical 
contact is possible for a while after removal has been started (and a while 
before insertion is complete).

My proposed solution is to change the above code to 
schedule_delayed_work(&host->detect, HZ/4). Waiting 1/4 of a second after an 
event for things to stabilise makes my test hardware completely functional. 
It also makes a lot of sense in general as far as I can see. Patch attached.

2. Card Initialisation Problems

One of my cards works fine. The other works when I enable debug and doesn't 
when I don't. I suspect the delay while it does a printk gives something 
time to happen that doesn't normally when running at full speed!

I suspect this is related to the 1ms wait that was added to mmc_setup() as 
per comments. Is there any documentation which tells us exactly what timings 
we should be aiming for here? Has anyone else has problems like this?

3. SD Support

Ian Molton seems to have added SD support to handhelds.org's kernel. I'm 
still trying to contact him to discuss this but the following patch enables 
SD cards to work for me:
http://www.rpsys.net/openzaurus/2.6.11-rc1/mmc_sd-r1.patch

Was there a reason why SD support wasn't included in the original driver? 
Would something like this patch be accepted into the kernel (I realise it 
has some rough edges). I'd probably remove the attempt at 4 bit support 
until a mainstream driver supported that...

Richard


[-- Attachment #2: mmc_delay-r0.patch --]
[-- Type: application/octet-stream, Size: 363 bytes --]


#
# Patch managed by http://www.holgerschurig.de/patcher.html
#

--- linux-2.6.11-rc1/drivers/mmc/mmc.c~mmc_delay
+++ linux-2.6.11-rc1/drivers/mmc/mmc.c
@@ -725,7 +725,7 @@
  */
 void mmc_detect_change(struct mmc_host *host)
 {
-	schedule_work(&host->detect);
+	schedule_delayed_work(&host->detect, HZ/4);
 }
 
 EXPORT_SYMBOL(mmc_detect_change);

Re: MMC Driver RFC

[Russell King]

On Wed, Jan 12, 2005 at 09:10:12PM -0000, Richard Purdie wrote:
> 1. Card Detection Interrupts
> 
> The MMC code completely misses card removals on my test hardware as when the 
> interrupt triggers electrical contact is still fully functional.
> 
> The PXA code calls mmc_detect_change() whenever an interrupt is detected. 
> The MMC core then does a schedule_work(&host->detect). The problem is that 
> when the interrupt is generated, the card may not be 100% inserted or 100% 
> removed. Given the mechanical nature of insertions and removals, electrical 
> contact is possible for a while after removal has been started (and a while 
> before insertion is complete).

If your socket works like that, you need to handle that by using a timer
yourself.  It normally only affects removal rather than insertion.

> 2. Card Initialisation Problems
> 
> One of my cards works fine. The other works when I enable debug and doesn't 
> when I don't. I suspect the delay while it does a printk gives something 
> time to happen that doesn't normally when running at full speed!

Different cards behave differently.  I suspect you have yet another
quirky card.

> I suspect this is related to the 1ms wait that was added to mmc_setup() as 
> per comments. Is there any documentation which tells us exactly what timings 
> we should be aiming for here? Has anyone else has problems like this?

There isn't any 1ms wait in mmc_setup().

> 3. SD Support
> 
> Ian Molton seems to have added SD support to handhelds.org's kernel. I'm 
> still trying to contact him to discuss this but the following patch enables 
> SD cards to work for me:
> http://www.rpsys.net/openzaurus/2.6.11-rc1/mmc_sd-r1.patch

People are nervous about SD support - the SD forum has been traditionally
rather closed, and there is the perception that a SD card driver may not
go down well.  I have even heard rumours of patent issues/IP issues in
this area, and I don't wish to get stung.

However, that said, the situation has improved recently - we've gone from
no documentation to limited documentation.  However, this documentation
still isn't sufficient to do the job - eg, the SD formats for the CID
and CSD registers remain completely undocumented.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: MMC Driver RFC

[Richard Purdie]

Russell King:
>> The PXA code calls mmc_detect_change() whenever an interrupt is detected.
>> The MMC core then does a schedule_work(&host->detect). The problem is 
>> that
>> when the interrupt is generated, the card may not be 100% inserted or 
>> 100%
>> removed. Given the mechanical nature of insertions and removals, 
>> electrical
>> contact is possible for a while after removal has been started (and a 
>> while
>> before insertion is complete).
>
> If your socket works like that, you need to handle that by using a timer
> yourself.  It normally only affects removal rather than insertion.

It has only shown up on removal events *so far*. I know that the interrupt 
triggers before the card is fully seated in the slot upon insertion on this 
device as well and I'd imagine it does so on other devices given the 
physical design of the cards. Initalisation whilst the electrical contacts 
are still moving can't be a wise idea even if it hasn't bitten anyone yet.

I'm therefore asking if there is a general case for waiting a short while 
after any card insertion/removal event?

If not, I will just have to delay the interrupt on my hardware as you 
suggest. (A user isn't going to notice 0.25s delay in the grand scheme of 
things...). I suspect I'll not be the last person to have problems with this 
though.

>> 2. Card Initialisation Problems
>
> Different cards behave differently.  I suspect you have yet another
> quirky card.

What is the policy on handling this? Pin the error down, then see what can 
be done about it? I'll just have to move delays about until I find the one 
that helps guess.

I was wondering if there was some kind of timing specification somewhere as 
all these cards seem to work fine under other operating systems...

>> I suspect this is related to the 1ms wait that was added to mmc_setup() 
>> as
>> per comments. Is there any documentation which tells us exactly what 
>> timings
>> we should be aiming for here? Has anyone else has problems like this?
>
> There isn't any 1ms wait in mmc_setup().

I was referrng to the 1ms delay in mmc_idle_cards() which is called twice by 
mmc_setup(). There is a comment about it in mmc_setup(): "We wait 1ms to 
give cards time to respond.". Was this just derived from experimentation?

> People are nervous about SD support - the SD forum has been traditionally
> rather closed, and there is the perception that a SD card driver may not
> go down well.  I have even heard rumours of patent issues/IP issues in
> this area, and I don't wish to get stung.
>
> However, that said, the situation has improved recently - we've gone from
> no documentation to limited documentation.  However, this documentation
> still isn't sufficient to do the job - eg, the SD formats for the CID
> and CSD registers remain completely undocumented.

Looking at the code from hh.org, it could be (and probably has been) derived 
from the documentation available so I can't see a patent/IP problem although 
I understand the concern. I agree that lack of info about the formatting of 
CID and CSD registers is an issue although the hh.org code does seem to 
work. Is guessing what the values mean an IP/patent infringement?...

Richard 

Re: MMC Driver RFC

[Russell King]

On Wed, Jan 12, 2005 at 10:07:26PM -0000, Richard Purdie wrote:
> Russell King:
> >> The PXA code calls mmc_detect_change() whenever an interrupt is detected.
> >> The MMC core then does a schedule_work(&host->detect). The problem is 
> >> that
> >> when the interrupt is generated, the card may not be 100% inserted or 
> >> 100%
> >> removed. Given the mechanical nature of insertions and removals, 
> >> electrical
> >> contact is possible for a while after removal has been started (and a 
> >> while
> >> before insertion is complete).
> >
> > If your socket works like that, you need to handle that by using a timer
> > yourself.  It normally only affects removal rather than insertion.
> 
> It has only shown up on removal events *so far*. I know that the interrupt 
> triggers before the card is fully seated in the slot upon insertion on this 
> device as well and I'd imagine it does so on other devices given the 
> physical design of the cards. Initalisation whilst the electrical contacts 
> are still moving can't be a wise idea even if it hasn't bitten anyone yet.

The same is true of PCMCIA cards as well.

> I'm therefore asking if there is a general case for waiting a short while 
> after any card insertion/removal event?

I believe the MMC "specification" with its power on times and minimum
number of clocks are supposed to take care of the insertion.  However,
see below.

> If not, I will just have to delay the interrupt on my hardware as you 
> suggest. (A user isn't going to notice 0.25s delay in the grand scheme of 
> things...). I suspect I'll not be the last person to have problems with
> this though.

That depends whether the hardware already provides 0.5s of debounce
already.  Some people do, some people don't.  This is why it needs to
be left to the implementation and not a core issue.

> >> 2. Card Initialisation Problems
> >
> > Different cards behave differently.  I suspect you have yet another
> > quirky card.
> 
> What is the policy on handling this? Pin the error down, then see what can 
> be done about it? I'll just have to move delays about until I find the one 
> that helps guess.
> 
> I was wondering if there was some kind of timing specification somewhere as 
> all these cards seem to work fine under other operating systems...

That's probably the official MMC specification from the MMC forum.  Us
mere open source developers don't have access to such costly specs, so
we have to make do with the specs released by card manufacturers which
do go into the protocol sufficiently deeply.

Unfortunately, such specs only cover MMC cards and not SD cards.

> >> I suspect this is related to the 1ms wait that was added to mmc_setup() 
> >> as
> >> per comments. Is there any documentation which tells us exactly what 
> >> timings
> >> we should be aiming for here? Has anyone else has problems like this?
> >
> > There isn't any 1ms wait in mmc_setup().
> 
> I was referrng to the 1ms delay in mmc_idle_cards() which is called twice by 
> mmc_setup(). There is a comment about it in mmc_setup(): "We wait 1ms to 
> give cards time to respond.". Was this just derived from experimentation?

This was added because someone was seeing a problem.  There is no
specified delay required by "specifications" I've seen to date.

> Looking at the code from hh.org, it could be (and probably has been) derived 
> from the documentation available so I can't see a patent/IP problem although 
> I understand the concern. I agree that lack of info about the formatting of 
> CID and CSD registers is an issue although the hh.org code does seem to 
> work. Is guessing what the values mean an IP/patent infringement?...

I have no idea - and that's the big problem.  We just don't know
what the situation is with SD.

Maybe now that it's more wildly known that there's SD support available
from handhelds.org, maybe (if the SD forum are reading lkml) we'll see
some reaction.  Let's just hope it's positive.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: MMC Driver RFC

[Ian Molton]

Russell King wrote:

> That depends whether the hardware already provides 0.5s of debounce
> already.  Some people do, some people don't.  This is why it needs to
> be left to the implementation and not a core issue.

Agreed. IIRC my toshiba PDAs *dont* provide a delay. OTOH they also 
provide *two* ways of detecting card presence...

>>>>2. Card Initialisation Problems
>>>
>>>Different cards behave differently.  I suspect you have yet another
>>>quirky card.
>>
>>What is the policy on handling this? Pin the error down, then see what can 
>>be done about it? I'll just have to move delays about until I find the one 
>>that helps guess.
>>
>>I was wondering if there was some kind of timing specification somewhere as 
>>all these cards seem to work fine under other operating systems...
> 
> That's probably the official MMC specification from the MMC forum.  Us
> mere open source developers don't have access to such costly specs, so
> we have to make do with the specs released by card manufacturers which
> do go into the protocol sufficiently deeply.
> 
> Unfortunately, such specs only cover MMC cards and not SD cards.

ISTR seeing a SD card doc at some point

> I have no idea - and that's the big problem.  We just don't know
> what the situation is with SD.
> 
> Maybe now that it's more wildly known that there's SD support available
> from handhelds.org, maybe (if the SD forum are reading lkml) we'll see
> some reaction.  Let's just hope it's positive.

Well I *know* I never saw the specs from the SD forum. I hacve never 
reverse engineered a SDHC core driver either (I have reverse engineered 
a chip driver but it contained no SD *protocol* information.

as such my code should be 100% safe to commit to the kernel.

PS. Richard - I am here - hope you receive this!

Re: MMC Driver RFC

[Richard Purdie]

Ian Molton:
>> That depends whether the hardware already provides 0.5s of debounce
>> already.  Some people do, some people don't.  This is why it needs to
>> be left to the implementation and not a core issue.
>
> Agreed. IIRC my toshiba PDAs *dont* provide a delay. OTOH they also 
> provide *two* ways of detecting card presence...

I hadn't realised some devices had hardware debounce and now agree its not a 
core problem.

> ISTR seeing a SD card doc at some point

The one I'm aware of is 
http://www.sdcard.org/sdio/Simplified%20Physical%20Layer%20Specification.PDF 
.

> Well I *know* I never saw the specs from the SD forum. I hacve never 
> reverse engineered a SDHC core driver either (I have reverse engineered a 
> chip driver but it contained no SD *protocol* information.
>
> as such my code should be 100% safe to commit to the kernel.

Having read things and talked to people (both before and since my posts on 
LKML), that is my conclusion as well.

> PS. Richard - I am here - hope you receive this!

I did. Have my mails to you been getting through?

Richard 

Re: MMC Driver RFC

[Pierre Ossman]

Nice too see that you're alive Ian ;)

I've been trying to send you some mail regarding your SD implementation 
but I haven't received any replies. Perhaps they've gotten lost somewhere?

I've made my own SD patch using some of your work but also a lot of my 
own stuff. I had some problems getting your patches to apply cleanly to 
the current tree so I reimplemented it using your code as a template.

The patch can be found at:
http://projects.drzeus.cx/wbsd/sd.php
That page also contains the legal issues as I've understood them.

A summary of what I've done (relative your work):

* flags renamed to caps to better reflect what it does.
* SD_4_BITS changed to 4_BIT_DATA. Hopefully 4-bit mode in SD and MMC 
will be compatible, at least on the driver level.
* HOST_ changed to MMC_ to conform with the rest of the macros.
* Added a function in the driver to test for SD read-only switch.
* Moved SD-specific commands to a separate section in the header so they 
are more easily distinguished.
* SCR register is read from card and used when determining bus width.
* I've separated SD detection a bit.
* The mode (SD/MMC) of the host is stored. Since MMC uses a bus topology 
and SD uses a star one it is useful to be able to see which mode the 
controller is in.

I also couldn't find the reason for the ACMD flags you've added. 
Application commands only differ in semantics, not format, so I couldn't 
figure out why these where needed. Perhaps I'm missing something.

Ian Molton wrote:
>>
>> Unfortunately, such specs only cover MMC cards and not SD cards.
> 
> 
> ISTR seeing a SD card doc at some point

I have specs for SD cards from Sandisk and Toshiba. Both found on the 
respective manufacturer's site using google. These have been the basis 
for my work.

> 
> Well I *know* I never saw the specs from the SD forum. I hacve never 
> reverse engineered a SDHC core driver either (I have reverse engineered 
> a chip driver but it contained no SD *protocol* information.
> 
> as such my code should be 100% safe to commit to the kernel.
> 

My code is based on the SD card specs I've found so it probably isn't as 
safe.

Rgds
Pierre

Re: MMC Driver RFC

[Ian Molton]

Pierre Ossman wrote:
> Nice too see that you're alive Ian ;)
> 
> I've been trying to send you some mail regarding your SD implementation 
> but I haven't received any replies. Perhaps they've gotten lost somewhere?

I've been getting errors replying to you but had no alternative address 
to use. perhaps you could mail me from another account ?

> A summary of what I've done (relative your work):
> 
> * flags renamed to caps to better reflect what it does.
> * SD_4_BITS changed to 4_BIT_DATA. Hopefully 4-bit mode in SD and MMC 
> will be compatible, at least on the driver level.
> * HOST_ changed to MMC_ to conform with the rest of the macros.
> * Added a function in the driver to test for SD read-only switch.

Good stuff.

> * Moved SD-specific commands to a separate section in the header so they 
> are more easily distinguished.

I had been meaning to move all the c code referencing SD to a seperate 
sd.c file such that it could be compiled optionally on top of MMC. at 
the time it wasnt mature enough to be worth it, but that may be worth 
revisiting now.

> * SCR register is read from card and used when determining bus width.

Good. This was needed.

> * I've separated SD detection a bit.

Good (see above :)

> * The mode (SD/MMC) of the host is stored. Since MMC uses a bus topology 
> and SD uses a star one it is useful to be able to see which mode the 
> controller is in.

Is this needed? presumably any controller that implements MMC/SD slots 
can only have one card/slot anyhow.

Mind you, I have plans to look at SDIO, so that may alter things...

> I also couldn't find the reason for the ACMD flags you've added. 
> Application commands only differ in semantics, not format, so I couldn't 
> figure out why these where needed. Perhaps I'm missing something.

The toshiba controller appears to want to be told when an ACMD is 
issued, compared to a normal CMD.

>> as such my code should be 100% safe to commit to the kernel.
> 
> My code is based on the SD card specs I've found so it probably isn't as 
> safe.

The card specs I have seen were public docs so we should be clear there.

Re: MMC Driver RFC

[Pierre Ossman]

Ian Molton wrote:

>
> I've been getting errors replying to you but had no alternative 
> address to use. perhaps you could mail me from another account ?
>
Afraid everything gets routed to the same account in the end anyway. I 
checked the logs and the problem is that your mail server has a HELO 
that differs from its IP (outmail.freedom2surf.net vs. 194.106.33.237). 
Reverse is ok, but forward points to 194.106.56.14.

>> * Moved SD-specific commands to a separate section in the header so 
>> they are more easily distinguished.
>
>
> I had been meaning to move all the c code referencing SD to a seperate 
> sd.c file such that it could be compiled optionally on top of MMC. at 
> the time it wasnt mature enough to be worth it, but that may be worth 
> revisiting now.
>
I've had the same idea. But I think it will be difficult since we need 
som funky logic during init. Perhaps a model where each mode 
(MMC/SD/SDIO) each gets their turn trying to find something on the bus. 
But this would require a rather large rewrite of the MMC layer. We would 
need to separate MMC logic from the driver interface. And mmc_block and 
sd_block would more or less be the same. Considering how much is similar 
(and most people want SD support anyhow), I'm not sure that we have much 
to gain from separating them.

>> * The mode (SD/MMC) of the host is stored. Since MMC uses a bus 
>> topology and SD uses a star one it is useful to be able to see which 
>> mode the controller is in.
>
>
> Is this needed? presumably any controller that implements MMC/SD slots 
> can only have one card/slot anyhow.
>
> Mind you, I have plans to look at SDIO, so that may alter things...
>
I need it to determine if the code should send an RCA or ask for one, 
and to determine if it should try and read the SCR. Your solution used 
an extra parameter but I thought a mode flag would be better since we 
might need to know mode later on (after init.).

>
> The toshiba controller appears to want to be told when an ACMD is 
> issued, compared to a normal CMD.

No hints in the spec about why? Seems very strange since there's no 
change in what goes over the wire.

Rgds
Pierre

Re: MMC Driver RFC

[Ian Molton]

Pierre Ossman wrote:
> Ian Molton wrote:

> Afraid everything gets routed to the same account in the end anyway. I 
> checked the logs and the problem is that your mail server has a HELO 
> that differs from its IP

I've sent mail to my ISP re that. cheers.

> I've had the same idea. But I think it will be difficult since we need 
> som funky logic during init. Perhaps a model where each mode 
> (MMC/SD/SDIO) each gets their turn trying to find something on the bus.

Might be worth the effort. I'll need to think on it.

> But this would require a rather large rewrite of the MMC layer.

Im not sure it'd be so catastrophic.

>> Mind you, I have plans to look at SDIO, so that may alter things...
>>
> I need it to determine if the code should send an RCA or ask for one, 
> and to determine if it should try and read the SCR. Your solution used 
> an extra parameter but I thought a mode flag would be better since we 
> might need to know mode later on (after init.).

Fair enough.

>> The toshiba controller appears to want to be told when an ACMD is 
>> issued, compared to a normal CMD.
> 
> No hints in the spec about why?

What spec? ;-)

 > Seems very strange since there's no change in what goes over the wire.

I think the controller (for some odd reason) keeps some extra internal 
state.

Re: MMC Driver RFC

[Pierre Ossman]

Ian Molton wrote:

>>> The toshiba controller appears to want to be told when an ACMD is 
>>> issued, compared to a normal CMD.
>>
>> Seems very strange since there's no change in what goes over the wire.
>
> I think the controller (for some odd reason) keeps some extra internal 
> state.

Have you tried using it without telling the controller that it's an ACMD 
being sent?

Rgds
Pierre

Re: MMC Driver RFC

[Alan Cox]

On Sul, 2005-01-16 at 23:17, Richard Purdie wrote:
> On the subject of patents, the whole idea behind SD is that there aren't 
> patents as for a patent to exist, we'd have some publicly available 
> information on how SD works. We're not breaking any copyrights as I nobody 
> involved with this code has see any code to copy from.
> 
> So in short, I can't see any reason we can't put the code we have into the 
> kernel...

Given that companies like Intel have been published the SD
initialisation sequences since 2002 and nobody has taken any action I
can't see this as being credibly a trade secret or obtained maliciously.
Nor does the document state anything is secret.

See Intel app note 278533-001 "Using SDCard and SDIO with Intel (r)
PXA250 Applications Processor MMC Controller" 

http://www.intel.com/design/pca/applicationsprocessors/applnots/278533-001.htm

If there were any secrets the owners appear to have failed to take any
action neccessary to defend them.

Alan

Re: MMC Driver RFC

[Richard Purdie]

Russell King:
> > 2. Card Initialisation Problems
> >
> > One of my cards works fine. The other works when I enable debug and 
> > doesn't when I don't. I suspect the delay while it does a printk gives 
> > something time to happen that doesn't normally when running at full 
> > speed!
>
> Different cards behave differently.  I suspect you have yet another
> quirky card.

For reference, I got the 512MB SD card working by adding an mdelay(3) into 
the middle of mmc_send_op_cond(). Anything shorter and it marks the card as 
bad...

http://www.rpsys.net/openzaurus/2.6.11-rc1/mmc_sd-r2.patch shows the updated 
SD code that works for me on the Sharp SL-C760 with the mdelay included.

Pierre Ossman:
> The patch can be found at:
> http://projects.drzeus.cx/wbsd/sd.php

Now I've got both my cards working, I plan to test this code and compare 
soon. The added features look good.

> That page also contains the legal issues as I've understood them.

I don't see the problems you mention there. Yes companies may have signed 
agreements with the SD card association and yes, that may possibly mean they 
can't distribute Linux with SD support but that would be *their* problem and 
not a reason against including SD support in the kernel. If they remove any 
SD code from Linux then they would still be able to distribute it. I suspect 
that they would be able to distribute SD code already in the public domain 
anyway.

On the subject of patents, the whole idea behind SD is that there aren't 
patents as for a patent to exist, we'd have some publicly available 
information on how SD works. We're not breaking any copyrights as I nobody 
involved with this code has see any code to copy from.

So in short, I can't see any reason we can't put the code we have into the 
kernel...

Richard 

Re: MMC Driver RFC

[Pierre Ossman]

Richard Purdie wrote:

> For reference, I got the 512MB SD card working by adding an mdelay(3) 
> into the middle of mmc_send_op_cond(). Anything shorter and it marks 
> the card as bad...

I fail to see what this delay does. A few lines further down you have a 
mmc_delay which you have removed. That delay was added just to give slow 
cards enough time to power up.

>> That page also contains the legal issues as I've understood them.
>
> *snip*
> So in short, I can't see any reason we can't put the code we have into 
> the kernel...

The point here was that it will probably come back to bite us in the ass 
if we create big obstacles for these companies. Even if it's "their own 
fault" they joined the SD card association. But as Alan pointed out the 
specs. are more or less public by now. Trade secret is most likely out 
of the question, but its difficult to know exactly what the contracts 
they have with their members say.
I, personally, would really like to see SD support included in the main 
kernel. But I can also fully understand if that's not currently possible.

Rgds
Pierre

Re: MMC Driver RFC

[Richard Purdie]

Pierre Ossman:
> I fail to see what this delay does. A few lines further down you have a 
> mmc_delay which you have removed. That delay was added just to give slow 
> cards enough time to power up.

I hadn't realised that delay had been added. It wasn't present in the older 
code I was working against and when I upgraded, I've failed to notice it had 
been added. Adding that will solve all the problems I was seeing.

> I, personally, would really like to see SD support included in the main 
> kernel. But I can also fully understand if that's not currently possible.

I think the way forward is for someone to propose a patch. Your code sounds 
the most advanced but Ian or myself may be prepared to propose something if 
you don't want to. A decision can then be made about whether it can be 
accepted. There have been no objections raised so far - just words of 
caution.

Richard 

Re: MMC Driver RFC

[Pierre Ossman]

Richard Purdie wrote:

> Pierre Ossman:
>
>> I, personally, would really like to see SD support included in the 
>> main kernel. But I can also fully understand if that's not currently 
>> possible.
>
> I think the way forward is for someone to propose a patch. Your code 
> sounds the most advanced but Ian or myself may be prepared to propose 
> something if you don't want to. A decision can then be made about 
> whether it can be accepted. There have been no objections raised so 
> far - just words of caution.

I have no problem with proposing my patch. The reason I've been waiting 
is that I got information from Jim Getttys (of HP) that the SD spec. 
would be made public very soon. So I was waiting for it to be released 
so that we could avoid the legal discussion completely. This was in 
october though and I haven't been able to reach him for an update. So 
perhaps it's time to try a submission notetheless.

What is Russell's position on this issue? After all the MMC layer is his 
baby ;)

Rgds
Pierre