- 14 8月, 2011 1 次提交
-
-
由 Kyungmin Park 提交于
The eMMC v4.5 Spec is released now: EXT_CSD_REV Extended CSD Revision 255-7 Reserved 6 Revision 1.6 (for MMC v4.5) 5 Revision 1.5 (for MMV v4.41) ... Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 26 7月, 2011 1 次提交
-
-
由 Amerigo Wang 提交于
It is not necessary to share the same notifier.h. Signed-off-by: NWANG Cong <amwang@redhat.com> Cc: David Miller <davem@davemloft.net> Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 7月, 2011 5 次提交
-
-
由 Daniel Drake 提交于
At http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg08371.html (thread: "mmc: sdio: reset card during power_restore") we found and fixed a bug where mmc's runtime power management functions were not being called. We have now also made improvements to the SDIO powerup routine which could possibly mask this kind of issue in future. Add debug messages to the runtime PM hooks so that it is easy to verify if and when runtime PM is happening. Signed-off-by: NDaniel Drake <dsd@laptop.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ohad Ben-Cohen 提交于
In the case where a driver returns -ENOSYS from its suspend handler to indicate that the device should be powered down over suspend, the remove routine of the driver was not being called, leading to lots of confusion during resume. The problem is that runtime PM is disabled during this process, and when we reach mmc_sdio_remove, calling the runtime PM functions here (validly) return errors, and this was causing us to skip the remove function. Fix this by ignoring the error value of pm_runtime_get_sync(), which can return valid errors. This also matches the behaviour of pci_device_remove(). Signed-off-by: NDaniel Drake <dsd@laptop.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Philip Rakity 提交于
Non default Drive Strength cannot be set automatically. It is a function of the board design and only if there is a specific platform handler can it be set. The platform handler needs to take into account the board design. Pass to the platform code the necessary information. For example: The card and host controller may indicate they support HIGH and LOW drive strength. There is no way to know what should be chosen without specific board knowledge. Setting HIGH may lead to reflections and setting LOW may not suffice. There is no mechanism (like ethernet duplex or speed pulses) to determine what should be done automatically. If no platform handler is defined -- use the default value. Signed-off-by: NPhilip Rakity <prakity@marvell.com> Reviewed-by: NArindam Nath <arindam.nath@amd.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Per Forlin 提交于
Previously there has only been one function mmc_wait_for_req() to start and wait for a request. This patch adds: * mmc_start_req() - starts a request wihtout waiting If there is on ongoing request wait for completion of that request and start the new one and return. Does not wait for the new command to complete. This patch also adds new function members in struct mmc_host_ops only called from core.c: * pre_req - asks the host driver to prepare for the next job * post_req - asks the host driver to clean up after a completed job The intention is to use pre_req() and post_req() to do cache maintenance while a request is active. pre_req() can be called while a request is active to minimize latency to start next job. post_req() can be used after the next job is started to clean up the request. This will minimize the host driver request end latency. post_req() is typically used before ending the block request and handing over the buffer to the block layer. Add a host-private member in mmc_data to be used by pre_req to mark the data. The host driver will then check this mark to see if the data is prepared or not. Signed-off-by: NPer Forlin <per.forlin@linaro.org> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NVenkatraman S <svenkatr@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Adrian Hunter 提交于
Some host controllers will not operate without a hardware timeout that is limited in value. However large discards require large timeouts, so there needs to be a way to specify the maximum discard size. A host controller driver may now specify the maximum discard timeout possible so that max_discard_sectors can be calculated. However, for eMMC when the High Capacity Erase Group Size is not in use, the timeout calculation depends on clock rate which may change. For that case Preferred Erase Size is used instead. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 14 7月, 2011 1 次提交
-
-
由 Philip Rakity 提交于
On reading the ext_csd for the first time (in 1 bit mode), save the ext_csd information needed for bus width compare. On every pass we make re-reading the ext_csd, compare the data against the saved ext_csd data. This fixes a regression introduced in 3.0-rc1 by 08ee80cc ("mmc: core: eMMC bus width may not work on all platforms"), which incorrectly assumed we would be re-reading the ext_csd at resume- time. Signed-off-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 26 6月, 2011 3 次提交
-
-
由 Adrian Hunter 提交于
The erase timeout calculation may depend on clock rate which is zero if the clock is gated, so use mmc_host_clk_rate() which allows for that case. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Daniel Drake 提交于
mmc_sdio_power_restore() skips some steps that are performed in other power-related codepaths which are necessary to fully reset the card. Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5. Signed-off-by: NDaniel Drake <dsd@laptop.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ohad Ben-Cohen 提交于
After commit e1866b33 "PM / Runtime: Rework runtime PM handling during driver removal" was introduced, the driver core stopped incrementing the runtime PM usage counter of the device during the invocation of the ->remove() callback. This indirectly broke SDIO's runtime PM path during driver removal, because no one calls _put_sync() anymore after ->remove() completes. This means that the power of runtime-PM-managed SDIO cards is kept high after their driver is removed (even if it was powered down beforehand). Fix that by directly calling _put_sync() when the last usage counter is downref'ed by the SDIO bus. Reported-and-tested-by: NDaniel Drake <dsd@laptop.org> Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 26 5月, 2011 2 次提交
-
-
由 Philip Rakity 提交于
CMD19 -- The offical way to validate bus widths from the JEDEC spec does not work on all platforms. Some platforms that use PCI/PCIe to connect their SD controllers are known to fail. If the quirk MMC_BUS_WIDTH_TEST is not defined we try to figure out the bus width by reading the ext_csd at different bus widths and compare this against the ext_csd read in 1 bit mode. If no ext_csd is available we default to 1 bit operations. Code has been tested on mmp2 against 8 bit eMMC and Transcend 2GB card that is known to not work in 4 bit mode. The physical pins on the card are not present to support 4 bit operation. Signed-off-by: NPhilip Rakity <prakity@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andrei Warkentin 提交于
SD cards operating at UHS104 or better support SET_BLOCK_COUNT. Signed-off-by: NAndrei Warkentin <andreiw@motorola.com> Reviewed-by: NArindam Nath <arindam.nath@amd.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 25 5月, 2011 27 次提交
-
-
由 Jaehoon Chung 提交于
mmc_rescan_try_freq() tries to init two times with the last frequency. For example, if host->f_min is 400KHz, we see the message below: mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz mmc1: mmc_rescan_try_freq: trying to init card at 400000 Hz Andy Ross says that he didn't try this code on a board with an f_min that exactly matches one of the table entries, which explains why the bug wasn't detected. Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Andy Ross <andy.ross@windriver.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Philip Rakity 提交于
eMMC voltage change not required for 1.8V. 3.3V and 1.8V vcc are capable of doing DDR. vccq of 1.8v is not required. Signed-off-by: NPhilip Rakity <prakity@marvell.com> Reviewed-by: NArindam Nath <arindam.nath@amd.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Philip Rakity 提交于
eMMC chips do not use CMD11 when changing voltage. Add extra argument to call to indicate if CMD11 needs to be sent. Signed-off-by: NPhilip Rakity <prakity@marvell.com> Reviewed-by: NArindam Nath <arindam.nath@amd.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Eliad Peller 提交于
Since the MMC_PM_KEEP_POWER flag should be set on each suspend, it should also cleared on each resume. Upon resuming, we have to know if power was kept (for re-initialization, etc.), so clear it just after resuming. Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Stefan Nilsson XK 提交于
If there is only 1 function interrupt registered it is possible to improve performance by directly calling the irq handler and avoiding the overhead of reading the CCCR registers. Signed-off-by: NPer Forlin <per.forlin@linaro.org> Acked-by: NUlf Hansson <ulf.hansson@stericsson.com> Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
According to the Host Controller spec v3.00, setting Preset Value Enable in the Host Control2 register lets SDCLK Frequency Select, Clock Generator Select and Driver Strength Select to be set automatically by the Host Controller based on the UHS-I mode set. This patch enables this feature. Since Preset Value Enable makes sense only for UHS-I cards, we enable this feature after successfull UHS-I initialization. We also reset Preset Value Enable next time before initialization. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
Host Controller needs tuning during initialization to operate SDR50 and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is indicated by bit 45 of the Host Controller Capabilities register. A new command CMD19 has been defined in the Physical Layer spec v3.01 to request the card to send tuning pattern. We enable Buffer Read Ready interrupt at the very begining of tuning procedure, because that is the only interrupt generated by the Host Controller during tuning. We program the block size to 64 in the Block Size register. We make sure that DMA Enable and Multi Block Select in the Transfer Mode register are set to 0 before actually sending CMD19. The tuning block is sent by the card to the Host Controller using DAT lines, so we set Data Present Select (bit 5) in the Command register. The Host Controller is responsible for doing the verfication of tuning block sent by the card at the hardware level. After sending CMD19, we wait for Buffer Read Ready interrupt. In case we don't receive an interrupt after the specified timeout value, we fall back on fixed sampling clock by setting Execute Tuning (bit 6) and Sampling Clock Select (bit 7) of Host Control2 register to 0. Before exiting the tuning procedure, we disable Buffer Read Ready interrupt and re-enable other interrupts. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
Since only UHS-I cards respond with S18A set in response to ACMD41, we set the card as ultra-high-speed after successfull initialization. We need to decide whether a card is SDXC based on the C_SIZE field of CSDv2.0 register. According to Physical Layer spec v3.01, the minimum value of C_SIZE for SDXC card is 00FFFFh. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
We decide on the current limit to be set for the card based on the Capability of Host Controller to provide current at 1.8V signalling, and the maximum current limit of the card as indicated by CMD6 mode 0. We then set the current limit for the card using CMD6 mode 1. As per the Physical Layer Spec v3.01, the current limit switch is only applicable for SDR50, SDR104, and DDR50 bus speed modes. For other UHS-I modes, we set the default current limit of 200mA. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
This patch adds support for setting UHS-I bus speed mode during UHS-I initialization procedure. Since both the host and card can support more than one bus speed, we select the highest speed based on both of their capabilities. First we set the bus speed mode for the card using CMD6 mode 1, and then we program the host controller to support the required speed mode. We also set High Speed Enable in case one of the UHS-I modes is selected. We take care to reset SD clock before setting UHS mode in the Host Control2 register, and then re-enable it as per the Host Controller spec v3.00. We then set the clock frequency for the UHS-I mode selected. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
This patch adds support for setting driver strength during UHS-I initialization procedure. Since UHS-I cards set S18A (bit 24) in response to ACMD41, we use this as a base for UHS-I initialization. We modify the parameter list of mmc_sd_get_cid() so that we can save the ROCR from ACMD41 to check whether bit 24 is set. We decide whether the Host Controller supports A, C, or D driver type depending on the Capabilities register. Driver type B is suported by default. We then set the appropriate driver type for the card using CMD6 mode 1. As per Host Controller spec v3.00, we set driver type for the host only if Preset Value Enable in the Host Control2 register is not set. SDHCI_HOST_CONTROL has been renamed to SDHCI_HOST_CONTROL1 to conform to the spec. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
SD cards which conform to Physical Layer Spec v3.01 can support additional Bus Speed Modes, Driver Strength, and Current Limit other than the default values. We use CMD6 mode 0 to read these additional card functions. The values read here will be used during UHS-I initialization steps. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Arindam Nath 提交于
Host Controller v3.00 adds another Capabilities register. Apart from other things, this new register indicates whether the Host Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec doesn't mention about explicit support for SDR12 and SDR25 UHS-I modes, so the Host Controller v3.00 should support them by default. Also if the controller supports SDR104 mode, it will also support SDR50 mode as well. So depending on the host support, we set the corresponding MMC_CAP_* flags. One more new register. Host Control2 is added in v3.00, which is used during Signal Voltage Switch procedure described below. Since as per v3.00 spec, UHS-I supported hosts should set S18R to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also need to set XPC (bit 28) of OCR in case the host can supply >150mA. This support is indicated by the Maximum Current Capabilities register of the Host Controller. If the response of ACMD41 has both CCS and S18A set, we start the signal voltage switch procedure, which if successfull, will switch the card from 3.3V signalling to 1.8V signalling. Signal voltage switch procedure adds support for a new command CMD11 in the Physical Layer Spec v3.01. As part of this procedure, we need to set 1.8V Signalling Enable (bit 3) of Host Control2 register, which if remains set after 5ms, means the switch to 1.8V signalling is successfull. Otherwise, we clear bit 24 of OCR and retry the initialization sequence. When we remove the card, and insert the same or another card, we need to make sure that we start with 3.3V signalling voltage. So we call mmc_set_signal_voltage() with MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling voltage before we actually start initializing the card. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: NArindam Nath <arindam.nath@amd.com> Reviewed-by: NPhilip Rakity <prakity@marvell.com> Tested-by: NPhilip Rakity <prakity@marvell.com> Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 John Calixto 提交于
Allows appropriately-privileged applications to send CMD (normal) and ACMD (application-specific; preceded with CMD55) commands to cards/devices on the mmc bus. This is primarily useful for enabling the security functionality built in to every SD card. It can also be used as a generic passthrough (e.g. to enable virtual machines to control mmc bus devices directly). However, this use case has not been tested rigorously. Generic passthrough testing was only conducted for a few non-security opcodes to prove the feasibility of the passthrough. Since any opcode can be sent using this passthrough, it is very possible to render the card/device unusable. Applications that use this ioctl must have CAP_SYS_RAWIO. Security commands tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC, TI OMAP3621/OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC. Signed-off-by: NJohn Calixto <john.calixto@modsystems.com> Reviewed-by: NAndrei Warkentin <andreiw@motorola.com> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Chris Ball 提交于
Converts from: struct mmc_request mrq; memset(&mrq, 0, sizeof(struct mmc_request)); to: struct mmc_request mrq = {0}; because it's shorter, as performant, and easier to work out whether initialization has happened. Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Chris Ball 提交于
Converts from: struct mmc_data data; memset(&data, 0, sizeof(struct mmc_data)); to: struct mmc_data data = {0}; because it's shorter, as performant, and easier to work out whether initialization has happened. Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Chris Ball 提交于
Converts from: struct mmc_command cmd; memset(&cmd, 0, sizeof(struct mmc_command)); to: struct mmc_command cmd = {0}; because it's shorter, as performant, and easier to work out whether initialization has happened. Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Chris Ball 提交于
mmc_send_if_cond did not zero out mmc_command on stack. Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andrei Warkentin 提交于
mmc_cmd_app did not zero out mmc_command on stack. Reported-by: NChuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: NAndrei Warkentin <andreiw@motorola.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andrei Warkentin 提交于
Allows device MMC boot partitions to be accessed. MMC partitions are treated effectively as separate block devices on the same MMC card. Signed-off-by: NAndrei Warkentin <andreiw@motorola.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andrei Warkentin 提交于
CMD6 is an R1B-type command, where DAT is used as busy. Depending on register written using CMD6, timeout value can be different as per spec. Signed-off-by: NAndrei Warkentin <andreiw@motorola.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andrei Warkentin 提交于
Renames erase_timeout to cmd_timeout_ms inside struct mmc_command. First step to making host honor timeouts for non-data-transfer commands. Cleans up erase timeout code. Signed-off-by: NAndrei Warkentin <andreiw@motorola.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Andrei Warkentin 提交于
The current mechanism is SDIO-only. This allows us to create function-specific quirks, without creating messy Kconfig dependencies, or polluting core/ with function-specific code. Signed-off-by: NAndrei Warkentin <andreiw@motorola.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Wolfram Sang 提交于
led_trigger_register_simple() allocates memory which must not be leaked in the error-path of mmc_add_host. Move it past the only error-check in the function. Signed-off-by: NWolfram Sang <w.sang@pengutronix.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ohad Ben-Cohen 提交于
The wl12xx device supports disconnecting the pull-up resistor on CD/DAT[3] (pin 1) of the card. Tell SDIO core to disconnect that resistor during card init, since we don't need it at that point (and anyway all hosts shall provide pull-up resistors on all data lines DAT[3:0] as described in section 6 of the SD physical specification). As a result, this may save some power, but it's also generally healthy since it prevents both ends from pulling up that pin, which results in undesirable asymmetric physical bus. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ohad Ben-Cohen 提交于
006ebd5d introduced sdio_disable_cd(), which disconnects the pull-up resistor on CD/DAT[3] (pin 1) of the card. Make it possible to start using sdio_disable_cd() by introducing MMC_QUIRK_DISABLE_CD. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ohad Ben-Cohen 提交于
Tell SDIO core to ignore the standard SDIO function interface codes indicated by the wl1271. This is required because the wl1271 erroneously indicates its first function as a standard Bluetooth SDIO interface, and that drives btsdio mad. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-