aboutsummaryrefslogtreecommitdiff
path: root/include/linux/mmc/mmc.h
AgeCommit message (Collapse)Author
2007-09-23MMC headers learn about SPIDavid Brownell
Teach the MMC/SD/SDIO system headers that some hosts use SPI mode - New host capabilities and status bits * MMC_CAP_SPI, with mmc_host_is_spi() test * mmc_host.use_spi_crc flag - SPI-specific declarations: * Response types, MMC_RSP_SPI_R* * Two SPI-only commands * Status bits used native to SPI: R1_SPI_*, R2_SPI_* - Fix a few (unrelated) whitespace bugs in the headers. - Reorder a few mmc_host fields, removing several bytes of padding None of these changes affect current code. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23mmc: read ext_csd version numberPierre Ossman
Make sure we do not try to parse a structure we do not understand. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-05-01mmc: Separate out protocol opsPierre Ossman
Move protocol operations and definitions into their own files in an effort to separate protocol handling and bus arbitration more clearly. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-05-01mmc: Move core functions to subdirPierre Ossman
Create a "core" subdirectory to house the central bus handling functions. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-05-01mmc: deprecate mmc bus topologyPierre Ossman
The classic MMC bus was defined as multi card bus system, which is reflected in the design in the MMC layer. When SD showed up, the bus topology was abandoned and a star topology (one card per host) was mandated. MMC version 4 has followed this, officially deprecating the bus topology. As we do not have any known users of the bus topology we can remove support for it. This will simplify the code and rectify some incorrect assumptions in the newer additions. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-02-04mmc: Add support for SDHC cardsPhilip Langdale
Thanks to the generous donation of an SDHC card by John Gilmore, and the surprisingly enlightened decision by the SD Card Association to publish useful specs, I've been able to bash out support for SDHC. The changes are not too profound: i) Add a card flag indicating the card uses block level addressing and check it in the block driver. As we never took advantage of byte-level addressing, this simply involves skipping the block -> byte translation when sending commands. ii) The layout of the CSD is changed - a set of fields are discarded to make space for a larger C_SIZE. We did not reference any of the discarded fields except those related to the C_SIZE. iii) Read and write timeouts are fixed values and not calculated from CSD values. iv) Before invoking SEND_APP_OP_COND, we must invoke the new SEND_IF_COND to inform the card we support SDHC. Signed-off-by: Philipl Langdale <philipl@overt.org> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-01-15mmc: Correct definition of R6Philip Langdale
During development of SDHC support, it was discovered that the definition for R6 was incorrect. This patch fixes that and patches the drivers that do switch on the response type. Signed-off-by: Philip Langdale <philipl@overt.org> Cc: Alex Dubov <oakad@yahoo.com> Cc: Pavel Pisa <ppisa@pikron.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2006-09-16[MMC] Remove data->blksz_bits memberRussell King
data->blksz_bits is unused now - remove it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-07[MMC] Cleanup 385e3227d4d83ab13d7767c4bb3593b0256bf246Russell King
Rather than having two places which independently calculate the timeout for data transfers, make it a library function instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Pierre Ossman <drzeus@drzeus.cx>
2006-05-19[ARM] 3531/1: i.MX/MX1 SD/MMC ensure, that clock are stopped before new ↵Pavel Pisa
command and cleanups Patch from Pavel Pisa There has been problems that for some paths that clock are not stopped during new command programming and initiation. Result is issuing of incorrect command to the card. Some other problems are cleaned too. Noisy report of known ERRATUM #4 has been suppressed. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-22[MMC] Fix mmc_cmd_type() maskRussell King
It's MMC_CMD_MASK not MMC_CMD_TYPE. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-02[MMC] Add MMC command type flagsRussell King
Some hosts need to know the command type, so pass it via a set of flags in cmd->flags. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-09[MMC] Indicate that R1/R1b contains command opcodePierre Ossman
Some controllers actually check the first byte of the response (most don't). This byte contains the command opcode for R1/R1b and all 1:s for other types. The difference must be indicated to the controller so it knows which reply to expect. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2006-01-09[MMC] Add DATA_MULTI flagRussell King
Some hosts need to know that a transfer will be multi-block. Add a data flag to indicate multiple data block transfers. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-10-28[ARM] 3031/1: fix typos in comments of mmc.hErik Hovland
Patch from Erik Hovland I noticed that the same typo (i before c in associated) showed up twice in the file kernel/include/linux/mmc/mmc.h. This patch fixes both of the instances I found with this mistake. The typos are in comments and should have no affect on working code. E Signed-off-by: Erik Hovland <erik@hovland.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-07[PATCH] sd: initialize SD cardsPierre Ossman
Support for the Secure Digital protocol in the MMC layer. A summary of the legal issues surrounding SD cards, as understood by yours truly: Members of the Secure Digital Association, hereafter SDA, are required to sign a NDA[1] before given access to any specifications. It has been speculated that including an SD implementation would forbid these members to redistribute Linux. This is the basic problem with SD support so it is unclear if it even is a problem since it has no effect on those of us that aren't members. The SDA doesn't seem to enforce these rules though since the patches included here are based on documentation made public by some of the members. The most complete specs[2] are actually released by Sandisk, one of the founding companies of the SDA. Because of this the NDA is considered a non-issue by most involved in the discussions concerning these patches. It might be that the SDA is only interested in protecting the so called "secure" bits of SD, which so far hasn't been found in any public spec. (The card is split into two sections, one "normal" and one "secure" which has an access scheme similar to TPM:s). (As a side note, Microsoft is working to make things easier for us since they want to be able to include the source code for a SD driver in one of their development kits. HP is making sure that the new NDA will allow a Linux implementation. So far only the SDIO specs have been opened up[3]. More will hopefully follow.) [1] http://www.sdcard.org/membership/images/ippolicy.pdf [2] http://www.sandisk.com/pdf/oem/ProdManualSDCardv1.9.pdf [3] http://www.sdcard.org/sdio/Simplified%20SDIO%20Card%20Specification.pdf This patch contains the central parts of the SD support. If no MMC cards are found on a bus then the MMC layer proceeds looking for SD cards. Helper functions are extended to handle the special needs of SD cards. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!