Results 1 to 1 of 1
Hi all! I have an embedded device incorporating Marvell PXA303 processor. It has two MMC/SD slots and SDIO WiFi card, all of them are connected via full 4bit bus (not ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-09-2012 #1
- Join Date
- Mar 2012
Multi cards-per-host mmc driver
I have an embedded device incorporating Marvell PXA303 processor.
It has two MMC/SD slots and SDIO WiFi card, all of them are connected via full 4bit bus (not SPI!) to PXA's MMC controllers.
PXA303 has two independent controllers, but there are three MMC devices..
Digging into device discovered that WiFi card occupies the second controller, while BOTH mmc/sd cards occupy the first controller.
All corresponding signals of cards are connected in parallel, except for CMD lines: CMD of the first card sits on GPIO 8, while CMD of the second is connected to GPIO 15.
Also, CMD of the first MMC controller can be "routed"(through MFP regs) either to GPIO8 or to GPIO15.
So, when we want to "speak" to card0, we configure GPIO8 as CMD line, GPIO15 as GPIO pulled 'high' (to virtually disconnect second card), and work with MMC controller as usual.
When we want to "speak" to card1, we configure GPIO8 as pulled 'high' GPIO, and GPIO15 as CMD line.
The whole concept of such switching is rather unusual, and there are no appropriate drivers in kernel.
There are only "pxamci" host driver, which can access only one card.
So, i decided to write my own driver to work correctly with that hardware.
The question is: is it correct to develop just a "host" driver, which registers _two_ mmc hosts to the mmc subsystem (in fact, both of these hosts would be tied to single hardware controller)?
How to implement proper locking in that case (would the simple mutex in process_request callback be enough?)
Or, maybe, you have other ideas, how to implement such a thing?
Ah, original device firmware is based on "Marvell Linux Preview Kit", which incorporates an old, not mainline, pxa-specific "mss" framework.
Of course, it works, but porting it to 3.* branch would be a terrible thing..
Can anyone recommend some good literature about kernel mmc subsystem? I would be grateful
And sorry for my bad english..