[   17.024963] EDAC DEBUG: get_memory_layout: TOHM: 132.160 GB (0x0000002043ffffff)<7>[   17.024971] EDAC DEBUG: get_memory_layout: SAD#0 DRAM up to 33.792 GB (0x0000000840000000) Interleave: 8:6 reg=0x000083c3
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are no more embedded kobjects in struct mem_ctl_info. Remove a header and
a comment that does not reflect the code anymore.
Signed-off-by: NShaun Ruffell <sruffell@digium.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This commit changes the CMA early initialization code to use phys_addr_t
for representing physical addresses instead of unsigned long.

Without this change, among other things, dma_declare_contiguous() simply
discards any memory regions whose address is not representable as unsigned
long.

This is a problem on 32-bit PAE machines where unsigned long is 32-bit
but physical address space is larger.
Signed-off-by: NVitaly Andrianov <vitalya@ti.com>
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>

Some gate clocks have special needs which must be handled during the
disable-unused clocks sequence.  These needs might be driven by software
due to the fact that we're disabling a clock outside of the normal
clk_disable path and a clk's enable_count will not be accurate.  On the
other hand a specific hardware programming sequence might need to be
followed for this corner case.

This change is needed for the upcoming OMAP port to the common clock
framework.  Specifically, it is undesirable to treat the disable-unused
path identically to the normal clk_disable path since other software
layers are involved.  In this case OMAP's clockdomain code throws WARNs
and bails early due to the clock's enable_count being set to zero.  A
custom callback mitigates this problem nicely.

Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

The matrix-keymap module is currently lacking a proper module license,
add one so we don't have this module tainting the entire kernel.  This
issue has been present since commit 1932811f ("Input: matrix-keymap
- uninline and prepare for device tree support")
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
CC: stable@vger.kernel.org # v3.5+
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commits a5091539 and
d7c3b937.

This is a revert of a revert of a revert.  In addition, it reverts the
even older i915 change to stop using the __GFP_NO_KSWAPD flag due to the
original commits in linux-next.

It turns out that the original patch really was bogus, and that the
original revert was the correct thing to do after all.  We thought we
had fixed the problem, and then reverted the revert, but the problem
really is fundamental: waking up kswapd simply isn't the right thing to
do, and direct reclaim sometimes simply _is_ the right thing to do.

When certain allocations fail, we simply should try some direct reclaim,
and if that fails, fail the allocation.  That's the right thing to do
for THP allocations, which can easily fail, and the GPU allocations want
to do that too.

So starting kswapd is sometimes simply wrong, and removing the flag that
said "don't start kswapd" was a mistake.  Let's hope we never revisit
this mistake again - and certainly not this many times ;)
Acked-by: NMel Gorman <mgorman@suse.de>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Extracting a part of the SDHCI card tasklet into a .card_event()
implementation allows SDHCI hosts to use generic card-detection
services, e.g. the GPIO slot function.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The slot-gpio API provides a generic card-detection handler. To support a
wider range of hosts it has to call the host's card-event callback, if
implemented. Also increase the debounce interval to 200ms to match the
SDHCI driver.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

'sc' is used only when CONFIG_PM_RUNTIME is defined. Hence define it
conditionally.

Silences the following warning:
drivers/mmc/host/sdhci-s3c.c: In function ‘sdhci_s3c_notify_change’:
drivers/mmc/host/sdhci-s3c.c:378:20: warning: unused variable ‘sc’ [-Wunused-variable]
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The Ricoh SDHCI controllers support Highspeed clocks as evident from
the ricoh_mmc_probe_slot() settings. Hence, SDHCI_CAN_DO_HISPD needs
to be set to enable SDIO client drivers to set/enable high speed clock
settings
Signed-off-by: NMadhvapathi Sriram <Madhvapathi.Sriram@csr.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This commit taken from Rabeeh's Cubox kernel and re-worked for DT;
Sebastian Hasselbrath is believed to be the original author.

Some Cuboxes require a GPIO for card detection; this implements the
optional GPIO support for card detection.  This GPIO is logic 0 for
card inserted.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NChris Ball <cjb@laptop.org>

We need to use the two-stage initialization for sdhci-pltfm if we're
going to do anything extra at initialization time.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use devm_clk_get() rather than clk_get() to make cleanup paths more simple.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NChris Ball <cjb@laptop.org>

A-003500: False ADMA Error might be reported when ADMA is used for
multiple block read command with Stop at Block Gap. If PROCTL[SABGREQ]
is set when the particular block's data is received by the System side
logic before entire block (with CRC) data is received by the SD side
logic, and also if ADMA descriptor line is fetched at the same time,
then DMA engine might report false ADMA error. eSDHC might not be able
to Continue (PROCTL[CREQ]=1) after Stop at Block Gap.
This issue will impact the eSDHC IP VVN2.3.
Signed-off-by: NHaijun Zhang <Haijun.Zhang@freescale.com>
Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

ctype is using 1-bit buswidth mode by default.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

To ensure the stable clock need to enable before set the
DW_MMC_CARD_NEED_INIT flag.  If set DW_MMC_CARD_NEED_INIT flag,
wait for 80-clock before first command after power-up.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

If "caps2" host capabilities does not indicate support for MMC
HS200, don't allow clock speeds >52MHz. Currently, for MMC, the
clock speed is set to the lesser of the max speed the eMMC module
supports (card->ext_csd.hs_max_dtr) or the max base clock of the
host controller (host->f_max based on BASE_CLK_FREQ in the host
CAPS register). This means that a host controller that doesn't
support HS200 mode but has a base clock of 100MHz and an eMMC module
that supports HS200 speeds will end up using a 100MHz clock.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use managed device resource functions for easy handling.
This makes driver simpler in the routine of error and exit.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

MMCIF only uses one clock, all ARM and SuperH platforms register MMCIF
clock lookup entries with no connection ID, hence it can be dropped in
the driver too.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NChris Ball <cjb@laptop.org>

SDHI only uses one clock, all ARM and SuperH platform register SDHI clock
lookup entries with no connection ID, hence it can be dropped in the
driver too.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NChris Ball <cjb@laptop.org>

During its probing the SDHI driver prints out the clock frequency, but
does it wrongly, always reporting 0Hz. Use the MMC host frequency value
to fix this issue.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NChris Ball <cjb@laptop.org>

kfree on a null pointer is a no-op.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

kfree on a null pointer is a no-op.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use devm_kzalloc, devm_gpio_request_one and devm_request_irq to make
cleanup path simpler.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.

However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available, so attempting to
switch to the 1.8v level will result in a situation that cannot be
recovered from without physically replugging the SD card.

Add a device tree flag that can be used on systems like these,
and hook it up to the equivalent SDHCI quirk.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.

However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available.

Add a quirk so that systems such as this one can override disable
1.8v support, adding support for UHS-I cards (by running them at
3.3v).

This avoids a problem where the system would first try to run the
card at 1.8v, fail, and then not be able to fully reset the card
to retry at the normal 3.3v voltage.

This is more appropriate than using the MISSING_CAPS quirk, which
is intended for cases where the SDHCI controller is actually lying
about its capabilities, and would force us to somehow override both
caps words from another source.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Suspend methods provided by SDIO drivers are not supposed to be called by
the PM core.  Instead, when the SDIO core gets to suspend a device's
ancestor, it calls the device driver's suspend routine.  However, the PM
core executes suspend callback routines directly for device drivers whose
bus types don't provide suspend callbacks.  In consequece, because the
SDIO bus type doesn't provide a suspend callback, the SDIO drivers'
suspend routines will be executed by the PM core (which shouldn't
happen).

To prevent this from happening, add empty system suspend/resume callbacks
for the SDIO bus type.

An analogous change had been made already by commit (e841a7c6 mmc: sdio:
Use empty system suspend/resume callbacks at the bus level), but then it
was reverted inadvertently by commit (d8e2ac33 mmc: sdio: Fix PM_SLEEP
related build warnings) that attempted to fix build warnings introduced
by commit e841a7c6.
Reported-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add missing usb_put_dev on failure path in vub300_probe().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NMarina Makienko <makienko@ispras.ru>
Signed-off-by: NChris Ball <cjb@laptop.org>

clk_{un}prepare is mandatory for platforms using common clock
framework. Because for SPEAr we don't do anything in clk_{un}prepare()
calls, just call them once in probe/remove.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

SPEAr sdhci driver expects the clock to be set to 50 MHz for proper
functioning.  This patch sets clk to 50 MHz in probe.
Signed-off-by: NVipul Kumar Samar <vipulkumar.samar@st.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds support for pin configuration using pinctrl subsystem
to the sdhci-s3c driver.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Acked-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The set of GPIO pins used by sdhci-s3c driver varies between
configurations, such as card detect method, pinctrl availability, etc.
This overly complicates the code requesting and freeing GPIO pins, which
must check which pins are used, when freeing them.

This patch modifies the sdhci-s3c driver to use devm_gpio_request to
free requested pins automatically after unbinding the driver.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Acked-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The IP versions older than 2.3 didn't support commands with busy
response which expect the TC bit set. But after the VVN2.3, eSDHC
IP has supported it.
Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The third argument for of_get_property() is a pointer, hence pass
NULL instead of 0.

Fixes the following sparse warning:
sdhci-s3c.c:452:48: warning: Using plain integer as NULL pointer
sdhci-s3c.c:457:52: warning: Using plain integer as NULL pointer
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).

Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled by default.  No functional changes.
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fatal errors for the driver are not reported when just error debug
is enabled. Convert selected dev_dbg to dev_err for accurate error
reporting.
Reported-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

prepare() is supposed to prevent new children from being registered.
On the MMC subsystem, children (new cards) registration starts with
the card detect IRQ.

Move card detect IRQ disabling to prepare() so that no new cards
will be registered while we're trying to suspend.

Likewise, move card detect IRQ enabling to complete() so we only
try to register new children after our MMC IP is back up.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.

From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation):

The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.

There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
  capabilities register and
- MMC/SD clock coming out of controller > 25MHz
Signed-off-by: NHebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Update error code to cmd->error for commands with response_busy and no data.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Avoid soft reset of command internal state machine on data errors.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>