- 10 Nov, 2014 35 commits
-
-
Doug Anderson authored
The dw_mmc driver had a bunch of code that ran whenever a card was ejected and inserted. However, this code was old and crufty and should be removed. Some evidence that it's really not needed: 1. Is is supposed to be legal to use 'cd-gpio' on dw_mmc instead of using the built-in card detect mechanism. The 'cd-gpio' code doesn't run any of the crufty old code but yet still works. 2. While looking at this, I realized that my old change (369ac861 mmc: dw_mmc: don't queue up a card detect at slot startup) actually castrated the old code a little bit already and nobody noticed. Specifically "last_detect_state" was left as 0 at bootup. That means that on the first card removal none of the crufty code ran. 3. I can run "while true; do dd if=/dev/mmcblk1 of=/dev/null; done" while ejecting and inserting an SD Card and the world doesn't explode. If some of the crufty old code is actually needed, we should justify it and also put it in some place where it will be run even with "cd-gpio". Note that in my case I'm using the "cd-gpio" mechanism but for various reasons the hardware triggers a dw_mmc "card detect" at bootup. That was actually causing a real bug. The card detect workqueue was running while the system was trying to enumerate the card. The "present != slot->last_detect_state" triggered and we were doing all kinds of crazy stuff and messing up enumeration. The new mechanism of just asking the core to check the card is much safer and then the bogus interrupt doesn't hurt. Signed-off-by:
Doug Anderson <dianders@chromium.org> Tested-by:
Jaehoon Chung <jh80.chung@samsung.com> Acked-by:
alim.akhtar <alim.akhtar@samsung.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Dan Carpenter authored
Presumably ->slotno is normally fairly small and the shift doesn't wrap but static checkers will complain about it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mike Looijmans authored
"ret" is a signed int, so use "%d" in format strings instead of "%u". This prevents cryptic codes in error messages like this: sdhci-arasan e0101000.sdhci: platform register failed (4294966779) Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Reviewed-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Alexandre Belloni authored
Use the generic platform_data header file instead of mach/atmel-mci.h Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Alexandre Belloni authored
Use the generic platform_data header file instead of mach/atmel-mci.h Signed-off-by:
-
Alexandre Belloni authored
Move the mach header that can come either from arm/mach-at91 or avr32 to platform_data to be able to switch the AT91 platforms to multiplatform. Signed-off-by:
-
Gwendal Grignou authored
For eMMC 5.0 compliant device, firmware version is stored in ext_csd. Report firmware as a 64bit hexa decimal. Vendor can use hexa or ascii string to report firmware version. Also add FFU related EXT_CSD register and note if the device is FFU capable. Signed-off-by:
Gwendal Grignou <gwendal@chromium.org> Signed-off-by:
-
Doug Anderson authored
The "set_ios" function is called with a clock of 0 when the clock is turning off. There's no reason to go through all the extra Rockchip logic (whose goal is to make sure DIV is 0 or 1) in that case. The Rockchip logic happened to work because the CCF will pick the lowest possible rate when you ask it for a clock of 0, but it's silly to go through all the remuxing and adjusting for no reason. Signed-off-by:
-
Doug Anderson authored
In (28f92b5 mmc: core: Try other signal levels during power up) we can see that there are times when it's valid to try several signal voltages. Don't print an ugly error in the logs when that happens. Signed-off-by:
-
Sonny Rao authored
We've already got a reset of DMA after it's done. Add one before we start DMA too. This fixes a data corruption on Rockchip SoCs which will get bad data when doing a DMA transfer after doing a PIO transfer. We tested this on an Exynos 5800 with HS200 and didn't notice any difference in sequential read throughput. Signed-off-by:
Sonny Rao <sonnyrao@chromium.org> Signed-off-by:
-
Ulf Hansson authored
Signed-off-by: -
Ulf Hansson authored
In most of the cases mmc_get|set_drvdata() didn't simplify code, which should be the primary reason for such macros. Let's remove them and convert to the common device_driver macros, dev_set|get_drvdata() instead. Signed-off-by: -
Ulf Hansson authored
The msm_sdcc host shall not use mmc core specific macros to handle its driver data. Instead, convert to use the platform device driver macros. Signed-off-by: -
Ulf Hansson authored
The struct mmc_driver adds an extra layer on top of the struct device_driver. That would be fine, if there were a good reason, but that's not the case. Let's simplify code by converting to the common struct device_driver instead and thus also removing superfluous overhead. Signed-off-by: -
Ulf Hansson authored
Instead of having specific mmc system PM callbacks for the mmc driver, let's convert to use the common ones. Signed-off-by: -
Ulf Hansson authored
The macro is only used by the mmc core, so let's move it in there. Signed-off-by: -
Ulf Hansson authored
Signed-off-by: -
Sebastian Hesselbarth authored
NULL-checking a struct clk it not only wrong but also not required as for PXAv3 driver the corresponding clock is mandatory. Remove the checks from sdhci_pxav3_runtime_{suspend,resume}. Signed-off-by:Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Sebastian Hesselbarth authored
clk_enable from struct sdhci_pxa is unused, remove it from the private driver data. Signed-off-by:
-
Sebastian Hesselbarth authored
struct sdhci_pxa is only used in sdhci_pxa driver itself, so move it there. Signed-off-by:
-
Sebastian Hesselbarth authored
commit bb8175a8 ("mmc: sdhci: clarify DDR timing mode between SD-UHS and eMMC") added MMC_DDR52 as eMMC's DDR mode to be distinguished from SD-UHS. While the differentation may be useful, pxav3 SDHCI controller lacks a corresponding check in its custom .set_uhs_signaling callback for MMC_DDR52. This patch adds a new switch case for MMC_TIMING_MMC_DDR52 to MMC_TIMING_UHS_DDR50 case. Signed-off-by:
-
Sebastian Hesselbarth authored
struct sdhci_pxa is private data of PXA SDHCI driver, but not used in sdhci-pxav2 at all. Drop unused references to struct sdhci_pxa. Signed-off-by:
-
Tomeu Vizoso authored
Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
-
Srinivas Kandagatla authored
If the post request is cancelling the channel and descriptor and which are equal to host->dma_current and host->dma_desc_current respectively, then it makes sense to reset these pointers to NULL, so that the driver does not reference it. Also the host_cookie can be reset to 0 in cases of error, so that the core could reissue the same mmc_request. This patch was tested with 'mmc: core: fix prepared requests while doing bkops' to fix the below issue. mmci-pl18x 12400000.sdcc: error during DMA transfer! Unable to handle kernel paging request at virtual address 40000000 pgd = c0204000 [40000000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: ipv6 ath6kl_sdio ath6kl_core CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.17.0-rc7-linaro-multi-v7 #1 task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000 PC is at v7_dma_inv_range+0x34/0x4c LR is at __dma_page_dev_to_cpu+0x80/0x100 pc : [<c021efc0>] lr : [<c021af18>] psr: 400f0193 sp : c0c93e20 ip : c0c9a478 fp : c08ea538 r10: c0c9f548 r9 : 00000002 r8 : e97d9000 r7 : 00000200 r6 : c0c9d504 r5 : c0db0880 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 40000200 r0 : 40000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: a9ef406a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc0c92250) Stack: (0xc0c93e20 to 0xc0c94000) 3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002 3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4 3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534 3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080 3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc 3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190 3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080 3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff 3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44 3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38 3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4 3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c 3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000 [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100) [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84) [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74) [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c) [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114) [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134) [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64) [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8) [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c) [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90) [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68) [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54) Exception stack(0xc0c93f28 to 0xc0c93f70) 3f20: 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c) [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c) [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0) [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238) [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390) Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36) ---[ end trace cf6cb3f6432c9834 ]--- Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
-
Srinivas Kandagatla authored
While starting the bkops the previously prepared request should be canceled and restarted after the bkops. As the prepared resource might already setup the dma channels and ready to be started. Now with the arrival of bkops request this prepared request can be serviced ONLY after the bkops. So holding on to the prepared request in the host driver is confusing at this point in time, so it makes sense to cleanup such dangling requests and reissue this request once bkops is done. Canceling the prepared request would give opportunity to the host drivers to perform cleanup on the prepared request. Without this patch host drivers like mmci gets confused when a blocking request like send_ext_csd(CMD8) is issued while there is already a prepared request. With the help of this patch, the driver can better manage such blocking requests and cleanup the prepared requests which are not started yet. Without this patch I hit below crash on Qualcomm APQ8064 based IFC6410 board with mmci host driver. mmci-pl18x 12400000.sdcc: error during DMA transfer! Unable to handle kernel paging request at virtual address 40000000 pgd = c0204000 [40000000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: ipv6 ath6kl_sdio ath6kl_core CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.17.0-rc7-linaro-multi-v7 #1 task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000 PC is at v7_dma_inv_range+0x34/0x4c LR is at __dma_page_dev_to_cpu+0x80/0x100 pc : [<c021efc0>] lr : [<c021af18>] psr: 400f0193 sp : c0c93e20 ip : c0c9a478 fp : c08ea538 r10: c0c9f548 r9 : 00000002 r8 : e97d9000 r7 : 00000200 r6 : c0c9d504 r5 : c0db0880 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 40000200 r0 : 40000000 Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: a9ef406a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc0c92250) Stack: (0xc0c93e20 to 0xc0c94000) 3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002 3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4 3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534 3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080 3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc 3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190 3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080 3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff 3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44 3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38 3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4 3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c 3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000 [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100) [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84) [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74) [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c) [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114) [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134) [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64) [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8) [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c) [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90) [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68) [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54) Exception stack(0xc0c93f28 to 0xc0c93f70) 3f20: 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b 3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70 3f60: c04bd630 c04bd5bc 200f0013 ffffffff [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c) [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c) [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0) [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238) [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390) Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36) ---[ end trace cf6cb3f6432c9834 ]--- Kernel panic - not syncing: Fatal exception in interrupt Reported-by:
Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by:
-
Andrew Gabbasov authored
In mmc_init_card function some of the branches in error handling paths go to "err" label, which skips removing of newly allocated card structure, that will actually not be used. Fix that by using proper "free_card" label. Also, some messages in these branches are reported as warnings, although the operation processing is not continued. Change these messages to error level. Signed-off-by:
Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by:
-
Andrew Gabbasov authored
The debug messages with commands execution results, that are printed after processing the request, do not include results of sbc (set block count) part of request. Add the debug message for that part too. Signed-off-by:
-
Andrew Gabbasov authored
Some request fields are initialized just before request processing for sanity purposes. This is done for command, data, and stop parts of the request, but not for sbc (set block count) part. Add such initialization for that part too. Signed-off-by:
-
Andrew Gabbasov authored
Add the case of SET_BLOCK_COUNT command error to the error conditions check for making a controller reset at request handling finish. Otherwise, if the SET_BLOCK_COUNT command failed, e.g. with a timeout, the controller state was not reset, and the next command failed too. In the case of data error the controller reset is already done in finish_data() function before sending stop command (if present), so the finish tasklet should make a reset after data error only if no stop command existed in the request. Also, fix the indentation of this condition check to make it more logical. Signed-off-by:
-
Andrew Gabbasov authored
As a follow-up of commit "mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmc" vmmc regulator disable is also not needed in sdhci_remove_host. The regulator is completely controlled by mmc_power_up and mmc_power_off functions and is already disabled by the time of removing the host. Extra regulator_disable call in sdhci_remove_host is unbalanced and causes a warning reported by regulator core, so should be removed. Signed-off-by:
-
Dirk Behme authored
The commit ad93220d ("mmc: sdhci-esdhc-imx: change pinctrl state according to uhs mode") exits the probe in case there are no valid pinctrl states found. As there are configurations doing the pin mux properly in the boot loader, don't exit. Just warn, but go on in case if there are no pinctrl states in the device tree. Signed-off-by:
Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by:
-
Matteo Facchinetti authored
If available voltages are not given, mmc_regulator_get_supply() function returns 0 and mxcmmc driver doesn't set a value for ocr_avail mask. In accordance with the comment in platform_data/mmc-mxcmmc.h, fix it, assuming MMC_VDD_32_33 | MMC_VDD_33_34 as default value. Signed-off-by:
Matteo Facchinetti <matteo.facchinetti@sirius-es.it> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Matteo Facchinetti authored
During a read of data block using dma, driver might have two ways to finish to read and free the resources: 1) checking STATUS_DATA_TRANS_DONE mask, in the mxcmci_irq() routine (pending to mmc irq) 2) mxmmc driver, registers also a mxcmci_dma_callback() and when transfer is finished, dma driver calls this callback. (pending to dma irq) Both ways are concurrent with each other. Race condition happens when following events occur: /* (1) mxcmci driver start data transfer */ 158.418970: mpc_dma_execute: mpc_dma_execute(): will_access_peripheral start cid=31 158.418976: mpc_dma_issue_pending <-mxcmci_request 158.418983: mxcmci_start_cmd <-mxcmci_request /* (2) mxcmci driver receive mmc irq */ 158.419656: mxcmci_irq <-handle_irq_event_percpu 158.419692: mxcmci_read_response <-mxcmci_irq /* (3) mxcmci driver checks that transfer is complete and call mxcmci_finish_data() */ 158.419726: mxcmci_data_done <-mxcmci_irq 158.419729: mxcmci_finish_data <-mxcmci_data_done 158.419733: dma_direct_unmap_sg <-mxcmci_finish_data 158.419736: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data 158.419762: mxcmci_read_response <-mxcmci_data_done /* (4) mxcmci driver (no dma): send stop command */ 158.419765: mxcmci_start_cmd <-mxcmci_data_done /* (5) mxcmci driver (no dma): receive the stop command irq response */ 158.419782: mxcmci_irq <-handle_irq_event_percpu 158.419812: mxcmci_read_response <-mxcmci_irq 158.419843: mxcmci_finish_request <-mxcmci_irq /* (6) dma driver: receive dma irq (finish data transfer) related by request on step 1 */ 158.419853: mpc_dma_irq <-handle_irq_event_percpu 158.420001: mpc_dma_irq_process <-mpc_dma_irq 158.420004: mpc_dma_irq_process <-mpc_dma_irq /* (7) dma driver: start dma tasklet to finish the dma irq handling */ 158.420008: mpc_dma_irq_process: mpc_dma_irq_process(): completed ch:31 /* (8) mxcmci driver: start next data transfer using dma */ 158.420174: mxcmci_request <-mmc_start_req 158.420182: dma_direct_map_sg <-mxcmci_request 158.420192: mpc_dma_prep_slave_sg <-mxcmci_request /* (9) dma driver: schedule irq tasklet and execute mxcmci dma driver callback */ 158.420250: mpc_dma_tasklet <-tasklet_action 158.420254: mpc_dma_process_completed <-tasklet_action 158.420267: mxcmci_dma_callback <-mpc_dma_process_completed /* ERROR!!! (10) mxcmci driver callback works on dma data related to the step 1 that is already finished */ 158.420271: mxcmci_data_done <-mpc_dma_process_completed 158.420273: mxcmci_finish_data <-mxcmci_data_done /* ERROR!!! (11) mxcmci driver: clear data that should be used by step 8 and send an other mmc stop command (already sended on step 4) */ 158.420276: dma_direct_unmap_sg <-mxcmci_finish_data 158.420279: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data 158.420330: mxcmci_read_response <-mxcmci_data_done 158.420333: mxcmci_start_cmd <-mxcmci_data_done 158.420338: dma_run_dependencies <-mpc_dma_process_completed ... ... ... 168.474223: mxcmci_watchdog <-call_timer_fn 168.474236: mxcmci_watchdog: mxcmci_watchdog 168.474397: mpc_dma_device_control <-mxcmci_watchdog In accordance with the other drivers that using the dma engine, fix it, leaving *only* to dma driver the complete control to ending the read operation. Removing STATUS_READ_OP_DONE event activation, has as effect to force mxcmci driver to handle the finish data transfer only by mxcmci dma callback. Signed-off-by: -
Peter Guo authored
Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue. Fixes: 01acf691 (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts) Signed-off-by:
Peter Guo <peter.guo@bayhubtech.com> Signed-off-by:
-
Baruch Siach authored
Make force_ro consistent with other sysfs entries. Fixes: 371a689f ('mmc: MMC boot partitions support') Cc: Andrei Warkentin <andrey.warkentin@gmail.com> Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
-
- 09 Nov, 2014 5 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fixes from Catalin Marinas: - enable bpf syscall for compat - cpu_suspend fix when checking the idle state type - defconfig update * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: defconfig: update defconfig for 3.18 arm64: compat: Enable bpf syscall arm64: psci: fix cpu_suspend to check idle state type for index
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "Another quiet week: - a fix to silence edma probe error on non-supported platforms from Arnd - a fix to enable the PL clock for Parallella, to make mainline usable with the SDK. - a somewhat verbose fix for the PLL clock tree on VF610 - enabling of SD/MMC on one of the VF610-based boards (for testing) - a fix for i.MX where CONFIG_SPI used to be implicitly enabled and now needs to be added to the defconfig instead - another maintainer added for bcm2835: Lee Jones" * tag 'armsoc-for-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: zynq: Enable PL clocks for Parallella dma: edma: move device registration to platform code ARM: dts: vf610: add SD node to cosmic dts MAINTAINERS: update bcm2835 entry ARM: imx: Fix the removal of CONFIG_SPI option ARM: imx: clk-vf610: define PLL's clock tree -
git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linuxLinus Torvalds authored
Pull devicetree bugfix from Grant Likely: "One buffer overflow bug that shouldn't be left around" * 'devicetree/merge' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux: of: Fix overflow bug in string property parsing functions
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fix from Chris Mason: "It's a one liner for an error cleanup path that leads to crashes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: fix kfree on list_head in btrfs_lookup_csums_range error cleanup
-
