28 May, 2016
1 commit
-
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: Arnd Bergmann
Cc: Andrzej Hajda
Cc: Andrew Morton
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla # For nvmem part
Signed-off-by: Linus Torvalds
27 May, 2016
1 commit
-
Pull MMC fixes from Ulf Hansson:
"Here are some mmc fixes intended for v4.7 rc1. They are based on a
commit earlier in the merge window and have been tested in linux-next
for a while.MMC core:
- Prevent re-tuning while serving requests for RPMB partitions
- Extend timeout for long read time quirk to support more eMMCsMMC host:
- sdhci-acpi: Ensure connected devices are powered when probing
- sdhci-pci|acpi: Remove unreliable MMC_CAP_BUS_WIDTH_TEST for Intel HWs
- dw_mmc: Correct the assigning of max_blk_size
- dw_mmc-rockchip: Allow RPMB partitions to be created
- dw_mmc-rockchip: Set the drive phase properly"* tag 'mmc-v4.7-rc1' of git://git.linaro.org/people/ulf.hansson/mmc:
mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers
mmc: sdhci-pci: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers
mmc: longer timeout for long read time quirk
mmc: dw_mmc: rockchip: Set the drive phase properly
mmc: dw_mmc: fix the wrong max_blk_size
mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities
mmc: sdhci-acpi: Ensure connected devices are powered when probing
ACPI / PM: Export acpi_device_fix_up_power()
mmc: block: Pause re-tuning while switched to the RPMB partition
mmc: block: Always switch back to main area after RPMB access
mmc: core: Add a facility to "pause" re-tuning
23 May, 2016
6 commits
-
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: Adrian Hunter
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson -
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: Adrian Hunter
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson -
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: Matt Gumbel
Signed-off-by: Adrian Hunter
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson -
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 7a03fe6f48f3 ("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 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 degreesAfter 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: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: Douglas Anderson
Reviewed-by: Shawn Lin
Tested-by: Heiko Stuebner
Tested-by: Enric Balletbo i Serra
Signed-off-by: Jaehoon Chung
Signed-off-by: Ulf Hansson -
According to DesignWare TRM, BLKSIZ is 16bits.
Then it's correct that max_blk_size should be 0xFFFF, not 0x10000.Signed-off-by: Jaehoon Chung
Reviewed-by: Shawn Lin
Signed-off-by: Ulf Hansson -
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 MiBSigned-off-by: Shawn Lin
Signed-off-by: Jaehoon Chung
Signed-off-by: Ulf Hansson
21 May, 2016
1 commit
-
Pull tty and serial driver updates from Greg KH:
"Here's the large TTY and Serial driver update for 4.7-rc1.A few new serial drivers are added here, and Peter has fixed a bunch
of long-standing bugs in the tty layer and serial drivers as normal.
Full details in the shortlog.All of these have been in linux-next for a while with no reported
issues"* tag 'tty-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (88 commits)
MAINTAINERS: 8250: remove website reference
serial: core: Fix port mutex assert if lockdep disabled
serial: 8250_dw: fix wrong logic in dw8250_check_lcr()
tty: vt, finish looping on duplicate
tty: vt, return error when con_startup fails
QE-UART: add "fsl,t1040-ucc-uart" to of_device_id
serial: mctrl_gpio: Drop support for out1-gpios and out2-gpios
serial: 8250dw: Add device HID for future AMD UART controller
Fix OpenSSH pty regression on close
serial: mctrl_gpio: add IRQ locking
serial: 8250: Integrate Fintek into 8250_base
serial: mps2-uart: add support for early console
serial: mps2-uart: add MPS2 UART driver
dt-bindings: document the MPS2 UART bindings
serial: sirf: Use generic uart-has-rtscts DT property
serial: sirf: Introduce helper variable struct device_node *np
serial: mxs-auart: Use generic uart-has-rtscts DT property
serial: imx: Use generic uart-has-rtscts DT property
doc: DT: Add Generic Serial Device Tree Bindings
serial: 8250: of: Make tegra_serial_handle_break() static
...
20 May, 2016
1 commit
-
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 78a898d0e395 ("ACPI / PM: Export acpi_device_fix_up_power()")Signed-off-by: Adrian Hunter
Reported-and-tested-by: Laszlo Fiat
Cc: # 4.5+
Signed-off-by: Ulf Hansson
Reported-by: Laszlo Fiat
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112571
Link: http://lkml.kernel.org/r/CA+7w51inLtQSr656bJvOjGG9oQWKYPXH+xxDPJKbeJ=CcrkS9Q@mail.gmail.com
18 May, 2016
1 commit
-
Pull block driver updates from Jens Axboe:
"On top of the core pull request, this is the drivers pull request for
this merge window. This contains:- Switch drivers to the new write back cache API, and kill off the
flush flags. From me.- Kill the discard support for the STEC pci-e flash driver. It's
trivially broken, and apparently unmaintained, so it's safer to
just remove it. From Jeff Moyer.- A set of lightnvm updates from the usual suspects (Matias/Javier,
and Simon), and fixes from Arnd, Jeff Mahoney, Sagi, and Wenwei
Tao.- A set of updates for NVMe:
- Turn the controller state management into a proper state
machine. From Christoph.- Shuffling of code in preparation for NVMe-over-fabrics, also
from Christoph.- Cleanup of the command prep part from Ming Lin.
- Rewrite of the discard support from Ming Lin.
- Deadlock fix for namespace removal from Ming Lin.
- Use the now exported blk-mq tag helper for IO termination.
From Sagi.- Various little fixes from Christoph, Guilherme, Keith, Ming
Lin, Wang Sheng-Hui.- Convert mtip32xx to use the now exported blk-mq tag iter function,
from Keith"* 'for-4.7/drivers' of git://git.kernel.dk/linux-block: (74 commits)
lightnvm: reserved space calculation incorrect
lightnvm: rename nr_pages to nr_ppas on nvm_rq
lightnvm: add is_cached entry to struct ppa_addr
lightnvm: expose gennvm_mark_blk to targets
lightnvm: remove mgt targets on mgt removal
lightnvm: pass dma address to hardware rather than pointer
lightnvm: do not assume sequential lun alloc.
nvme/lightnvm: Log using the ctrl named device
lightnvm: rename dma helper functions
lightnvm: enable metadata to be sent to device
lightnvm: do not free unused metadata on rrpc
lightnvm: fix out of bound ppa lun id on bb tbl
lightnvm: refactor set_bb_tbl for accepting ppa list
lightnvm: move responsibility for bad blk mgmt to target
lightnvm: make nvm_set_rqd_ppalist() aware of vblks
lightnvm: remove struct factory_blks
lightnvm: refactor device ops->get_bb_tbl()
lightnvm: introduce nvm_for_each_lun_ppa() macro
lightnvm: refactor dev->online_target to global nvm_targets
lightnvm: rename nvm_targets to nvm_tgt_type
...
17 May, 2016
4 commits
-
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: Adrian Hunter
Signed-off-by: Ulf Hansson -
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: Adrian Hunter
Signed-off-by: Ulf Hansson -
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: Adrian Hunter
Signed-off-by: Ulf Hansson -
Pull power management updates from Rafael Wysocki:
"The majority of changes go into the cpufreq subsystem this time.To me, quite obviously, the biggest ticket item is the new "schedutil"
governor. Interestingly enough, it's the first new cpufreq governor
since the beginning of the git era (except for some out-of-the-tree
ones).There are two main differences between it and the existing governors.
First, it uses the information provided by the scheduler directly for
making its decisions, so it doesn't have to track anything by itself.
Second, it can invoke drivers (supporting that feature) to adjust CPU
performance right away without having to spawn work items to be
executed in process context or similar. Currently, the acpi-cpufreq
driver is the only one supporting that mode of operation, but then it
is used on a large number of systems.The "schedutil" governor as included here is very simple and mostly
regarded as a foundation for future work on the integration of the
scheduler with CPU power management (in fact, there is work in
progress on top of it already). Nevertheless it works and the
preliminary results obtained with it are encouraging.There also is some consolidation of CPU frequency management for ARM
platforms that can add their machine IDs the the new stub dt-platdev
driver now and that will take care of creating the requisite platform
device for cpufreq-dt, so it is not necessary to do that in platform
code any more. Several ARM platforms are switched over to using this
generic mechanism.In addition to that, the intel_pstate driver is now going to respect
CPU frequency limits set by the platform firmware (or a BMC) and
provided via the ACPI _PPC object.The devfreq subsystem is getting a new "passive" governor for SoCs
subsystems that will depend on somebody else to manage their voltage
rails and its support for Samsung Exynos SoCs is consolidated.The rest is support for new hardware (Intel Broxton support in
intel_idle for one example), bug fixes, optimizations and cleanups in
a number of places.Specifics:
- New cpufreq "schedutil" governor (making decisions based on CPU
utilization information provided by the scheduler and capable of
switching CPU frequencies right away if the underlying driver
supports that) and support for fast frequency switching in the
acpi-cpufreq driver (Rafael Wysocki)- Consolidation of CPU frequency management on ARM platforms allowing
them to get rid of some platform-specific boilerplate code if they
are going to use the cpufreq-dt driver (Viresh Kumar, Finley Xiao,
Marc Gonzalez)- Support for ACPI _PPC and CPU frequency limits in the intel_pstate
driver (Srinivas Pandruvada)- Fixes and cleanups in the cpufreq core and generic governor code
(Rafael Wysocki, Sai Gurrappadi)- intel_pstate driver optimizations and cleanups (Rafael Wysocki,
Philippe Longepe, Chen Yu, Joe Perches)- cpufreq powernv driver fixes and cleanups (Akshay Adiga, Shilpasri
Bhat)- cpufreq qoriq driver fixes and cleanups (Jia Hongtao)
- ACPI cpufreq driver cleanups (Viresh Kumar)
- Assorted cpufreq driver updates (Ashwin Chaugule, Geliang Tang,
Javier Martinez Canillas, Paul Gortmaker, Sudeep Holla)- Assorted cpufreq fixes and cleanups (Joe Perches, Arnd Bergmann)
- Fixes and cleanups in the OPP (Operating Performance Points)
framework, mostly related to OPP sharing, and reorganization of
OF-dependent code in it (Viresh Kumar, Arnd Bergmann, Sudeep Holla)- New "passive" governor for devfreq (for SoC subsystems that will
rely on someone else for the management of their power resources)
and consolidation of devfreq support for Exynos platforms, coding
style and typo fixes for devfreq (Chanwoo Choi, MyungJoo Ham)- PM core fixes and cleanups, mostly to make it work better with the
generic power domains (genpd) framework, and updates for that
framework (Ulf Hansson, Thierry Reding, Colin Ian King)- Intel Broxton support for the intel_idle driver (Len Brown)
- cpuidle core optimization and fix (Daniel Lezcano, Dave Gerlach)
- ARM cpuidle cleanups (Jisheng Zhang)
- Intel Kabylake support for the RAPL power capping driver (Jacob
Pan)- AVS (Adaptive Voltage Switching) rockchip-io driver update (Heiko
Stuebner)- Updates for the cpupower tool (Arjun Sreedharan, Colin Ian King,
Mattia Dongili, Thomas Renninger)"* tag 'pm-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (112 commits)
intel_pstate: Clean up get_target_pstate_use_performance()
intel_pstate: Use sample.core_avg_perf in get_avg_pstate()
intel_pstate: Clarify average performance computation
intel_pstate: Avoid unnecessary synchronize_sched() during initialization
cpufreq: schedutil: Make default depend on CONFIG_SMP
cpufreq: powernv: del_timer_sync when global and local pstate are equal
cpufreq: powernv: Move smp_call_function_any() out of irq safe block
intel_pstate: Clean up intel_pstate_get()
cpufreq: schedutil: Make it depend on CONFIG_SMP
cpufreq: governor: Fix handling of special cases in dbs_update()
PM / OPP: Move CONFIG_OF dependent code in a separate file
cpufreq: intel_pstate: Ignore _PPC processing under HWP
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
PM / OPP: add non-OF versions of dev_pm_opp_{cpumask_, }remove_table
cpufreq: tango: Use generic platdev driver
PM / OPP: pass cpumask by reference
cpufreq: Fix GOV_LIMITS handling for the userspace governor
cpupower: fix potential memory leak
PM / devfreq: style/typo fixes
PM / devfreq: exynos: Add the detailed correlation for Exynos5422 bus
..
16 May, 2016
6 commits
-
* pm-core:
PM / sleep: Drop unused `info' variable
PM / Runtime: Move ignore_children flag under CONFIG_PM
PM / Runtime: Fix error path in pm_runtime_force_resume()* pm-domains:
PM / Domains: Drop unnecessary wakeup code from pm_genpd_prepare()
PM / Domains: Remove redundant pm_runtime_get|put*() in pm_genpd_prepare()
PM / Domains: Remove ->save|restore_state() callbacks
PM / Domains: Rename pm_genpd_runtime_suspend|resume()
PM / Domains: Rename stop_ok to suspend_ok for the genpd governor -
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: Adrian Hunter
Signed-off-by: Ulf Hansson -
Tested on a Salvator-X board with a Spectec SDW-823 WLAN card.
Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
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: Wolfram Sang
Signed-off-by: Ulf Hansson -
Add some logging to make it clear just how the emmc timeout
was handled.Signed-off-by: Ken Sumrall
[AmitP: cherry-picked this Android patch from aosp
common kernel android-4.4]
Signed-off-by: Amit Pundir
Signed-off-by: Ulf Hansson -
After commit d6463f170cf0 ("mmc: sdhci: Remove redundant runtime PM calls"),
some of original sdhci_do_xx() function wrappers becomes meaningless,
so remove them.Signed-off-by: Dong Aisheng
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
10 May, 2016
2 commits
-
mmc_select_hs200() and mmc_select_hs() will keep the timing
as before if switch fails. So it's meaningless to print the
failed switched mode outside based on the current host timing.Furthermore, the original print is wrong, it should be:
pr_warn("%s: switch to %s failed\n",
mmc_hostname(card->host),
mmc_card_hs(card) ? "high-speed" :
(mmc_card_hs200(card) ? "hs200" : ""));Since we already have error message in mmc_select_hs200(),
simply remove it outside.Signed-off-by: Dong Aisheng
Signed-off-by: Ulf Hansson -
Currently MMC core will keep going if HS200/HS timing switch failed
with -EBADMSG error by the assumption that the old timing is still valid.However, for mmc_select_hs200 case, the signal voltage may have already
been switched. If the timing switch failed, we should fall back to
the old voltage in case the card is continue run with legacy timing.If fall back signal voltage failed, we explicitly report an EIO error
to force retry during the next power cycle.Signed-off-by: Dong Aisheng
Signed-off-by: Ulf Hansson
09 May, 2016
1 commit
-
We want the pty fixes in here as well so that patches can build on it.
Signed-off-by: Greg Kroah-Hartman
04 May, 2016
9 commits
-
commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for
sdhci-of-arasan") introduce phy support for arasan. According to
the vendor's databook, we should make sure the phy is in poweroff
status before we configure the clk stuff. Otherwise it may cause
some IO sample timing issues from the test. And we don't need this
extra operation while running in low performance mode since phy
doesn't trigger sampling block.Signed-off-by: Shawn Lin
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson -
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
CC: Ulf Hansson
CC: Jarkko Nikula
Signed-off-by: Ulf Hansson -
CMD0 or hardware reset may invalidate the cache, so it needs to be
flushed before reset.In the case of recovery, we can't expect flushing the cache to work
always, but have a go and ignore errors.Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson -
And return the old clock rate if something went wrong.
Signed-off-by: Wolfram Sang
Tested-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
We had a regression on r8a7740 where the SDHI clock was a generic
peripheral clock, so changing its rate was not desired. This should be
fixed in the clock driver. However, it also shows that the new clock
calculation should only be used on tested systems. Add a check for that.Signed-off-by: Wolfram Sang
Tested-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
RCar Gen2 and later implementations of TMIO/SDHI have their own set of
features and additions. FAST_CLK_CHG is just one of them and I see a few
others being added soon. Some may work on older chipsets but this needs
to be tested case by case. Instead of adding a bunch of flags for each
feature, add a global RCar2+ one for now. We can still break out
features if the need arises.Signed-off-by: Wolfram Sang
Tested-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
Save a few lines, the codebase is large enough.
Signed-off-by: Wolfram Sang
Tested-by: Geert Uytterhoeven
Signed-off-by: Ulf Hansson -
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
Signed-off-by: Ulf Hansson -
The controller claims to support SDR104. In fact, it only supports a
degraded SDR104 since the maximum frequency of the SD clock is 120 MHz
instead of 208 MHz.
The sdhci core is unaware of it and will compute a wrong clock divider.
We can deal with this specific case by using presets.Signed-off-by: Ludovic Desroches
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
02 May, 2016
7 commits
-
Some boards need different pin drive strength for the UHS mode. Add an
optional pinctrl setting with two pin states covering UHS speeds and
other speeds.Signed-off-by: Lars Persson
Signed-off-by: Ulf Hansson -
Add a start_signal_voltage_switch() operation to support enabling of
UHS modes.Signed-off-by: Lars Persson
Signed-off-by: Ulf Hansson -
The driver in its current form does not support UHS at all due to
a missing start_signal_voltage_switch callback.Also when this callback is added we should let the device tree control
UHS capabilities using the standard mmc bindings.Signed-off-by: Lars Persson
Signed-off-by: Ulf Hansson -
Now that reading CTL_STATUS is consistent, we can remove CTL_STATUS2 and
document how this is handled internally.Reviewed-by: Simon Horman
Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
This bit has a different meaning in SDHI and original TMIO. Document
that and use the proper naming.Reviewed-by: Simon Horman
Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
To prevent confusion, use the virtual u32 CTL_STATUS in card_busy() the
same way as in other parts of this driver.Reviewed-by: Simon Horman
Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson -
BIT() makes it easier to match the bits to the datasheet. This is
especially important here, since some variants have different names in
their datasheets (like with Renesas R-Car).Reviewed-by: Simon Horman
Signed-off-by: Wolfram Sang
Signed-off-by: Ulf Hansson
