- 10 Apr, 2015 7 commits
-
-
Peter Griffin authored
This patch updates the binding information to reflect the extra dt options which are now supported by the sdhci-st.c driver which enable support for stih407 family silicon. STiH410 SoC and later support UHS modes for eMMC, so the driver now makes use of these common bindings. Examples are provided for both eMMC (which has additional bindings) and also sd slot for STiH407. Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Acked-by:
Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Peter Griffin authored
Some additional quirks need to be enabled now we support UHS modes. This avoids some spurious warnings like "Got data interrupt 0x00000002 even though no data operation was in progress" Testing on stih410-b2120 board achieves the following speeds with HS200 eMMC card. max-frequency = 200Mhz /dev/mmcblk0p1: Timing buffered disk reads: 270 MB in 3.02 seconds = 89.54 MB/sec max-frequency = 100Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 210 MB in 3.00 seconds = 70.00 MB/sec max-frequency = 50Mhz root@debian-armhf:~# hdparm -t /dev/mmcblk0p1 /dev/mmcblk0p1: Timing buffered disk reads: 118 MB in 3.00 seconds = 39.28 MB/sec This is better than the 3.10 kernel which achieves 77.59 MB/sec at 200Mhz clock (same board/soc/eMMC). Signed-off-by:
Giuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by:
-
Peter Griffin authored
To allow UHS modes to work properly we need to provide the st specific set_uhs_signaling callback function. This function differs from the generic sdhci_set_uhs_signaling callback in that we need to configure the correct delay depending on the UHS mode, and also set the V18_EN bit. Signed-off-by:
-
Peter Griffin authored
STiH407 family SoC's have glue registers in the flashSS subsystem which are used to configure the Arasan HC. This patch configures these glue registers according to what has been specified in the DT. Signed-off-by:
-
Peter Griffin authored
Due to the tight timing constraints in some UHS modes, it is required to have some delay management in the design. Two types of delay management are supported in the HW: - 1) Static delay management 2) Dynamic delay management NB: The delay management is only there when eMMC interface is selected. 1: Static delay management: is used to provide PVT dependent static delay on the clock/data lines to manage setup/hold requirements of the interface. The maximum delay possible is 3.25ns. These delays are PVT dependent, and thus delay values applied are not accurate and vary across provcess voltage and temperature range. Due to this these delays must not be used on the very time critical paths. 2. Dynamic delay locked loop (DLL): is used to provide dynamic delay management. The advantage of DLL is that it provides accurate & PVT indepedent delay. The DLL is used to provide delay on the loopback clock on "Read Path" to capture read data reliably. On TX path the clock on which output data is transmitted is delayed, resulting in delay of TX data. Signed-off-by:
-
Peter Griffin authored
STiH407 family SoC's can have a reset signal for the controller which needs to be managed. Also the eMMC controller has some additional 'top' memory mapped registers which are used to manage the dynamic and static delay required for UHS modes. This patch adds support for creating the mapping, which will be used by subsequent patches. Signed-off-by:
-
Peter Griffin authored
The stih407 family SoC's have additional glue registers in the flashSS which are used to configure the Arasan controller. This patch adds macros for the register offsets and bitfields which will be used by subsequent patches to support stih407 family SoC's. Signed-off-by:
-
- 09 Apr, 2015 7 commits
-
-
Fabio Estevam authored
Currently it is not possible to use 'mmc-pwrseq-simple' property with this driver because mmc_of_parse() is never called. mmc_of_parse() calls mmc_pwrseq_alloc() that manages MMC power sequence and allows passing GPIOs in the devicetree to properly power/reset the Wifi chipset. When using mmc_of_parse() we no longer need to have custom code to request card-detect and write-protect pins, as this can now be handled by the mmc core. Tested on a imx6sl-warp board where BT/Wifi is functional and also on a imx6q-sabresd. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Doug Anderson authored
It is possible for the cmd11 interrupt to fire and delete the cmd11_timer before the cmd11_timer was actually setup. Let's fix this race by adding a few spinlocks. Note that the race wasn't seen in practice without adding some printk statements, but it still seems wise to fix. Fixes: 5c935165 ("mmc: dw_mmc: Add a timeout for sending CMD11") Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Doug Anderson authored
If we get an unexpected cmd11 timeout we shouldn't actually treat it as a timeout (not that we really expect to get an unexpected cmd11 timeout, but still). Fixes: 5c935165 ("mmc: dw_mmc: Add a timeout for sending CMD11") Reported-by:
-
Doug Anderson authored
Although the cmd11 interrupt should come within 2ms, that's a very short time. Let's increase the timeout to be really sure that we don't get an accidnetal timeout. One case in particular this is useful is if you've got a serial console and printk in just the right places. Under that scenario I've seen delays of up to 130ms before the interrupt fired. CMD11 is only sent during card insertion, so this extra timeout shouldn't be terrible. Fixes: 5c935165 ("mmc: dw_mmc: Add a timeout for sending CMD11") Signed-off-by:
-
Ben Dooks authored
The dw_mmc driver changes to make the IO accesors endian agnostic did not take into account the fifo accesses do not need to be swapped. To fix this add a mmci_fifo_read/write wrapper to allow these to be passed through the IO without being swapped. Since these are now specific functions, it would be easier just to store the pointer to the fifo registers in the host block instead of the offset to them. So change the host->data_offset to host->fifo_reg (which also means we catch all the places this is read or written). Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by:
-
Ben Dooks authored
The dw_mmc driver does not take into account the processor may be in big endian when writing the descriptors. Change the descriptors for the 32bit IDMA to use __le32 and ensure they are suitably swapped before writing. Note, this has not been tested as the socfpga driver does not try to use idma. Signed-off-by:
-
Ben Dooks authored
The dw_mmc driver does not use endian agnostic IO accessors, so fix the use of __raw reads and writes to be the relaxed versions. This fixes the dw_mmc driver initialisation on Altera socfpga in big endian. Signed-off-by:
-
- 08 Apr, 2015 3 commits
-
-
Ulf Hansson authored
Everybody expects the error field in the struct mmc_command|data to be and int but it's actually an unsigned int. Let's convert it into an int to meet the expectations. Signed-off-by: -
Michal Simek authored
Also check MMC OF properties. The controller supports MMC too. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Micky Ching authored
rts5250 chip failed handle 64 bit ADMA for address below 4G. Add 64 BIT quirks to disable this feature. Signed-off-by:
Micky Ching <micky_ching@realsil.com.cn> Signed-off-by:
-
- 02 Apr, 2015 1 commit
-
-
Hans de Goede authored
The eMMC on a tablet I've will stop working / communicating as soon as the kernel executes: mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HPI_MGMT, 1, card->ext_csd.generic_cmd6_time); There seems to be no way to reliable identify eMMC-s which have a broken hpi implementation, but at least for eMMC's which are soldered onto a board we can work around this by specifying that hpi is broken in devicetree. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 01 Apr, 2015 1 commit
-
-
Mylene JOSSERAND authored
Modify the driver to handle GPIOs using the descriptor API. Signed-off-by:
Mylene JOSSERAND <josserand.mylene@gmail.com> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Tested-by:
-
- 31 Mar, 2015 6 commits
-
-
Andreas Fenkart authored
Signed-off-by:
Andreas Fenkart <afenkart@gmail.com> Signed-off-by:
-
Andreas Fenkart authored
strip the card dectet logic from cover detect isr and vice versa the generic mmc_gpio_cd_irqt isr, uses 200ms on removal/insertion, hence that should be fine here as well Signed-off-by:
-
Doug Anderson authored
If dw_mci_init_slot() returns that we got a probe deferral then it may leave slot->mmc as NULL. That will cause dw_mci_enable_cd() to crash when it calls mmc_gpio_get_cd(). Fix this by moving the call of dw_mci_enable_cd() until we're sure that we're good. Note that if we have more than one slot and one defers (but the others don't) things won't work so well. ...but that's not a new thing and everyone has already agreed that multislot support ought to be removed from dw_mmc eventually anyway since it is unused, untested, and you can see several bugs like this by inspecting the code. Fixes: bcafaf5470f0 ("mmc: dw_mmc: Only enable CD after setup and only if needed") Signed-off-by: -
Doug Anderson authored
In the Designware databook's description of the "Voltage Switch Normal Scenario" it instructs us to set a timer and fail the voltage change if we don't see the voltage change interrupt within 2ms. Let's implement that. Without implementing this I have often been able to reproduce a hang while trying to send CMD11 on an rk3288-based board while constantly ejecting and inserting UHS cards. Signed-off-by:
-
Jaehoon Chung authored
Enable card-read-threshold, when eMMC mode is HS400. Refer to f1d2736c (mmc: dw_mmc: control card read threshold) Signed-off-by:
-
Ulf Hansson authored
Currently those host drivers which have deployed runtime PM, deals with the runtime PM reference counting entirely by themselves. Since host drivers don't know when the core will send the next request through some of the host_ops callbacks, they need to handle runtime PM get/put between each an every request. In quite many cases this has some negative effects, since it leads to a high frequency of scheduled runtime PM suspend operations. That due to the runtime PM reference count will normally reach zero in-between every request. We can decrease that frequency, by enabling the core to deal with runtime PM reference counting of the host device. Since the core often knows that it will send a seqeunce of requests, it makes sense for it to keep a runtime PM reference count during these periods. More exactly, let's increase the runtime PM reference count by invoking pm_runtime_get_sync() from __mmc_claim_host(). Restore that action by invoking pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() in mmc_release_host(). In this way a runtime PM reference count will be kept during the complete cycle of a claim -> release host. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Acked-by:
Konstantin Dorfman <kdorfman@codeaurora.org>
-
- 27 Mar, 2015 3 commits
-
-
Andreas Fenkart authored
board-rx51 has no card detect pin in the mmc slot, but can detect that the (cell-phone) cover has been removed and the card is accessible. The semantics between cover/card detect differ, the gpio on the slot informs you after the card has been removed, cover removal does not necessarily mean that the card has been removed. This means different code paths are necessary. To complete this we also want different fields in the platform data for cover and card detect. This separation is not pushed all the way down into struct omap2_hsmmc_info which is used to initialize the platform data. If we did that we had to go over all board files and set the new gpio_cod pin to -EINVAL. If we forget one board or some out-of-tree archicture forgets that the default '0' is used which is a valid pin number. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
NeilBrown authored
These callbacks have been set to deprecated for some time. The last user (omap_hsmmc) has moved away from using them, which thus enables us to completely remove them. Signed-off-by:
NeilBrown <neil@brown.name> Signed-off-by:
-
NeilBrown authored
The ->enable|disable() callbacks are only used to get and put runtime PM references. Currently omap_hsmmc's ->set_ios() already does this itself. Other host drivers deals with runtime PM without using the ->enable|disable() callbacks and thus do the runtime PM reference counting themselves. Apply that approach for omap_hsmmc as well and then discard the ->enable|disable() callbacks. Signed-off-by:
-
- 25 Mar, 2015 5 commits
-
-
Georgi Djakov authored
Some versions of this controller do not advertise their 3.0v and 8bit bus-width support capabilities. It is required to explicitly set these capabilities for the specific controller versions. Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
-
Sascha Hauer authored
Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Bjorn Andersson authored
Signed-off-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Ulf Hansson authored
Jaehoon has volunteered in maintaining the SDHCI SAMSUNG DRIVER so add him. Since we are updating this section let's also correct file path to cover all files for sdhci-s3c. Cc: Ben Dooks <ben-linux@fluff.org> Cc: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: -
Ben Dooks authored
Change the __raw IO functions to endian agnostic relaxed ones to allow the driver to function on big endian ARM systems. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
- 23 Mar, 2015 7 commits
-
-
Fabian Frederick authored
of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
NeilBrown authored
Every call to sdio_enable_4bit_bus is followed (on success) by a call to mmc_set_bus_width(). To simplify the code, include those calls directly in sdio_enable_4bit_bus(). Signed-off-by:
-
Ulf Hansson authored
As Chris Ball has moved on to other assignments, he's no longer able to help me maintain MMC. Let's remove him from the MMC sections in MAINTAINERS and add him to CREDIT file. This also affects the SDHCI DRIVER section, since its state now becomes orphan. Cc: Chris Ball <chris@printf.net> Signed-off-by:
Chris Ball <chris@printf.net>
-
Ulf Hansson authored
Anton told me that he isn't maintaing the SDHCI-OF parts anymore, so let's remove him from this section to avoid confusion. Morover, since the SDHCI-OF section overlaps with the SDHCI DRIVER section, let's just remove it completely. Cc: Anton Vorontsov <anton@enomsg.org> Signed-off-by: -
Hans de Goede authored
When the sunxi mmc-controller code was initially merged MMC_CAP_SDIO_IRQ was not added to the host caps because of issues with some sdio wifi modules. It turns out that these issues have nothing to do with using sdio-irq support, they also happen with oob interrupts. Since the hardware supports sdio-irq everywhere, and since the one reason to not claim the capability is gone, add MMC_CAP_SDIO_IRQ to the default host caps. Signed-off-by:
-
Dmitry Torokhov authored
The driver co-allocates sdhci_iproc_host with sdhci_pltfm_host and so to access it we need to use sdhci_pltfm_priv() and not pltfm_host->priv. Signed-off-by:
Dmitry Torokhov <dtor@chromium.org> Signed-off-by:
-
Scott Branden authored
The sdhci_request function should consider a non-removable device always present. Call the correct logic already available in sdhci_do_get_cd function. This fixes some logic paths where MMC requests are being made to non-removable devices that do not have the card detect pin connected on the hardware as it is non-removable. Signed-off-by:
Scott Branden <sbranden@broadcom.com> Signed-off-by:
-
