13 Jan, 2012

1 commit


20 Dec, 2011

1 commit


27 Oct, 2011

2 commits

  • Ths patch allows runtime PM for sdhci-pci, runtime suspending after
    inactivity of 50ms and ensuring runtime resume before SDHC registers
    are accessed. During runtime suspend, interrupts are masked.
    The host controller state is restored at runtime resume.

    For Medfield, the host controller's card detect mechanism is
    supplanted by an always-on GPIO which provides for card detect wake-up.

    Signed-off-by: Adrian Hunter
    Signed-off-by: Chris Ball

    Adrian Hunter
     
  • Add an SDHCI operation for hardware reset and connect it to the
    host controller operation.

    Signed-off-by: Adrian Hunter
    Signed-off-by: Chris Ball

    Adrian Hunter
     

26 May, 2011

2 commits


25 May, 2011

9 commits

  • Allow platform specific code to set UHS registers if
    implementation requires speciial platform specific handling

    Signed-off-by: Philip Rakity
    Reviewed-by: Arindam Nath
    Signed-off-by: Chris Ball

    Philip Rakity
     
  • Host Controller v3.00 can support retuning modes 1,2 or 3 depending on
    the bits 46-47 of the Capabilities register. Also, the timer count for
    retuning is indicated by bits 40-43 of the same register. We initialize
    timer_list for retuning the first time we execute tuning procedure. This
    condition is indicated by SDHCI_NEEDS_RETUNING not being set. Since
    retuning mode 1 sets a limit of 4MB on the maximum data length, we set
    max_blk_count appropriately. Once the tuning timer expires, we set
    SDHCI_NEEDS_RETUNING flag, and if the flag is set, we execute tuning
    procedure before sending the next command. We need to restore mmc_request
    structure after executing retuning procedure since host->mrq is used
    inside the procedure to send CMD19. We also disable and re-enable this
    flag during suspend and resume respectively, as per the spec v3.00.

    Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
    on mmp2 in SDMA mode.

    Signed-off-by: Arindam Nath
    Reviewed-by: Philip Rakity
    Tested-by: Philip Rakity
    Acked-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    Arindam Nath
     
  • Host Controller v3.00 supports programmable clock mode as an optional
    feature. The support for this mode is indicated by non-zero value in
    bits 48-55 of the Capabilities register. If supported, the actual
    value of Clock Multiplier is one more than the value provided in the
    bit fields. We only set Clock Generator Select (bit 5) and SDCLK
    Frequency Select (bits 8-15) of the Clock Control register in case
    Preset Value Enable is not set, otherwise these fields are automatically
    set by the Host Controller based on the UHS mode selected. Also, since
    the maximum and minimum clock frequency in this mode can be
    (Base Clock * Clock Mul) and (Base Clock * Clock Mul)/1024 respectively,
    f_max and f_min have been recalculated to reflect this change.

    Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
    on mmp2 in SDMA mode.

    Signed-off-by: Arindam Nath
    Reviewed-by: Philip Rakity
    Tested-by: Philip Rakity
    Acked-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    Arindam Nath
     
  • Host Controller needs tuning during initialization to operate SDR50
    and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is
    indicated by bit 45 of the Host Controller Capabilities register.
    A new command CMD19 has been defined in the Physical Layer spec
    v3.01 to request the card to send tuning pattern.

    We enable Buffer Read Ready interrupt at the very begining of tuning
    procedure, because that is the only interrupt generated by the Host
    Controller during tuning. We program the block size to 64 in the
    Block Size register. We make sure that DMA Enable and Multi Block
    Select in the Transfer Mode register are set to 0 before actually
    sending CMD19. The tuning block is sent by the card to the Host
    Controller using DAT lines, so we set Data Present Select (bit 5) in
    the Command register. The Host Controller is responsible for doing
    the verfication of tuning block sent by the card at the hardware
    level. After sending CMD19, we wait for Buffer Read Ready interrupt.
    In case we don't receive an interrupt after the specified timeout
    value, we fall back on fixed sampling clock by setting Execute
    Tuning (bit 6) and Sampling Clock Select (bit 7) of Host Control2
    register to 0. Before exiting the tuning procedure, we disable Buffer
    Read Ready interrupt and re-enable other interrupts.

    Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
    on mmp2 in SDMA mode.

    Signed-off-by: Arindam Nath
    Reviewed-by: Philip Rakity
    Tested-by: Philip Rakity
    Acked-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    Arindam Nath
     
  • This patch adds support for setting UHS-I bus speed mode during UHS-I
    initialization procedure. Since both the host and card can support
    more than one bus speed, we select the highest speed based on both of
    their capabilities. First we set the bus speed mode for the card using
    CMD6 mode 1, and then we program the host controller to support the
    required speed mode. We also set High Speed Enable in case one of the
    UHS-I modes is selected. We take care to reset SD clock before setting
    UHS mode in the Host Control2 register, and then re-enable it as per
    the Host Controller spec v3.00. We then set the clock frequency for
    the UHS-I mode selected.

    Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
    on mmp2 in SDMA mode.

    Signed-off-by: Arindam Nath
    Reviewed-by: Philip Rakity
    Tested-by: Philip Rakity
    Acked-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    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: Arindam Nath
    Reviewed-by: Philip Rakity
    Tested-by: Philip Rakity
    Acked-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    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: Arindam Nath
    Reviewed-by: Philip Rakity
    Tested-by: Philip Rakity
    Acked-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    Arindam Nath
     
  • Marvell pxa controllers have private registers that may need to be
    modified before and after a reset is done.

    For example, the SD reset operation, RESET_ALL, will reset the private
    registers to their default state. This will cause the clock adjustment
    registers that may have been programmed to have incorrect values.

    RESET_DATA sometimes needs to be delayed before the reset is done
    (depending on SoC) to enable any transactions being handled by the
    SDIO card to be completed. Needed in pre SD 3.0 silicon to handle
    clock gating.

    Implement hooks to allow this to happen.

    Signed-off-by: Philip Rakity
    Signed-off-by: Chris Ball

    Philip Rakity
     
  • Some SD host controllers (noticed on an integrated JMicron SD reader on an
    HP Pavilion dv5-1250eo laptop) don't update the dma address register before
    signaling a dma interrupt due to a dma boundary. Update the register
    manually to the next boundary (by default 512KiB), at which the transfer
    stopped.

    As long as each transfer is at most 512KiB in size (guaranteed by a BUG_ON
    in sdhci_prepare_data()) and the boundary is kept at the default value,
    this fix is needed at most once per transfer. Smaller boundaries are taken
    care of by counting the transferred bytes.

    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=28462

    Signed-off-by: Mikko Vinni
    Signed-off-by: Chris Ball

    Mikko Vinni
     

25 Mar, 2011

1 commit


09 Jan, 2011

2 commits

  • Some old MMC devices fail with the 4/8 bits the driver tries to use
    exclusively. This patch adds a test for the given bus setup and falls
    back to the lower bit mode (until 1-bit mode) when the test fails.

    [Major rework and refactoring by tiwai]
    [Quirk addition and many fixes by prakity]

    Signed-off-by: Aries Lee
    Signed-off-by: Takashi Iwai
    Signed-off-by: Philip Rakity
    Tested-by: Philip Rakity
    Signed-off-by: Chris Ball

    Aries Lee
     
  • More information should be shown when sdhci_dumpregs is called.
    Knowing the command is useful for debugging, and Capability 1
    is useful for SD v3.

    Signed-off-by: Philip Rakity
    Reviewed-by: Chris Ball
    Signed-off-by: Chris Ball

    Philip Rakity
     

23 Nov, 2010

1 commit

  • We now:
    * check for a v3 controller before setting 8-bit bus width
    * offer a callback for platform code to switch to 8-bit mode, which
    allows non-v3 controllers to support it
    * rely on mmc->caps |= MMC_CAP_8_BIT_DATA; in platform code to specify
    that the board designers have indeed brought out all the pins for
    8-bit to the slot.

    We were previously relying only on whether the *controller* supported
    8-bit, which doesn't tell us anything about the pin configuration in
    the board design.

    This fixes the MMC card regression reported by Maxim Levitsky here:
    http://thread.gmane.org/gmane.linux.kernel.mmc/4336
    by no longer assuming that 8-bit works by default.

    Signed-off-by: Philip Rakity
    Tested-by: Giuseppe Cavallaro
    Signed-off-by: Chris Ball

    Philip Rakity
     

08 Nov, 2010

1 commit


23 Oct, 2010

6 commits

  • Some controllers handle their write-protection differently. Introduce a
    callback to be able to handle it, ensuring the same locking takes place
    for it. Rename the status variable to make it more obvious why the read
    from the registers needs to be inverted.

    Signed-off-by: Wolfram Sang
    Tested-by: Eric Bénard
    Signed-off-by: Chris Ball

    Wolfram Sang
     
  • Snippet of code for how adaptation layer should handle the call:
    /*
    * eMMC spec calls for the host to send 74 clocks to the card
    * during initialization, right after voltage stabilization.
    * create the clocks manually right here.
    */
    void generate_init_clocks_A0(struct sdhci_host *host, u8 power_mode)
    {
    struct sdhci_mmc_slot *slot = sdhci_priv(host);

    if (slot->power_mode == MMC_POWER_UP &&
    power_mode == MMC_POWER_ON) {
    /* controller specific code here */
    /* slot->power_mode holds previous power setting */
    }
    slot->power_mode = power_mode;
    }

    Signed-off-by: Philip Rakity
    Signed-off-by: Chris Ball

    Philip Rakity
     
  • Some platforms based on sdhci-pltfm need to set their own quirks.
    Previously to this patch, the quirks were in drivers/mmc/host/sdhci.h.

    This patch splits drivers/mmc/host/sdhci.h into two parts:

    * drivers/mmc/host/sdhci.h includes the HC registers and I/O accessors.
    * include/linux/mmc/sdhci.h includes the sdhci structure and quirks.

    Instead of including drivers/mmc/host/sdhci.h, -pltfm drivers should
    now include include/linux/mmc/sdhci.h and include/linux/sdhci-pltfm.h.

    This patch avoids adding/changing the calls/flags in the
    sdhci_pltfm_data structure. It has been tested on STM platforms
    (e.g. STx7106, STx7108, STx5206) where the driver is configured
    and used as shown in the example below:

    [snip]
    static int mmc_pad_resources(struct sdhci_host *sdhci)
    {
    if (!devm_stm_pad_claim(sdhci->mmc->parent,
    &stx7108_mmc_pad_config,
    dev_name(sdhci->mmc->parent)))
    return -ENODEV;

    return 0;
    }

    static struct sdhci_pltfm_data stx7108_mmc_platform_data = {
    .init = mmc_pad_resources,
    .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
    };

    static struct platform_device stx7108_mmc_device = {
    .name = "sdhci",
    [snip]

    Note: drivers/mmc/host/sdhci.h now also includes linux/mmc/sdhci.h,
    and no modifications should be needed on other sdhci- drivers.

    Signed-off-by: Giuseppe Cavallaro
    Reviewed-by: Wolfram Sang
    Signed-off-by: Chris Ball

    Giuseppe Cavallaro
     
  • While we're at it, add symbols for SDHCI_MAX_DIV_SPEC_{200,300}.

    Signed-off-by: Zhangfei Gao
    Signed-off-by: Chris Ball

    Zhangfei Gao
     
  • SDHC Spec 3.0: Capabilities Register bits[15-08] are Base Clock Frequency
    1.0/2.0: Capabilities Register bits[13-08] are Base Clock Frequency

    Signed-off-by: Zhangfei Gao
    Cc: David Vrabel
    Cc: Matt Fleming
    Cc: Michal Miroslaw
    Signed-off-by: Andrew Morton
    Signed-off-by: Chris Ball

    Zhangfei Gao
     
  • Signed-off-by: Zhangfei Gao
    Cc: Michał Mirosław
    Cc: David Vrabel
    Reviewed-by: Matt Fleming
    Signed-off-by: Chris Ball

    Zhangfei Gao
     

21 Aug, 2010

1 commit


11 Aug, 2010

5 commits

  • Add auto CMD12 command support for eSDHC driver. This is needed by P4080
    and P1022 for block read/write. Manual asynchronous CMD12 abort operation
    causes protocol violations on these silicons.

    Signed-off-by: Jerry Huang
    Signed-off-by: Roy Zang
    Cc: Benjamin Herrenschmidt
    Cc: Kumar Gala
    Cc: Grant Likely
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jerry Huang
     
  • This patch adds support for regulator API to sdhci core driver.
    Regulators can be used to disable power in suspended state to reduce
    dissipated energy.

    Signed-off-by: Marek Szyprowski
    Signed-off-by: Kyungmin Park
    Acked-by: Mark Brown
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marek Szyprowski
     
  • On some Samsung SoCs not all SDHCI controllers have card detect (CD) line.
    For some embedded designs it is not even needed, because ususally the
    device (like SDIO flash memory or wifi controller) is permanently wired to
    the controller. There are also systems which have a card detect line
    connected to some of the external interrupt lines or the presence of the
    card depends on some other actions (like enabling a power regulator).

    This patch adds support for all these cases. The following card detection
    methods are possible:

    1. internal sdhci host card detect line
    2. external event
    3. external gpio interrupt
    4. no card detect line, controller will poll for the card
    5. no card detect line, card is permanently wired to the controller
    (once detected host won't poll it any more)

    By default, all existing code would use method #1, what is compatible with
    the previous version of the driver.

    In case of external event, two callbacks must be provided in platdata:
    ext_cd_init and ext_cd_cleanup. Both of them get a callback to a function
    that notifies the s3c-sdhci host contoller as their argument. That
    callback function should be called from the even dispatcher to let host
    notice the card insertion/removal.

    In case of external gpio interrupt, a gpio pin number must be provided in
    platdata (ext_cd_gpio parameter), as well as the information about the
    polarity of that gpio pin (ext_cd_gpio_invert). By default
    (ext_cd_gpio_invert == 0) gpio value 0 means 'card has been removed', but
    this can be changed to 'card has been removed' when ext_cd_gpio_invert ==
    1.

    This patch adds all required changes to sdhci-s3c driver.

    Signed-off-by: Marek Szyprowski
    Signed-off-by: Kyungmin Park
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marek Szyprowski
     
  • Some host controllers such as s5pc110 support the WIDE8 feature.

    Signed-off-by: Kyungmin Park
    Cc: Grant Likely
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kyungmin Park
     
  • The current way of disabling it is not well tested by vendor and has all
    kinds of bugs that show up on resume from ram/disk. A very good example
    is a dead SDHCI controller.

    Old way of disabling is still supported by continuing to use
    CONFIG_MMC_RICOH_MMC.

    Based on 'http://list.drzeus.cx/pipermail/sdhci-devel/2007-December/002085.html'
    Therefore most of the credit for this goes to Andrew de Quincey

    Signed-off-by: Maxim Levitsky
    Cc: Andrew de Quincey
    Acked-by: Philip Langdale
    Cc: "Rafael J. Wysocki"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Maxim Levitsky
     

28 May, 2010

4 commits

  • The s3c6410 sdhci controller does not support the 'End' attribute and NOP
    attribute in the same 8-Byte ADMA descriptor. This patch adds a new quirk
    to identify sdhci host contollers with such behaviour. In addition to
    this, for controllers using the new quirk, the last entry in the ADMA
    descritor table is marked with the 'End' attribute (instead of using a NOP
    descriptor with 'End' attribute).

    Signed-off-by: Maurus Cuelenaere
    Signed-off-by: Thomas Abraham
    Acked-by: Ben Dooks
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Abraham
     
  • Unfortunately some architectures #define their read{b,w,l} and
    write{b,w,l} I/O accessors which makes the SDHCI I/O accessor functions of
    the same names subject to preprocessing. This leads to the following
    compiler error,

    In file included from drivers/mmc/host/sdhci.c:26:
    drivers/mmc/host/sdhci.h:318:35: error: macro "writel" passed 3 arguments, but takes just 2

    Rename the SDHCI I/O functions so that CONFIG_MMC_SDHCI_IO_ACCESSORS can
    be enabled for architectures that implement their read{b,w,l} and
    write{b,w,l} functions with macros.

    Signed-off-by: Matt Fleming
    Cc: Zhangfei Gao
    Acked-by: Anton Vorontsov
    Acked-by: Wolfram Sang
    Acked-by: Ben Dooks
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matt Fleming
     
  • Signed-off-by: Zhangfei Gao
    Reviewed-by: Matt Fleming
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Zhangfei Gao
     
  • Some hosts (e.g. as found in CNS3xxx SOCs) report wrong value in
    CLOCK_BASE capability field, and currently there is no way to force the
    SDHCI core to use the platform-provided base clock value.

    This patch implements CAP_CLOCK_BASE_BROKEN quirk. When enabled, the
    SDHCI core will always use base clock frequency provided by the platform.

    Signed-off-by: Anton Vorontsov
    Cc: Richard Röjfors
    Cc: David Vrabel
    Cc: Pierre Ossman
    Cc: Ben Dooks
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Vorontsov
     

18 Dec, 2009

1 commit


23 Sep, 2009

2 commits

  • Add support for ADMA on SDHCI hosts, not supporting SDMA.

    According to the SDHCI specifications a host can support ADMA but not SDMA

    Signed-off-by: Richard Röjfors
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Röjfors
     
  • eSDHC fails to recognize some SDHS cards, throwing timeout errors:

    mmc0: error -110 whilst initialising SD card

    That's because we calculate timeout value in a wrong way: on eSDHC hosts
    the timeout clock is derivied from the SD clock, which is set dynamically.

    As David Vrabel suggested, deriving timeout clock from SD clock is a
    common scheme, so let's implement DATA_TIMEOUT_USES_SDCLK quirk and use it
    for eSDHC hosts.

    Also, from now on we don't need esdhc_get_timeout_clock() callback, so
    remove it.

    Signed-off-by: Anton Vorontsov
    Cc: Pierre Ossman
    Cc: Kumar Gala
    Cc: David Vrabel
    Cc: Ben Dooks
    Cc: Sascha Hauer
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Vorontsov
     

30 Jul, 2009

1 commit

  • Since commit 8dfd0374be84793360db7fff2e635d2cd3bbcb21 ("MMC core: limit
    minimum initialization frequency to 400kHz") MMC core checks for minimum
    frequency, and that causes following messages flood when using eSDHC
    controllers:

    ...
    mmc0: Minimum clock frequency too high for identification mode
    mmc0: Minimum clock frequency too high for identification mode
    ...

    The warnings are legitimate, since if we'd use 133 MHz clocks for standard
    SDHCI controllers, we'd not able to scale frequency down to 400 kHz.

    But eSDHC controllers have a non-standard SD clock management, so we can
    divide clock by 256 * 16, not just 256.

    This patch introduces get_min_clock() callback for sdhci core and
    implements it for sdhci-of driver, and thus fixes the issue.

    Signed-off-by: Anton Vorontsov
    Cc: Matt Fleming
    Cc: Ian Molton
    Cc: "Roberto A. Foglietta"
    Cc: Pierre Ossman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Vorontsov