Our hardware engineers confirmed that it is unnecessary to wait when
turning the clock on/off. The documentation was a tad vague, so we
used to play safe.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use a proper define.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When defining bits, make sure we always have a reference to the register
they belong to. For now, renaming all bits properly seems too intrusive,
so at least make sure we have proper documentation.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since commit 10c7fcbd ("ARM: shmobile: sh7372: Remove ZBOOT
MMC/SDHI support"), this define is not needed anymore.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

I always anticipated this code to be not correct, but now I had a test
case to prove it. According to all documentation I have, setting the
TMIO_STOP_STP bit ever only worked during block transfers. This bit is
like manually enforcing an autocmd12 during a so far seamless transfer.
It does NOT work when the block transfer had errors. It also does NOT
work with any other cmd except block commands. For all those, CMD12 has
to be treated like any other command. So, basically, we could use this
bit only for mrq->data->stop cmds. But for these, we happily use the
autocmd12 feature using the TMIO_STOP_SEC bit. As a result, the above
bit is not useful for us and we need to treat CMD12 as a regular cmd
always. Just remove the special handling code. Note that the BSP
recognized this issue as well yet had a more cautious solution to the
problem [1]. Which is understandable but makes CMD12 handling even more
complicated.

Checked with a Renesas Salvator-X/M3-W which needed to send CMD12 when
retuning one of my SD cards.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=2838a2ff8ca776f6d18b7fbbe75f3df8dd64183aSigned-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NJan Klötzke <jan.kloetzke@preh.de>
Tested-by: NNguyen Viet Dung <dung.nguyen.aj@renesas.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

platform_get_irq() returns an error code, but the mxcmmc driver
ignores it and always returns -EINVAL. This is not correct,
and prevents -EPROBE_DEFER from being propagated properly.

Print error message and propagate the return value of
platform_get_irq on failure.
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Local variable transfer_error is assigned to a constant value and
it is never updated again.

Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 1222110
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

shdci-st driver can be used for ppc476 fsp2 soc.
Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Reduce max_segs to 64, a value that allows allocation of an entire
EDMA descriptor list within a single page - EDMA descriptors
are 40 bytes and the header is much larger. This avoids doing a
higher order GFP_ATOMIC allocation in edma_prep_slave_sg
when setting up a transfer which can potentially fail due to
fragmentation under heavy I/O load.

The current value of 1024 is unusually high in comparison to
other mmc host drivers which mostly use values of between 1
and 256. The EDMA driver at present splits lists above 20
segments in any case so reducing the size of lists we pass to
it shouldn't add much overhead.
Signed-off-by: NWill Newton <willn@resin.io>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add a new variant of the SDHI driver to support R-Car Gen3 with DMA via
on-chip bus mastering.  Since the DMAC is in a part of the SDHI module it
is not suitable to be used via DMA Engine.

Clearing of DM_CM_INFO1 after DMA thanks to Dirk Behme

Cc: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NAi Kyuse <ai.kyuse.uw@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add dataend to DMA ops to allow DMAC implementation dependent
handling of DMA data end.

Also implement the operation for SDHI.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Allow TMIO and SDHI driver implementations to provide values for
max_segs and max_blk_count.

A follow-up patch will set these values for Renesas Gen3 SoCs
the using an SDHI driver.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NAi Kyuse <ai.kyuse.uw@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

dev_pm_ops are not supposed to change at runtime. All functions
working with dev_pm_ops provided by <linux/device.h> work with const
dev_pm_ops. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
  11586	    624	      0	  12210	   2fb2	drivers/mmc/host/omap_hsmmc.o

File size After adding 'const':
   text	   data	    bss	    dec	    hex	filename
  11778	    432	      0	  12210	   2fb2	drivers/mmc/host/omap_hsmmc.o
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

omap_hsmmc driver always relied on CMD12 to stop transmission.
However if CMD12 is not issued at the correct timing, the card will
indicate a out of range error. With certain cards in some of the
DRA7 based boards, -EIO error is observed. By Adding CMD23 capability,
the MMC core will send MMC_SET_BLOCK_COUNT command before
MMC_READ_MULTIPLE_BLOCK/MMC_WRITE_MULTIPLE_BLOCK commands.

commit a04e6bae ("mmc: core: check also R1 response for
stop commands") exposed this bug in omap_hsmmc driver.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When the device is non removable, the card detect signal is often used
for another purpose i.e. muxed to another SoC peripheral or used as a
GPIO. It could lead to wrong behaviors depending the default value of
this signal if not muxed to the SDHCI controller.

Fixes: bb5f8ea4 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
Signed-off-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Change to print the information about when the deprecated "num-slots" DT
binding is being used, as to avoid confusion when browsing the log:

dwmmc_rockchip fe320000.dwmmc: 'num-slots' was deprecated.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Fixes: d30a8f7b ("mmc: dw_mmc: deprecated the "num-slots" property")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove unused callbacks in the omap_hsmmc_platform_data structure
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The register for the "new timing mode" also has bit fields for setting
output and sample timing phases. According to comments in Allwinner's
BSP kernel, the default values are good enough.

Keep the default values already in the hardware when setting new timing
mode, instead of overwriting the whole register.

Fixes: 9a37e53e ("mmc: sunxi: Enable the new timings for the A64 MMC
controllers")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The existing code gives an incorrect pointer value.
The buffer pointer 'buf' was of type unsigned short *, and 'count' was a
number in bytes. A cast of buf should have been used.

However, instead of casting, just change the code to use u32 pointers.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: 8185e51f: ("mmc: tmio-mmc: add support for 32bit data port")
Signed-off-by: NChris Brandt <chris.brandt@renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

__GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to
the page allocator.  This has been true but only for allocations
requests larger than PAGE_ALLOC_COSTLY_ORDER.  It has been always
ignored for smaller sizes.  This is a bit unfortunate because there is
no way to express the same semantic for those requests and they are
considered too important to fail so they might end up looping in the
page allocator for ever, similarly to GFP_NOFAIL requests.

Now that the whole tree has been cleaned up and accidental or misled
usage of __GFP_REPEAT flag has been removed for !costly requests we can
give the original flag a better name and more importantly a more useful
semantic.  Let's rename it to __GFP_RETRY_MAYFAIL which tells the user
that the allocator would try really hard but there is no promise of a
success.  This will work independent of the order and overrides the
default allocator behavior.  Page allocator users have several levels of
guarantee vs.  cost options (take GFP_KERNEL as an example)

 - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_
   attempt to free memory at all. The most light weight mode which even
   doesn't kick the background reclaim. Should be used carefully because
   it might deplete the memory and the next user might hit the more
   aggressive reclaim

 - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic
   allocation without any attempt to free memory from the current
   context but can wake kswapd to reclaim memory if the zone is below
   the low watermark. Can be used from either atomic contexts or when
   the request is a performance optimization and there is another
   fallback for a slow path.

 - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) -
   non sleeping allocation with an expensive fallback so it can access
   some portion of memory reserves. Usually used from interrupt/bh
   context with an expensive slow path fallback.

 - GFP_KERNEL - both background and direct reclaim are allowed and the
   _default_ page allocator behavior is used. That means that !costly
   allocation requests are basically nofail but there is no guarantee of
   that behavior so failures have to be checked properly by callers
   (e.g. OOM killer victim is allowed to fail currently).

 - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior
   and all allocation requests fail early rather than cause disruptive
   reclaim (one round of reclaim in this implementation). The OOM killer
   is not invoked.

 - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator
   behavior and all allocation requests try really hard. The request
   will fail if the reclaim cannot make any progress. The OOM killer
   won't be triggered.

 - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior
   and all allocation requests will loop endlessly until they succeed.
   This might be really dangerous especially for larger orders.

Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL
because they already had their semantic.  No new users are added.
__alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if
there is no progress and we have already passed the OOM point.

This means that all the reclaim opportunities have been exhausted except
the most disruptive one (the OOM killer) and a user defined fallback
behavior is more sensible than keep retrying in the page allocator.

[akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c]
[mhocko@suse.com: semantic fix]
  Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz
[mhocko@kernel.org: address other thing spotted by Vlastimil]
  Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz
Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Alex Belits <alex.belits@cavium.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: David Daney <david.daney@cavium.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: NeilBrown <neilb@suse.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

GPDwin uses PCI wifi which conflicts with SDIO's use of
acpi_device_fix_up_power() on child device nodes. Specifically
acpi_device_fix_up_power() causes the wifi module to get turned off.
Identifying GPDwin is problematic, but since SDIO is only used for wifi,
the presence of the PCI wifi card in the expected slot with an ACPI
companion node, is used to indicate that acpi_device_fix_up_power() should
be avoided.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove the unnecessary slot variable.
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>

Remove the 'cur_slot'. Instead, just use 'slot'.
There is no multiple slots, so we need to consider only one slot.
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>

Doesn't need to pass the id value for slot functions.
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>

It doesn't need to use the array of slots anymore.
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>

dwmmc controller has used the only one slot.
It doesn't need to check the other slots.
Remove the loop about finding slots.
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>

dwmmc controller is supporting only one slot per a IP.
Even though DWMMC IP is provided the multiple slot, but there is no
usage in real world.
In mmc subsystem, not allow the multiple slot concept.
Then "num-slots" property is deprecated.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.comi>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently we unconditionally do tuning for each degree, which
costs 900ms for each boot and resume.

May someone argue that this is a question of accuracy VS time. But I
would say it's a trick of how we need to do decision for our boards.
If we don't care the time we spend at all, we could definitely do tuning
for each degree. But when we need to improve the user experience, for
instance, speed up resuming from S3, we should also have the right to
do that. This patch add parsing "rockchip,desired-num-phases", for folks
to specify the number of doing tuning. If not specified, 360 will be used
as before.
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>

Trivial updates to improve checkpatch cleanness.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Trivial updates to improve checkpatch cleanness.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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

The MMC_CAP2_HC_ERASE_SZ is used only by a few mmc host drivers. Its intent
is to enable eMMC's high-capacity erase size, as to improve the behaviour
of the erase operations.

We should strive to avoid software configuration options that aren't
necessary, but instead deploy common behaviours. For these reasons, let's
remove the capability bit for MMC_CAP2_HC_ERASE_SZ and make it the default
behaviour.

Note that this change doesn't affect eMMCs supporting trim/discard, because
these commands operates on sectors and takes precedence over erase
commands.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NShawn Lin <shawn.lin@rock-chips.com>

In preparation for using the generic mmc binding for io regulator
("vqmmc"), use mmc_regulator_get_supply() to get vmmc and vqmmc regulators.
Only if "vqmmc" regulator isn't found, fallback to use "vmmc_aux"
regulator.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Do not initialize MMC regulators to NULL on error in omap_hsmmc driver
similar to what is done in mmc_regulator_get_supply(). This is in
preparation for using mmc_regulator_get_supply() to get MMC
regulators.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add PCI ids and enhanced strobe support for Intel CNP. This is combined
with GLK due to the pending CMDQ support which they both share.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Update copyrights to reflect work by Wolfram Sang and myself since last
year.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use EXPORT_SYMBOL_GPL rather than the non _GPL variant as there seems to be
no reason not to.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The acpi-subsys already calls acpi_bus_get_status() and checks that
device->status.present is set before even registering the platform_device
so out probe function will never get called if device->status.present is
false and there is no need for this check.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

To achieve that, we set the registers in the generic HW reset routine
which gets called at both, init and resume. We also make sure to move
SDIO initialization before reset gets called in probe().
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NMasaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>