12e626dd0ef04c2e43a193b623a914745e1fd1e9 |
|
04-Dec-2008 |
San Mehat <san@android.com> |
mmc: sd: Add retries in re-detection Signed-off-by: San Mehat <san@android.com> mmc: sd: Remove debugging printk Signed-off-by: Dima Zavin <dima@android.com>
|
65a213ff7fcec3c901d1aa929008d98ed35ed866 |
|
01-Dec-2008 |
San Mehat <san@android.com> |
mmc: sd: When resuming, try a little harder to init the card Signed-off-by: San Mehat <san@android.com>
|
9faee2387ae0ba36f1db00b55337990bbc89ca3e |
|
11-Nov-2008 |
San Mehat <san@google.com> |
mmc: sd: Add new CONFIG_MMC_PARANOID_SD_INIT for enabling retries during SD detection Signed-off-by: San Mehat <san@google.com>
|
6606110d89aefcb21b9e70adfe064987cbd8393a |
|
12-Sep-2014 |
Joe Perches <joe@perches.com> |
mmc: Convert pr_warning to pr_warn Use the much more common pr_warn instead of pr_warning. Other miscellanea: o Coalesce formats o Realign arguments o Remove extra spaces when coalescing formats Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
3d705d14fe4c72be83bae1610680e209ee226b9d |
|
19-Aug-2014 |
Sascha Hauer <s.hauer@pengutronix.de> |
mmc: implement Driver Stage Register handling Some eMMC and SD cards implement a DSR register that allows to tune raise/fall times and drive strength of the CMD and DATA outputs. The values to use depend on the card in use and the host. It might be needed to reduce the drive strength to prevent voltage peaks above the host's specification. Implement a 'dsr' devicetree property that allows to specify the value to set the DSR to. For non-dt setups the new members of mmc_host can be set by board code. This patch was initially authored by Sascha Hauer. It contains improvements authored by Markus Niebel and Uwe Kleine-König. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
cdc991790c51c693d0c347a5286af017826a5d01 |
|
23-Apr-2014 |
Seungwon Jeon <tgih.jun@samsung.com> |
mmc: drop the speed mode of card's state Timing mode identifier has same role and can take the place of speed mode. This change removes all related speed mode. Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
|
d1e58212caa4fdd95dfb003ba6e90aa0c9c1ac03 |
|
08-Mar-2014 |
Axel Lin <axel.lin@ingics.com> |
mmc: Convert to use ATTRIBUTE_GROUPS Use new ATTRIBUTE_GROUPS macro to declare attribute groups. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
|
2501c9179dff2add6aadd3898cd729e94e777d3a |
|
30-Oct-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Use MMC_UNSAFE_RESUME as default behavior Invoking system suspend or shutdown without using the Kconfig option MMC_UNSAFE_RESUME, did trigger an ungraceful power cut of the card. To improve the situation, change the behavior to always make use of the available bus_ops callbacks that handles system suspend and shutdown properly. By changing the behavior MMC_UNSAFE_RESUME becomes redundant, so lets's remove it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
|
9288cac05405a7da406097a44721aa4004609b4d |
|
26-Nov-2013 |
Wolfram Sang <wsa@the-dreams.de> |
mmc: core: sd: implement proper support for sd3.0 au sizes This reverts and updates commit 77776fd0a4cc541b9 ("mmc: sd: fix the maximum au_size for SD3.0"). The au_size for SD3.0 cannot be achieved by a simple bit shift, so this needs to be implemented differently. Also, don't print the warning in case of 0 since 'not defined' is different from 'invalid'. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: stable <stable@vger.kernel.org> # [3.12, 3.13] Signed-off-by: Chris Ball <chris@printf.net>
|
4d22378221bd0ed69c2e99408d31c108d72aeb80 |
|
10-Oct-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Add MMC_CAP_RUNTIME_RESUME to resume at runtime_resume In some environments it is to prefer to postpone the resume of the card device until runtime_resume is being carried out, since it will mean a signficant decrease of the total system resume time. The reason of the decreased resume time is simply because of the actual re-initalization of the card, which typically takes hundreds of milliseconds, is performed outside the resume sequence and wont thus affect it. For removable card, the detect work tries to re-detect the card to make sure it is still present, as a part of that sequence the card will also be runtime_resumed and thus also fully resumed. For a non-removable card, typically a mmc blk request will trigger a runtime_resume and thus fully resume the card. This also means the first request will likely suffer from an inital latency since the re-initialization of the card needs to be performed. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
0cb403a227774f60f6f52137ca3618805498c4e6 |
|
10-Oct-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Improve runtime PM support during suspend/resume for sd/mmc The card device is considered as in-active after it has been suspended. To prevent any further runtime PM requests in suspend state, we then disable runtime PM. After the card device has been resumed, we shall consider it as active, like we also do after a probe sequence. When resumed, we can safely enable runtime PM again. This will make sure the PM core can request the card device to go to in-active state after a resume has been completed. Previously we had to wait for new pm_runtime_get->pm_runtime_put cycle to be executed. Additionally, once a resume has been carried out, update the last busy mark. At the moment this will have no effect but if the PM core will respect autosuspend enabled devices, when it directly triggers a runtime_suspend from a runtime_idle, it will mean the card device will be scheduled for a delayed runtime_suspend instead of done immediately. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
0cc81a8c6442e43618ff245948bfaa14fdf7938b |
|
03-Oct-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Remove redundant mmc_power_up|off at runtime callbacks Commit "mmc: core: Push common suspend|resume code into each bus_ops" moved the responsibility for doing mmc_power_up|off into each suspend/resume bus_ops. When using MMC_CAP_AGGRESSIVE_PM, through the runtime callbacks, calls to mmc_power_up|off became redundant. When removing them, we are also able to remove the calls to mmc_claim|release_host, thus simplifing code a bit more. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
9ec775f7efd6d17084b4f361804d2030d50fca0e |
|
02-Oct-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: Don't force card to active state when entering suspend/shutdown By adding a card state that records if it is suspended or resumed, we can accept asyncronus suspend/resume requests for the mmc and sd bus_ops. MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime bus_ops callbacks, execute a suspend of the the card. In the state were this has been done, we can receive a suspend request for the mmc bus, which for sd and mmc forced the card to active state by a pm_runtime_get_sync. In other words, the card was resumed and then immediately suspended again, completely unnecessary. Since the suspend/resume bus_ops callbacks for sd and mmc are now capable of handling asynchronous requests, we no longer need to force the card to active state before executing suspend. Evidently preventing the above sequence for MMC_CAP_AGGRESSIVE_PM. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
726d6f2374410d980341bfeb49399614e689e702 |
|
16-Sep-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Collect common code for card ocr validation Since mmc_select_voltage now only gets called from the attach sequence, it makes sense to move the out of spec validations of the card ocr into this function. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
ce69d37b7d8fa692c45d71d94aa0c921859b82ce |
|
16-Sep-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Prevent violation of specs while initializing cards According to eMMC/SD/SDIO specs, the VDD (VCC) voltage level must be maintained during the initialization sequence. If we want/need to tune the voltage level, a complete power cycle of the card must be executed. Most host drivers conforms to the specifications by only allowing to change VDD voltage level at the MMC_POWER_UP state, but some also cares about MMC_POWER_ON state, which they should'nt. This patch will not break those drivers, but they could clean up code to better reflect what is expected from the protocol layer. A big re-work of the mmc_select_voltage function is done to only change VDD voltage level if the host supports MMC_CAP2_FULL_PWR_CYCLE. Otherwise only validation of the host and card ocr mask will be done. A very nice side-effect of this patch is that we now don't need to reset the negotiated ocr mask at the mmc_power_off function, since now it will actually reflect the present voltage level, which safely can be used at the next power up and re-initialization. Moreover, we then only need to execute mmc_select_voltage from the attach sequence. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
6904115095ad60ced638eb1e36e0e4e5e7de00b0 |
|
13-Sep-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Move cached value of the negotiated ocr mask to card struct The negotiated ocr mask is directly related to the card. Once a card gets removed, the mask shall be dropped. By moving the cache of the ocr mask from the host struct to the card struct we have accomplished this. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
0f791fdad82a02af013e4fc8c385dc690080c366 |
|
12-Sep-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Let mmc_set_signal_voltage take ocr as parameter This is yet another step of restructure code to be able to fixup the setup of the negotiated ocr mask. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
4a065193c46a16f1ddf20622c7011c8f327e0478 |
|
12-Sep-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Let mmc_power_up|cycle take ocr as parameter As a step to fixup the setup of the negotiated ocr mask, we need the mmc_power_up|cycle functions to take the ocr as a parameter. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
77776fd0a4cc541b9a528eacc1d31ca47eb1ae7a |
|
18-Jul-2013 |
Jaehoon Chung <jh80.chung@samsung.com> |
mmc: sd: fix the maximum au_size for SD3.0 Since SD Physical Layer specification V3.0, AU_SIZE is supported up to 0xf. So If SD-card is supported v3.0, then max_au should be 0xf. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
7fca96758e977497c67a424006c60aaf2d3db212 |
|
17-Jul-2013 |
Wei WANG <wei_wang@realsil.com.cn> |
mmc: core: free mmc_card if cmd 3,9,7 fails in mmc_sd_init_card In function mmc_sd_init_card, if command 3/9/7 got failed, mmc_card allocated just before won't be freed. This would cause memory leak. Signed-off-by: Wei WANG <wei_wang@realsil.com.cn> Signed-off-by: Chris Ball <cjb@laptop.org>
|
5992e78697484d8f58b749f87a06f89f4ba40a47 |
|
10-Jun-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Add shutdown callback for SD bus_ops For the SD .shutdown callback we re-use the SD suspend function since it performs the relevant actions. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
74590263384e5d4601de7f0ee2790477578829ea |
|
10-Jun-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Push common suspend|resume code into each bus_ops By moving code from the mmc_suspend|resume_host down into each .suspend|resume bus_ops callback, we get a more flexible solution. Some nice side effects are that we get a better understanding of each bus_ops suspend|resume sequence and the common code don't have to take care of specific corner cases, especially for the SDIO case. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
c4d770d72492df510077b277f21ac5f0dad9e5eb |
|
02-May-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: core: Support aggressive power management for (e)MMC/SD Aggressive power management is suitable when saving power is essential. At request inactivity timeout, aka pm runtime autosuspend timeout, the card will be suspended. Once a new request arrives, the card will be re-initalized and thus the first request will suffer from a latency. This latency is card-specific, experiments has shown in general that SD-cards has quite poor initialization time, around 300ms-1100ms. eMMC is not surprisingly far better but still a couple of hundreds of ms has been observed. Except for the request latency, it is important to know that suspending the card will also prevent the card from executing internal house-keeping operations in idle mode. This could mean degradation in performance. To use this feature make sure the request inactivity timeout is chosen carefully. This has not been done as a part of this patch. Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and by setting CONFIG_MMC_UNSAFE_RESUME. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
e94cfef698aae6b209d8918dd319312e4b02118d |
|
02-May-2013 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: block: Enable runtime pm for mmc blkdevice Once the mmc blkdevice is being probed, runtime pm will be enabled. By using runtime autosuspend, the power save operations can be done when request inactivity occurs for a certain time. Right now the selected timeout value is set to 3 s. Obviously this value will likely need to be configurable somehow since it needs to be trimmed depending on the power save algorithm. For SD-combo cards, we are still leaving the enablement of runtime PM to the SDIO init sequence since it depends on the capabilities of the SDIO func driver. Moreover, when the blk device is being suspended, we make sure the device will be runtime resumed. The reason for doing this is that we want the host suspend sequence to be unaware of any runtime power save operations done for the card in this phase. Thus it can just handle the suspend as the card is fully powered from a runtime perspective. Finally, this patch prepares to make it possible to move BKOPS handling into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be accomplished. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
810e08ee425f8d7327e4b30069a9b2b3dccfc67d |
|
17-Apr-2013 |
Fredrik Soderstedt <fredrik.soderstedt@stericsson.com> |
mmc: core: Only execute tuning for SDR50 and SDR104 Only execute tuning for sd and sdio devices that are using SDR50 or SDR104. Make sure clock is hold during tuning for sdio devices. Signed-off-by: Fredrik Soderstedt <fredrik.soderstedt@stericsson.com> Acked-by: Johan Rudholm <jrudholm@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
52983382c74f59a3953e622d7661a24e1bc4388a |
|
31-Jan-2013 |
Kevin Liu <kliu5@marvell.com> |
mmc: sdhci: enhance preset value function 4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization") added preset value support and enabled it by default during sd card init. Below are the enhancements introduced by this patch: 1. In current code, preset value is enabled after setting clock finished, which means the clock is manually set by driver firstly and then suddenly switched to preset value at this point. So the first setting is useless and unnecessary. What's more, the first clock setting may differ from the preset one. The better way is enable preset value just after switch to UHS mode so the preset value can take effect immediately. So move preset value enable from mmc_sd_init_card to sdhci_set_ios which will be called during set timing. 2. In current code, preset value is disabled at the beginning of mmc_attach_sd. It's too late since low freq (400khz) should be set in mmc_power_up. So move preset value disable to sdhci_set_ios which will be called during power up. 3. host->clock and ios->drv_type should also be updated according to the preset value if it's enabled. Current code missed this. 4. This patch also introduce a quirk to disable preset value in case preset value doesn't work. This patch has been verified on sdhci-pxav3 platform with both preset enabled and disabled. Signed-off-by: Kevin Liu <kliu5@marvell.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
0797e5f1453b2bedc08bbcbea0ea4fbe20350823 |
|
28-Jan-2013 |
Johan Rudholm <johan.rudholm@stericsson.com> |
mmc: core: Fixup signal voltage switch When switching SD and SDIO cards from 3.3V to 1.8V signal levels, the clock should be gated for 5 ms during the step. After enabling the clock, the host should wait for at least 1 ms before checking for failure. Failure by the card to switch is indicated by dat[0:3] being pulled low. The host should check for this condition and power-cycle the card if failure is indicated. Add a retry mechanism for the SDIO case. If the voltage switch fails repeatedly, give up and continue the initialization using the original voltage. This patch places a couple of requirements on the host driver: 1) mmc_set_ios with ios.clock = 0 must gate the clock 2) mmc_power_off must actually cut the power to the card 3) The card_busy host_ops member must be implemented if these requirements are not fulfilled, the 1.8V signal voltage switch will still be attempted but may not be successful. Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com> Signed-off-by: Kevin Liu <kliu5@marvell.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wei WANG <wei_wang@realsil.com.cn> Signed-off-by: Chris Ball <cjb@laptop.org>
|
567c89032cfdda8047562abe450947ac01f2d3c7 |
|
28-Jan-2013 |
Johan Rudholm <johan.rudholm@stericsson.com> |
mmc: core: Break out start_signal_voltage_switch Allow callers to access the start_signal_voltage_switch host_ops member without going through any cmd11 logic. This is mostly a preparation for the following signal voltage switch patch. Also, reset ios.signal_voltage to its original value if start_signal_voltage_switch fails. Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wei WANG <wei_wang@realsil.com.cn> Signed-off-by: Chris Ball <cjb@laptop.org>
|
3f8a7fabd60e83eb2fb7add00d353d455c0e7a78 |
|
28-Jan-2013 |
Johan Rudholm <johan.rudholm@stericsson.com> |
mmc: sd: Simplify by using mmc_host_uhs Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
108ecc4cf9c46a4caabaf18efc42d19818c95b70 |
|
10-Jul-2012 |
Aaron Lu <aaron.lu@amd.com> |
mmc: core: reset signal voltage on power up Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in mmc_power_up so that we do not need to touch signal voltage setting in mmc/sd/sdio init functions and rescan function. For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe resume case, the card will lose its power and when powered on again, we will set signal voltage to 3.3v in mmc_power_up before its resume function gets called, which will re-init the card. And for sdio cards, when doing a suspend/resume cycle, consider the unsafe resume case, the card will either lose its power or not depending on if it wants to wakeup the host. If power is not maintained, it is the same case as mmc/sd cards. If power is maintained, mmc_power_up will not be called and the card's signal voltage will remain at the last setting. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Tested-by: Venkatraman S <svenkatr@ti.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
55c4665ea0a42fd6427826bfce96eb4b0389262a |
|
04-Jul-2012 |
Aaron Lu <aaron.lu@amd.com> |
mmc: sd: Fix sd current limit setting Host has different current capabilities at different voltages, we need to record these settings seperately. The defined voltages are 1.8/3.0/3.3. For other voltages, we do not touch current limit setting. Before we set the current limit for the sd card, find out the host's operating voltage first and then find out the current capabilities of the host at that voltage to set the current limit. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
a39ca6ae0a08994a59d017a445939e164bc77fd5 |
|
03-Jul-2012 |
Aaron Lu <aaron.lu@amd.com> |
mmc: core: Simplify and fix for SD switch processing In mmc_read_switch, just do a one time mode 0 switch command to get the support bits information, no need to do multiple times as the support bits do not change with different arguments. And no need to check current limit support bits, as these bits are fixed according to the signal voltage. If the signal voltage is 1.8V, the support bits would be 0xf and if the signal voltage is 3.3V, the support bits would be 0x01. We will check host's ability to set the current limit. Signed-off-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
b63b5e819d5b21ae493c17c356018ffa98d3ee1c |
|
02-Jul-2012 |
Alan Cox <alan@linux.intel.com> |
mmc: core: correct invalid error checking The effect of the existing code is that we continue blindly when we should warn about an invalid allocation unit. Reported-by: dcb314@hotmail.com Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44061 Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
0aa6770000bafa65c17cf44b6619d328d4fc79b3 |
|
28-May-2012 |
Philip Rakity <prakity@marvell.com> |
mmc: sdhci: only set 200mA support for 1.8v if 200mA is available max_current_caps can return 0 if not available from the sd controller. If no regulator is present or the regulator specifies a current less then 200ma, we no longer still set the 200mA caps bit anyway. Signed-off-by: Philip Rakity <prakity@marvell.com> Reviewed-by: Aaron Lu <aaron_lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
85e727edb963459d13cdd9ce84c335d251a005a7 |
|
31-May-2012 |
Jaehoon Chung <jh80.chung@samsung.com> |
mmc: core: return an error on suspend if mmc_deselect_cards fails When mmc_host is not spi mode, mmc/sd is doing mmc_deselect_cards(). mmc_deselect_cards could be returned error. If returned error, we can know something wrong when enter suspend. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
e7747475b61fdc2a4a412475a9d64d8c309916e3 |
|
01-Mar-2012 |
Ulf Hansson <ulf.hansson@stericsson.com> |
mmc: core: Fixup suspend/resume issues for UHS-I cards Even if cards supports 1.8V I/O voltage those should anyway be initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs. Some eMMC and embedded SDIO devices are able to be initialized at 1.8V as well, but it is better to be safe. Do note that initialization in this context means that the card has been completely powered off, otherwise the card will remain at the last I/O voltage level that were negotitiated. Due to the above being taken care of the suspend/resume issues for UHS-I SD-cards has been fixed. Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com> Acked-by: Philip Rakity <prakity@marvell.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
2c4967f741e87cdd63de7271b97807041dccbf3b |
|
04-Feb-2012 |
Sujit Reddy Thumma <sthumma@codeaurora.org> |
mmc: core: Ensure clocks are always enabled before host interaction Ensure clocks are always enabled before any interaction with the host controller driver. This makes sure that there is no race between host execution and the core layer turning off clocks in different context with clock gating framework. Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Per Forlin <per.forlin@stericsson.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
a4924c71aa43d4f8a3f342b1f71788349472e684 |
|
11-Jan-2012 |
Girish K S <girish.shivananjappa@linaro.org> |
mmc: core: HS200 mode support for eMMC 4.5 This patch adds the support of the HS200 bus speed for eMMC 4.5 devices. The eMMC 4.5 devices have support for 200MHz bus speed. The function prototype of the tuning function is modified to handle the tuning command number which is different in sd and mmc case. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
d30495048892980e5d453328d1cc9343b3f7e917 |
|
28-Nov-2011 |
Adrian Hunter <adrian.hunter@intel.com> |
mmc: allow upper layers to know immediately if card has been removed Add a function mmc_detect_card_removed() which upper layers can use to determine immediately if a card has been removed. This function should be called after an I/O request fails so that all queued I/O requests can be errored out immediately instead of waiting for the card device to be removed. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
a303c5319c8e6ab0e744ebca118da8420043b2c3 |
|
15-Nov-2011 |
Philip Rakity <prakity@marvell.com> |
mmc: sdio: support SDIO UHS cards This patch adds support for sdio UHS cards per the version 3.0 spec. UHS mode is only enabled for version 3.0 cards when both the host and the controller support UHS modes. 1.8v signaling support is removed if both the card and the host do not support UHS. This is done to maintain compatibility and some system/card combinations break when 1.8v signaling is enabled when the host does not support UHS. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Aaron Lu <Aaron.lu@amd.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Tested-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
fffe5d5aa05b4e69f79bc75a51c5ee0fc6203fa5 |
|
08-Nov-2011 |
Qiang Liu <qiang.liu@freescale.com> |
mmc: sd: Macro name cleanup for high speed dtr Add new macros for the high speed 50MHz case, rather than having a confusing reuse of the value for UHS SDR50, which is 100MHz. Reported-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
0205a904df57bf2ed79571fe097b99d2940659b1 |
|
15-Jul-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
mmc: Fix implicit use of stat.h header in associated files Once the implicit use of module.h is prevented, these files will fail to find the stat.h header content. Fix up the implicit usage expectations in advance of the cleanup. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
f2815f68dabbb373fd1c9f0fd4a609d486697c2b |
|
10-Aug-2011 |
Subhash Jadavani <subhashj@codeaurora.org> |
mmc: sd: Handle SD3.0 cards not supporting UHS-I bus speed mode Here is Essential conditions to indicate Version 3.00 Card (SD_SPEC=2 and SD_SPEC3=1) : (1) The card shall support CMD6 (2) The card shall support CMD8 (3) The card shall support CMD42 (4) User area capacity shall be up to 2GB (SDSC) or 32GB (SDHC) User area capacity shall be more than or equal to 32GB and up to 2TB (SDXC) (5) Speed Class shall be supported (SDHC or SDXC) So even if SD card doesn't support any of the newly defined UHS-I bus speed mode, it can advertise itself as SD3.0 cards as long as it supports all the essential conditions of SD3.0 cards. Given this, these type of cards should atleast run in High Speed mode @50MHZ if it supports HS. But current initialization sequence for SD3.0 cards is such that these non-UHS-I SD3.0 cards runs in Default Speed mode @25MHz. This patch makes sure that these non-UHS-I SD3.0 cards run in High Speed Mode @50MHz. Tested this patch with SanDisk Extreme SDHC 8GB Class 10 card. Reported-by: "Hiremath, Vaibhav" <hvaibhav@ti.com> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
a3c76eb9d4a1e68a69dd880cf0bcb8a52418b993 |
|
11-Oct-2011 |
Girish K S <girish.shivananjappa@linaro.org> |
mmc: replace printk with appropriate display macro All the files using printk function for displaying kernel messages in the mmc driver have been replaced with corresponding macro. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
44669034815a7ad263542ac605c581a10b22d146 |
|
15-Sep-2011 |
Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com> |
mmc: core: Set correct bus mode before card init Earlier all cards where initiated with bus mode set as OPENDRAIN, and then later switched to PUSHPULL. According to the MMC/SD/SDIO specifications only MMC cards use OPENDRAIN during init. For both SD and SDIO the bus mode shall be PUSHPULL before attempting to init the card. The consequence of having incorrect bus mode can lead to not being able to detect the card. Therefore the default behavior have now been changed to PUSHPULL in mmc_power_up, and will only be temporarily switched when trying to attach or init a MMC card. Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com> Signed-off-by: Ulf HANSSON <ulf.hansson@stericsson.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
7f7e4129c23f0419257184dff6fec89d2d5a8964 |
|
21-Sep-2011 |
Ulf Hansson <ulf.hansson@stericsson.com> |
mmc: core: Fix hangs related to insert/remove of cards During a rescan operation mmc_attach(sd|mmc|sdio) functions are called. The error handling in these function can trigger a detach of the bus, which also meant a power off. This is not notified by the rescan operation which then continues to the next attach function. If a power off has been done, the framework must never send any new commands to the host driver, without first doing a new power up. This will most likely trigger any host driver to hang. Moving power off out of detach and instead handle power off separately when it is actually needed, solves the issue. Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: <stable@kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
93c712f99d8e412b2d297edfe9f59b90636897c1 |
|
08-Aug-2011 |
Subhash Jadavani <subhashj@codeaurora.org> |
mmc: sd: UHS-I bus speed should be set last in UHS initialization mmc_sd_init_uhs_card function sets the driver type, current limit and bus speed mode on card as well as on host controller side. Currently bus speed mode is set by sending CMD6 to card and immediately setting the timing mode in host controller. But then before initiating tuning sequence, it also tries to set current limit by sending CMD6 to card which results in data timeout errors in controller if bus speed mode is SDR50/SDR104 mode. So basically bus speed mode should be set only after current limit is set in the card and immediately after setting the bus speed mode, tuning sequence should be initiated. Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
ca8e99b32e3863c98ac958617cc157a00bf445b8 |
|
06-Jul-2011 |
Philip Rakity <prakity@marvell.com> |
mmc: core: Set non-default Drive Strength via platform hook 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: Philip Rakity <prakity@marvell.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
f0d89972b01798cf9d245dfa1cacfa0ee78a3593 |
|
23-May-2011 |
Andrei Warkentin <andreiw@motorola.com> |
mmc: core: Block CMD23 support for UHS104/SDXC cards. SD cards operating at UHS104 or better support SET_BLOCK_COUNT. Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
261bbd463a091b939770255d559bbc89b1bad568 |
|
13-May-2011 |
Philip Rakity <prakity@marvell.com> |
mmc: core: eMMC signal voltage does not use CMD11 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: Philip Rakity <prakity@marvell.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
4d55c5a13a189a80d40383f02c8026f9a87d7c87 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sdhci: enable preset value after uhs initialization 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
b513ea250eb7c36a8afb3df938d632ca6b4df7cd |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: add support for tuning during uhs initialization 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
3a3035114307cd55e024662bb295a87b849f0bd4 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: report correct speed and capacity of uhs cards 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
5371c927bcd06a5c9dd6785bab2d452b87d9abc6 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: set current limit for uhs cards 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
49c468fcf878d2c86e31920cf54aa90c88418a66 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: add support for uhs bus speed mode selection 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
d6d50a15a2897d4133d536dd4343b5cf21163db3 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: add support for driver type selection 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
013909c4ffd16ded4895528b856fd8782df04dc6 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: query function modes for uhs cards 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
f2119df6b764609af4baceb68caf1e848c1c8aa7 |
|
04-May-2011 |
Arindam Nath <arindam.nath@amd.com> |
mmc: sd: add support for signal voltage switch procedure 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: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
ce1014965ae2538e7447b19879bd0e8109690b79 |
|
10-Feb-2011 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
mmc: Ensure prototypes for SD API are visible in sd.c So we know the implementation and prototypes agree with each other. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Chris Ball <cjb@laptop.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
807e8e40673d9628fa7dcdd14423424b4ee5f43b |
|
03-Jan-2011 |
Andy Ross <andy.ross@windriver.com> |
mmc: Fix sd/sdio/mmc initialization frequency retries Rewrite and clean up mmc_rescan() to properly retry frequencies lower than 400kHz. Failures can happen both in sd_send_* calls and mmc_attach_*. Break out "mmc_rescan_try_freq" from the frequency selection loop. Symmetrize claim/release logic in mmc_attach_* API, and move the sd_send_* calls there to make mmc_rescan easier to read. Signed-off-by: Andy Ross <andy.ross@windriver.com> Reviewed-and-Tested-by: Hein Tibosch <hein_tibosch@yahoo.es> Reviewed-by: Chris Ball <cjb@laptop.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
8f230f454fe04ba326ffaead3a6b88dcf44eaf4b |
|
08-Dec-2010 |
Takashi Iwai <tiwai@suse.de> |
mmc: Add support for JMicron 388 SD/MMC controller JMicron 388 SD/MMC combo controller supports the 1.8V low-voltage for SD, but MMC doesn't work with the low-voltage, resulting in an error at probing. This patch adds the support for multiple voltage mask per device type, so that SD works with 1.8V while MMC forces 3.3V. Here new ocr_avail_* fields for each device are introduced, so that the actual OCR mask is switched dynamically. Also, the restriction of low-voltage in core/sd.c is removed when the bit is allowed explicitly via ocr_avail_sd mask. This patch was rewritten from scratch based on Aries' original code. Signed-off-by: Aries Lee <arieslee@jmicron.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Chris Ball <cjb@laptop.org> Signed-off-by: Chris Ball <cjb@laptop.org>
|
12ae637f081a7a05144af65802a7b492b9162660 |
|
02-Oct-2010 |
Ohad Ben-Cohen <ohad@wizery.com> |
mmc: propagate power save/restore ops return value Allow power save/restore and their relevant mmc_bus_ops handlers exit with a return value. Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Tested-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Chris Ball <cjb@laptop.org>
|
71d7d3d190fe77588269a8febf93cd739bd91eb3 |
|
27-Sep-2010 |
Matt Fleming <matt@console-pimps.org> |
mmc: Add helper function to check if a card is removable There are two checks that need to be made when determining whether a card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the controller does not support removing cards (e.g. eMMC), in which case the card is physically non-removable. Also the 'mmc_assume_removable' module parameter can be configured at module load time, in which case the card may be logically non-removable. A helper function keeps the logic in one place so that code always checks both conditions. Because this new function is likely to be called from modules we now need to export the mmc_assume_removable symbol. Signed-off-by: Matt Fleming <matt@console-pimps.org> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Chris Ball <cjb@laptop.org>
|
dfe86cba7676d58db8de7e623f5e72f1b0d3ca35 |
|
11-Aug-2010 |
Adrian Hunter <adrian.hunter@nokia.com> |
mmc: add erase, secure erase, trim and secure trim operations SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4 cards can support secure erase, trim and secure trim operations that are all variants of the basic erase command. SD/MMC device attributes "erase_size" and "preferred_erase_size" have been added. "erase_size" is the minimum size, in bytes, of an erase operation. For MMC, "erase_size" is the erase group size reported by the card. Note that "erase_size" does not apply to trim or secure trim operations where the minimum size is always one 512 byte sector. For SD, "erase_size" is 512 if the card is block-addressed, 0 otherwise. SD/MMC cards can erase an arbitrarily large area up to and including the whole card. When erasing a large area it may be desirable to do it in smaller chunks for three reasons: 1. A single erase command will make all other I/O on the card wait. This is not a problem if the whole card is being erased, but erasing one partition will make I/O for another partition on the same card wait for the duration of the erase - which could be a several minutes. 2. To be able to inform the user of erase progress. 3. The erase timeout becomes too large to be very useful. Because the erase timeout contains a margin which is multiplied by the size of the erase area, the value can end up being several minutes for large areas. "erase_size" is not the most efficient unit to erase (especially for SD where it is just one sector), hence "preferred_erase_size" provides a good chunk size for erasing large areas. For MMC, "preferred_erase_size" is the high-capacity erase size if a card specifies one, otherwise it is based on the capacity of the card. For SD, "preferred_erase_size" is the allocation unit size specified by the card. "preferred_erase_size" is in bytes. Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Acked-by: Jens Axboe <axboe@kernel.dk> Cc: Kyungmin Park <kmpark@infradead.org> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Ben Gardiner <bengardiner@nanometrics.ca> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
71578a1eaa7b8b9bd3efc9c97d77ef2b63d5dc2b |
|
11-Aug-2010 |
Michal Miroslaw <mirq-linux@rere.qmqm.pl> |
mmc: split mmc_sd_init_card() This series adds support for SD combo cards to MMC/SD driver stack. SD combo consists of SD memory and SDIO parts in one package. Since the parts have a separate SD command sets, after initialization, they can be treated as independent cards on one bus. Changes are divided into two patches. First is just moving initialization code around so that SD memory part init can be called from SDIO init. Second patch is a proper change enabling SD memory along SDIO. I tried to move as much no-op changes to the first patch so that it's easier to follow the required changes to initialization flow for SDIO cards. This is based on Simplified SDIO spec v.2.00. The init sequence is slightly modified to follow current SD memory init implementation. Command sequences, assuming SD memory and SDIO indeed ignore unknown commands, are the same as before for both parts. This patch: Prepare for SD-combo (IO+mem) support by splitting SD memory card init and related functions. Signed-off-by: Michal Miroslaw <mirq-linux@rere.qmqm.pl> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: Chris Ball <cjb@laptop.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
5a0e3ad6af8660be21ca98a971cd00f331318c05 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
bd68e0838fe85794b06892054772fa013a8d1986 |
|
15-Dec-2009 |
Ben Hutchings <ben@decadent.org.uk> |
mmc: add module parameter to set whether cards are assumed removable Some people run general-purpose distribution kernels on netbooks with a card that is physically non-removable or logically non-removable (e.g. used for /home) and cannot be cleanly unmounted during suspend. Add a module parameter to set whether cards are assumed removable or non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME. In general, it is not possible to tell whether a card present in an MMC slot after resume is the same that was there before suspend. So there are two possible behaviours, each of which will cause data loss in some cases: CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed during suspend. Any filesystem on them must be unmounted before suspend; otherwise, buffered writes will be lost. CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during suspend. They must not be swapped during suspend; otherwise, buffered writes will be flushed to the wrong card. Currently the choice is made at compile time and this allows that to be overridden at module load time. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
95cdfb72b9bc568803f395c266152c71b034b461 |
|
23-Sep-2009 |
Nicolas Pitre <nico@fluxnic.net> |
mmc: propagate error codes back from bus drivers' suspend/resume methods Especially for SDIO drivers which may have special conditions/errors to report, it is a good thing to relay the returned error code back to upper layers. This also allows for the rationalization of the resume path where code to "remove" a no-longer-existing or replaced card was duplicated into the MMC, SD and SDIO bus drivers. In the SDIO case, if a function suspend method returns an error, then all previously suspended functions are resumed and the error returned. An exception is made for -ENOSYS which the core interprets as "we don't support suspend so just kick the card out for suspend and return success". When resuming SDIO cards, the core code only validates the manufacturer and product IDs to make sure the same kind of card is still present before invoking functions resume methods. It's the function driver's responsibility to perform further tests to confirm that the actual same card is present (same MAC address, etc.) and return an error otherwise. Signed-off-by: Nicolas Pitre <nico@marvell.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
d08ebeddfb3293fa4bdfca9c610daf1e8ec8b233 |
|
23-Sep-2009 |
Wolfgang Muees <wolfgang.mues@auerswald.de> |
mmc_spi: fail gracefully if host or card do not support the switch command Some time ago, I have send a patch to the mmc_spi subsystem changing the error codes. This was after a discussion with Pierre about using EINVAL only for non-recoverable errors. This patch was accepted as http://git.kernel.org/linus/fdd858db7113ca64132de390188d7ca00701013d Unfortunately, several weeks later, I realized that this patch has opened a little can of worms because there are SD cards on the market which a) claim that they support the switch command AND b) refuse to execute this command if operating in SPI mode. So, such a card would get unusuable in an embedded linux system in SPI mode, because the init sequence terminates with an error. This patch adds the missing error codes to the caller of the switch command and restores the old behaviour to fail gracefully if these commands can not execute. Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de> Cc: <linux-mmc@vger.kernel.org> Cc: <stable@kernel.org> [2.6.31.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
eae1aeeed852aae37621b82a9e7f6c05096a18fd |
|
23-Sep-2009 |
Adrian Hunter <adrian.hunter@nokia.com> |
mmc: add ability to save power by powering off cards Power can be saved by powering off cards that are not in use. This is similar to suspend / resume except it is under the control of the driver, and does not require any power management support. It can only be used when the driver can monitor whether the card is removed, otherwise it is unsafe. This is possible because, unlike suspend, the driver still receives card detect and / or cover switch interrupts. Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Acked-by: Matt Fleming <matt@console-pimps.org> Cc: Ian Molton <ian@mnementh.co.uk> Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> Cc: Jarkko Lavinen <jarkko.lavinen@nokia.com> Cc: Denis Karpov <ext-denis.2.karpov@nokia.com> Cc: Pierre Ossman <pierre@ossman.eu> Cc: Philip Langdale <philipl@overt.org> Cc: "Madhusudhan" <madhu.cr@ti.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
9feae246963c648b212abad0f0eb8938de5f5fe5 |
|
23-Sep-2009 |
Adrian Hunter <adrian.hunter@nokia.com> |
mmc: add MMC_CAP_NONREMOVABLE host capability eMMC's are not removable, so unsafe resume is OK always. To permit this a new host capability MMC_CAP_NONREMOVABLE has been added and suspend / resume updated accordingly. Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> Acked-by: Matt Fleming <matt@console-pimps.org> Cc: Ian Molton <ian@mnementh.co.uk> Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> Cc: Jarkko Lavinen <jarkko.lavinen@nokia.com> Cc: Denis Karpov <ext-denis.2.karpov@nokia.com> Cc: Pierre Ossman <pierre@ossman.eu> Cc: Philip Langdale <philipl@overt.org> Cc: "Madhusudhan" <madhu.cr@ti.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
a4dbd6740df0872cdf0a86841f75beec8381964d |
|
24-Jun-2009 |
David Brownell <dbrownell@users.sourceforge.net> |
driver model: constify attribute groups Let attribute group vectors be declared "const". We'd like to let most attribute metadata live in read-only sections... this is a start. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
9d9f25c036dd584db175552a7d162403d3ab54b3 |
|
07-Apr-2009 |
Wolfgang Muees <wolfgang.mues@auerswald.de> |
mmc_spi: do not check CID and CSD blocks with CRC16 Some cards are not able to calculate a valid CRC16 value for CID and CSD reads (CRC for 512 byte data blocks is OK). By moving the CRC enable after the read of CID and CSD, these cards can be used. This patch was tested with a faulty 8 GByte takeMS Class 6 SDHC card. This patch was suggested by Pierre Ossman. Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de> Signed-off-by: Pierre Ossman <pierre@ossman.eu>
|
8769392b1918ec70ab62eebc82e06c47c12f8304 |
|
17-Jun-2008 |
Deepak Saxena <dsaxena@plexity.net> |
MMC: Trivial comment cleanup Make the variable name in the comments match the actual name of the variable. Signed-off-by: Deepak Saxena <dsaxena@laptop.org> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
08f80bb5196517a0dfe50dc7c10f234c0ff2f0e8 |
|
17-Jun-2008 |
Anton Vorontsov <avorontsov@ru.mvista.com> |
mmc: change .get_ro() callback semantics Now get_ro() callback must return 0/1 values for its logical states, and negative errno values in case of error. If particular host instance doesn't support RO/WP switch, it should return -ENOSYS. This patch changes some hosts in two ways: 1. Now functions should be smart to not return negative values in "RO asserted" case (particularly gpio_ calls could return negative values for the outermost GPIOs). Also, board code usually passes get_ro() callbacks that directly return gpioreg & bit result, so at91_mci, imxmmc, pxamci and mmc_spi's get_ro() handlers need take special care when returning platform's values to the mmc core. 2. In case of host instance didn't implement get_ro() callback, it should really return -ENOSYS and let the mmc core decide what to do about it (mmc core thinks the same way as the hosts, so it isn't functional change). Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
51ec92e295d563dd5712d198a7e46c2ae5ccccb2 |
|
21-Mar-2008 |
Pierre Ossman <drzeus-list@drzeus.cx> |
mmc: use sysfs groups to handle conditional attributes Suppressing uevents turned out to be a bad idea as it screws up the order of events, making user space very confused. Change the system to use sysfs groups instead. This is a regression that, for some odd reason, has gone unnoticed for some time. It confuses hal so that the block devices (which have the mmc device as a parent) are not registered. End result being that desktop magic when cards are inserted won't work. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
af51715079e7fb6b290e1881d63d815dc4de5011 |
|
08-Aug-2007 |
David Brownell <david-b@pacbell.net> |
MMC core learns about SPI 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>
|
d84075c8aed771d47d7ac6e96b098559da361c25 |
|
09-Aug-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: replace BUG_ON with WARN_ON 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>
|
adf66a0dc5e8be8d4e64f3c2114f9b175558235b |
|
22-Jul-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: improve error code feedback Now that we use "normal" error codes, improve the reporting and response to error codes in the core. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
17b0429dde9ab60f9cee8e07ab28c7dc6cfe6efd |
|
22-Jul-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: remove custom error codes Convert the MMC layer to use standard error codes and not its own, incompatible values. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
facba9179e3cd5fa91ff40bbc555c5cd4c101092 |
|
24-Jul-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: add missing printk levels Some printk:s were missing an explicit level. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
109b5bed18441599b5ab0e1f3623efa5715a4703 |
|
23-Jul-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: be more verbose about card insertions/removal 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>
|
2986d0bf23d97d68804ccfa80965073ccf1af242 |
|
22-Jul-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: Don't hold lock when releasing an added card 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>
|
70f10482c668301c483acded13bf68780ad352b9 |
|
11-Jul-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: update header file paths Make sure all headers in the files reflect their true position in the tree. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
4101c16a910b15afd190c6bc7d45864461cf5c25 |
|
19-May-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: refactor bus operations Move bus operations to its own file for the sake of clarity. Also delegate sysfs attributes to bus handlers in preparation for other more exotic types. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
c3bff2ec10b8bf2f53c954e370f9bdae93064472 |
|
13-Jun-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: get back read-only switch function Somehow the code to read the read-only switch of SD cards got lost in the reorganisation. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
3373c0ae6a51085b10a95fd9d2214a9995ef7563 |
|
31-May-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: don't call switch on old cards Make sure we don't call the switch function on cards too old to support it. They should just ignore it, but some have been reported to lock up instead. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
71651297a448289353b2493c6c3c183f9be7be7c |
|
06-Jun-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: fix broken if clause Fix a broken if clause which was causing SD cards to go into 4-bit mode even if the host did not support it. (Reported by David Brownell and Marc Pignat) Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
bd766312618d2ecc85bce663f95faec601447ecb |
|
01-May-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: remove old card states Remove card states that no longer make any sense. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
6abaa0c9fec563538f2a28a682af8c89bb9b125c |
|
01-May-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: support unsafe resume of cards Since many have the system root on MMC/SD we must allow some foot shooting when it comes to resume. We cannot detect if a card is removed and reinserted during suspend, so the safe approach would be to assume it was, avoiding potential filesystem corruption. This will of course not work if you cannot release the card before suspend. This commit adds a compile time option that makes the MMC layer assume the card wasn't touched if it is redetected upon resume. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
1addfcdbe4b23a20f28a097c2469d9f0c21bef23 |
|
01-May-2007 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: break apart switch function Break apart the SD switch function into one that reads the capabilities and one that acts on them. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
55556da01284af8c2174b786b3eca8e11301b656 |
|
17-Mar-2007 |
Philip Langdale <philipl@overt.org> |
MMC: Fix handling of low-voltage cards Fix handling of low voltage MMC cards. The latest MMC and SD specs both agree that support for low-voltage operations is indicated by bit 7 in the OCR. The MMC spec states that the low voltage range is 1.65-1.95V while the SD spec leaves the actual voltage range undefined - meaning that there is still no such thing as a low voltage SD card. However, an old Sandisk spec implied that bits 7.0 represented voltages below 2.0V in 1V or 0.5V increments, and the code was accordingly written with that expectation. This confusion meant that host drivers attempting to support the typical low voltage (1.8V) would set the wrong bits in the host OCR mask (usually bits 5 and/or 6) resulting in the the low voltage mode never being used. This change corrects the low voltage range and adds sanity checks on the reserved bits (0-6) and for SD cards that claim to support low-voltage operations. Signed-off-by: Philip Langdale <philipl@overt.org> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
7ea239d9e6d6993469a6a8ca83ff23834dfc3fce |
|
31-Dec-2006 |
Pierre Ossman <drzeus@drzeus.cx> |
mmc: add bus handler Delegate protocol handling to "bus handlers". This allows the core to just handle the task of arbitrating the bus. Initialisation and pampering of cards is now done by the different bus handlers. This design also allows MMC and SD (and later SDIO) to be more cleanly separated, allowing easier maintenance. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|