Since commit edc6afc549 ("[PATCH] tty: switch to ktermios and new
framework") arbitrary baud rates can be requested using BOTHER and input
rates can be requested using the termios CIBAUD bits (CBAUD shifted
IBSHIFT bits).
This functionality has been conditionally compiled depending on whether
an architecture defines BOTHER and IBSHIFT respectively, but would in
fact fail to compile unless both symbols were defined due to cross
dependencies.
Relax the IBSHIFT => BOTHER dependency so that an architecture could
theoretically support CIBAUD without the Linux-specific BOTHER, while
hopefully making the current conditional-compilation directives a bit
less confusing.
Note that the long-term goal is still to have all architectures support
both features, so an alternative could just be to have the lot depend on
BOTHER.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement and use tegra_sdhci_get_max_clock() which returns the true
maximum host clock rate. The issue with tegra_sdhci_get_max_clock() is
that it returns the current clock rate of the host instead of the
maximum one, which can lead to unnecessarily small clock rates.
This differs from the previous implementation of
tegra_sdhci_get_max_clock() in that it doesn't divide the result by two.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When the termios CIBAUD bits are left unset (i.e. B0), we use the same
output and input speed and should leave CIBAUD unchanged.
When the user requests a rate using BOTHER and c_ospeed which the driver
cannot set exactly, the driver can report back the actual baud rate
using tty_termios_encode_baud_rate(). If this rate is close enough to a
standard rate however, we could end up setting CIBAUD to a Bfoo value
despite the user having left it unset.
This in turn could lead to an unexpected input rate being set on
subsequent termios updates.
Fix this by using a zero tolerance value also for the input rate when
CIBAUD is clear so that the matching logic works as expected.
Fixes: 78137e3b34 ("[PATCH] tty: improve encode_baud_rate logic")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to clear the CIBAUD bits before OR-ing the new mask when
encoding the termios input baud rate.
This could otherwise lead to an incorrect input rate being reported back
and incidentally set on subsequent termios updates.
Fixes: edc6afc549 ("[PATCH] tty: switch to ktermios and new framework")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for flow control functionality in the GENI serial driver
and also support for non-console higher baud rate(upto 4Mbps) usecases.
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the IRQ controller is not yet probed do not proceed with irq=0,
try to defer the probe.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't dispose IRQ mapping before it has been created.
Fixes: aa9594740 ("serial: 8250_of: Add IO space support")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for a "RZ_SCIFA" which is different than a traditional
SCIFA. It looks like a normal SCIF with FIFO data, but with a
compressed address space. Also, the break out of interrupts
are different then traditinal SCIF: ERI/BRI, RXI, TXI, TEI, DRI.
The R7S9210 (RZ/A2) contains this type of SCIF.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When ashmem_shrink is called from direct reclaim on a user thread, a
call to do_fallocate will check for permissions against the security
policy of that user thread. It can thus fail by chance if called on a
thread that isn't permitted to modify the relevant ashmem areas.
Because we know that we have a shmem file underneath, call the shmem
implementation of fallocate directly instead of going through the
user-space interface for fallocate.
Signed-off-by: Tobias Lindskog <tobias.lindskog@sonymobile.com>
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch warning: avoid unnecessary line continuation
to allow grepping of whole error message.
Signed-off-by: Matthias Wolf <der_wolf_@web.de>
Signed-off-by: Felix Siegel <felix.siegel@stud.uni-hannover.de>
Signed-off-by: Tim Cofala <cofala@stud.uni-hannover.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch line over 80 characters where it seemed appropriate
Signed-off-by: Matthias Wolf <der_wolf_@web.de>
Signed-off-by: Felix Siegel <felix.siegel@stud.uni-hannover.de>
Signed-off-by: Tim Cofala <cofala@stud.uni-hannover.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shift '=' assignment operator to the end of previous
line to conform to preferred kernel style line wrapping.
Issue reported by checkpatch CHECK.
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the uSDHC case (e.g. i.MX 6) clocks only get disabled if frequency
is set to 0. However, it could be that the stack asks for a frequency
change while clocks are on. In that case the function clears the
divider registers (by clearing ESDHC_CLOCK_MASK) while the clock is
enabled! This causes a short period of time where the clock is
undivided (on a i.MX 6DL a clock of 196MHz has been measured).
For older IP variants the driver disables clock by clearing some bits
in ESDHC_SYSTEM_CONTROL.
Make sure to disable card clock before changing frequency for uSDHC
IP variants too.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
It seems that SD3.0 advertisement needs to be set for higher eMMC
speed modes (namely DDR52) as well. The TRM states that the SD3.0
advertisement bit should be set for all controller instances, even
for those not supporting UHS-I mode...
When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra
SD/MMC instance which is connected to a eMMC device, the stack
enables SD3.0. However, enabling it has consequences: If SDHCI 3.0
support is advertised the stack enables Auto-CMD23. Unfortunately
Auto-CMD23 seems not to work well with Tegra 3 currently. It leads
to regular warnings:
mmc2: Got command interrupt 0x00010000 even though no command operation was in progress.
It is not entirely clear why those errors happens. It seems that
a Linux 3.1 based downstream kernel which has Auto-CMD23 support
does not show those warnings.
Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being
used for now. With this the eMMC works stable on high-speed mode
while still announcing SD3.0.
This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52
mode read speed improves from about 42MiB/s to 72MiB/s on an
Apalis T30.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Make sure the clock is doubled when using eMMC DDR52 mode.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The stack assumes that SDHC controller which support SD3.0 (SDR104) do
support HS200. This is not the case for Tegra 3, which does support SD
3.0
but only supports eMMC spec 4.41.
Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not
support HS200.
Note that commit 156e14b126 ("mmc: sdhci: fix caps2 for HS200") added
the tie between SD3.0 (SDR104) and HS200. I don't think that this is
necessarly true. It is fully legitimate to support SD3.0 and not support
HS200. The quirk naming suggests something is broken in the controller,
but this is not the case: The controller simply does not support HS200.
Fixes: 7ad2ed1dfc ("mmc: tegra: enable UHS-I modes")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Synopsys has DWC MSHC controller on HPAS-DX platform connected using PCIe
interface with SD card slot and eMMC device slots. This patch is to
enable SD cards connected on this platform. As Clock generation logic
is implemented using MMCM module of HAPS-DX platform, we have separate
functions to control the MMCM to generate required clocks with respect
to speed mode.
Signed-off-by: Prabu Thangamuthu <prabu.t@synopsys.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add a driver for SDHCI OF Synopsys DesignWare Cores Mobile Storage
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
For eMMC devices it is valid to only support 1.8V signaling. When
vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V
initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed
Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is
not available. This prevents the stack from even trying to use
3.3V signaling and avoids the above warning.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses
when doing DMA. Make sure that the corresponding dma mask is correctly
configured.
Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings
for sdhci end up 48-bit wide. However, on these chips sdhci only use
40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device
generates transactions with clipped 40-bit addresses, thus smmu context
faults are triggered. Setting up the correct dma mask fixes this
situation.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
A recent commit introduced a call to mmc_of_parse() and removed the
explicit assignment of GPIOs in the pdata structure. This will leave
them set to 0, which is a valid GPIO per se, so the code that looks
at these members will try to allocate them and fail.
To fix this properly, make the following changes:
a) Refrain from allocating and assiging a pdata struct from
pxamci_of_init(). It's a hack to do it this way anyway.
Instead, move the only remaining member of interest in
'struct pxamci_host' and assign the value from either
the passed in pdata pointer or with the value read from DT.
b) Let the only user of 'detect_delay_ms' look at the member of
'struct pxamci_host', not the pdata.
c) Make more code in pxamci_probe() dependent on the presence of
actual pdata.
This will also ease the removal of pdata one day.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Strip some code by letting the mmc core handle the regulators. The old
.gpio_power pdata handling is kept around for now.
This also set the voltage on the regulator and handles -EPROBE_DEFER
correctly.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Devicetree-enabled boards should use proper regulators to control the
power of cards, not GPIOs, so let's remove this property. The regulator
properties are supported by the MMC core and are described in the
generic MMC document:
Documentation/devicetree/bindings/mmc/mmc.txt
Note that devicetree support for PXA platforms hasn't fully landed yet,
so this binding does not have any users at this point.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Call into mmc_of_parse() from pxamci_of_init(). As it needs a pointer to a
struct mmc_host, refactor the code a bit.
This allows all generic MMC properties to be set that are described in
Documentation/devicetree/bindings/mmc/mmc.txt. Reword the documentation
a bit to make that clear.
The "cd" and "wp" gpio lookups are removed as the lookup will now be
done by mmc_of_parse().
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
pxamci_of_init() had some weird indenting.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
These gpio assignments don't make sense, as they are not used anywhere.
Remove the dead code.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
These members are no longer in use, so let's remove them.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This seems to be a left-over from times before the IRQ was handled by devm
functions. Remove it.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The field support_vsel is currently only used in the device tree
case. Get rid of it. No change in behavior.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The uSDHC supports DDR modes for eMMC devices running at 3.3V. This
allows to run eMMC with 3.3V signaling voltage at DDR52 mode:
# cat /sys/kernel/debug/mmc1/ios
clock: 52000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 8 (mmc DDR52)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The last user of mmc_power_save|restore_host() APIs is gone, hence let's
drop them. Drop also the corresponding bus_ops callback,
->power_save|restore() as those becomes redundant.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Eyal Reizer <eyalreizer@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Convert to use of_match_node method to fix up eSDHC clock for
ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a
according to its datasheet. The maxmum speed for ls1021a eSDHC
high speed mode is 46.5MHz.
Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some controllers immediately report SDHCI_CLOCK_INT_STABLE after
enabling the clock even when the clock is not stable. When used in
conjunction with older/slower cards, this can result in:
mmc0: error -84 whilst initialising SD card
When the stable reporting is known to be broken, we simply wait for the
maximum stabilization period.
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some controllers immediately report that their internal clock is stable
after activating it even when the clock is not stable. When used in
conjunction with older/slower cards, this can result in:
mmc0: error -84 whilst initialising SD card
This flag allows documenting and thus working around such a hardware
defect.
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support to use the new compatible string "qcom,sdhci-msm-v5".
Based on the msm variant, pick the relevant variant data and
use it for register read/write to msm specific registers.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For SDCC version 5.0.0 and higher, new compatible string
"qcom,sdhci-msm-v5" is added.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In addition to offsets of certain registers changing, the registers in
core_mem have been shifted to HC mem as well. To access these
registers, define msm version specific functions. These functions can
be loaded into the function pointers at the time of probe based on
the msm version detected.
Also defind new data structure to hold version specific Ops and
register addresses.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For SDCC version 5.0.0, MCI registers are removed from SDCC
interface and some registers are moved to HC.
Define a new data structure where we can statically define
the address offsets for the registers in different SDCC versions.
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
