5 patches: updates to SPI and mmc_spi, kernel 2.6.19

5 patches: updates to SPI and mmc_spi, kernel 2.6.19

[Hans-Peter Nilsson]

(Please CC me on replies, I'm not subscribed to LKML.  Thanks.)

Five SPI-related patches follow.

1: bugfix for spi_bitbang: always call the setup_transfer
function via the overridable pointer.

2: Allow clocking SPI with chip-select inactive.

3: Define the bit-value transmitted for SPI transfers with no tx_buf.

4: Update of David B.'s (et al) kind-of-proof-of-concept
MMC <-> SPI glue driver mmc_spi posted on Aug 1, found at e.g.
<URL:http://www.gossamer-threads.com/lists/linux/kernel/671939#671939>.

5: SPI cleanup should not have const on its argument.

All patches are based on 2.6.19 (sorry, not based on the new MMC
framework).

brgds, H-P

Re: 5 patches: updates to SPI and mmc_spi, kernel 2.6.19

[David Brownell]

On Wednesday 24 January 2007 8:47 pm, Hans-Peter Nilsson wrote:
> (Please CC me on replies, I'm not subscribed to LKML.  Thanks.)
> 
> Five SPI-related patches follow.
> 
> 1: bugfix for spi_bitbang: always call the setup_transfer
> function via the overridable pointer.
> 
> 2: Allow clocking SPI with chip-select inactive.
> 
> 3: Define the bit-value transmitted for SPI transfers with no tx_buf.
> 
> 4: Update of David B.'s (et al) kind-of-proof-of-concept
> MMC <-> SPI glue driver mmc_spi posted on Aug 1, found at e.g.
> <URL:http://www.gossamer-threads.com/lists/linux/kernel/671939#671939>.
> 
> 5: SPI cleanup should not have const on its argument.

Cool ... two of those (#1, #5) seem ok to merge right now, and
I expect that #2 can go in with only minor tweaks.

#3 needs more attention (see my response) and I'll have to look
at #4 soon.

Thanks for looking at this.  I know various folk have needed to
have MMC/SD working over SPI for some time, and was hoping that
someone else would make time to take that code the next few steps
on the way.  Just like you did!

So to summarize ... you now have MMC-over-SPI working on CRIS
hardware, with these patches?   Can you yet run filesystem
stress tests with ext3 on such an MMC card, or is this more at
the level of everything working with light/early test loads,
so it's time to see if other folk can reproduce your results?

- Dve

Re: 5 patches: updates to SPI and mmc_spi, kernel 2.6.19

[Hans-Peter Nilsson]

> From: David Brownell <david-b@pacbell.net>
> Date: Thu, 25 Jan 2007 04:59:37 -0800

> So to summarize ... you now have MMC-over-SPI working on CRIS
> hardware, with these patches?

Yes.  FWIW, we'll ship with our ETRAX FS developer boards, soon
enough (in a week or so, knock-on-wood).

>   Can you yet run filesystem
> stress tests with ext3 on such an MMC card,

I'd have to configure it in, but I guess I could, if you're not
happy with just vfat.  I just copied (tarred both to file, and
separately copied the tree through tar) 174 MeB from a USB stick
to separately a 512 MeB SDcard and a 2 GiB MMC card and they
both read out correctly from an (USB) SDcard reader connected to
my PC.  Is there a specific test you have in mind?

(I finally hashed out the "DMA" problems I've had.  I mistakenly
thought that a wait_for_completion_timeout return of 0 meant
that the completion didn't happen, grr!  Buggy or just confusing
API?  Kind-of the same problem as with your scanbyte timeout!
Looks like this kind of bug is elsewhere in the kernel too.)

> or is this more at
> the level of everything working with light/early test loads,
> so it's time to see if other folk can reproduce your results?

What's the difference? :-)  (Don't forget, it's considered ok to
include experimental drivers on developer boards.)

brgds, H-P

Re: 5 patches: updates to SPI and mmc_spi, kernel 2.6.19

[David Brownell]

On Friday 26 January 2007 6:31 am, Hans-Peter Nilsson wrote:
> > From: David Brownell <david-b@pacbell.net>
> > Date: Thu, 25 Jan 2007 04:59:37 -0800
> 
> > So to summarize ... you now have MMC-over-SPI working on CRIS
> > hardware, with these patches?
> 
> Yes.  FWIW, we'll ship with our ETRAX FS developer boards, soon
> enough (in a week or so, knock-on-wood).

Cool!  It's getting more real then.


> >   Can you yet run filesystem
> > stress tests with ext3 on such an MMC card,
> 
> I'd have to configure it in, but I guess I could, if you're not
> happy with just vfat.  I just copied (tarred both to file, and
> separately copied the tree through tar) 174 MeB from a USB stick
> to separately a 512 MeB SDcard and a 2 GiB MMC card and they
> both read out correctly from an (USB) SDcard reader connected to
> my PC.  Is there a specific test you have in mind?

No, I just wanted to get a feel for how solid you thought this was.

- Dave