- 25 5月, 2011 3 次提交
-
-
由 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>
-
- 16 3月, 2011 1 次提交
-
-
由 Mark Brown 提交于
So we know the implementation and prototypes agree with each other. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: NChris Ball <cjb@laptop.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 09 1月, 2011 2 次提交
-
-
由 Andy Ross 提交于
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: NAndy Ross <andy.ross@windriver.com> Reviewed-and-Tested-by: NHein Tibosch <hein_tibosch@yahoo.es> Reviewed-by: NChris Ball <cjb@laptop.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Takashi Iwai 提交于
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: NAries Lee <arieslee@jmicron.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NChris Ball <cjb@laptop.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 23 10月, 2010 2 次提交
-
-
由 Ohad Ben-Cohen 提交于
Allow power save/restore and their relevant mmc_bus_ops handlers exit with a return value. Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com> Tested-by: NLuciano Coelho <luciano.coelho@nokia.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Matt Fleming 提交于
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: NMatt Fleming <matt@console-pimps.org> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com> Acked-by: NWolfram Sang <w.sang@pengutronix.de> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 12 8月, 2010 1 次提交
-
-
由 Adrian Hunter 提交于
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: NAdrian Hunter <adrian.hunter@nokia.com> Acked-by: NJens 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 11 8月, 2010 1 次提交
-
-
由 Michal Miroslaw 提交于
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: NMichal 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
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: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 16 12月, 2009 1 次提交
-
-
由 Ben Hutchings 提交于
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: NBen Hutchings <ben@decadent.org.uk> Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 9月, 2009 4 次提交
-
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@marvell.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Wolfgang Muees 提交于
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: NWolfgang Muees <wolfgang.mues@auerswald.de> Cc: <linux-mmc@vger.kernel.org> Cc: <stable@kernel.org> [2.6.31.x] Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Adrian Hunter 提交于
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: NAdrian Hunter <adrian.hunter@nokia.com> Acked-by: NMatt 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Adrian Hunter 提交于
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: NAdrian Hunter <adrian.hunter@nokia.com> Acked-by: NMatt 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 16 9月, 2009 1 次提交
-
-
由 David Brownell 提交于
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: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 09 4月, 2009 1 次提交
-
-
由 Wolfgang Muees 提交于
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: NWolfgang Muees <wolfgang.mues@auerswald.de> Signed-off-by: NPierre Ossman <pierre@ossman.eu>
-
- 15 7月, 2008 2 次提交
-
-
由 Deepak Saxena 提交于
Make the variable name in the comments match the actual name of the variable. Signed-off-by: NDeepak Saxena <dsaxena@laptop.org> Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Anton Vorontsov 提交于
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: NAnton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 23 3月, 2008 1 次提交
-
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 9月, 2007 2 次提交
-
-
由 David Brownell 提交于
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: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-
- 23 9月, 2007 2 次提交
-
-
由 Pierre Ossman 提交于
Now that we use "normal" error codes, improve the reporting and response to error codes in the core. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
Convert the MMC layer to use standard error codes and not its own, incompatible values. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 26 7月, 2007 4 次提交
-
-
由 Pierre Ossman 提交于
Some printk:s were missing an explicit level. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
Let the user know that the kernel actually detected the card by printing some basic information in dmesg. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
Make sure all headers in the files reflect their true position in the tree. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 10 7月, 2007 1 次提交
-
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-
- 14 6月, 2007 1 次提交
-
-
由 Pierre Ossman 提交于
Somehow the code to read the read-only switch of SD cards got lost in the reorganisation. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
- 07 6月, 2007 2 次提交
-
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-
- 01 5月, 2007 5 次提交
-
-
由 Pierre Ossman 提交于
Remove card states that no longer make any sense. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
Break apart the SD switch function into one that reads the capabilities and one that acts on them. Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Philip Langdale 提交于
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: NPhilip Langdale <philipl@overt.org> Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
-
由 Pierre Ossman 提交于
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: NPierre Ossman <drzeus@drzeus.cx>
-