- 23 Sep, 2007 40 commits
-
-
David Vrabel authored
Add sdio_f0_readb() and sdio_f0_writeb() functions to reading and writing function 0 registers. Writes outside the vendor specific CCCR registers (0xF0 - 0xFF) are not permitted. Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Replace all cases of BUG_ON with WARN_ON where there is a chance (with varying degrees of slim) that the kernel can continue without incidence. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Mariusz Kozlowski authored
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
David Vrabel authored
Extend sdio_readsb(), sdio_writesb(), sdio_memcpy_fromio(), and sdio_memcpy_toio() to handle any length of buffer by splitting the transfer into several IO_RW_EXTENDED commands. Typically, a transfer would be split into a single block mode transfer followed by a byte mode transfer for the remainder but we also handle lack of block mode support and the block size being greater than 512 (the maximum byte mode transfer size). host->max_seg_size <= host->max_req_size so there's no need to check both when determining the maximum data size for a single command. Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
David Vrabel authored
Before a driver is probed, set the function's block size to the default so the driver is sure the block size is something sensible and it needn't explicitly set it. The default block size is the largest that's supported by both the card and the host, with a maximum of 512 to ensure aribitrarily sized transfer use the optimal (least) number of commands. See http://lkml.org/lkml/2007/8/7/150 for reasons for the block size choice. Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
David Vrabel authored
Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
SDIO doesn't have a CSD so it uses different timeout values than SD memory. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Enable 4-bit data bus mode, according to host and card capabilities. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Change clock speed to the highest supported by the card. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Adrian Bunk authored
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote: >... > Changes since 2.6.22-rc6-mm1: >... > git-mmc.patch >... > git trees >... sdio_dev_attrs[] can become static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Support the multi-byte transfer operation, including handlers for common operations like writel()/readl(). Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
This mimics what the serial_core does. Useful for diagnostics. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
This currently only accepts the GPS class since that's all I have for testing. Tested with a Matsushita GPS and gpsd version 2.34. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
It is sometimes necessary to give up on trying to claim the host lock, especially if that happens in a thread that has to be stopped. While at it, fix the description for mmc_claim_host() which was wrong. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Make the mmc bus uevent callback look like all other subsystems. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
The problem is that the sdio_bus must be registered before any SDIO drivers are registered against it otherwise the kernel sulks. Because the sdio_bus registration happens through module_init (equivalent to device_initcall), then any SDIO drivers linked before the SDIO core code in the kernel will be initialized first. Upcoming SDIO function drivers are likely to be located outside the drivers/mmc directory as it is common practice to group drivers according to their function rather than the bus they use. SDIO drivers are therefore likely to appear at random location in the kernel link. To make sure the sdio_bus is always initialized before any SDIO drivers, let's move the MMC init to the subsys_initcall level. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add a more clean separation between global, common CIS information and the function specific one as we need the common information in places where no specific function is specified. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
This way those tuples that the core cares about are consumed by the core code, and tuples that only function drivers might make sense of are available to drivers. Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Nicolas Pitre authored
Signed-off-by: Nicolas Pitre <npitre@mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Like many other buses, the devices (functions) on the SDIO bus must be enabled before they can be used. Add functions that allow drivers to do so. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add command wrappers that simplify register access from SDIO function drivers. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add basic driver handling to the SDIO device model. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Add the sdio bus type and basic device handling. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Really basic init sequence for SDIO cards. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Marc Pignat authored
This kind of transfer is not supported, so don't advertise it and make it fail early. Signed-off-by: Marc Pignat <marc.pignat@hevs.ch> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Some printk:s were missing an explicit level. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
The MMC_DATA_MULTI flag never had a proper definition of what it means, so remove it and let the drivers check the block count in the request. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Remove the BYTEBLOCK capability and let the broken hosts fail the requests with -EINVAL instead. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
The write parameter in mmc_set_data_timeout() is redundant as the data structure contains information about the direction of the transfer. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-
Pierre Ossman authored
Make sure we do not try to parse a structure we do not understand. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
-