GP2X Sdio Soon In Mainline Of Linux-arm

[kardasan]

I've found something that might interest You. There was a post on linux-arm-kernel@lists.arm.linux.org.uk mailing list made by Nicolas Pitre that gives me a lot of hope about SDIO support:

QUOTE
I am happy to announce that SDIO support will soon be a standard
feature in Linux. No more proprietary stacks with all the troubles
(legal and technical) that go with them.

The new code is written from scratch by yours truly and Nicolas Pitre.
There were several stacks out there that were recently made available
under the GPL, but none of them were in any shape to be merged into the
kernel.

Current status is that basic functionality is in place. There is a
driver model (with device matching and module auto-loading) and
functions for easy register access. It is also possible to receive
interrupts from the card.

There is only one driver in the tree right now (for the standard GPS
interface), but it should be complete enough for everyone to see how
the API works.

The pieces still missing are mostly performance related:
- No clock speed change.
- No wide bus support
- Interrupts are polled
- No support for combo (mem+IO) cards

The last point is unlikely to change as neither Nicolas nor I currently
possess such a card. As usual, patches/hardware is welcome.

So what we'd like to see now is extensive testing. Try the stack out on
every MMC controller you can find and review as much of the code as
possible. With some luck, we'll be able to get this ready in time for
the next merge window.

You can find the code in -mm and as just the SDIO stuff on top of
Linus' tree:

git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#sdio

(PS. I've posted this both to LKML and LAKML. Interested readers should
probably check both lists for replies)

Rgds
--
-- Pierre Ossman

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


He says in later posts that they're following SDIO version 2.0 specifications and theoretically there is a code for multifunction card support but they haven't got any multifunction card to test it.

 

[Squidge]

and of course this is just like adding usb support to the kernel: The physical layer was already there, they've added the transport layer, and now we need drivers to provide the other layers for whatever cards we want to use.

Therefore, it would be a bad idea at the moment for everyone to go out and buy SD-Wifi cards/etc.

 

[pcklee123]

I suppose this is for a 2.6 kernel?

 

[DJWillis]

I suppose this is for a 2.6 kernel?

Of course . 2.4 ARM went end of life years ago as far as the ARM maintainers see it. Add to that the fact the core 2.4 maintainers would not take a feature like this in mainline anyway I would guess.

Backporting some of it may be a possibility (we discussed using other open SDIO stacks at length with Open2x) but in all honesty I am personally not sure of the benefits as you would have to have a combined mem/SDIO card (Open2x does not leave any user NAND and we don’t currently include any sort of browser). You would also have to backport almost every driver that may be used by SDIO cards, all in all a painful and fruitless job.

That said, this really could be a shot in the arm for the flagging SDIO market as a number of devices would just need hardware driver wrappers to add SDIO support to 2.6 Linux products (Zaurii spring to mind) that lacked it before. I’ll keep watching it with interest and see where this goes. Something to consider with the 2.6 GP2X work maybe?

 

[el_pango]

I have (what may be) a (very newbish) question: what prevents us from reimplementing their sdio stack as a kernel module, and programs that need, say, networking can load it the way they currently load mmuhack.o without the consumer having to worry about what kernel they've got?

As for having myriad drivers for various sdio wifi/storage combo cards (which is really what 99% of us want sdio for ), if it's anything like other small devices, I'd imagine that the great majority of them have parts from maybe three or four manufacturers, (pure speculation on my part, of course) which would mean reduced chance of driver stupidity. And then, there would be some glue between this and the normal socket interface (and maybe expose new ioctls for people who need to do something unusual, if that can be done from a module).

Again, I am an utterly talentless newbie who is still reading and learning, so I don't know whether what I am thinking of is impossible or not. Comments?