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>

Allows appropriately-privileged applications to send CMD (normal) and ACMD
(application-specific; preceded with CMD55) commands to cards/devices on
the mmc bus.  This is primarily useful for enabling the security
functionality built in to every SD card.

It can also be used as a generic passthrough (e.g. to enable virtual
machines to control mmc bus devices directly).  However, this use case has
not been tested rigorously.  Generic passthrough testing was only conducted
for a few non-security opcodes to prove the feasibility of the passthrough.

Since any opcode can be sent using this passthrough, it is very possible to
render the card/device unusable.  Applications that use this ioctl must
have CAP_SYS_RAWIO.

Security commands tested on TI PCIxx12 (SDHCI), Sigma Designs SMP8652 SoC,
TI OMAP3621/OMAP3630 SoC, Samsung S5PC110 SoC, Qualcomm MSM7200A SoC.
Signed-off-by: NJohn Calixto <john.calixto@modsystems.com>
Reviewed-by: NAndrei Warkentin <andreiw@motorola.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

To avoid lockdep warnings:

BUG: key dc90a520 not in .data!
------------[ cut here ]------------
WARNING: at /home/rabin/kernel/arm/kernel/lockdep.c:2701 sysfs_add_file_mode+0x4c/0xb0()
Modules linked in:
[<c004b5d8>] (unwind_backtrace+0x0/0xe4) from [<c0074f20>] (warn_slowpath_common+0x4c/0x64)
[<c0074f20>] (warn_slowpath_common+0x4c/0x64) from [<c0074f50>] (warn_slowpath_null+0x18/0x1c)
[<c0074f50>] (warn_slowpath_null+0x18/0x1c) from [<c0157fec>] (sysfs_add_file_mode+0x4c/0xb0)
[<c0157fec>] (sysfs_add_file_mode+0x4c/0xb0) from [<c02d61e4>] (mmc_add_disk+0x40/0x64)
[<c02d61e4>] (mmc_add_disk+0x40/0x64) from [<c02d64cc>] (mmc_blk_probe+0x188/0x1fc)
[<c02d64cc>] (mmc_blk_probe+0x188/0x1fc) from [<c02ce820>] (mmc_bus_probe+0x14/0x18)
...
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NChris Ball <cjb@laptop.org>

On HP laptops with JMicron 388 chip, the write-locked SD card isn't
detected correctly as read-only in many cases.  This is because the
PRESENT_STATE register becomes unsable just after plugging, and it
returns the WRITE_PROTECT bit wrongly at the first read.

This patch fixes the read-only detection by adding a new sdhci quirk
indicating to check the register more intensively with a relatively
long delay.

The patch is tested with 2.6.39-rc4 kernel.

Cc: Aries Lee <arieslee@jmicron.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

With the hardware partitions support (which represent additional logical
devices present on MMC), devidx does not correspond with index used to form
/dev/mmcblkX names. So use an additional allocated index for device names.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit 373e6a (mmc: sdhci: R1B command handling + MMC_CAP_ERASE) moved the
handling of SDHCI_QUIRK_TIMEOUT_USES_SDCLK from sdhci_calc_timeout() to
sdhci_add_host(). This causes division by zero errors on at least the S3C
SDHCI controller as the quirk implementation needs host->clock set to work
but host->clock has not been set when sdhci_add_host() is called.

Fix this by backing out that portion of the change, the clock may vary at
runtime anyway. It does occur to me that we may want to move the quirk to
where we set the clock but this seems more invasive and I'm concerned
about undesirable side effects.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Converts from:
	struct mmc_request mrq;
	memset(&mrq, 0, sizeof(struct mmc_request));

to:
	struct mmc_request mrq = {0};

because it's shorter, as performant, and easier to work out whether
initialization has happened.
Signed-off-by: NChris Ball <cjb@laptop.org>

Converts from:
	struct mmc_data data;
	memset(&data, 0, sizeof(struct mmc_data));

to:
	struct mmc_data data = {0};

because it's shorter, as performant, and easier to work out whether
initialization has happened.
Signed-off-by: NChris Ball <cjb@laptop.org>

Converts from:
	struct mmc_command cmd;
	memset(&cmd, 0, sizeof(struct mmc_command));

to:
	struct mmc_command cmd = {0};

because it's shorter, as performant, and easier to work out whether
initialization has happened.
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_blk_issue_rw_rq did not zero out mmc_command on stack.
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_send_if_cond did not zero out mmc_command on stack.
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_cmd_app did not zero out mmc_command on stack.
Reported-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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=28462Signed-off-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Block quirks implemented using core/quirks.c support.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Allows device MMC boot partitions to be accessed. MMC partitions are
treated effectively as separate block devices on the same MMC card.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Move host claim/release into mmc_blk_issue_rq.

(This is helpful so that selecting partition only has to happen
in one place for these commands.)
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

CMD6 is an R1B-type command, where DAT is used as busy. Depending
on register written using CMD6, timeout value can be different
as per spec.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

ERASE command needs R1B response, so fix R1B-type command
handling for SDHCI controller. For non-DAT commands using a busy
response, the cmd->cmd_timeout_ms (in ms) field is used for timeout
calculations.

Based on patch by Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Renames erase_timeout to cmd_timeout_ms inside struct mmc_command.
First step to making host honor timeouts for non-data-transfer
commands. Cleans up erase timeout code.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fix data truncation warnings: .manfid is not unsigned long:

drivers/mmc/core/quirks.c:36: warning: large integer implicitly truncated to unsigned type
drivers/mmc/core/quirks.c:40: warning: large integer implicitly truncated to unsigned type
drivers/mmc/core/quirks.c:43: warning: large integer implicitly truncated to unsigned type
drivers/mmc/core/quirks.c:46: warning: large integer implicitly truncated to unsigned type
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The current mechanism is SDIO-only. This allows us to create
function-specific quirks, without creating messy Kconfig dependencies,
or polluting core/ with function-specific code.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

led_trigger_register_simple() allocates memory which must not be leaked
in the error-path of mmc_add_host. Move it past the only error-check in
the function.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes 21 errors and 6 warnings reported by checkpatch.pl.
Signed-off-by: NAmeya Palande <2ameya@gmail.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

The wl12xx device supports disconnecting the pull-up resistor on
CD/DAT[3] (pin 1) of the card.

Tell SDIO core to disconnect that resistor during card init,
since we don't need it at that point (and anyway all
hosts shall provide pull-up resistors on all data lines DAT[3:0]
as described in section 6 of the SD physical specification).

As a result, this may save some power, but it's also generally healthy
since it prevents both ends from pulling up that pin, which
results in undesirable asymmetric physical bus.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

006ebd5d introduced sdio_disable_cd(), which disconnects the pull-up
resistor on CD/DAT[3] (pin 1) of the card.

Make it possible to start using sdio_disable_cd() by introducing
MMC_QUIRK_DISABLE_CD.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Tell SDIO core to ignore the standard SDIO function interface
codes indicated by the wl1271. This is required because the
wl1271 erroneously indicates its first function as a standard
Bluetooth SDIO interface, and that drives btsdio mad.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Introduce MMC_QUIRK_NONSTD_FUNC_IF to ignore the "SDIO Standard Function
interface code" as indicated by the card's FBR, and instead treat all
functions as non-standard interfaces.

This is required to prevent standard drivers from facing
errors when trying to communicate with SDIO cards that erroneously
indicate standard function interface codes.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

6b5eda36 followed SDIO spec part E1 section 8, which states that
in case SDIO interrupts are being used to wake up a suspended host,
then it is required to switch to 1-bit mode before stopping the clock.

Before switching to 1-bit mode (or back to 4-bit mode on resume),
make sure that SDIO interrupts are really being used to wake the host.

This is helpful for devices which have an external irq line (e.g.
wl1271), and do not use SDIO interrupts to wake up the host.

In this case, switching to 1-bit mode (and back to 4-bit mode on resume)
is not necessary.
Reported-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_card_is_powered_resumed is a mouthful; instead, simply use
mmc_card_keep_power, which also better explains the purpose of
the macro.

Employ mmc_card_keep_power() where possible.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Allows reliable writes to be used for MMC writes. Reliable writes are used
to service write REQ_FUA/REQ_META requests. Handles both the legacy and
the enhanced reliable write support in MMC cards.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

This config option is used to decide whether tegra sdhci support
should be build into the sdhci-platform module.  So setting it 'm'
is nonsense, since we can't build part of an module as a module.
The effect for 'm' will probably be the same as for 'n'.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.

This patch allows the mach-tegra support to tell the tegra MMC host
controller to NOT turn off power for the MMC controller the WIFI part
lives behind.  Thus bcm4329 firmware doesn't need to be reloaded.
Signed-off-by: NVenkat Rao <vrao@broadcom.com>
Tested-by: NGrant Grundler <grundler@chromium.org>
Reviewed-by: NOlof Johansson <olof@lixom.net>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NChris Ball <cjb@laptop.org>

There is no need to disable irq's when using the sg_copy_*_buffer()
functions because those functions do that already. There are also
no races for the mm_queue struct here that would require the irq's
to be disabled before calling sg_copy_*_buffer().
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

uBoot sometimes leaves eMMC pointing to the private boot partition.
Ensure we always start looking at the user partition.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NBruce Clemens <bpclemens@marvell.com>
Signed-off-by: NMark F. Brown <markb@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm: Take lock around probes for drm_fb_helper_hotplug_event
  drm/i915: Revert i915.semaphore=1 default from 47ae63e0
  vga_switcheroo: don't toggle-switch devices
  drm/radeon/kms: add some evergreen/ni safe regs
  drm/radeon/kms: fix extended lvds info parsing
  drm/radeon/kms: fix tiling reg on fusion

We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.

Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:

[   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[   17.772458] Hardware name: Latitude E6400
[   17.772460] Modules linked in: ....
[   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
[   17.772584] Call Trace:
[   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
[   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: NFrederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

My Q67 / i7-2600 box has rev09 Sandy Bridge graphics.  It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work.  Setting i915.semaphore=0 fixes it.

Semaphores were disabled in a1656b90
in 2.6.38 and were re-enabled by

commit 47ae63e0
Merge: c59a333f 467cffba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 7 12:32:44 2011 +0000

    Merge branch 'drm-intel-fixes' into drm-intel-next

    Apply the trivial conflicting regression fixes, but keep GPU semaphores
    enabled.

    Conflicts:
        drivers/gpu/drm/i915/i915_drv.h
        drivers/gpu/drm/i915/i915_gem_execbuffer.c

(It's worth noting that the offending change is i915_drv.c,
 which is not a conflict.)
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Acked-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the requested device is already active, ignore the request.

This restores the original behaviour of the interface. The change was
probably an unintended side effect of

commit 66b37c67 vga_switcheroo: split switching into two stages

which did not take into account to duplicate the !active check in the split-off
stage2.

Fix this by factoring that check out of stage1 into the debugfs_write routine.

References: https://bugzilla.kernel.org/show_bug.cgi?id=34252Reported-by: NIgor Murzov <e-mail@date.by>
Tested-by: NIgor Murzov <e-mail@date.by>
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>