mmc_spi.c driver

mmc_spi.c driver

[hartleys]

Hello all,

I'm trying to use the mmc_spi.c driver on an EP93xx platform and ran
into the "can't share SPI bus" issue.

My platform currently has an EEPROM (SST25LF040A using the at25.c
driver) and a MMC socket connected to the SPI bus. Just to see what
would happen I commented out the return when multiple devices are found
and just let the driver load. The driver then  appears to load ok and I
can mount the MMC card and still access the EEPROM.

Is there a patch to correctly handle the shared bus issue? If not has
anyone thought about what might need to be done?

Also, I have hooked up the card detect irq thru the
host->pdata->init(&spi->dev, mmc_spi_detect_irq, mmc) call and added a
comment in mmc_spi_detect_irq() to make sure it is called. Nothing
happens after that. I haven't looked into what mmc_detect_change() does
yet but shouldn't I see a new message from the mmc stuff about a "new
MMC card on SPI"?

Maybe I'm just missing something... still pretty new at this whole Linux
thing... ;-)

Thanks for the help,
Hartley Sweeten


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: mmc_spi.c driver

[David Brownell]

On Thursday 03 April 2008, hartleys wrote:
> Hello all,
> 
> I'm trying to use the mmc_spi.c driver on an EP93xx platform and ran
> into the "can't share SPI bus" issue.
> 
> My platform currently has an EEPROM (SST25LF040A using the at25.c
> driver) and a MMC socket connected to the SPI bus. Just to see what
> would happen I commented out the return when multiple devices are found
> and just let the driver load. The driver then  appears to load ok and I
> can mount the MMC card and still access the EEPROM.

Presumably that means you're doing mutual exclusion "by hand"
and accessing one device at a time. 

If you access both devices concurrently -- say, running a
script that loops over EEPROM access in the background while
runing an FSCK over MMC in the foreground -- I'd expect you
to see problems caused by EEPROM operations appearing in the
midst of multi-phase MMC operations.


> Is there a patch to correctly handle the shared bus issue?

Nothinge mergeable.


> If not has anyone thought about what might need to be done?

Yes; check the list archives.

 
> Also, I have hooked up the card detect irq thru the
> host->pdata->init(&spi->dev, mmc_spi_detect_irq, mmc) call and added a
> comment in mmc_spi_detect_irq() to make sure it is called. Nothing
> happens after that. I haven't looked into what mmc_detect_change() does
> yet but shouldn't I see a new message from the mmc stuff about a "new
> MMC card on SPI"?

Are you actually getting the IRQ?

However, card detection can be a bit troublesome for various reasons,
and there's a known (but un-solved) issue whereby MMC-over-SPI really
wants to start out with a card that's just been through a power cycle
reset.

- Dave

 
> Maybe I'm just missing something... still pretty new at this whole Linux
> thing... ;-)
> 
> Thanks for the help,
> Hartley Sweeten
> 
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[David Brownell]

On Tuesday 15 April 2008, hartleys wrote:
> I do get the IRQ on every card insertion and removal. Actually if I boot
> the system with the card removed I end up getting a:
> 
> mmc0: error -22 whilst initialising SDIO card

That's correct, except for the obvious lie about SDIO.  ;)


> If I then insert the card I get the IRQ and:
> 
> mmc0: new MMC card on SPI
> mmcblk0: mmc0:0001 SDM064 62720KiB
>  mmcblk0: p1 p2 p3 p4
> 
> So it appears the initial card detect does work. But for some reason
> it's not seeing the removal of the card or the insertion of a new card.
> 
> Any ideas?

No; that used to work OK.  I wonder if there have been
changes in the MMC framework which caused this trouble;
I've seen some oddness there too, the last few times I
have tried to use those card detect code paths.

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[David Brownell]

On Tuesday 15 April 2008, hartleys wrote:

> One of the cards actually produces a "Division by zero in kernel." error.
> It appears to happen in the mmc_set_data_timeout() function. I added a
> printk to the function and get the following when the card is inserted.
> 
> mmc_set_data_timeout  timeout_ns:0  timeout_clks:0  ios.clock:400000
> mmc_set_data_timeout  timeout_ns:-589934592  timeout_clks:0  ios.clock:400000
> mmc0: new SD card on SPI
> mmcblk0: mmc0:0000       29888KiB
>  mmcblk0:mmc_set_data_timeout  timeout_ns:-589934592  timeout_clks:0  ios.clock:0
> Division by zero in kernel.
> [<c003e650>] (dump_stack+0x0/0x14) from [<c003e67c>] (__div0+0x18/0x20)
> [<c003e664>] (__div0+0x0/0x20) from [<c01766d8>] (Ldiv0+0x8/0x10)
> [<c0210cb4>] (mmc_set_data_timeout+0x0/0x128) from [<c0216e28>] (mmc_blk_issue_rq+0x124/0x73c)
>  r7:c50b8000 r6:c4949614 r5:c5560e00 r4:c50b8000
> [<c0216d04>] (mmc_blk_issue_rq+0x0/0x73c) from [<c0217a80>] (mmc_queue_thread+0xd8/0x180)
> [<c02179a8>] (mmc_queue_thread+0x0/0x180) from [<c006d6a8>] (kthread+0x54/0x80)
>  r8:00000000 r7:00000000 r6:00000000 r5:c02179a8 r4:fffffffc
> [<c006d654>] (kthread+0x0/0x80) from [<c005a1dc>] (do_exit+0x0/0x828)
>  r5:00000000 r4:00000000
>  p1

That's wrong.  :(


> For some reason the card->host->ios.clock value is getting changed to 0 on
> the third call to the function. I haven't been able to trace down where/why
> this would happen. Any idea on that one?

ISTR the MMC stack sometimes sets clockspeed to zero as a way
of disabling a controller ... but if that were happening, I'd
expect it not to have issued a request like taht.

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[hartleys]

>> One of the cards actually produces a "Division by zero in kernel."
error.
>> It appears to happen in the mmc_set_data_timeout() function. I added
a 
>> printk to the function and get the following when the card is
inserted.
>> 
>> mmc_set_data_timeout  timeout_ns:0  timeout_clks:0  ios.clock:400000 
>> mmc_set_data_timeout  timeout_ns:-589934592  timeout_clks:0  
>> ios.clock:400000
>> mmc0: new SD card on SPI
>> mmcblk0: mmc0:0000       29888KiB
>>  mmcblk0:mmc_set_data_timeout  timeout_ns:-589934592  timeout_clks:0

>> ios.clock:0 Division by zero in kernel.
>> [<c003e650>] (dump_stack+0x0/0x14) from [<c003e67c>] 
>> (__div0+0x18/0x20) [<c003e664>] (__div0+0x0/0x20) from [<c01766d8>] 
>> (Ldiv0+0x8/0x10) [<c0210cb4>] (mmc_set_data_timeout+0x0/0x128) from 
>> [<c0216e28>] (mmc_blk_issue_rq+0x124/0x73c)  r7:c50b8000 r6:c4949614 
>> r5:c5560e00 r4:c50b8000 [<c0216d04>] (mmc_blk_issue_rq+0x0/0x73c)
from 
>> [<c0217a80>] (mmc_queue_thread+0xd8/0x180) [<c02179a8>] 
>> (mmc_queue_thread+0x0/0x180) from [<c006d6a8>] (kthread+0x54/0x80)  
>> r8:00000000 r7:00000000 r6:00000000 r5:c02179a8 r4:fffffffc 
>> [<c006d654>] (kthread+0x0/0x80) from [<c005a1dc>] (do_exit+0x0/0x828)

>> r5:00000000 r4:00000000
>>  p1
>
>That's wrong.  :(
>
>
>> For some reason the card->host->ios.clock value is getting changed to

>> 0 on the third call to the function. I haven't been able to trace
down 
>> where/why this would happen. Any idea on that one?

>ISTR the MMC stack sometimes sets clockspeed to zero as a way of
disabling
>a controller ... but if that were happening, I'd expect it not to have
>issued a request like taht.

I didn't think of checking dmesg before, here's the actual dump after I
insert
the SD card:

mmc_spi_detect_irq
mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi0.1: mmc_spi: power up (21)
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi0.1: mmc_spi: power on (21)
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc_spi spi0.1:   mmc_spi: CMD0, resp R1
mmc0: req done (CMD0): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc_spi spi0.1:   mmc_spi: CMD8, resp R3/R4/R7
mmc_spi spi0.1:   ... CMD8 response SPI_R3/R4/R: resp 0005 ffffffff
mmc0: req done (CMD8): -22: 00000005 ffffffff 00000000 00000000
mmc0: starting CMD5 arg 00000000 flags 000002e1
mmc_spi spi0.1:   mmc_spi: CMD5, resp R3/R4/R7
mmc_spi spi0.1:   ... CMD5 response SPI_R3/R4/R: resp 0005 ffffffff
mmc0: req done (CMD5): -22: 00000005 ffffffff 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi0.1:   mmc_spi: CMD55, resp R1
mmc0: req done (CMD55): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD41 arg 00000000 flags 000000e1
mmc_spi spi0.1:   mmc_spi: CMD41, resp R1
mmc0: req done (CMD41): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc_spi spi0.1:   mmc_spi: CMD0, resp R1
mmc0: req done (CMD0): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD58 arg 00000000 flags 00000280
mmc_spi spi0.1:   mmc_spi: CMD58, resp R3/R4/R7
mmc0: req done (CMD58): 0: 00000001 00ff8000 00000000 00000000
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc_spi spi0.1:   mmc_spi: CMD0, resp R1
mmc0: req done (CMD0): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc_spi spi0.1:   mmc_spi: CMD8, resp R3/R4/R7
mmc_spi spi0.1:   ... CMD8 response SPI_R3/R4/R: resp 0005 ffffffff
mmc0: req done (CMD8): -22: 00000005 ffffffff 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi0.1:   mmc_spi: CMD55, resp R1
mmc0: req done (CMD55): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD41 arg 00000000 flags 000000e1
mmc_spi spi0.1:   mmc_spi: CMD41, resp R1
mmc0: req done (CMD41): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
mmc_spi spi0.1:   mmc_spi: CMD55, resp R1
mmc0: req done (CMD55): 0: 00000001 00000000 00000000 00000000
mmc0: starting CMD41 arg 00000000 flags 000000e1
mmc_spi spi0.1:   mmc_spi: CMD41, resp R1
mmc0: req done (CMD41): 0: 00000000 00000000 00000000 00000000
mmc0: starting CMD59 arg 00000001 flags 00000080
mmc_spi spi0.1:   mmc_spi: CMD59, resp R1
mmc0: req done (CMD59): 0: 00000000 00000000 00000000 00000000
mmc0: starting CMD10 arg 00000000 flags 000000b5
mmc0:     blksz 16 blocks 1 flags 00000200 tsac 0 ms nsac 0
mmc_spi spi0.1:   mmc_spi: CMD10, resp R1
mmc_spi spi0.1:     mmc_spi: read block, 16 bytes
mmc0: req done (CMD10): 0: 00000000 00000000 00000000 00000000
mmc0:     16 bytes transferred: 0
mmc0: starting CMD9 arg 00000000 flags 000000b5
mmc0:     blksz 16 blocks 1 flags 00000200 tsac 0 ms nsac 0
mmc_spi spi0.1:   mmc_spi: CMD9, resp R1
mmc_spi spi0.1:     mmc_spi: read block, 16 bytes
mmc0: req done (CMD9): 0: 00000000 00000000 00000000 00000000
mmc0:     16 bytes transferred: 0
mmc0: starting CMD55 arg 00000000 flags 00000095
mmc_spi spi0.1:   mmc_spi: CMD55, resp R1
mmc0: req done (CMD55): 0: 00000000 00000000 00000000 00000000
mmc0: starting CMD51 arg 00000000 flags 000000b5
mmc0:     blksz 8 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi0.1:   mmc_spi: CMD51, resp R1
mmc_spi spi0.1:     mmc_spi: read block, 8 bytes
mmc0: req done (CMD51): 0: 00000000 00000000 00000000 00000000
mmc0:     8 bytes transferred: 0
mmc0: clock 0Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi0.1: card is read-write
mmc0: new SD card on SPI
mmc0: starting CMD16 arg 00000200 flags 00000095
mmc_spi spi0.1:   mmc_spi: CMD16, resp R1
mmc0: req done (CMD16): 0: 00000000 00000000 00000000 00000000
mmcblk0: mmc0:0000 D0507 29888KiB
 mmcblk0:Division by zero in kernel.
[<c003e650>] (dump_stack+0x0/0x14) from [<c003e67c>] (__div0+0x18/0x20)
[<c003e664>] (__div0+0x0/0x20) from [<c0176718>] (Ldiv0+0x8/0x10)
[<c0210bf4>] (mmc_set_data_timeout+0x0/0xf8) from [<c0217418>]
(mmc_blk_issue_rq
+0x124/0x73c)
 r8:c494f304 r7:c50b8000 r6:c493f614 r5:c5e22000 r4:c50b8000
[<c02172f4>] (mmc_blk_issue_rq+0x0/0x73c) from [<c0218070>]
(mmc_queue_thread+0x
d8/0x180)
[<c0217f98>] (mmc_queue_thread+0x0/0x180) from [<c006d6e0>]
(kthread+0x54/0x80)
 r8:00000000 r7:00000000 r6:00000000 r5:c0217f98 r4:fffffffc
[<c006d68c>] (kthread+0x0/0x80) from [<c005a214>] (do_exit+0x0/0x828)
 r5:00000000 r4:00000000
mmc0: starting CMD18 arg 00000000 flags 000000b5
mmc0:     blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0:     CMD12 arg 00000000 flags 0000049d
mmc_spi spi0.1:   mmc_spi: CMD18, resp R1
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:     mmc_spi: read block, 512 bytes
mmc_spi spi0.1:   mmc_spi: CMD12, resp R1B
mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
mmc0:     4096 bytes transferred: 0
mmc0:     (CMD12): 0: 00000000 00000000 00000000 00000000
 p1

It appears the mmc core is setting the clock to 0Hz for some reason.

If I hack the mmc_set_data_timeout() function to prevent the divide by
zero
the problem goes away and I am able to mount the SD card.

	timeout_us = data->timeout_ns / 1000;
	if (card->nost->ios.clock) {
		timeout_us += data->timeout_clks * 1000 /
			(card->host->ios.clock / 1000);
	}

But this "is" a hack. The question is why does the core set the clock to
0Hz?

Hartley

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[Pierre Ossman]

On Tue, 15 Apr 2008 15:26:54 -0400
"hartleys" <hartleys@visionengravers.com> wrote:

> I do get the IRQ on every card insertion and removal. Actually if I boot
> the system with the card removed I end up getting a:
> 
> mmc0: error -22 whilst initialising SDIO card  

This is a bit odd. It shouldn't have gone down that route unless it is
sure it's an SDIO card it is dealing with.

> If I then insert the card I get the IRQ and:
> 
> mmc0: new MMC card on SPI
> mmcblk0: mmc0:0001 SDM064 62720KiB
>  mmcblk0: p1 p2 p3 p4
> 
> So it appears the initial card detect does work. But for some reason
> it's not seeing the removal of the card or the insertion of a new card.
> 
> Any ideas?  

Without debugging info it's impossible to tell if it's the driver or the core that's doing something wrong. Have you checked that interrupts keep coming?

> 
> New issue. All of my testing so far has been with MMC cards. All of them
> have worked so far. I just tried a couple of SD cards and none of them
> work with the driver, they do work fine on my host system.
> 
> One of the cards actually produces a "Division by zero in kernel." error.
> It appears to happen in the mmc_set_data_timeout() function. I added a
> printk to the function and get the following when the card is inserted.
> 
> mmc_set_data_timeout  timeout_ns:0  timeout_clks:0  ios.clock:400000
> mmc_set_data_timeout  timeout_ns:-589934592  timeout_clks:0  ios.clock:400000
> mmc0: new SD card on SPI
> mmcblk0: mmc0:0000       29888KiB
>  mmcblk0:mmc_set_data_timeout  timeout_ns:-589934592  timeout_clks:0  ios.clock:0
> Division by zero in kernel.

Ouch.

> 
> For some reason the card->host->ios.clock value is getting changed to 0 on
> the third call to the function. I haven't been able to trace down where/why
> this would happen. Any idea on that one?
> 

Not the slightest. It should never be set to zero except when powering
down, which it only does when there is no card attached.

> I didn't think of checking dmesg before, here's the actual dump after I
> insert
> the SD card:

My guess would be transfer problems that causes the core to believe the
card cannot handle a higher speed. We should of course have a check
that we don't compute a too low speed, but that's not the root of the
problem.

Have you disabled the CRC checks?

I guess I'll have to warm up my old SPI test board and get it updated.
David, I don't suppose you've checked if you can reproduce this?

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: mmc_spi.c driver

[David Brownell]

On Thursday 24 April 2008, Pierre Ossman wrote:
> On Tue, 15 Apr 2008 15:26:54 -0400
> "hartleys" <hartleys-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org> wrote:
> 
> > I do get the IRQ on every card insertion and removal. Actually if I boot
> > the system with the card removed I end up getting a:
> > 
> > mmc0: error -22 whilst initialising SDIO card  
> 
> This is a bit odd. It shouldn't have gone down that route unless it is
> sure it's an SDIO card it is dealing with.

I've seen that in the past, I forget why.  It may have been the
problem with cards that didn't like to respond to certain requests
while they're resetting ... the problem which ensures that I must
always use the appended patch, since you didn't want to merge it.


> > If I then insert the card I get the IRQ and:
> > 
> > mmc0: new MMC card on SPI
> > mmcblk0: mmc0:0001 SDM064 62720KiB
> >  mmcblk0: p1 p2 p3 p4
> > 
> > So it appears the initial card detect does work. But for some reason
> > it's not seeing the removal of the card or the insertion of a new card.
> > 
> > Any ideas?  
> 
> Without debugging info it's impossible to tell if it's the driver or
> the core that's doing something wrong. Have you checked that
> interrupts keep coming?  

I have a patch I've been playing with that should help make the card
detect debounce work better.  I'll send it along in a bit.  Not sure
it's properly cooked yet.  I *do* still observe delays in detection
of the removal ... sometimes adding up to "not detected"; and when
those delays appear, similar delays in detecting newly inserted cards.
Removing then re-inserting seems to help at that point.


> David, I don't suppose you've checked if you can reproduce this?

I tried with a few cards; nope, no such problems observed.

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[David Brownell]

On Tuesday 29 April 2008, David Brownell wrote:
> 
> > > mmc0: error -22 whilst initialising SDIO card  
> > 
> > This is a bit odd. It shouldn't have gone down that route unless it is
> > sure it's an SDIO card it is dealing with.
> 
> I've seen that in the past, I forget why.  It may have been the
> problem with cards that didn't like to respond to certain requests
> while they're resetting ... the problem which ensures that I must
> always use the appended patch, since you didn't want to merge it.
> 

When enumerating MMC cards using SPI, don't support the "just probe"
mechanism since it doesn't always work.  Instead, always wait for the
reset to complete before issuing the next request.  (Failed on an
otherwise trusty SanDisk MMC card...)

Signed-off-by: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
---
 drivers/mmc/core/mmc_ops.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/mmc/core/mmc_ops.c	2007-11-05 18:17:50.000000000 -0800
+++ b/drivers/mmc/core/mmc_ops.c	2007-11-05 18:24:32.000000000 -0800
@@ -114,8 +114,11 @@ int mmc_send_op_cond(struct mmc_host *ho
 		if (err)
 			break;
 
-		/* if we're just probing, do a single pass */
-		if (ocr == 0)
+		/* if we're just probing, do a single pass ... except,
+		 * accomodate cards which don't behave right until a
+		 * SPI reset completes.
+		 */
+		if (ocr == 0 && !mmc_host_is_spi(host))
 			break;
 
 		/* otherwise wait until reset completes */


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[PATCH] Add card detect switch sensing during mmc_rescan

[hartleys]

The following patch adds optional card detect switch sensing.

This eliminates having to probe to determine what type of card is
installed in mmc_rescan() if we can determine that nothing is installed.

It eliminates the "mmc0: error -22 whilst initialising SDIO card" error
message that occurs when nothing is installed in the socket. It also
makes mmc_detect_change() in the mmc_spi.c driver work correctly.

This was tested on an EP93xx based platform with the mmc_spi.c driver.

Please let me know if there is anything wrong with this patch.

Thanks,
Hartley Sweeten


diff -burN linux-2.6.25/include/linux/mmc/host.h
/home/bigguiness/linux-crater_1-0-3/kernel/linux-2.6.25/include/linux/mm
c/host.h
--- linux-2.6.25/include/linux/mmc/host.h	2008-04-16
19:49:44.000000000 -0700
+++
/home/bigguiness/linux-crater_1-0-3/kernel/linux-2.6.25/include/linux/mm
c/host.h	2008-04-30 13:49:27.000000000 -0700
@@ -54,6 +54,7 @@
 	void	(*set_ios)(struct mmc_host *host, struct mmc_ios *ios);
 	int	(*get_ro)(struct mmc_host *host);
 	void	(*enable_sdio_irq)(struct mmc_host *host, int enable);
+	int	(*get_cd)(struct mmc_host *host);
 };
 
 struct mmc_card;
diff -burN linux-2.6.25/drivers/mmc/core/core.c
/home/bigguiness/linux-crater_1-0-3/kernel/linux-2.6.25/drivers/mmc/core
/core.c
--- linux-2.6.25/drivers/mmc/core/core.c	2008-04-16
19:49:44.000000000 -0700
+++
/home/bigguiness/linux-crater_1-0-3/kernel/linux-2.6.25/drivers/mmc/core
/core.c	2008-04-30 14:24:58.000000000 -0700
@@ -650,6 +650,17 @@
 		mmc_send_if_cond(host, host->ocr_avail);
 
 		/*
+		 * Check the card detect switch, if supported...
+		 */
+		if (host->ops->get_cd) {
+			if (!host->ops->get_cd(host)) {
+				mmc_release_host(host);
+				mmc_power_off(host);
+				return;
+			}
+		}
+
+		/*
 		 * First we search for SDIO...
 		 */
 		err = mmc_send_io_op_cond(host, 0, &ocr);
@@ -682,8 +693,19 @@
 		mmc_release_host(host);
 		mmc_power_off(host);
 	} else {
-		if (host->bus_ops->detect && !host->bus_dead)
+		if (host->ops->get_cd) {
+			if (!host->ops->get_cd(host)) {
+				if (host->bus_ops->remove &&
!host->bus_dead) {
+					host->bus_ops->remove(host);
+
+					mmc_claim_host(host);
+					mmc_detach_bus(host);
+					mmc_release_host(host);
+				}
+			}
+		} else if (host->bus_ops->detect && !host->bus_dead) {
 			host->bus_ops->detect(host);
+		}
 
 		mmc_bus_put(host);
 	}
diff -burN linux-2.6.25/drivers/mmc/host/mmc_spi.c
/home/bigguiness/linux-crater_1-0-3/kernel/linux-2.6.25/drivers/mmc/host
/mmc_spi.c
--- linux-2.6.25/drivers/mmc/host/mmc_spi.c	2008-04-16
19:49:44.000000000 -0700
+++
/home/bigguiness/linux-crater_1-0-3/kernel/linux-2.6.25/drivers/mmc/host
/mmc_spi.c	2008-04-30 14:25:41.000000000 -0700
@@ -1131,11 +1131,21 @@
 	return 0;
 }
 
+static int mmc_spi_get_cd(struct mmc_host *mmc)
+{
+	struct mmc_spi_host *host = mmc_priv(mmc);
+
+	if (host->pdata && host->pdata->get_cd)
+		return host->pdata->get_cd(mmc->parent);
+	/* board doesn't support card detection; assume present */
+	return 1;
+}
 
 static const struct mmc_host_ops mmc_spi_ops = {
 	.request	= mmc_spi_request,
 	.set_ios	= mmc_spi_set_ios,
 	.get_ro		= mmc_spi_get_ro,
+	.get_cd		= mmc_spi_get_cd,
 };
 
  

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[Pierre Ossman]

I haven't had any time to try to reproduce this myself yet, but I can
at least comment on your logs...

On Thu, 24 Apr 2008 18:53:02 -0400
"hartleys" <hartleys-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org> wrote:

> Hello Pierre,
> 
> I still have three issues with the mmc_spi.c driver:
> 
> 1) I still haven't tracked down why the ios.clock value is getting set to 0 then a transfer is attempted to the SD card.
> 2) I also haven't figured out why a SDIO card is found at power up when no card is installed.
> 3) When I insert or remove a card it is not detected (other than the first detect if I boot without a card installed).
> 

All of these things can be explained by a single bug, as explained
below...

> 
> Here's a snip of the output from boot without a card installed.
> 
> user.info kernel: ep93xx spi device registered in bit-bang mode
> user.info kernel: at25 spi0.0: 512 KByte 25LF040A eeprom, pagesize 4096
> ...
> user.err kernel: mmc_spi spi0.1: can't share SPI bus
> user.warn kernel: mmc_spi spi0.1: ASSUMING SPI bus stays unshared!
> user.info kernel: mmc_spi spi0.1: card detect on IRQ 79
> user.debug kernel: mmc0: clock 0Hz busmode 0 powermode 0 cs 0 Vdd 0 width 0 timing 0
> user.debug kernel: mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width 0 timing 0
> user.debug kernel: mmc_spi spi0.1: mmc_spi: power up (21)
> user.debug kernel: mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
> user.debug kernel: mmc_spi spi0.1: mmc_spi: power on (21)
> user.info kernel: mmc_spi spi0.1: SD/MMC host mmc0, no DMA, no poweroff
> ...
> user.debug kernel: mmc_spi spi0.1: mmc_spi:  clock to 400000 Hz, 0
> user.debug kernel: mmc0: starting CMD0 arg 00000000 flags 000000c0
> user.debug kernel: mmc_spi spi0.1:   mmc_spi: CMD0, resp R1
> user.debug kernel: mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000
> user.debug kernel: mmc0: starting CMD8 arg 000001aa flags 000002f5
> user.debug kernel: mmc_spi spi0.1:   mmc_spi: CMD8, resp R3/R4/R7
> user.debug kernel: mmc0: req done (CMD8): 0: 00000000 00000000 00000000 00000000
> user.debug kernel: mmc0: starting CMD5 arg 00000000 flags 000002e1
> user.debug kernel: mmc_spi spi0.1:   mmc_spi: CMD5, resp R3/R4/R7
> user.debug kernel: mmc0: req done (CMD5): 0: 00000000 00000000 00000000 00000000
> user.debug kernel: mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0
> user.debug kernel: mmc_spi spi0.1: mmc_spi: power off (0)
> user.err kernel: mmc0: error -22 whilst initialising SDIO card
> user.debug kernel: mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0
> ...
> 

The problem here is that your controller is giving us false data. So
the MMC core believes it is getting a valid response, hence it thinks
that a card is there and that it's a SDIO card (since that's the first
type probed).

Have you checked that you have proper pull-ups on the lines? And have
you disabled CRC checking in the mmc_spi host? I don't know all the
commands by heart, but some of these should be protected by a CRC.

> 
> Here's the debug info after inserting the card.
> 

*snip*

> user.debug kernel: mmc0: starting CMD51 arg 00000000 flags 000000b5
> user.debug kernel: mmc0:     blksz 8 blocks 1 flags 00000200 tsac 100 ms nsac 0
> user.debug kernel: mmc_spi spi0.1:   mmc_spi: CMD51, resp R1
> user.debug kernel: mmc_spi spi0.1:     mmc_spi: read block, 8 bytes
> user.debug kernel: mmc0: req done (CMD51): 0: 00000000 00000000 00000000 00000000
> user.debug kernel: mmc0:     8 bytes transferred: 0
> user.debug kernel: mmc0: clock 0Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
> !!!

Basically the same problem, but with a card present. The command
returns garbage data, which tricks the MMC core into believing that the
maximum frequency supported by the card is 0 Hz.

> 
> If I then remove the card I get:
> 
> user.warn kernel: mmc_spi_detect_irq
> user.debug kernel: mmc0: starting CMD13 arg 00000000 flags 00000195
> user.debug kernel: mmc_spi spi0.1:   mmc_spi: CMD13, resp R2/R5
> user.debug kernel: mmc0: req done (CMD13): 0: 00000000 00000000 00000000 00000000
> 
> Re-inserting it gives:
> 
> user.warn kernel: mmc_spi_detect_irq
> user.debug kernel: mmc0: starting CMD13 arg 00000000 flags 00000195
> user.debug kernel: mmc_spi spi0.1:   mmc_spi: CMD13, resp R2/R5
> user.debug kernel: mmc0: req done (CMD13): 0: 00000000 00000000 00000000 00000000
> 
> Repeating the remove/insert generates the same debug messages.
> 

Same problem a third time. Because the core gets a reply, although
bogus, it believes the card is still there.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: mmc_spi.c driver

[Pierre Ossman]

On Thu, 8 May 2008 19:56:10 -0400
"hartleys" <hartleys-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org> wrote:

> On Wednesday, May 07, 2008 11:38 AM, Pierre Ossman wrote:
> >
> > Have you checked that you have proper pull-ups on the lines? And have
> > you disabled CRC checking in the mmc_spi host? I don't know all the
> > commands by heart, but some of these should be protected by a CRC.
> 
> Figured that was the problem. If I understand the driver layering
> correctly, my setup has this configuration:
> 
> MMC core <-> mmc_spi.c host driver <-> SPI core <-> ep93xx spi bus
> driver <-> card socket <-> the actual mmc/sd-card
> 

That's correct, yes.

> Unfortunately, with no card inserted in the socket when the card is
> probed by the SPI bus driver it will return zero's for all data. I have
> tried installing pull-ups on the MOSI/MISO (txd/rxd) signals of the SPI
> bus but I still always get zero's. I'm not sure if this a an artifact
> (i.e. "bug") of the ep93xx SPI port or if this is what would happen on
> another platform.

I'd recommend double checking your wiring. That's the culprit in 9 out
of 10 cases.

For reference, here's how it is supposed to look:

mmc0: clock 0Hz busmode 0 powermode 0 cs 0 Vdd 0 width 0 timing 0
mmc_spi spi1.0: SD/MMC host mmc0, no WP, no poweroff
mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi1.0: mmc_spi: power up (21)
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc_spi spi1.0: mmc_spi: power on (21)
mmc_spi spi1.0: mmc_spi:  clock to 400000 Hz, 0
mmc0: starting CMD0 arg 00000000 flags 000000c0
mmc_spi spi1.0:   mmc_spi: CMD0, resp R1
mmc0: req done (CMD0): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD8 arg 000001aa flags 000002f5
mmc_spi spi1.0:   mmc_spi: CMD8, resp R3/R4/R7
mmc0: req done (CMD8): -110: 00000000 00000000 00000000 00000000

The -110 is the result of mmc_spi seeing all ones in the data. This was
tested with a 2.6.26-rc1 kernel on a Atmel NGW100 board.

> 
> As far as disabling the CRC checking. I know that sending CMD59 to the
> card will turn on/off the CRC checking but I'm not sure where/how you
> enable that feature. Anyway, I don't think this will help for the
> situation where a card is not inserted to receive the command.
> 

If you haven't touched anything then it should be on.

> > Basically the same problem, but with a card present. The command
> > returns garbage data, which tricks the MMC core into believing that
> > the maximum frequency supported by the card is 0 Hz.
> 
> What exactly is the garbage data? As far as I know CMD51 is an optional
> command and is reserved when a mmc/sd-card is used in SPI mode. In that
> situation the data returned would be garbage anyway. Correct?
> 

Not quite, the command is actually ACMD51, not CMD51. The controller
doesn't know this though.

As for the contents, no idea. It it not printed out to dmesg. But it
seems you have a general case of shoddy communication between the card
and the controller.

> 
> I submitted a patch (last week?) that added hardware card detect switch
> sensing to the MMC core and the mmc_spi.c driver. That did fix my
> problems for issues 2 and 3. Has anyone had a chance to look at it?
> 

Just briefly and it is not really acceptable as a solution here. Adding
support for controllers that know if a card is present or not is merely
an optimisation. The core should work just fine without this
information, so your patch would only hide the problem.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

mmc_spi.c driver

[hartleys]

Hello Pierre and David,

With the help you supplied to me back in Apr/May I was able to get my
spi driver for the ep93xx cleaned up enough to get the mmc_spi driver to
work correctly. Thanks for the help.

Now I have run into another problem. But I don't know if it's a mdev
issue or something in the mmc core.

When I first boot my system, with the mmc card installed, the card is
detected and the device nodes are created correctly. At that point I can
mount the card and everything works great.

>From boot messages:
...
mmc0: new SD card on SPI
mmcblk0: mmc0:0000 SR016 14400KiB
 mmcblk0: p1
...

# ls /dev/mmc* -la
brw-rw----    1 root     disk     179,   0 Oct 30 09:10 /dev/mmcblk0
brw-rw----    1 root     disk     179,   1 Oct 30 09:10 /dev/mmcblk0p1

Then, if I eject the card I get:

mmc0: SPI card removed

# ls /dev/mmc* -la

And then re-insert it:

mmc0: new SD card on SPI
mmcblk1: mmc0:0000 SR016 14400KiB
mmcblk1: p1

# ls /dev/mmc* -la
crw-rw----    1 root     disk     179,   8 Oct 30 09:30 /dev/mmcblk1
crw-rw----    1 root     disk     179,   9 Oct 30 09:30 /dev/mmcblk1p1

Why does the re-inserted card show up as mmcblk1* instead of mmcblk0*?
Also, why would it change from a block device to a char device and the
minor number has changed?

Thanks for any help you can provide.
Hartley

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[Pierre Ossman]

On Thu, 30 Oct 2008 18:46:54 -0400
"hartleys" <hartleys-3FF4nKcrg1dE2c76skzGb0EOCMrvLtNR@public.gmane.org> wrote:

> 
> Why does the re-inserted card show up as mmcblk1* instead of mmcblk0*?
> Also, why would it change from a block device to a char device and the
> minor number has changed?
> 

I'd guess you forgot to unmount the card. The device name "mmcblk0"
will still be around in that case and it will take the next one in line.

No idea why it pops up as a character device. Must be some mdev bug.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org

  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.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[hartleys]

On Friday, October 31, 2008 12:03 AM, Pierre Ossman wrote:
>> 
>> Why does the re-inserted card show up as mmcblk1* instead of
mmcblk0*?
>> Also, why would it change from a block device to a char device and
the 
>> minor number has changed?
>> 
>
> I'd guess you forgot to unmount the card. The device name "mmcblk0"
> will still be around in that case and it will take the next one in
line.
>
> No idea why it pops up as a character device. Must be some mdev bug.

You were correct on the first part. I just retested without mounting the
card and it does come back as "mmcblk0" and "mmcblk0p1".

But it also comes back as a character device not a block device even
though the minor/major numbers are the same. Why would mdev initially
create the node as a block device then change it? As far as I can tell
/etc/mdev.conf just defines the ownership and permissions for the nodes.

Thanks,
Hartley

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[David Brownell]

On Friday 31 October 2008, hartleys wrote:
> But it also comes back as a character device not a block device even
> though the minor/major numbers are the same. Why would mdev initially
> create the node as a block device then change it?

Because of the mdev bug I mentioned to you yesterday.  Since you
didn't enable the sysfs legacy support, a string compare result
makes mdev not realize it's a block device.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[hartleys]

On Friday, October 31, 2008 11:32 AM, David Brownell wrote:
>> But it also comes back as a character device not a block device even 
>> though the minor/major numbers are the same. Why would mdev initially

>> create the node as a block device then change it?
>
> Because of the mdev bug I mentioned to you yesterday.  Since you
> didn't enable the sysfs legacy support, a string compare result
> makes mdev not realize it's a block device.

Sorry. Saw Pierre's response but hadn't got to yours yet.

Where is the sysfs legacy support enabled? In the kernel config or
buildroot's config.

I think I remember seeing that somewhere but can't locate it.

Thanks,
Hartley

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[David Brownell]

On Friday 31 October 2008, hartleys wrote:
> Where is the sysfs legacy support enabled? In the kernel config

exactly.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[hartleys]

Friday, October 31, 2008 11:48 AM, David Brownell wrote:
>> Where is the sysfs legacy support enabled? In the kernel config
>
> exactly.

Sorry if I'm being a pain. Is it CONFIG_SYSFS_DEPRECATED_V2?

Thanks,
Hartley

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[David Brownell]

On Friday 31 October 2008, hartleys wrote:
> Friday, October 31, 2008 11:48 AM, David Brownell wrote:
> >> Where is the sysfs legacy support enabled? In the kernel config
> >
> > exactly.
> 
> Sorry if I'm being a pain. Is it CONFIG_SYSFS_DEPRECATED_V2?

yes.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[hartleys]

On Friday, October 31, 2008 12:23 PM, David Brownell wrote:
>>>> Where is the sysfs legacy support enabled? In the kernel config
>>>
>>> exactly.
>>
>> Sorry if I'm being a pain. Is it CONFIG_SYSFS_DEPRECATED_V2?
>
> yes.

That fixed it. Don't think I would have figured that one out.

Thanks,
Hartley

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: mmc_spi.c driver

[David Brownell]

On Thursday 30 October 2008, hartleys wrote:
> Also, why would it change from a block device to a char device and the
> minor number has changed?

It's an mdev bug I've seen before.  I think the workaround
was to enable the legacy sysfs links so that a strcmp() would
behave better.

- Dave

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/