- Aug 21, 2017
-
-
Shawn Lin authored
We to some extent should tolerate R1_OUT_OF_RANGE for open-ending mode as it is expected behaviour and most of the backup partition tables should be located near some of the last blocks which will always make open-ending read exceed the capacity of cards. Fixes: 9820a5b1 ("mmc: core: for data errors, take response of stop cmd into account") Fixes: a04e6bae ("mmc: core: check also R1 response for stop commands") Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
- Aug 09, 2017
-
-
Michał Mirosław authored
Fix lockdep splat introduced in v4.13-rc4. [ 266.297226] ------------[ cut here ]------------ [ 266.300078] WARNING: CPU: 2 PID: 176 at /mnt/src/jaja/git/tf300t/include/linux/blkdev.h:657 mmc_blk_remove_req+0xd0/0xe8 [mmc_block] [ 266.302937] Modules linked in: mmc_block(-) sdhci_tegra sdhci_pltfm sdhci pwrseq_simple pwrseq_emmc mmc_core [ 266.305941] CPU: 2 PID: 176 Comm: rmmod Tainted: G W 4.13.0-rc4mq-00208-gb691e67724b8-dirty #694 [ 266.308852] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) [ 266.311719] [<b011144c>] (unwind_backtrace) from [<b010ca54>] (show_stack+0x18/0x1c) [ 266.314664] [<b010ca54>] (show_stack) from [<b062e3f4>] (dump_stack+0x84/0x98) [ 266.317644] [<b062e3f4>] (dump_stack) from [<b01214f4>] (__warn+0xf4/0x10c) [ 266.320542] [<b01214f4>] (__warn) from [<b01215d4>] (warn_slowpath_null+0x28/0x30) [ 266.323534] [<b01215d4>] (warn_slowpath_null) from [<af067858>] (mmc_blk_remove_req+0xd0/0xe8 [mmc_block]) [ 266.326568] [<af067858>] (mmc_blk_remove_req [mmc_block]) from [<af068f40>] (mmc_blk_remove_parts.constprop.6+0x50/0x64 [mmc_block]) [ 266.329678] [<af068f40>] (mmc_blk_remove_parts.constprop.6 [mmc_block]) from [<af0693b8>] (mmc_blk_remove+0x24/0x140 [mmc_block]) [ 266.332894] [<af0693b8>] (mmc_blk_remove [mmc_block]) from [<af0052ec>] (mmc_bus_remove+0x20/0x28 [mmc_core]) [ 266.336198] [<af0052ec>] (mmc_bus_remove [mmc_core]) from [<b046aa64>] (device_release_driver_internal+0x164/0x200) [ 266.339367] [<b046aa64>] (device_release_driver_internal) from [<b046ab54>] (driver_detach+0x40/0x74) [ 266.342537] [<b046ab54>] (driver_detach) from [<b046982c>] (bus_remove_driver+0x68/0xdc) [ 266.345660] [<b046982c>] (bus_remove_driver) from [<af06ad40>] (mmc_blk_exit+0xc/0x2cc [mmc_block]) [ 266.348875] [<af06ad40>] (mmc_blk_exit [mmc_block]) from [<b01aee30>] (SyS_delete_module+0x1c4/0x254) [ 266.352068] [<b01aee30>] (SyS_delete_module) from [<b0108480>] (ret_fast_syscall+0x0/0x34) [ 266.355308] ---[ end trace f68728a0d3053b72 ]--- Fixes: 7c84b8b4 ("mmc: block: bypass the queue even if usage is present for hotplug") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by:
-
- Aug 08, 2017
-
-
Haibo Chen authored
Change the default err value to -EINVAL, make sure the card only has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage setting when select hs400es mode. Fixes: commit 1720d354 ("mmc: core: switch to 1V8 or 1V2 for hs400es mode") Cc: <stable@vger.kernel.org> Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Reviewed-by:
-
- Aug 03, 2017
-
-
Shawn Lin authored
The commit 304419d8 ("mmc: core: Allocate per-request data using the block layer core") refactored mechanism of queue handling caused mmc_init_request() can be called just after mmc_cleanup_queue() caused null pointer dereference. Another commit bbdc74dc ("mmc: block: Prevent new req entering queue after its cleanup") tried to fix the problem. However it actually miss one corner case. We could still reproduce the issue mentioned with these steps: (1) insert a SD card and mount it (2) hotplug it, so it will leave md->usage still be counted (3) reboot the system which will sync data and umount the card [Unable to handle kernel NULL pointer dereference at virtual address 00000000 [user pgtable: 4k pages, 48-bit VAs, pgd = ffff80007bab3000 [[0000000000000000] *pgd=000000007a828003, *pud=0000000078dce003, *pmd=000000007aab6003, *pte=0000000000000000 [Internal error: Oops: 96000007 [#1] PREEMPT SMP [Modules linked in: [CPU: 3 PID: 3507 Comm: umount Tainted: G W 4.13.0-rc1-next-20170720-00012-g9d9bf45 #33 [Hardware name: Firefly-RK3399 Board (DT) [task: ffff80007a1de200 task.stack: ffff80007a01c000 [PC is at mmc_init_request+0x14/0xc4 [LR is at alloc_request_size+0x4c/0x74 [pc : [<ffff0000087d7150>] lr : [<ffff000008378fe0>] pstate: 600001c5 [sp : ffff80007a01f8f0 .... [[<ffff0000087d7150>] mmc_init_request+0x14/0xc4 [[<ffff000008378fe0>] alloc_request_size+0x4c/0x74 [[<ffff00000817ac28>] mempool_create_node+0xb8/0x17c [[<ffff00000837aadc>] blk_init_rl+0x9c/0x120 [[<ffff000008396580>] blkg_alloc+0x110/0x234 [[<ffff000008396ac8>] blkg_create+0x424/0x468 [[<ffff00000839877c>] blkg_lookup_create+0xd8/0x14c [[<ffff0000083796bc>] generic_make_request_checks+0x368/0x3b0 [[<ffff00000837b050>] generic_make_request+0x1c/0x240 So mmc_blk_put wouldn't calling blk_cleanup_queue which actually the QUEUE_FLAG_DYING and QUEUE_FLAG_BYPASS should stay. Block core expect blk_queue_bypass_{start, end} internally to bypass/drain the queue before actually dying the queue, so it didn't expose API to set the queue bypass. I think we should set QUEUE_FLAG_BYPASS whenever queue is removed, although the md->usage is still counted, as no dispatch queue could be found then. Fixes: 304419d8 ("mmc: core: Allocate per-request data using the block layer core") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- Jul 13, 2017
-
-
Grzegorz Sluja authored
The commit 304419d8 ("mmc: core: Allocate per-request data using the block layer core"), refactored the mechanism of queue handling, but also made mmc_init_request() to be called after mmc_cleanup_queue(). This triggers a null pointer dereference: [ 683.123791] BUG: unable to handle kernel NULL pointer dereference at (null) [ 683.123801] IP: mmc_init_request+0x2c/0xf0 [mmc_block] ... [ 683.123905] Call Trace: [ 683.123913] alloc_request_size+0x4f/0x70 [ 683.123919] mempool_alloc+0x5f/0x150 [ 683.123925] ? __enqueue_entity+0x6c/0x70 [ 683.123928] get_request+0x3ad/0x720 [ 683.123933] ? prepare_to_wait_event+0x110/0x110 [ 683.123937] blk_queue_bio+0xc1/0x3a0 [ 683.123940] generic_make_request+0xf8/0x2a0 [ 683.123942] submit_bio+0x75/0x150 [ 683.123947] submit_bio_wait+0x51/0x70 [ 683.123951] blkdev_issue_flush+0x5c/0x90 [ 683.123956] ext4_sync_fs+0x171/0x1b0 [ 683.123961] sync_filesystem+0x73/0x90 [ 683.123965] fsync_bdev+0x24/0x50 [ 683.123971] invalidate_partition+0x24/0x50 [ 683.123973] del_gendisk+0xb2/0x2a0 [ 683.123977] mmc_blk_remove_req.part.38+0x71/0xa0 [mmc_block] [ 683.123980] mmc_blk_remove+0xba/0x190 [mmc_block] [ 683.123990] mmc_bus_remove+0x1a/0x20 [mmc_core] [ 683.123995] device_release_driver_internal+0x141/0x200 [ 683.123999] device_release_driver+0x12/0x20 [ 683.124001] bus_remove_device+0xfd/0x170 [ 683.124004] device_del+0x1e8/0x330 [ 683.124012] mmc_remove_card+0x60/0xc0 [mmc_core] [ 683.124019] mmc_remove+0x19/0x30 [mmc_core] [ 683.124025] mmc_stop_host+0xfb/0x1a0 [mmc_core] [ 683.124032] mmc_remove_host+0x1a/0x40 [mmc_core] [ 683.124037] sdhci_remove_host+0x2e/0x1c0 [mmc_sdhci] [ 683.124042] sdhci_pci_remove_slot+0x3f/0x80 [sdhci_pci] [ 683.124045] sdhci_pci_remove+0x39/0x70 [sdhci_pci] [ 683.124049] pci_device_remove+0x39/0xc0 [ 683.124052] device_release_driver_internal+0x141/0x200 [ 683.124056] driver_detach+0x3f/0x80 [ 683.124059] bus_remove_driver+0x55/0xd0 [ 683.124062] driver_unregister+0x2c/0x50 [ 683.124065] pci_unregister_driver+0x29/0x90 [ 683.124069] sdhci_driver_exit+0x10/0x4f3 [sdhci_pci] [ 683.124073] SyS_delete_module+0x171/0x250 [ 683.124078] entry_SYSCALL_64_fastpath+0x1e/0xa9 Fix this by setting the queue DYING flag before cleanup the queue, as it prevents new reqs from entering the queue. Signed-off-by:
Grzegorz Sluja <grzegorzx.sluja@intel.com> Signed-off-by:
-
- Jul 11, 2017
-
-
Geert Uytterhoeven authored
With gcc 4.1.2: drivers/mmc/core/block.c: In function ‘mmc_blk_ioctl_cmd_issue’: drivers/mmc/core/block.c:630: warning: ‘ioc_err’ may be used uninitialized in this function Indeed, if mq_rq->ioc_count is zero, an uninitialized value will be stored in mq_rq->drv_op_result and passed to blk_end_request_all(). Can mq_rq->ioc_count be zero? - mmc_blk_ioctl_cmd() sets ioc_count to 1, so this is safe, - mmc_blk_ioctl_multi_cmd() obtains ioc_count from user space in response to the MMC_IOC_MULTI_CMD ioctl, and does allow zero. To avoid returning an uninitialized value, and as it is pointless to do all this work when the MMC_IOC_MULTI_CMD ioctl is used with zero entries, check for this early in mmc_blk_ioctl_multi_cmd(), and return zero, like was returned before. Fixes: 3ecd8cf2 ("mmc: block: move multi-ioctl() to use block layer") Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
With gcc 4.1.2: drivers/mmc/core/block.c: In function ‘mmc_blk_issue_drv_op’: drivers/mmc/core/block.c:1178: warning: ‘ret’ may be used uninitialized in this function Indeed, for MMC_DRV_OP_IOCTL, if mq_rq->ioc_count is zero, an uninitialized value will be stored in mq_rq->drv_op_result and passed to blk_end_request_all(). Can mq_rq->ioc_count be zero? - mmc_blk_ioctl_cmd() sets ioc_count to 1, so this is safe, - mmc_blk_ioctl_multi_cmd() obtains ioc_count from user space in response to the MMC_IOC_MULTI_CMD ioctl, and does allow zero. Initialize ret to zero to fix this for current and future callers. Fixes: 0493f6fe ("mmc: block: Move boot partition locking into a driver op") Signed-off-by:
-
- Jun 27, 2017
-
-
Christoph Hellwig authored
BLK_BOUNCE_ANY is the defauly now, so the call is superflous. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Jun 20, 2017
-
-
Adrian Hunter authored
Add host capability MMC_CAP_CD_WAKE to enable irq wake on the card detect irq. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Ulf Hansson authored
The MMC_CAP2_HC_ERASE_SZ is used only by a few mmc host drivers. Its intent is to enable eMMC's high-capacity erase size, as to improve the behaviour of the erase operations. We should strive to avoid software configuration options that aren't necessary, but instead deploy common behaviours. For these reasons, let's remove the capability bit for MMC_CAP2_HC_ERASE_SZ and make it the default behaviour. Note that this change doesn't affect eMMCs supporting trim/discard, because these commands operates on sectors and takes precedence over erase commands. Signed-off-by:
-
Wolfram Sang authored
Some errors are flagged only with the next command after a multiblock transfer, e.g. ECC error. So, when checking for data transfer errors, we check the result from the stop command as well. Signed-off-by:
-
Wolfram Sang authored
To detect errors like ECC errors, we must parse the R1 response bits. Introduce a helper function to also set the error value of a command when R1 error bits are set. Add ECC error to list of flags checked. Use the new helper for the stop command to call mmc_blk_recovery when detecting ECC errors which are only flagged on the next command after multiblock. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Ulf Hansson authored
To make the code more consistent and to increase readability, add an mmc_spi_send_csd() function, which gets called from mmc_send_csd() in case of SPI mode. Signed-off-by:
-
Ulf Hansson authored
Signed-off-by:
-
Ulf Hansson authored
Instead of having the caller to check for SPI mode, let's leave that to internals of mmc_send_cid(). In this way the code gets cleaner and it becomes clear what is specific to SPI and non-SPI mode. Signed-off-by:
-
Ulf Hansson authored
The mmc_send_cid() is never called using non SPI mode. Thus, let's remove the redundant code dealing with this. Signed-off-by:
-
Ulf Hansson authored
Signed-off-by:
-
Ulf Hansson authored
The mmc_flush_cache() is a eMMC specific function, let's move it to mmc_ops.c to make that clear. Signed-off-by:
-
Ulf Hansson authored
The mmc_interrupt_hpi() is a eMMC specific function, let's move it to mmc_ops.c to make that clear. The move also enables us to make mmc_send_hpi_cmd() static, so let's do that change as well. Signed-off-by:
-
Ulf Hansson authored
The mmc_start_bkops(), mmc_stop_bkops() and mmc_read_bkops_status() functions are all specific to eMMCs. To make this clear, let's move them from from core.c to mmc_ops.c and take the opportunity to make mmc_read_bkops_status() static. While moving them, get rid of MMC_BKOPS_MAX_TIMEOUT (4 min) and use the common default timeout MMC_OPS_TIMEOUT_MS (10 min) instead, as there is no need to have specific default timeout for bkops. Signed-off-by:
-
Ulf Hansson authored
The mmc_start|stop_bkops(), mmc_read_bkops_status() and mmc_interrupt_hpi() functions are all used from within the mmc core module, thus there are no need to use EXPORT_SYMBOL() for them, so let's remove it. Signed-off-by:
-
Adrian Hunter authored
Drivers core will runtime suspend a device with no driver. That means the SDIO card will be runtime suspended as soon as it is added. It is then runtime resumed to add each function. That is entirely pointless, so add pm runtime get/put to keep the SDIO card runtime resumed until the function devices have been added. Signed-off-by:
-
Adrian Hunter authored
The error path deletes the device by calling mmc_sdio_remove() which must be called without the host claimed. Simplify the error path so it does just that and add a comment about why we don't disable runtime PM. Signed-off-by:
-
David Woods authored
Using the device_property interfaces allows mmc drivers to work on platforms which run on either device tree or ACPI. Signed-off-by:
David Woods <dwoods@mellanox.com> Reviewed-by:
Chris Metcalf <cmetcalf@mellanox.com> Cc: stable@vger.linux.org Signed-off-by:
-
Wu Fengguang authored
drivers/mmc/core/block.c:1929:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Ulf Hansson authored
The only reason to why the mmc block device driver needs to implements its own version of how to get the status of the card, is that it needs to specify a different amount of retries. Therefore add a new exported function which allows the caller to specify the number of retries and convert everybody to use it, as this simplifies the code. Signed-off-by:
-
Linus Walleij authored
This moves the boot partition lock command (issued from sysfs) into a custom block layer request, just like the ioctl()s, getting rid of yet another instance of mmc_get_card(). Since we now have two operations issuing special DRV_OP's, we rename the result variable ->drv_op_result. Tested by locking the boot partition from userspace: > cd /sys/devices/platform/soc/80114000.sdi4_per2/mmc_host/mmc3/ mmc3:0001/block/mmcblk3/mmcblk3boot0 > echo 1 > ro_lock_until_next_power_on [ 178.645324] mmcblk3boot1: Locking boot partition ro until next power on [ 178.652221] mmcblk3boot0: Locking boot partition ro until next power on Also tested this with a huge dd job in the background: it is now possible to lock the boot partitions on the card even under heavy I/O. Signed-off-by: -
Linus Walleij authored
We will need to access static functions above the pure block layer operations in the file, so move the driver operations issue function down so we can see all non-blocklayer symbols. Signed-off-by:
-
Linus Walleij authored
We will expand the DRV_OP usage, so we need to know which operation we're performing. Tag the operations with an enum:ed type and rename the function so it is clear that it deals with any command and put a switch statement in it. Currently only ioctls are supported. Signed-off-by:
-
Linus Walleij authored
Just as we can use blk_mq_rq_from_pdu() to get the per-request tag we can use blk_mq_rq_to_pdu() to get a request from a tag. Introduce a static inline helper so we are on the clear what is happening. Suggested-by:
-
Markus Elfring authored
Omit an extra message for memory allocation failures. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Linus Walleij authored
commit cdf8a6fb "mmc: block: Introduce queue semantics" deleted the last user of mmc_req_is_special() and it was a horrible hack to classify requests as "special" or "not special" to begin with, so delete the helper. Signed-off-by:
-
Linus Walleij authored
This switches also the multiple-command ioctl() call to issue all ioctl()s through the block layer instead of going directly to the device. We extend the passed argument with an argument count and loop over all passed commands in the ioctl() issue function called from the block layer. By doing this we are again loosening the grip on the big host lock, since two calls to mmc_get_card()/mmc_put_card() are removed. Signed-off-by:
Avri Altman <Avri.Altman@sandisk.com>
-
Linus Walleij authored
This wraps single ioctl() commands into block requests using the custom block layer request types REQ_OP_DRV_IN and REQ_OP_DRV_OUT. By doing this we are loosening the grip on the big host lock, since two calls to mmc_get_card()/mmc_put_card() are removed. We are storing the ioctl() in/out argument as a pointer in the per-request struct mmc_blk_request container. Since we now let the block layer allocate this data, blk_get_request() will allocate it for us and we can immediately dereference it and use it to pass the argument into the block layer. We refactor the if/else/if/else ladder in mmc_blk_issue_rq() as part of the job, keeping some extra attention to the case when a NULL req is passed into this function and making that pipeline flush more explicit. Tested on the ux500 with the userspace: mmc extcsd read /dev/mmcblk3 resulting in a successful EXTCSD info dump back to the console. This commit fixes a starvation issue in the MMC/SD stack that can be easily provoked in the following way by issueing the following commands in sequence: > dd if=/dev/mmcblk3 of=/dev/null bs=1M & > mmc extcs read /dev/mmcblk3 Before this patch, the extcsd read command would hang (starve) while waiting for the dd command to finish since the block layer was holding the card/host lock. After this patch, the extcsd ioctl() command is nicely interpersed with the rest of the block commands and we can issue a bunch of ioctl()s from userspace while there is some busy block IO going on without any problems. Conversely userspace ioctl()s can no longer starve the block layer by holding the card/host lock. Signed-off-by:
-
Linus Walleij authored
The variable is_rpmb is clearly a bool and even assigned true and false, yet declared as an int. Signed-off-by:
-
Linus Walleij authored
The mmc_queue_req is a per-request state container the MMC core uses to carry bounce buffers, pointers to asynchronous requests and so on. Currently allocated as a static array of objects, then as a request comes in, a mmc_queue_req is assigned to it, and used during the lifetime of the request. This is backwards compared to how other block layer drivers work: they usally let the block core provide a per-request struct that get allocated right beind the struct request, and which can be obtained using the blk_mq_rq_to_pdu() helper. (The _mq_ infix in this function name is misleading: it is used by both the old and the MQ block layer.) The per-request struct gets allocated to the size stored in the queue variable .cmd_size initialized using the .init_rq_fn() and cleaned up using .exit_rq_fn(). The block layer code makes the MMC core rely on this mechanism to allocate the per-request mmc_queue_req state container. Doing this make a lot of complicated queue handling go away. We only need to keep the .qnct that keeps count of how many request are currently being processed by the MMC layer. The MQ block layer will replace also this once we transition to it. Doing this refactoring is necessary to move the ioctl() operations into custom block layer requests tagged with REQ_OP_DRV_[IN|OUT] instead of the custom code using the BigMMCHostLock that we have today: those require that per-request data be obtainable easily from a request after creating a custom request with e.g.: struct request *rq = blk_get_request(q, REQ_OP_DRV_IN, __GFP_RECLAIM); struct mmc_queue_req *mq_rq = req_to_mq_rq(rq); And this is not possible with the current construction, as the request is not immediately assigned the per-request state container, but instead it gets assigned when the request finally enters the MMC queue, which is way too late for custom requests. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com>
-
Linus Walleij authored
This option is activated by all multiplatform configs and what not so we almost always have it turned on, and the memory it saves is negligible, even more so moving forward. The actual bounce buffer only gets allocated only when used, the only thing the ifdefs are saving is a little bit of code. It is highly improper to have this as a Kconfig option that get turned on by Kconfig, make this a pure runtime-thing and let the host decide whether we use bounce buffers. We add a new property "disable_bounce" to the host struct. Notice that mmc_queue_calc_bouncesz() already disables the bounce buffers if host->max_segs != 1, so any arch that has a maximum number of segments higher than 1 will have bounce buffers disabled. The option CONFIG_MMC_BLOCK_BOUNCE is default y so the majority of platforms in the kernel already have it on, and it then gets turned off at runtime since most of these have a host->max_segs > 1. The few exceptions that have host->max_segs == 1 and still turn off the bounce buffering are those that disable it in their defconfig. Those are the following: arch/arm/configs/colibri_pxa300_defconfig arch/arm/configs/zeus_defconfig - Uses MMC_PXA, drivers/mmc/host/pxamci.c - Sets host->max_segs = NR_SG, which is 1 - This needs its bounce buffer deactivated so we set host->disable_bounce to true in the host driver arch/arm/configs/davinci_all_defconfig - Uses MMC_DAVINCI, drivers/mmc/host/davinci_mmc.c - This driver sets host->max_segs to MAX_NR_SG, which is 16 - That means this driver anyways disabled bounce buffers - No special action needed for this platform arch/arm/configs/lpc32xx_defconfig arch/arm/configs/nhk8815_defconfig arch/arm/configs/u300_defconfig - Uses MMC_ARMMMCI, drivers/mmc/host/mmci.[c|h] - This driver by default sets host->max_segs to NR_SG, which is 128, unless a DMA engine is used, and in that case the number of segments are also > 1 - That means this driver already disables bounce buffers - No special action needed for these platforms arch/arm/configs/sama5_defconfig - Uses MMC_SDHCI, MMC_SDHCI_PLTFM, MMC_SDHCI_OF_AT91, MMC_ATMELMCI - Uses drivers/mmc/host/sdhci.c - Normally sets host->max_segs to SDHCI_MAX_SEGS which is 128 and thus disables bounce buffers - Sets host->max_segs to 1 if SDHCI_USE_SDMA is set - SDHCI_USE_SDMA is only set by SDHCI on PCI adapers - That means that for this platform bounce buffers are already disabled at runtime - No special action needed for this platform arch/blackfin/configs/CM-BF533_defconfig arch/blackfin/configs/CM-BF537E_defconfig - Uses MMC_SPI (a simple MMC card connected on SPI pins) - Uses drivers/mmc/host/mmc_spi.c - Sets host->max_segs to MMC_SPI_BLOCKSATONCE which is 128 - That means this platform already disables bounce buffers at runtime - No special action needed for these platforms arch/mips/configs/cavium_octeon_defconfig - Uses MMC_CAVIUM_OCTEON, drivers/mmc/host/cavium.c - Sets host->max_segs to 16 or 1 - Setting host->disable_bounce to be sure for the 1 case arch/mips/configs/qi_lb60_defconfig - Uses MMC_JZ4740, drivers/mmc/host/jz4740_mmc.c - This sets host->max_segs to 128 so bounce buffers are already runtime disabled - No action needed for this platform It would be interesting to come up with a list of the platforms that actually end up using bounce buffers. I have not been able to infer such a list, but it occurs when host->max_segs == 1 and the bounce buffering is not explicitly disabled. Signed-off-by:
-
Ulf Hansson authored
For hosts not supporting MMC_CAP2_SDIO_IRQ_NOTHREAD but MMC_CAP_SDIO_IRQ, the SDIO IRQs are processed from a dedicated kernel thread. For these cases, the host calls mmc_signal_sdio_irq() from its ISR to signal a new SDIO IRQ. Signaling an SDIO IRQ makes the host's ->enable_sdio_irq() callback to be invoked to temporary disable the IRQs, before the kernel thread is woken up to process it. When processing of the IRQs are completed, they are re-enabled by the kernel thread, again via invoking the host's ->enable_sdio_irq(). The observation from this, is that the execution path is being unnecessary complex, as the host driver already knows that it needs to temporary disable the IRQs before signaling a new one. Moreover, replacing the kernel thread with a work/workqueue would not only greatly simplify the code, but also make it more robust. To address the above problems, let's continue to build upon the support for MMC_CAP2_SDIO_IRQ_NOTHREAD, as it already implements SDIO IRQs to be processed without using the clumsy kernel thread and without the ping-pong calls of the host's ->enable_sdio_irq() callback for each processed IRQ. Therefore, let's add new API sdio_signal_irq(), which enables hosts to signal/process SDIO IRQs by using a work/workqueue, rather than using the kernel thread. Add also a new host callback ->ack_sdio_irq(), which the work invokes when the SDIO IRQs have been processed. This informs the host about when it shall re-enable the SDIO IRQs. Potentially, we could re-use the existing ->enable_sdio_irq() callback instead of adding a new one, however it has turned out that it's more convenient for hosts to get this information via a separate callback. Hosts that wants to use this new method to signal/process SDIO IRQs, must enable MMC_CAP2_SDIO_IRQ_NOTHREAD and implement the ->ack_sdio_irq() callback. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
Ulf Hansson authored
In cases when MMC_CAP2_SDIO_IRQ_NOTHREAD is set, there is a minor window for when the mmc host could call sdio_run_irqs(), while in fact an SDIO func driver could have decided to released the SDIO IRQ via a call to sdio_release_irq(). In this scenario, processing of the SDIO IRQs are done even if there is none IRQ claimed, which is not what we want. To prevent this from happen, close the window by validating that at least one SDIO IRQs is claimed, before deciding to process them. Signed-off-by:
-
Ulf Hansson authored
In case if a pwrseq-emmc has been bound to the host, a call to mmc_power_up() triggers an eMMC HW reset via the pwrseq_emmc's ->post_power_on() callback. This isn't really what we want, as mmc_power_up() is called each time when resuming the card. As a matter of fact, the current approach may also violate the eMMC spec, as the involved delays managed in pwrseq_emmc assumes both VCC and VCCQ has been turned on, which isn't the case for VCCQ, unless the regulator is always on. Fix this behaviour by aligning to the same procedure used when the mmc host implements the ->hw_reset() callback and has the MMC_CAP_HW_RESET flag set. In this way the eMMC HW reset is issued at card detection scan, to cope with bogus bootloaders and in the error recovery path via the mmc specific bus_ops->reset() callback. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com>
-
