Currently we print a message about some bad states wrt function IRQ
handlers but return 0 from process_sdio_pending_irqs() nevertheless.
This can lead to an infinite loop as nothing might have cleared the
condition for the pending card interrupt from the host controller by
the time host->ops->enable_sdio_irq(host, 1) is called.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
If func is actually null we won't get much from sdio_func_id(func).
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The interrupt polling frequency is a compromise between power usage and
interrupt latency. Unfortunately, it affects throughput rather severely
for devices which require an interrupt for every chunk of data.
By making the polling frequency adaptive, we get better throughput with
those devices without sacficing too much power. Polling will quickly
increase when there is an actual interrupt, and slowly fall back to the
idle frequency when the interrupts stop coming.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Add a led trigger for each host controller that indicates if there
is a request active on the controller.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Teach the MMC/SD/SDIO core about using SPI mode.
- Use mmc_host_is_spi() so enumeration works through SPI signaling
and protocols, not just the native versions.
- Provide the SPI response type flags with each request issued,
including requests from the new lock/unlock code.
- Understand that cmd->resp[0] and mmc_get_status() results for SPI
return different values than for "native" MMC/SD protocol; this
affects resetting, checking card lock status, and some others.
- Understand that some commands act a bit differently ... notably:
* OP_COND command doesn't return the OCR
* APP_CMD status doesn't have an R1_APP_CMD analogue
Those changes required some new and updated primitives:
- Provide utilities to access two SPI-only requests, and one
request that wasn't previously needed:
* mmc_spi_read_ocr() ... SPI only
* mmc_spi_set_crc() ... SPI only (override by module parm)
* mmc_send_cid() ... for use without broadcast mode
- Updated internal routines:
* Previous mmc_send_csd() modified into mmc_send_cxd_native();
it uses native "R2" responses, which include 16 bytes of data.
* Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
helper for command-and-data access
* Bugfix to that mmc_send_cxd_data() code: dma-to-stack is
unsafe/nonportable, so kmalloc a bounce buffer instead.
- Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper
- Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
those helper routines based on whether they're native or SPI
The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI: MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Increase delay for power up in order to support some slower boards.
Also add some comments about why the delays are there.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
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>
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>
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>
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>
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>
Support the multi-byte transfer operation, including handlers for
common operations like writel()/readl().
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
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>
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>
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>
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>
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>
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>
This patch makes the following needlessly global functions static:
- sd_ops.c: mmc_app_cmd()
- core.c: __mmc_release_bus()
- core.c: mmc_start_request()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Make sure that the debugging output in the core is complete.
This should allow us to clean up all the extra debug output
that each and every other host driver seems to contain.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Let the user know that the kernel actually detected the card
by printing some basic information in dmesg.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
When the card has been added to the device model, it might be bound
to a card driver. Therefore, we have to release the host lock when
trying to remove it as we otherwise might deadlock with the driver.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
