Fix/revpi 1343/RPI4-108/shorten tx drain interval #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a byproduct of me trying to wrap my head around the driver, submitted in the hope of making life easier for folks coming after me. The dmacr element of struct uart_amba_port is unnecessary if CONFIG_DMA_ENGINE is disabled, therefore moved into the #ifdef section. I've taken the liberty to shuffle the other elements around slightly to make the order more logical, at least to my perception. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
…rier_depends()" This reverts commit 93fab07.
Identical code is present in pl011_dma_startup() and pl011_rx_chars(). By moving this to a separate function, an ugly #ifdef can be avoided in the upcoming pio_rx() thread function. Also, the code would have been indented so far to the right that it wouldn't have fit within 80 chars. There's an oddity in pl011_dma_startup() wherein the poll timer is started unconditionally even if pl011_dma_rx_trigger_dma() failed. I assume this is harmless in that the poll function won't find any characters in the RX DMA buffer and stop polling after a few tries, but it nevertheless seems inefficient... Likewise odd is that polling is not stopped when RX DMA cannot be retriggered in pl011_dma_rx_irq() and pl011_dma_rx_callback(). Cc: Chanho Min <chanho.min@lge.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
When not using DMA, the interrupt handler pl011_int() alternatingly reads 256 characters from the RX FIFO and writes as many characters as possible from the circular buffer to the TX FIFO. That's a problem because: - If data is constantly sent or received at a high baud rate, interrupts will be disabled for prolonged periods, increasing latency for other tasks. In theory the interrupt handler could even get stuck in an infinite loop and hog the CPU. - Because data is received and transmitted alternatingly, the UART's full duplex capabilities are not used. - The situation becomes worse once rs485 support is added because it requires that after sending data, the interrupt handler waits for the FIFO to empty, waits for the rs485-rts-delay specified in the device tree and finally deasserts RTS. This process can add multiple milliseconds to the amount of time spent with interrupts disabled. Again, if DMA is used, this is mostly a non-issue. However some PL011 implementations lack DMA, most notably the BCM2835/6/7 (Raspberry Pi). With 14 million sold as of July 2017, there's a sizeable amount of affected devices out there. We can't use request_threaded_irq() here because we need two threads for RX and TX. As a first step, introduce a pio_rx kthread which is woken from the interrupt handler and receives data asynchronously. It is spawned on ->startup and killed on ->shutdown. The PL011 does not allow querying the fill level of the RX FIFO, only whether it is empty. Previously this was checked before every read from the RX FIFO, but the present commit adds an optimization: The RX interrupt is signaled when the FIFO becomes half full, so the fill level is known at that point. The interrupt handler stores this information in a counter in shared memory and the pio_rx kthread can thus skip the register access to check emptiness of the FIFO. Access to the counter is lockless, the interrupt handler inserts a write memory barrier after setting it and the pio_rx kthread inserts a data dependency barrier before reading it. After reading a character from the FIFO, the pio_rx kthread decrements the counter. I believe a memory barrier is not necessary afterwards because worst case the decrement operation is reordered after a concurrent store operation by the interrupt handler, merely resulting in fewer characters that can be read blindly (i.e. without checking FIFO emptiness). Once the counter reaches zero, the kthread falls back to checking emptiness of the FIFO before reading from it. This is necessary because characters may arrive as fast as they are read from the FIFO and the RX interrupt is not signaled earlier than the fill level transitioning past the "half full" mark. The interrupt handler previously did not clear RX and RT interrupts because they were automatically cleared by the hardware once the interrupt handler emptied the FIFO. However that happens asynchronously now, so amend the interrupt handler to clear them. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> [p.rosenberger: include correct header for struct sched_param] Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
We've just added threaded interrupt handling for RX, now do the same for TX. The RX and TX code paths are disjunct, so convert them in separate commits for clarity. As before, introduce a pio_tx kthread which is woken from the interrupt handler to send data asynchronously and which is spawned on ->startup and killed on ->shutdown. The serial core can start and stop TX at will and that state is tracked by the pio_tx kthread in a bool "stopped". The thread contains a simple state machine that can carry out certain steps when started and stopped. This is needed when adding rs485 support so that RTS is asserted when started and deasserted when stopped. Obviously, these steps are needed not only in PIO mode but also in DMA mode. So when the serial core invokes ->start_tx, the pio_tx thread is woken, will carry out the steps common to DMA and PIO code, then try switching to DMA mode by calling pl011_dma_tx_start(). If that fails or if the PL011 is not DMA-capable, the kthread will fall back to PIO transmission. Conversely, upon invocation of ->stop_tx by the serial core, the pio_tx kthread is likewise woken and will take care of disabling DMA and, in an upcoming commit, deassert RTS in rs485 mode. In essence the pio_tx kthread manages starting and stopping but delegates the actual transmission to DMA if possible. Previously there were two possibilities to switch from PIO to DMA mode: Via pl011_dma_tx_irq() upon reception of a TX interrupt and via pl011_dma_tx_start() upon invocation of ->start_tx by the serial core. With threaded interrupt handling this distinction is now gone as in both cases all that happens is a wake-up of the pio_tx kthread which then independently does the right thing. Thus one of the two entry points, pl011_dma_tx_irq(), becomes obsolete and is removed. pl011_dma_tx_start() may now be invoked with the TX interrupt enabled or disabled and is therefore amended to disable the interrupt upon successfully switching to DMA mode or enabling it on failure. When transmitting in PIO mode, the FIFO fill level is tracked as with pio_rx to avoid a register read for checking FIFO fullness. On ->stop_tx, the TX interrupt is now deliberately left on so that the fill level is updated. As an additional optimization, on ->start_tx the "Transmit FIFO empty" bit in the Flag Register is checked, in which case the full FIFO length is available for "blind" writing. Signed-off-by: Lukas Wunner <lukas@wunner.de> [p.rosenberger: removew throttling support] Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de> [p.rosenberger: port to 5.10] Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Loosely based on a patch by Ladislav Michl to add basic rs485 support: https://marc.info/?l=linux-serial&m=150159197222289&w=4 Cc: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Previously the interrupt handler alternatingly read bytes from the UART and wrote bytes to it in a loop until no interrupt would be signaled anymore. Now that the interrupt handler just wakes threads, the loop is no longer necessary as the threads will keep reading or writing from the FIFOs independently. Adding debug printk's to the interrupt handler has shown that the loop is never executed more than once. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
This became necessary because the RevPi DIO module doesn't perform any delay between receiving a command and sending a response, so it takes no more than 19 usec until the response is received by the RevPi Core or Connect. Shortening the delay as done herein seems to fix the issue. Signed-off-by: Lukas Wunner <lukas@wunner.de Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
On the first revision of the "RevPi Core" open source PLC, the ks8851 interrupt pin is not connected. Work around by polling the interrupt once per millisecond. Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Tristram Ha <tristram.ha@micrel.com> Cc: David J. Choi <david.choi@micrel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> [p.rosenberger: port to 5.10] Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The ks8851 datasheet specifies that the reset pin is active low and this is also hardcoded into the driver. However on the RevPi Core and RevPi Connect it is active high, so invert the polarity in the driver. Additionally, the RevPi Core and Connect require a delay after the pin is deasserted (20 ms is too short, 25 is sufficient). On the RevPi Core both ks8851 chips are reset by the same GPIO pin. They are probed sequentially, hence the DeviceTree overlay specifies a reset pin only for the chip which is probed first. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Prepare for addition of a netfilter egress hook by renaming <linux/netfilter_ingress.h> to <linux/netfilter_netdev.h>. The egress hook also necessitates a refactoring of the include file, but that is done in a separate commit to ease reviewing. No functional change intended. Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit b030f19) Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Prepare for addition of a netfilter egress hook by generalizing the ingress hook introduced by commit e687ad6 ("netfilter: add netfilter ingress hook after handle_ing() under unique static key"). In particular, rename and refactor the ingress hook's static inlines such that they can be reused for an egress hook. No functional change intended. Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 5418d38) Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Commit e687ad6 ("netfilter: add netfilter ingress hook after handle_ing() under unique static key") introduced the ability to classify packets on ingress. Allow the same on egress. Position the hook immediately before a packet is handed to tc and then sent out on an interface, thereby mirroring the ingress order. This order allows marking packets in the netfilter egress hook and subsequently using the mark in tc. Another benefit of this order is consistency with a lot of existing documentation which says that egress tc is performed after netfilter hooks. Egress hooks already exist for the most common protocols, such as NF_INET_LOCAL_OUT or NF_ARP_OUT, and those are to be preferred because they are executed earlier during packet processing. However for more exotic protocols, there is currently no provision to apply netfilter on egress. A common workaround is to enslave the interface to a bridge and use ebtables, or to resort to tc. But when the ingress hook was introduced, consensus was that users should be given the choice to use netfilter or tc, whichever tool suits their needs best: https://lore.kernel.org/netdev/20150430153317.GA3230@salvia/ This hook is also useful for NAT46/NAT64, tunneling and filtering of locally generated af_packet traffic such as dhclient. There have also been occasional user requests for a netfilter egress hook in the past, e.g.: https://www.spinics.net/lists/netfilter/msg50038.html Performance measurements with pktgen surprisingly show a speedup rather than a slowdown with this commit: * Without this commit: Result: OK: 34240933(c34238375+d2558) usec, 100000000 (60byte,0frags) 2920481pps 1401Mb/sec (1401830880bps) errors: 0 * With this commit: Result: OK: 33997299(c33994193+d3106) usec, 100000000 (60byte,0frags) 2941410pps 1411Mb/sec (1411876800bps) errors: 0 * Without this commit + tc egress: Result: OK: 39022386(c39019547+d2839) usec, 100000000 (60byte,0frags) 2562631pps 1230Mb/sec (1230062880bps) errors: 0 * With this commit + tc egress: Result: OK: 37604447(c37601877+d2570) usec, 100000000 (60byte,0frags) 2659259pps 1276Mb/sec (1276444320bps) errors: 0 * With this commit + nft egress: Result: OK: 41436689(c41434088+d2600) usec, 100000000 (60byte,0frags) 2413320pps 1158Mb/sec (1158393600bps) errors: 0 Tested on a bare-metal Core i7-3615QM, each measurement was performed three times to verify that the numbers are stable. Commands to perform a measurement: modprobe pktgen echo "add_device lo@3" > /proc/net/pktgen/kpktgend_3 samples/pktgen/pktgen_bench_xmit_mode_queue_xmit.sh -i 'lo@3' -n 100000000 Commands for testing tc egress: tc qdisc add dev lo clsact tc filter add dev lo egress protocol ip prio 1 u32 match ip dst 4.3.2.1/32 Commands for testing nft egress: nft add table netdev t nft add chain netdev t co \{ type filter hook egress device lo priority 0 \; \} nft add rule netdev t co ip daddr 4.3.2.1/32 drop All testing was performed on the loopback interface to avoid distorting measurements by the packet handling in the low-level Ethernet driver. Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 8537f78) [p.rosenberger: port to 5.10] Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
If a TPM 2.0 chip has not been initialized by the platform firmware, a message "A TPM error (256) occurred attempting the self test" is emitted with KERN_ERR severity in addition to a KERN_INFO message "starting up the TPM manually". The former message is caused by tpm_transmit_cmd() misinterpreting the (expected) TPM2_RC_INITIALIZE response code as an error. The error message is particularly inappropriate on TPMs which are not used for integrity measurements but merely to store key material and which are hence not touched by the firmware. (In our case, a TPM attached to a Raspberry Pi.) Silence the error by adding the response code in question to the existing whitelist of allowed response codes. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The code comment preceding register_console() claims that:
"There are two types of consoles - bootconsoles (early_printk) and
"real" consoles (everything which is not a bootconsole) which are
handled differently. [...]
As soon as a "real" console is registered, all bootconsoles
will be unregistered automatically."
But that's not what the code does: The code unregisters bootconsoles
only when the *preferred* console registers, i.e. the last one on the
command line. If that console's driver never registers (e.g. because
it is disabled in the kernel config), bootconsoles stay around
indefinitely. Should the command line contain both a bootconsole as
well as a real console on a particular serial port, all messages are
logged twice once the real console registers. Also, the log buffer is
replayed once the real console registers even though the messages were
already emitted by the bootconsole.
Amend the code to be congruent with the above-quoted code comment to
avoid these issues.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
[p.rosenberger: fixup to 5.10]
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
To build external modules, one needs executables such as fixdep and modpost. But when cross-compiling the kernel, those executables are only generated for the host arch, not the target arch. Distributions ship packages which users need to install in order to build external modules. These packages contain headers and Makefiles from the kernel source tree as well as fixdep & friends. Usually the packages are cross-built on a single host arch for the multitude of arches supported by the distribution. But because fixdep & friends are only compiled for the host arch, distributions are forced to duplicate these executables' Makefiles in order to cross-compile them. For instance, these are Debian's duplicated Makefiles: https://salsa.debian.org/kernel-team/linux/-/tree/master/debian/rules.d/scripts Make distribution maintainers' lives easier by providing a new target "make kbuild_install" which cross-compiles the required executables for the target arch and installs them below $(INSTALL_KBUILD_PATH). To avoid wasting compile time and disk space, compile only programs which are essential for building external modules. They are declared essential by adding them to extmodprogs. For now, these are: recordmcount sign-file fixdep genksyms modpost The rules to cross-compile the executables reside in Makefile.kbuildinst. They are similar to the rules in Makefile.host, but I've left out rules for C++ executables and shared libraries as they're not necessary. The host versions of the executables are generated in $(obj) whereas the cross-compiled versions are generated in $(obj)/.cross/ . This necessitates a modification of Makefile.lib because the multi_depend macro creates rules which assume that the target and its dependencies always reside in $(obj). Refactor the macro to use $(dir $1) in lieu of $(obj). Likewise, the target-stem macro strips $(obj)/ instead of $(obj)/.cross/. Refactor it to use $(notdir $@). In a future step, Makefile.kbuildinst may be extended to also install headers and other bits necessary for building external modules. Signed-off-by: Lukas Wunner <lukas@wunner.de> from: https://patchwork.kernel.org/project/linux-kbuild/patch/c744107b341e487cf37139597a7775f6f62e12e8.1596702608.git.lukas@wunner.de/ [p.rosenberger: fixup to 5.10] Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
suspend testing Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
… boot As the RTC is on an i2c bus the i2c host drivers needs to be built in. The same aplies to the RTC driver. This seems to be fixed with f9b2a4d. This commit might not be needed any more. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
KS8851: eth1 74X164: dout MAX3191X: din DAC082S085: aout MUX_GPIO: ain mux IIO_MUX: ain mux Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
If a mac address is set as module parameter a second device would get the same mac address. Just increase the mac address from the last device. If this results in an invalid mac address just fall back to generating a radom one. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
As the compatibles should be listed from specific to more general the kunbus,<board> compatible should be listed first. This is the only way to match it with udev rules or to write a board/platform driver only for the matching board. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Make sure the leds use the led triggers which are provided by the piControl module as default. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The application of the device tree overlay to the generic raspberry device-tree failed if applied via the command dtoverlay. The reason is that some node labels that were already defined in the generic device tree, were redefined by the flat-overlay. While the bootloader seems to tolerate those duplicates (i.e. if the overlay is applied by setting dtoverlay=revpi-flat in /boot/config.txt), dtoverlay failes with the error message "* Failed to apply overlay '0_revpi-flat' (kernel)" To fix this remove the duplicate labels which are: 2c0_gpio44: already defined in arch/arm/boot/dts/bcm283x.dtsi i2c1_gpio2: already defined in arch/arm/boot/dts/bcm283x.dtsi emmc_gpio34: already defined in arch/arm/boot/dts/bcm2710-rpi-cm3.dts spi0_cs_pins: already defined in arch/arm/boot/dts/bcm2710-rpi-cm3.dts Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The TPM uses GPIO 1 for interrupts, not GPIO 2. Fix this. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
GPIO 0 is currently configured as "in" while GPIO 1 is configured as "out". However GPIO 0 is supposted to be used for TPM reset and thus has to be "out" while GPIO 1 is supposed to be used as the TPM irq and thus has to be "in". Fix this. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Read the mac address from device tree if the property "local-mac-address" is specified. In this case skip reading the MAC from the dongle. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Provide the "local-mac-address" property for the wireless lan interface so that it can be set by the bootloader. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Enable all available USB CAN drivers. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
To resume normal operation after a total power loss (no or empty battery) the "Power-On Reset Override (PORO)" facility needs to be disabled. The register reset value sets the PORO enabled and the data sheet recommends setting it to disabled for normal operation. From what I've seen on the PCF2127 and PCF2129 there is no event generated at the interrupt pin (INT), as long the PORO bit is set. This behavior is not documented in the manual. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210118085752.5759-2-p.rosenberger@kunbus.com (cherry picked from commit b9ac079) Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The datasheet of the PCF2127 states, it is recommended to process an OTP refresh once the power is up and the oscillator is operating stable. The OTP refresh takes less than 100 ms to complete. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210118085752.5759-3-p.rosenberger@kunbus.com (cherry picked from commit 15f57b3) Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
Properly set flag WD_CD for rtc chips(pcf2129, pca2129) Signed-off-by: Biwen Li <biwen.li@nxp.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201202031840.15582-1-biwen.li@oss.nxp.com (cherry picked from commit 2843d56) Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The KSZ8851 on the RevPi Core has a circuit which will keep it for around 80ms in the reset when the reset gpio is released. The driver needs to wait this time after the reset gpio is released. The driver has no support for this. So we use a regulator with the approprieate delays as workaround. The startup-delay is set to 80ms. So The driver should wait for at least 80ms after enabling the regulator. The off-on-delay is set to 11.5ms. The data sheet of the KSZ8851 says it needs a 10ms reset and the circuit adds 1.5ms to drain the capacitor. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The KSZ8851 on the RevPi Connect has a circuit which will keep it for around 80ms in the reset when the reset gpio is released. The driver needs to wait this time after the reset gpio is released. The driver has no support for this. So we use a regulator with the approprieate delays as workaround. The startup-delay is set to 80ms. So The driver should wait for at least 80ms after enabling the regulator. The off-on-delay is set to 11.5ms. The data sheet of the KSZ8851 says it needs a 10ms reset and the circuit adds 1.5ms to drain the capacitor. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
The reset gpio of KSZ8851 on the RevPi Core and RevPi Connect is inverted. The reset circuit also has a buffer which keeps the KSZ8851 upto 80ms in reset even if the reset pin was released. To workaround the issue without totally breaking the driver on other boards the reset is implemented as a fixed regulator. This makes it possible to workaround the inverted polarity and the 80ms of the buffer. The actuall reset of at least 10ms is not reached with this workaround. So we add an extra delay after the vdd regulator is enabled. Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
This reverts commit ab34413. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
This reverts commit a25a018. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
This reverts commit 0c5b74d. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
This reverts commit 60ace52. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
This reverts commit fb6dee0. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Add basic RS485 support. This is loosely based on an implementation by Lukas Wunner. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Currently the tx drain interval is calculated by means of the port timeout which is provided by the serial core. However this timeout is based on jiffies. The jiffie resolution may not be sufficient to provide values that result in very small drain intervals, e.g. if the baud rate is 115200 bit/s or higher. For this reason do an own calculation of the max period to drain the tx queue which provides usec resolution. This leads to a reduction of the calculated tx queue drain interval from 625 to 86 usec if a baud rate of 115200 bit/s is used. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
According to Lukas Wunner it may only take 19 usecs until the response of the DIOs is received after data is requested (see the commit message of the patch "serial: pl011: Shorten delay to deassert rs485 Transmit Enable"). The calculated max delay used for the tx queue draining is 86 usecs with a baud rate of 115200 bit/s. To provide a better responsiveness in the average case divide this value by 5. For the best case this reduces the delay to 17 usecs. For the worst case however the delay has to be repeated multiple times up to a total of 86 usecs. So this is only meant as a workaround to reduce the probability of problems like data corruption in case of a communication with DIOs. The real fix should be a in the DIO firmware in the form of a minimal delay of 86 usecs or more before a response is sent. Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
iluminat23
force-pushed
the
devel/revpi-5.10_core3+
branch
from
633bc73 to
8a352bd
Compare
iluminat23
pushed a commit
that referenced
this pull request
Jan 20, 2022
[ Upstream commit d412137 ] The perf_buffer fails on system with offline cpus: # test_progs -t perf_buffer test_perf_buffer:PASS:nr_cpus 0 nsec test_perf_buffer:PASS:nr_on_cpus 0 nsec test_perf_buffer:PASS:skel_load 0 nsec test_perf_buffer:PASS:attach_kprobe 0 nsec test_perf_buffer:PASS:perf_buf__new 0 nsec test_perf_buffer:PASS:epoll_fd 0 nsec skipping offline CPU #24 skipping offline CPU #25 skipping offline CPU #26 skipping offline CPU #27 skipping offline CPU #28 skipping offline CPU #29 skipping offline CPU #30 skipping offline CPU #31 test_perf_buffer:PASS:perf_buffer__poll 0 nsec test_perf_buffer:PASS:seen_cpu_cnt 0 nsec test_perf_buffer:FAIL:buf_cnt got 24, expected 32 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Changing the test to check online cpus instead of possible. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211021114132.8196-2-jolsa@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
|
@linosanfilippo-kunbus is this still relevant or can we close this PR? |
nbuchwitz
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.