Add SDHCI driver for Broadcom BRCMSTB SoCs.
This driver works with all ARM based SoCs and the 7425, 7429
and 7435 MIPS based SoCs.

The driver disables all UHS speed modes by default and relies
on the Device Tree node properties to enable these modes for
SoC/Board combinations that support them.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Apparently a cut-and-paste error, 'do_data_tag' is using 'brq' for data
size even though 'brq' has not been set up. Instead use blk_rq_sectors().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used
and hence this patch disables the HPI feature for such buggy cards.

As some of the other features like BKOPs/Cache/Sanitize are dependent on
HPI feature, those features would also get disabled if HPI is disabled.
Signed-off-by: NPratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: NSubhash Jadavani <subhashj@codeaurora.org>
[gdavis: Forward port and cleanup]
Signed-off-by: NGeorge G. Davis <george_davis@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_bus_width() returns bus width (4 or 8) on success or
zero if unsupported. So only change mode if setting the bus width
is successful.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase
size. As some high capacity eMMC (64MB) reports this size to 512kB, the
discard operations end up taking very long time.

Improve the behaviour by instead calculating the preferred erase size
based on the eMMC size. In this way the discard operations becomes faster.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
[Ulf: Updated changelog and improved comment in code]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The sdhci-bcm2835 is no more needed since it has been replaced
by sdhci-iproc.
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To slove the issue which was found on gru board for hs400.

[    4.616946] sdhci: Secure Digital Host Controller Interface driver
[    4.623135] sdhci: Copyright(c) Pierre Ossman
[    4.722575] sdhci-pltfm: SDHCI platform and OF driver helper
[    4.730962] sdhci-arasan fe330000.sdhci: No vmmc regulator found
[    4.737444] sdhci-arasan fe330000.sdhci: No vqmmc regulator found
[    4.774930] mmc0: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[    4.980295] mmc0: switch to high-speed from hs200 failed, err:-84
[    4.986487] mmc0: error -84 whilst initialising MMC card

We should change HS400 mode selection timing to meet JEDEC
specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ
after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode
selection:
Set the "Timing Interface" parameter in the HS_TIMING[185] field of the
Extended CSD register to 0x1 to switch to High Speed mode and then set
the clock frequency to a value not greater than 52MHZ.
Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Per JEDEC spec, it is not recommended to use CMD13 to get card status
after speed mode switch. below are two reason about this:
1. CMD13 cannot be guaranteed due to the asynchronous operation.
Therefore it is not recommended to use CMD13 to check busy completion
of the timing change indication.
2. After switch to HS200, CMD13 will get response of 0x800, and even the
busy signal gets de-asserted, the response of CMD13 is aslo 0x800.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some MMC hosts do not support MMC_CAP_WAIT_WHILE_BUSY, but implements the
->card_busy() callback. In such cases, extend __mmc_switch() to use this
method to check card status after switch command.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

host->card_busy() was introduced for SD voltage switching which checks all
4 data lines.

Increasingly, host->card_busy is being used to poll the the busy signal
which is only data line 0 (DAT[0]).

The current logic in sdhci_card_busy() does not work in that case because
it returns false if any of the data lines is high.  It also ignores
possibilities:
	- data lines 1-3 are not connected and could show at any level
	- data lines 1-2 can be used by SDIO for other purposes

According to the SD specification, it is OK to check any of the data lines
for voltage switching, so change to use DAT[0] only.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Sparse complains about the implicit cast. Making it explicit is indeed
better coding style.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently sdhci-arasan 5.1 can support enhanced strobe function,
and we now limit it just for "arasan,sdhci-5.1". Add
mmc-hs400-enhanced-strobe in DT to enable the function if we're
sure our controller can support it.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We introduce HS400 with enhanced strobe function, so we need
to add it for debug show.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Controllers use data strobe line to latch data from devices
under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC
introduces enhanced strobe mode for latching cmd response from
emmc devices to host controllers. This new feature is optional,
so it depends both on device's cap and host's cap to decide
whether to use it or not.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch introduce mmc-hs400-enhanced-strobe for platforms
which want to enable enhanced strobe function from DT if the
mmc host controller claims to support enhanced strobe.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Activating wakeup event is not enough to get a wakeup signal. The
corresponding events have to be enabled in the Interrupt Status Enable
Register too. It follows the specification and is needed at least by
sdhci-of-at91.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In sectors alignment check, brq->data.blocks means sectors of the
previous mqrq since data.blocks for mqrq_cur hasn't been updated yet.
data.blocks will be updated later in mmc_blk_packed_hdr_wrq_prep or
mmc_blk_rw_rq_prep.

static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, ......
        ......
    struct mmc_blk_request *brq = &mq->mqrq_cur->brq;
Signed-off-by: NYuan Juntao <juntao.yuan@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since commit 7ce45e95 ("mmc: sdhci: SD tuning is broken for some
controllers") sdhci_execute_tuning() no longer includes a timeout in its
loop counter(s) so remove portion of the comment regarding this.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Replace hardcoded values with meaningful names and document what we
know.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

As reported by Dan in his report in [1], there is a potential NULL
pointer derefence if these conditions are met :
 - there is no platform_data provided, ie. host->pdata = NULL

Fix this by only using the platform data ro_invert when a gpio for
read-only is provided by the platform data.

This doesn't appear yet as every pxa board provides a platform_data, and
calls pxa_set_mci_info() with a non NULL pointer.

[1] [bug report] mmc: pxamci: fix card detect with slot-gpio API.
The commit fd546ee6 ("mmc: pxamci: fix card detect with slot-gpio
API") from Sep 26, 2015, leads to the following static checker warning:

	drivers/mmc/host/pxamci.c:809 pxamci_probe()
	warn: variable dereferenced before check 'host->pdata' (see line 798)

Fixes: fd546ee6 ("mmc: pxamci: fix card detect with slot-gpio API")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The code that fills packed command header assumes that CPU runs in
little-endian mode. Hence the header is malformed in big-endian mode
and causes MMC data transfer errors:

[  563.200828] mmcblk0: error -110 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc40
[  563.219647] mmcblk0: packed cmd failed, nr 2, sectors 16, failure index: -1

Convert header data to LE.
Signed-off-by: NTaras Kondratiuk <takondra@cisco.com>
Fixes: ce39f9d1 ("mmc: support packed write command for eMMC4.5 devices")
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Set 'idata->buf' to NULL so that it never gets returned without
initialization. This fixes a bug where mmc_blk_ioctl_cmd() would
free both 'idata' and 'idata->buf' but 'idata->buf' was returned
uninitialized.

Fixes: 1ff8950c ("mmc: block: change to use kmalloc when copy data from userspace")
Signed-off-by: NVille Viinikka <ville@tuxera.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Now the the HS-DDR mode clock timings have been corrected, we can
re-enable these modes on the A80.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.

The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.

The settings for the slower timing modes seem to work despite being
wrong, so leave them be.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.

Fix this by checking for a positive return value instead.

Fixes: 287980e4 ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The CMD19/CMD14 bus width test has been found to be unreliable in
some cases.  It is not essential, so simply remove it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

008GE0 Toshiba mmc in some Intel Baytrail tablets responds to
MMC_SEND_EXT_CSD in 450-600ms.

This patch will...

() Increase the long read time quirk timeout from 300ms to 600ms. Original
   author of that quirk says 300ms was only a guess and that the number
   may need to be raised in the future.

() Add this specific MMC to the quirk
Signed-off-by: NMatt Gumbel <matthew.k.gumbel@intel.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Historically for Rockchip devices we've relied on the power-on
default (or perhaps the firmware setting) to get the correct drive
phase for dw_mmc devices.  This worked OK for the most part, but:

* Relying on the setting just "being right" is a bit fragile.

* As soon as there is an instance where the power on default is wrong or
  where the firmware didn't configure this properly then we'll get a
  mysterious failure.

In commit 7a03fe6f ("clk: rockchip: reset init state before mmc card
initialization") we actually started setting this explicitly in the
kernel, but that commit wasn't quite right and also wasn't quite
enough.  See <https://patchwork.kernel.org/patch/9085311/> for some
details.

Let's explicitly set this phase in dw_mmc.

The comments inside this patch try to explain the situation quite
throughly, but the high level overview of this is:

Before this patch on rk3288 devices tested (after revert of the clock
patch described above):
* eMMC: 180 degrees
* SDMMC/SDIO0/SDIO1: 90 degrees

After this patch:
* Use 90 degree phase offset usually.
* Use 180 degree phase offset for MMC_DDR52, SDR104, HS200.

That means we are _changing_ behavior for those devices in this way:

* If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90
  degrees (vs 180) but otherwise have no change.

* For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at
  90 degrees (vs 180).  It seems fairly unlikely that building modern
  hardware is using an eMMC that isn't using DDR52 or HS200, of course.

* For SDR104 cards we'll now run with 180 degree phase offset (vs 90).
  It's expected that 90 degree phase offset would have worked OK, but
  this gives us extra margin.

I have tested this by inserting my collection of uSD cards (mostly UHS,
though a few not) into a veyron_minnie and confirmed that they still
seem to enumerate properly.  For a subset of them I tried putting a
filesystem on them and also tried running mmc_test.

Fixes: 7a03fe6f ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

According to DesignWare TRM, BLKSIZ is 16bits.
Then it's correct that max_blk_size should be 0xFFFF, not 0x10000.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise
failing to create rpmb partition. With it, we can
get rpmb successfully:

mmc1: new HS200 MMC card at address 0001
mmcblk0: mmc1:0001 DS2016 14.7 GiB
mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB
mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB
mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some devices connected to the SDHCI controller may have separate enabling
lines that are controlled through GPIO. These devices need to be powered
on and enabled before probing. This is to ensure all devices connected can
be seen by the controller.

Note, for "stable" this patch depends on the following change:
commit 78a898d0 ("ACPI / PM: Export acpi_device_fix_up_power()")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reported-and-tested-by: NLaszlo Fiat <laszlo.fiat@gmail.com>
Cc: <stable@vger.kernel.org> # 4.5+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reported-by: NLaszlo Fiat <laszlo.fiat@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571
Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com

Re-tuning is not possible when switched to the RPMB
partition.  However re-tuning should not be needed
if re-tuning is done immediately before switching,
a small set of operations is done, and then we
immediately switch back to the main partition.

A previous patch ensured that we immediately switch
back to the main partition.

This patch uses the new facility to "pause" re-tuning
before switching to the RPMB partition, and to "unpause"
it after switching from the RPMB partition.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation to support the use of the RPMB partition with transfer
modes that might require re-tuning, always switch back to the main
area after RPMB access.

RPMB is accessible only via IOCTL so only those paths are affected.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Re-tuning is not possible when switched to the RPMB
partition.  However re-tuning should not be needed
if re-tuning is done immediately before switching,
a small set of operations is done, and then we
immediately switch back to the main partition.

To ensure that re-tuning can't be done for a short
while, add a facility to "pause" re-tuning.

The existing facility to hold / release re-tuning
is used but it also flags re-tuning as needed to cause
re-tuning before the next command (which will be the
switch to RPMB).

We also need to "unpause" in the recovery path, which
is catered for by adding it to mmc_retune_disable().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some eMMCs set the partition switch timeout too low.

Now typically eMMCs are considered a critical component (e.g. because
they store the root file system) and consequently are expected to be
reliable.  Thus we can neglect the use case where eMMCs can't switch
reliably and we might want a lower timeout to facilitate speedy
recovery.

Although we could employ a quirk for the cards that are affected (if
we could identify them all), as described above, there is little
benefit to having a low timeout, so instead simply set a minimum
timeout.

The minimum is set to 300ms somewhat arbitrarily - the examples that
have been seen had a timeout of 10ms but were sometimes taking 60-70ms.

Cc: stable@vger.kernel.org
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Tested on a Salvator-X board with a Spectec SDW-823 WLAN card.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

I have two SDIO WLAN cards which specify being SDIO Rev. 1.1 cards but
their FUNCE tuple reports the smaller size of a Rev 1.0 card. So,
enforce 1.0 on these cards to avoid reading the not present registers.
They are not really used anyhow. My cards initialize properly after this
patch.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>