Not much dramatic changes at this time, but we've received quite
a lot of changes for ASoC, while there are still a few fixes and
quirks for usual HD- and USB-auido. Here are some highlights.
* ASoC:
- Overhaul of endianness specification for data formats, avoiding
needless restrictions due to CODECs
- Initial stages of Intel AVS driver merge
- Introduction of v4 IPC mechanism for SOF
- TDM mode support for AK4613
- Support for Analog Devices ADAU1361, Cirrus Logic CS35L45, Maxim
MAX98396, MediaTek MT8186, NXP i.MX8 micfil and SAI interfaces,
nVidia Tegra186 ASRC, and Texas Instruments TAS2764 and TAS2780
* Others
- A few regression fixes after the USB-audio endpoint management
refactoring
- More enhancements for Cirrus HD-audio codec support (still ongoing)
- Addition of generic serial MIDI driver
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmKOEiAOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE96FxAAnoVCecFK955fWInCULe15xYpi9kqngDSLAQk
k6TkbP8AFyX+3PbIb9YVK9u+fLBaZzdK/ZIRqZNfb5T4q8tVTHphg2P+SNB36qaD
nTTaEQ6dr6VUJO3fwwVBa3NJ+rGPr8KMKLlQGCg/I8HKdFeW2t/mV1YZI/ZxM7Or
MXu3F5dt3yVXXMgUb33if+atYCXOwJ9YIqe1WHE4oPTtfOhbwiIdFeHgg88Kq7vJ
ep7PCbyJ0rqfA9BIAnBfQuD9ZoaS7mKlo9xgyauNBzWnbRVd7dYyUnaxH++XLPPS
GS0MEgftJfmUay6o++I7qrhoTyMKMHN/CU+6RlR1GD6WBpBhQ6T+poLkFDvKqbL8
kvFEBFrEf0soeAKkUinzl1wCJnzWvpq2PF0EewQp03A3vOL5MOzGdId1wLKLmbCw
Z0e0HAKTP4/AQeBluLo/SjiNoeSEU76xYYv8tFGv531ybIhvsF0nm/Suv4VZcy0V
9tr2gLSORDLTBqSJqCf1JgN8oJht0QLirzgSekk8HUvx1JnIwwAaH1Dvy1DMrjyu
TQ6oRyDS2giHKh7FItv3+U+HE1CkA89dzDvGrIbKrT6xkodHGzLNr0DxaDGuR11w
H9f9oFEnGBpBxWmfLkGTa8+oBenTz8YRm4Ti8xhZkJkD1ys/4fjasAYoIKJqdnxH
iG1DWic=
=5qBk
-----END PGP SIGNATURE-----
Merge tag 'sound-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"Not much dramatic changes at this time, but we've received quite a lot
of changes for ASoC, while there are still a few fixes and quirks for
usual HD- and USB-auido. Here are some highlights.
ASoC:
- Overhaul of endianness specification for data formats, avoiding
needless restrictions due to CODECs
- Initial stages of Intel AVS driver merge
- Introduction of v4 IPC mechanism for SOF
- TDM mode support for AK4613
- Support for Analog Devices ADAU1361, Cirrus Logic CS35L45, Maxim
MAX98396, MediaTek MT8186, NXP i.MX8 micfil and SAI interfaces,
nVidia Tegra186 ASRC, and Texas Instruments TAS2764 and TAS2780
Others:
- A few regression fixes after the USB-audio endpoint management
refactoring
- More enhancements for Cirrus HD-audio codec support (still ongoing)
- Addition of generic serial MIDI driver"
* tag 'sound-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (504 commits)
ALSA: hda/realtek - Add new type for ALC245
ALSA: usb-audio: Configure sync endpoints before data
ALSA: ctxfi: fix typo in comment
ALSA: cs5535audio: fix typo in comment
ALSA: ctxfi: Add SB046x PCI ID
ALSA: usb-audio: Add missing ep_idx in fixed EP quirks
ALSA: usb-audio: Workaround for clock setup on TEAC devices
ALSA: lola: Bounds check loop iterator against streams array size
ASoC: max98090: Move check for invalid values before casting in max98090_put_enab_tlv()
ASoC: rt1308-sdw: add the default value of register 0xc320
ASoC: rt9120: Use pm_runtime and regcache to optimize 'pwdnn' logic
ASoC: rt9120: Fix 3byte read, valule offset typo
ASoC: amd: acp: Set Speaker enable/disable pin through rt1019 codec driver.
ASoC: amd: acp: Set Speaker enable/disable pin through rt1019 codec driver
ASoC: wm2000: fix missing clk_disable_unprepare() on error in wm2000_anc_transition()
ASoC: codecs: lpass: Fix passing zero to 'PTR_ERR'
ASoC: SOF: sof-client-ipc-flood-test: use pm_runtime_resume_and_get()
ASoC: SOF: mediatek: remove duplicate include in mt8195.c
ASoC: SOF: mediatek: Add mt8195 debug dump
ASoC: SOF: mediatek: Add mediatek common debug dump
...
The i.MX DMA drivers are device tree only, nothing in
include/linux/platform_data/dma-imx.h has platform_data in it, so move
the file to include/linux/dma/imx-dma.h.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-By: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20220414162249.3934543-10-s.hauer@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 76821e222c ("serial: imx: ensure that RX irqs are off if RX is
off") accidentally enabled overrun interrupts unconditionally when
deferring DMA enable until after the receiver has been enabled during
startup.
Fix this by using the DMA-initialised instead of DMA-enabled flag to
determine whether overrun interrupts should be enabled.
Note that overrun interrupts are already accounted for in
imx_uart_clear_rx_errors() when using DMA since commit 41d98b5da9
("serial: imx-serial - update RX error counters when DMA is used").
Fixes: 76821e222c ("serial: imx: ensure that RX irqs are off if RX is off")
Cc: stable@vger.kernel.org # 4.17
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20220411081957.7846-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, uart_console_write->putchar's second parameter (the
character) is of type int. It makes little sense, provided uart_console_write()
accepts the input string as "const char *s" and passes its content -- the
characters -- to putchar(). So switch the character's type to unsigned
char.
We don't use char as that is signed on some platforms. That would cause
troubles for drivers which (implicitly) cast the char to u16 when
writing to the device. Sign extension would happen in that case and the
value written would be completely different to the provided char. DZ is
an example of such a driver -- on MIPS, it uses u16 for dz_out in
dz_console_putchar().
Note we do the char -> uchar conversion implicitly in
uart_console_write(). Provided we do not change size of the data type,
sign extension does not happen there, so the problem is void.
This makes the types consistent and unified with the rest of the uart
layer, which uses unsigned char in most places already. One exception is
xmit_buf, but that is going to be converted later.
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Tobias Klauser <tklauser@distanz.ch>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vineet Gupta <vgupta@kernel.org>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Karol Gugala <kgugala@antmicro.com>
Cc: Mateusz Holenko <mholenko@antmicro.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Taichi Sugaya <sugaya.taichi@socionext.com>
Cc: Takao Orito <orito.takao@socionext.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Andreas Färber" <afaerber@suse.de>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: Orson Zhai <orsonzhai@gmail.com>
Cc: Baolin Wang <baolin.wang7@gmail.com>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com> [atmel_serial]
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson_serial
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20220303080831.21783-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Right now, even when `delay_rts_before_send` and `delay_rts_after_send`
are 0, the hrtimer is triggered (with timeout 0) which can introduce a
few 100us of additional overhead on slower i.MX platforms.
Implement a fast path when the delays are 0, where the RTS signal is
toggled immediately instead of going through an hrtimer. This fast path
behaves identical to the code before delay support was implemented.
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Harald Seiler <hws@denx.de>
Link: https://lore.kernel.org/r/20220119145204.238767-1-hws@denx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Triggering RX interrupt for every byte defeats the purpose of aging
timer and leads to interrupt storm at high baud rates. The interrupt
storm can starve line discipline worker and prevent tty throttling,
rendering hardware/software flow control useless.
Increase receiver trigger level to 8 to increase the minimum period
between RX interrupts to 8 characters time. The tradeoff is increased
latency.
Aging timer resets with every received character. Worst case scenario
happens when RX data intercharacter delay is slightly less than the
aging timer timeout (8 characters time). The upper bound of the time
a character can wait in RxFIFO before interrupt is raised is:
(RXTL - 1) * (8 character time timeout + received 1 character time)
Usually the data is received in frames, with low intercharacter delay.
In such case the latency increase is 8 characters time at the end of
the frame with probability (RXTL - 1) / RXTL.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Tomasz Moń <tomasz.mon@camlingroup.com>
Link: https://lore.kernel.org/r/20220117060417.624613-1-tomasz.mon@camlingroup.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The UCR4_OREN should be disabled before disabling the uart receiver in
.stop_rx() instead of in the .shutdown().
Otherwise, if we have the overrun error during the receiver disable
process, the overrun interrupt will keep trigging until we disable the
OREN interrupt in the .shutdown(), because the ORE status can only be
cleared when read the rx FIFO or reset the controller. Although the
called time between the receiver disable and OREN disable in .shutdown()
is very short, there is still the risk of endless interrupt during this
short period of time. So here change to disable OREN before the receiver
been disabled in .stop_rx().
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20211125020349.4980-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clear RTSD status before enabling the irq event for RTSD in
imx_uart_enable_wakeup function.
Since RTSD can be set as the wakeup source, this can avoid any risk of
false triggering of a wake-up interrupts.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20211125014306.4432-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During console setup imx_uart_console_setup() enables clocks, but they
are never disabled when the console is unregistered, this leads to
clk_prepare_enable() being called multiple times without a matching
clk_disable_unprepare() in case of console unregister.
Ensure that clock enable/disable are balanced adding
clk_disable_unprepare() in the console exit callback.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20211020192643.476895-3-francesco.dolcini@toradex.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to optimize serial communication (performance/throughput VS
latency), we may need to tweak DMA period number and size. This adds
DT properties to configure those values before initialising DMA.
The defaults will stay the same as before.
[update documentation and commit message, rebase to current master,
switch back to DT instead of sysfs]
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20210430175038.103226-2-sebastian.reichel@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's no need to initialise irq-flags variables before saving the
interrupt state.
Drop the redundant initialisations from drivers that got this wrong.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210519092541.10137-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Force-threaded interrupt handlers used to run with interrupts enabled,
something which could lead to deadlocks in case a threaded handler
shared a lock with code running in hard interrupt context (e.g. timer
callbacks) and did not explicitly disable interrupts.
This was specifically the case for serial drivers that take the port
lock in their console write path as printk can be called from hard
interrupt context also with forced threading ("threadirqs").
Since commit 81e2073c17 ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers always run with interrupts
disabled on non-RT so that drivers no longer need to do handle this.
Drop the now obsolete workaround added by commit 33f16855dc ("tty:
serial: imx: fix potential deadlock").
Cc: Sam Nobs <samuel.nobs@taitradio.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210322111036.31966-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This really eliminates multiplications from the assembly. I would have
thought they are optimized by inlining ktime_set, but not on x86_64 with
gcc 10.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210302062214.29627-10-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver only probes via devicetree, we can move the
content of imx_uart_probe_dt() directly into imx_uart_probe() to
make the code simpler.
Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201209214712.15247-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since 5.10-rc1 i.MX is a devicetree-only platform and the NULL check on
of_device_get_match_data() is no longer needed.
This check was only needed when this driver supported both DT and non-DT
platforms.
Remove the unneeded of_device_get_match_data() NULL check.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201126124643.3371-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As described in Documentation, poll_init() is called by kgdb to initialize
hardware which supports both poll_put_char() and poll_get_char().
It's necessary to enable TXEN bit, otherwise, it will cause hardware fault
and kernel panic when calling imx_poll_put_char().
Generally, if use /dev/ttymxc0 as kgdb console as well as system
console, ttymxc0 is initialized early by system console which does enable
TXEN bit.But when use /dev/ttymxc1 as kgbd console, ttymxc1 is only
initialized by imx_poll_init() cannot enable the TXEN bit, which will
cause kernel panic.
Signed-off-by: Mingrui Ren <jiladahe1997@gmail.com>
Link: https://lore.kernel.org/r/20201202072543.151-1-972931182@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl+69egeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGTSYH/ifRBlaxy5UiHFc0
2zdR7pkjWrYfDTTT3sazIAhdlzzcfnkUqgFxOP45F4ZIqeTzunH3sUY+5UlT9IX7
liUgnLxQ/1R9Gx8kPGQfu+tLCey78xVFydGsqJoW9sPRw2R+apMdGGa/lOrk+OXz
DXIN+dDnGFqwCCNJpK+rxQQhFf++IPpSI8z6Y23moOFhsDZrEziHuVFy2FGyRM6z
prZ/us/tcobE8ptCk1RmOxLoJ1DR6UxpA2vLimTE+JD8siOsSWPbjE0KudnWCnd5
BLqIjrsPJbSxyuzzK3v9dnO5wMv7tMDuMIuYM/MQTXDttNwtsqt/aP6gdnUCym7N
5eHEj5g=
=MuO1
-----END PGP SIGNATURE-----
Merge 5.10-rc5 into tty-next
We need the tty/serial fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since 5.10-rc1 i.MX is a devicetree-only platform and the existing
.id_table support in this driver was only useful for old non-devicetree
platforms.
Get rid of the .id_table since it is no longer used.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201115110341.22761-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since 5.10-rc1 i.MX is a devicetree-only platform and the existing
platform data support in this driver was only useful for old non-devicetree
platforms.
Get rid of the platform data support since it is no longer used.
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201110214840.16768-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enabling the lock dependency validator has revealed
that the way spinlocks are used in the IMX serial
port could result in a deadlock.
Specifically, imx_uart_int() acquires a spinlock
without disabling the interrupts, meaning that another
interrupt could come along and try to acquire the same
spinlock, potentially causing the two to wait for each
other indefinitely.
Use spin_lock_irqsave() instead to disable interrupts
upon acquisition of the spinlock.
Fixes: c974991d26 ("tty:serial:imx: use spin_lock instead of spin_lock_irqsave in isr")
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sam Nobs <samuel.nobs@taitradio.com>
Link: https://lore.kernel.org/r/1604955006-9363-1-git-send-email-samuel.nobs@taitradio.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The IPG clock is disabled at the end of imx_uart_shutdown(); we really
don't want to run any IRQ handlers after this point.
At least on i.MX8MN, the UART will happily continue to generate interrupts
even with its clocks disabled, but in this state, all register writes are
ignored (which will cause the shadow registers to differ from the actual
register values, resulting in all kinds of weirdness).
In a transfer without DMA, this could lead to the following sequence of
events:
- The UART finishes its transmission while imx_uart_shutdown() is run,
triggering the TXDC interrupt (we can trigger this fairly reliably by
writing a single byte to the TTY and closing it right away)
- imx_uart_shutdown() finishes, disabling the UART clocks
- imx_uart_int() -> imx_uart_transmit_buffer() -> imx_uart_stop_tx()
imx_uart_stop_tx() should now clear UCR4_TCEN to disable the TXDC
interrupt, but this register write is ineffective. This results in an
interrupt storm.
To disable all interrupts in the same place, and to avoid setting UCR4
twice, clearing UCR4_OREN is moved below del_timer_sync() as well; this
should be harmless.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/20200925082412.12960-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When calculate "ucr1" UCR1_TRDYEN is duplicate.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200903062401.692442-1-yebin10@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for building i.MX serial driver as module.
The changes of the patch:
- imx console driver can be built as module.
- move out earlycon code to separated driver like imx_earlycon.c,
and imx earlycon driver only support build-in.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Link: https://lore.kernel.org/r/20200724070815.11445-2-fugang.duan@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch imitates 6e0a5de213 ("serial: 8250: Use hrtimers for
rs485 delays") in replacing the previously used classic timers
with hrtimers. The old way provided a too coarse resolution on
systems with configs of less than 1000 HZ.
Use of hrtimers addresses this and can be easily extended to
support microsecond resolution in future when support
for this arrives upstream.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20200714093012.21621-3-uwe@kleine-koenig.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds support for delays between assertion of RTS (which is supposed
to enable the rs485 transmitter) and sending as well as between the last
send char and deassertionof RTS.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200714093012.21621-2-uwe@kleine-koenig.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 8f065acec7.
There has been a quick fix against uninitialised lock revealed by
the commit f743061a85 ("serial: core: Initialise spin lock before use
in uart_configure_port()"). Since we have now better fix in serial core,
this may be safely reverted.
Fixes: 8f065acec7 ("serial: imx: Initialize lock for non-registered console")
Depends-on: f743061a85 ("serial: core: Initialise spin lock before use in uart_configure_port()")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200711135346.71171-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The AGTIM flag must be cleared explicitly, otherwise the IRQ handler
will be called in an endless loop.
Fortunately, this issue currently doesn't affect mainline kernels in
practice, as the the RX FIFO trigger level is set to 1 in UFCR. When
setting the trigger level to a higher number, the issue is trivially
reproducible by any RX without DMA that doesn't fill the FIFO up to the
configured level.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/20200528154747.14201-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit a3cb39d258
("serial: core: Allow detach and attach serial device for console")
changed a bit logic behind lock initialization since for most of the console
driver it's supposed to have lock already initialized even if console is not
enabled. However, it's not the case for Freescale IMX console.
Initialize lock explicitly in the ->probe().
Note, there is still an open question should or shouldn't not this driver
register console properly.
Fixes: a3cb39d258 ("serial: core: Allow detach and attach serial device for console")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200525105952.13744-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We're about to amend uart_get_rs485_mode() to support a GPIO pin for
rs485 bus termination. Retrieving the GPIO descriptor may fail, so
allow uart_get_rs485_mode() to return an errno and change all callers
to check for failure.
The GPIO descriptor is going to be stored in struct uart_port. Pass
that struct to uart_get_rs485_mode() in lieu of a struct device and
struct serial_rs485, both of which are directly accessible from struct
uart_port.
A few drivers call uart_get_rs485_mode() before setting the struct
device pointer in struct uart_port. Shuffle those calls around where
necessary.
[Heiko Stuebner did the ar933x_uart.c portion, hence his Signed-off-by.]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/271e814af4b0db3bffbbb74abf2b46b75add4516.1589285873.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The peripheral has support for inverting its input and/or output
signals. This is useful if the hardware flips polarity of the
peripheral's signal, such as swapped +/- pins on an RS-422 transceiver,
or an inverting level shifter. Add support for these control registers
via the device tree binding.
As part of this change, make the writes of the various registers more
uniform by moving the UCR3 block up near the other registers' blocks,
since the INVT bit must be set before enabling the peripheral.
Signed-off-by: George Hilliard <ghilliard@kopismobile.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200226222319.18383-3-ghilliard@kopismobile.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The main irq handler function starts by first masking disabled
interrupts in the status register values to ensure to only handle
enabled interrupts. This is important as when the RX path in the
hardware is disabled reading the RX fifo results in an external abort.
This checking must be done under the port lock, otherwise the following
can happen:
CPU1 | CPU2
|
irq triggers as there are chars |
in the RX fifo |
| grab port lock
imx_uart_int finds RRDY enabled |
and calls imx_uart_rxint which |
has to wait for port lock |
| disable RX (e.g. because we're
| using RS485 with !RX_DURING_TX)
|
| release port lock
read from RX fifo with RX |
disabled => exception |
So take the port lock only once in imx_uart_int() instead of in the
functions called from there.
Reported-by: Andre Renaud <arenaud@designa-electronics.com>
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20200121071702.20150-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The SUPPORT_SYSRQ ifdeffery is not nice as:
- May create misunderstanding about sizeof(struct uart_port) between
different objects
- Prevents moving functions from serial_core.h
- Reduces readability (well, it's ifdeffery - it's hard to follow)
In order to remove SUPPORT_SYSRQ, has_sysrq variable has been added.
Initialise it in driver's probe and remove ifdeffery.
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20191213000657.931618-20-dima@arista.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".
Fixes: b4cdc8f61b ("serial: imx: add DMA support for imx6q")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/1573108875-26530-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All i.MX SoCs except i.MX1 have ONLY one necessary IRQ, use
platform_get_irq_optional() to get second/third IRQ which are
optional to avoid below error message during probe:
[ 0.726219] imx-uart 30860000.serial: IRQ index 1 not found
[ 0.731329] imx-uart 30860000.serial: IRQ index 2 not found
Fixes: 7723f4c5ec ("driver core: platform: Add an error message to platform_get_irq*()")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Link: https://lore.kernel.org/r/1570614559-11900-1-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using only 4 DMA periods for UART RX is very few if we have a high
frequency of small transfers - like in our case using Bluetooth with
many small packets via UART - causing many dma transfers but in each
only filling a fraction of a single buffer. Such a case may lead to
the situation that DMA RX transfer is triggered but no free buffer is
available. When this happens dma channel ist stopped - with the patch
"dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
possible consequences that:
with disabled hw flow control:
If enough data is incoming on UART port the RX FIFO runs over and
characters will be lost. What then happens depends on upper layer.
with enabled hw flow control:
If enough data is incoming on UART port the RX FIFO reaches a level
where CTS is deasserted and remote device sending the data stops.
If it fails to stop timely the i.MX' RX FIFO may run over and data
get lost. Otherwise it's internal TX buffer may getting filled to
a point where it runs over and data is again lost. It depends on
the remote device how this case is handled and if it is recoverable.
Obviously we want to avoid having no free buffers available. So we
decrease the size of the buffers and increase their number and the
total buffer size.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20190923135916.1212-1-philipp.puschmann@emlix.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This should help to avoid unnecessary gaps in transmission while
adding little overhead due to low default Tx threshold level (2
bytes).
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1567017475-11919-6-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
imx_set_termios(): avoid writing baud rate divider registers when the
values to be written are the same as current. Any writing seems to
restart transmission/receiving logic in the hardware, that leads to
data breakage even when rate doesn't in fact change. E.g., user
switches RTS/CTS handshake and suddenly gets broken bytes.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1567017475-11919-5-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
imx_set_termios(): disabling individual interrupt requests in UART for
duration of the routine is pointless. Get rid of it.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1567017475-11919-4-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
imx_set_termios(): stopping receiver and transmitter does harm when
something that doesn't touch transmission format/rate changes, such as
RTS/CTS handshake.
OTOH, it does no good on baud rate or format change, as
synchronization on upper-level protocols is still required to do it
right.
Therefore, just stop doing it.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1567017475-11919-3-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
imx_set_termios(): remove busy-waiting "drain Tx FIFO" loop. Worse
yet, it was potentially unbounded wait due to RTS/CTS (hardware)
handshake.
Let user space ensure draining is done before termios change, if
draining is needed in the first place.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1567017475-11919-2-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Called in only one place, for RS232, it only obscures things, as it
doesn't go well with 2 similar named functions,
imx_uart_rts_inactive() and imx_uart_rts_active(), that both are
RS485-specific.
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1564167161-3972-4-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
imx_uart_set_mctrl() happened to set UCR2_CTSC bit whenever TIOCM_RTS
was set, no matter if RTS/CTS handshake is enabled or not. Now fixed by
turning handshake on only when CRTSCTS bit for the port is set.
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1564167161-3972-3-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't let receiver hardware automatically control RTS output if it
was requested to be inactive.
To ensure this, set_termios() shouldn't set UCR2_CTSC bit if UCR2_CTS
(=TIOCM_RTS) is cleared. Added corresponding check in imx_uart_rts_auto()
to fix this.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Link: https://lore.kernel.org/r/1564167161-3972-2-git-send-email-sorganov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
