PBIAS voltage should be set along with setting vqmmc voltage and
these voltages should be set as part of start_signal_voltage_switch
callback. However since omap_hsmmc is about to be deprecated,
remove setting of PBIAS voltage leaving the PBIAS voltage to be
at the reset value of 3.3V (we'll never have to change this to 1.8V
since UHS mode support will not be added to omap_hsmmc). This will
let pbias regulator driver to be fixed to support a maximum voltage of
3.3V.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf 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: Will Newton <willn@resin.io>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf 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: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Ulf 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 a04e6bae9e ("mmc: core: check also R1 response for
stop commands") exposed this bug in omap_hsmmc driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Remove unused callbacks in the omap_hsmmc_platform_data structure
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
devm_pinctrl_get() returns error pointers, it never returns NULL.
Fixes: 455e5cd6f7 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fixes: a45c6cb816 ("[ARM] 5369/1: omap mmc: Add new omap
hsmmc controller for 2430 and 34xx, v3")
when using really large timeout (up to 4*60*1000 ms for bkops)
there is a possibility of data overflow using
unsigned int so use 64 bit unsigned long long.
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
commit e2bf08d643 ("omap_hsmmc: set a large data timeout for
commands with busy signal") sets an arbitrary timeout value (100ms) for
commands like CMD6 (MMC SWITCH). However extended CSD register defined
in the eMMC standard has a field for GENERIC_CMD6_TIME which indicates
the default maximum timeout for a SWITCH command.
Use busy_timeout of cmd structure (populated with GENERIC_CMD6_TIME
in the case of SWITCH command) to program the data timeout value in
omap_hsmmc driver.
SWITCH command to turn the cache on took more than 100ms to complete
with MICRON eMMC card present in AM572x IDK REV 1.3A resulting in
timeout and failed enumeration. It is fixed here by programming the
timeout with the value advertised in GENERIC_CMD6_TIME.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When CEB (command end bit error) occurs
reset CMD line to avoid system ending up in
erroneous state.
While command line is reset for CTO and CCRC errors,
it's not done for CEB error. Fix it here.
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The void (*pre_req) callback in the struct mmc_host_ops vtable
is passing an argument "is_first_req" indicating whether this is
the first request or not.
None of the in-kernel users use this parameter: instead, since
they all just do variants of dma_map* they use the DMA cookie
to indicate whether a pre* callback has already been done for
a request when they decide how to handle it.
Delete the parameter from the callback and all users, as it is
just pointless cruft.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It is wrong to use uninitialized dma_slave_config and configure only
certain fields as the DMAengine driver might look at non initialized
(random data) fields and tries to interpret it.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
With the new dma_request_chan() the client driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the driver can now support deferred probing
against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The legacy user space for n900 relies on the MMC slot names.
Let's check if those are passed in pdata and use them.
As this makes the DT booting compatible with legacy booting,
we should be able to start dropping omap3 legacy booting
support in v4.8.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: linux-mmc@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit 9250aea76b ("mmc: core: Enable runtime PM management of host
devices"), made some calls to the runtime PM API from the driver
redundant. Especially those which deals with runtime PM reference
counting, so let's remove them.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
unnecessary indirection via 'struct device' back to omap_hsmmc_host
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When DT based probing is used but the DMA request fails, the
driver will print uninitialized stack data from the rx_req
and tx_req variables, as indicated by this warning:
drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe':
drivers/mmc/host/omap_hsmmc.c:2162:3: warning: 'rx_req' may be used uninitialized in this function [-Wmaybe-uninitialized]
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
This removes the DMA request line number from the warning, which
is the easiest solution and won't hurt us any more as we are
planning to remove the legacy code path anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Since v4.3+, CONFIG_REGULATOR_PBIAS should be enabled (for platforms that
have PBIAS regulator) in order for MMC1 to work.
Add a more verbose print to help enable CONFIG_REGULATOR_PBIAS for users
using a olddefconfig or a custom .config.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit 5de85b9d57 ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.
However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:
omap_device_enable() called from invalid state 1
And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.
The solution is to fix the drivers to follow the PM runtime documentation:
1. For sections of code that needs the device disabled, use
pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
been set.
2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
set.
Fixes: 5de85b9d57 ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver will not probe without valid DMA channels so no need to check
if they are valid when the module is removed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Starting with commit 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc") MMC on omap3 stopped working
for legacy booting.
This is because legacy booting sets up some of the resource in the
platform init code, and for optional regulators always seem to
return -EPROBE_DEFER for the legacy booting.
Let's fix the issue by checking for device tree based booting for
now. Then when omap3 boots in device tree only mode, this patch
can be just reverted.
Fixes: 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit c55d7a0553.
Without reverting this commit we get "unbalanced disables for pbias_mmc_omap4"
errors on omap4430. It seems that 4430 and 4460 behave in a different way for
the PBIAS regulator registers and until that has been debugged further we
cannot rely on the regulator status registers in hardare on 4430.
Fixes: 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Now that support for platforms which have optional regulator is added,
remove CONFIG_REGULATOR check in omap_hsmmc.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
vdd voltage is set in mmc core to ios->vdd and vmmc should actually
be set to this voltage. Modify omap_hsmmc_enable_supply
to not take vdd as argument since now it's directly set to
the voltage in ios->vdd.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use regulator_is_enabled of pbias regulator to find pbias regulator
status instead of maintaining a custom bookkeeping
pbias_enabled variable.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
enable vmmc_aux regulator only if it is in disabled state and disable
vmmc_aux regulator only if it is in enabled state.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If the regulator is enabled on boot (checked using regulator_is_enabled),
invoke regulator_enable() so that the usecount reflects the correct
state of the regulator and then disable the regulator so that the
initial state of the regulator is disabled. Avoid using ->set_power,
since set_power also takes care of setting the voltages which is not
needed at this point.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fix omap_hsmmc_set_power so that pbias regulator is not enabled
during power off.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
No functional change. Cleanup omap_hsmmc_set_power by adding separate
functions to set pbias and invoke it from omap_hsmmc_set_power.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
No functional change. Cleanup omap_hsmmc_set_power by adding separate
functions for enable/disable supply and invoke it from
omap_hsmmc_set_power.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Return error if any of the regulator APIs (regulator_enable,
regulator_disable, regulator_set_voltage) fails in
omap_hsmmc_set_power to avoid undefined behavior.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Remove the unnecessary pbias regulator_set_voltage done after
pbias regulator_disable in omap_hsmmc_set_power.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
No functional change. Instead of using omap_hsmmc_host's vcc and vcc_aux
members, use vmmc and vqmmc present in mmc_host which is present
for the same purpose.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If the vmmc regulator provides a valid ocrmask, use it. By this even if
the pdata has a valid ocrmask, it will be overwritten with the ocrmask
of the vmmc regulator.
Also remove the unnecessary compatibility check between the ocrmask in
the pdata and the ocrmask from the vmmc regulator.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
No functional change. Instead of using a local regulator variable
in omap_hsmmc_reg_get() for holding the return value of
devm_regulator_get_optional() and then assigning to omap_hsmmc_host
regulator members: vcc, vcc_aux and pbias, directly use the
omap_hsmmc_host regulator members.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Now return error only if the return value of
devm_regulator_get_optional() is not the same as -ENODEV, since with
-EPROBE_DEFER, the regulator can be obtained later and all other
errors are fatal.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Since vmmc can be optional for some platforms, use
devm_regulator_get_optional() for vmmc. Now return error only
if the return value of devm_regulator_get_optional() is not the
same as -ENODEV, since with -EPROBE_DEFER, the regulator can be
obtained later and all other errors are fatal.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
If no pdata.set_power was set by the platform code, the driver
was updating pdata with its own fallback function. This is a no-no
since pdata shall be read-only.
This patch pushes the check 'pdata->set_power != NULL' down into
the fallback functions. If pdata.set_power is really set, it calls them
and exits, otherwise the fallback code is used.
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Sometimes BADA, DEB or CEB error interrupts occur when sd card is
unplugged during data transfer. These interrupts are currently ignored
by the interrupt handler. But, this results in card not being
recognised on subsequent insertion. This is because mmcqd is waiting
forever for the data transfer(for which error occurred) to complete.
Fix this, by reporting BADA, DEB, CEB errors to mmc-core as -EILSEQ, so
that the core can do appropriate handling.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ"). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit 'host->data' is checked after
it has been cleared to NULL by omap_hsmmc_dma_cleanup().
Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked
making core layer not to be aware of DTO/DCRC errors. Because of this
any command invoked after DTO/DCRC error leads to a hang.
Fix this by checking for 'host->data' before it is actually cleared.
Fixes: ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
HSMMC IRQ")
CC: stable@vger.kernel.org
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
We can now use generic wakeirq handling and remove the custom handling
for the wake-up interrupts.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
strip the card dectet logic from cover detect isr and vice versa
the generic mmc_gpio_cd_irqt isr, uses 200ms on removal/insertion,
hence that should be fine here as well
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
board-rx51 has no card detect pin in the mmc slot, but can detect that
the (cell-phone) cover has been removed and the card is accessible.
The semantics between cover/card detect differ, the gpio on the slot
informs you after the card has been removed, cover removal does not
necessarily mean that the card has been removed.
This means different code paths are necessary. To complete this we
also want different fields in the platform data for cover and card
detect. This separation is not pushed all the way down into struct
omap2_hsmmc_info which is used to initialize the platform data.
If we did that we had to go over all board files and set the new
gpio_cod pin to -EINVAL. If we forget one board or some out-of-tree
archicture forgets that the default '0' is used which is a valid pin
number.
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The ->enable|disable() callbacks are only used to get and put runtime
PM references. Currently omap_hsmmc's ->set_ios() already does this
itself.
Other host drivers deals with runtime PM without using the
->enable|disable() callbacks and thus do the runtime PM reference
counting themselves. Apply that approach for omap_hsmmc as well and
then discard the ->enable|disable() callbacks.
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Setting a dev_pm_ops suspend/resume pair but not a set of
hibernation functions means those pm functions will not be
called upon hibernation.
Fix this by using SET_SYSTEM_SLEEP_PM_OPS, which appropriately
assigns the suspend and hibernation handlers and move
omap_hsmmc_x callbacks under CONFIG_PM_SLEEP to avoid build warnings.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
[Grygorii.Strashko@linaro.org: rebased on top of K4.0]
Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Mobile phones (some) have no card detect pin, but can detect if the
cover is removed. The purpose is the same; detect if card is being
added/removed, but the details differ.
When the cover is removed, it does not mean the card is gone. But it
might, since it is accessible now. It's like a warning. All the driver
does is to limit write access to the card, see protect_card flag.
In contrast, card detect notifies us after the fact, e.g.
card is gone, card is inserted. We can't take precautions, but we can
rely on those events, -- the card is really gone, or do scan the card.
To summarize there is not much code sharing between cover and card
detect, it only increases confusion. By splitting, both will be
simplified in a followup patch.
Signed-off-by: Andreas Fenkart <afenkart@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
