Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 12月, 2017 4 次提交
    • J
      serial: max310x: Use batched reads when reasonably safe · 2b4bac48
      由 Jan Kundrát 提交于 
      The hardware has a 128 byte RX FIFO buffer for each independent UART.
Previously, the code was always reading that byte-by-byte via
independent SPI transactions and the associated overhead. In practice,
this led to up to eight bytes over SPI for just one byte in the UART's
RX FIFO:

- reading the global IRQ register (two bytes, one for command, the other
for data)
- reading one UART's ISR (again two bytes)
- reading the byte count (two bytes yet again)
- finally, reading one byte of the FIFO via another two-byte transaction

We cannot always use a batched read. If the TTY is set to intercept
break conditions or report framing or parity errors, then it is required
to check the Line Status Register (LSR) for each byte which is read from
the RX FIFO. The documentation does not show a way of doing that in a
single SPI transaction; registers 0x00 and 0x04 are separate.

In my testing, this is no silver bullet. I was feeding 2MB of random
data over four daisy-chaned UARTs of MAX14830, and this is the
distribution that I was getting:

- R <= 1: 7437322
- R <= 2: 162093
- R <= 4: 4093
- R <= 8: 4196
- R <= 16: 645
- R <= 32: 165
- R <= 64: 58
- R <= 128: 0

For a reference, batching the write operations works much better:

- W <= 1: 2664
- W <= 2: 1305
- W <= 4: 627
- W <= 8: 371
- W <= 16: 121
- W <= 32: 68
- W <= 64: 33
- W <= 128: 63139

That's probably because this HW/SW combination (Clearfog Base, Armada
388) is probably "good enough" to react to the chip's IRQ "fast enough"
most of the time. Still, I was getting RX overruns every now and then.
In future, I plan to improve this by letting the RX FIFO be filled a
little more (the chip has support for that and also for a "stale
timeout" to prevent additional starvation).
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b4bac48
    • J
      serial: max310x: use a batch write op for UART transmit · d584b65c
      由 Jan Kundrát 提交于 
      The transmit register supports batched writes. The key is simply to keep
sending additional bytes up to the FIFO size in the same SPI
transaction with the CS pin still being held low.

This duplicates the regmap infrastructure to a certain extent. There are
some provisions for multiple writes in there, but there does not appear
to be any support for those writes which are destined to the *same*
register (and also no standard for SPI bus transfers of these, anyway).

This patch does not solve every case (if the UART xmit circular buffer
wraps around, we're still doing two SPI transactions), but at least
it's not one-byte-per-transaction anymore.

This change does not touch the receive path at this time. Doing that in
the generic case appears to be impossible in the general case, because
the chips' status register contains data about the *current* byte in the
HW's Rx FIFO. We cannot read these two registers in one go,
unfortunately.
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d584b65c
    • J
      serial: max310x: Support IRQ sharing with other devices · 78be70c8
      由 Jan Kundrát 提交于 
      According to my chip's datasheet [1], the IRQ output is an open
collector pin which is suitable for sharing with other chips. The chip
also has a register which indicates which UART performed a change and
the driver checks that register already, so we have everything what is
needed to effectively share the IRQ GPIO.

[1] https://datasheets.maximintegrated.com/en/ds/MAX14830.pdfSigned-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      78be70c8
    • J
      serial: max310x: Do not hard-code the IRQ type · bceb4839
      由 Jan Kundrát 提交于 
      As suggested by Russell King, a driver should not really care about bits
such as the interrupt polarity or whether it is edge- or level-
triggered. The reasons for that include:

- an upstream IRQ controller which cannot support edge- or
level-triggered interrupts,
- board design with a built-in inverter

The interrupt type is being already specified by the Device Tree,
anyway. Other drivers (gpio/gpio-tc3589x.c for example) already work in
this way, delegating the proper IRQ line setup to the DT and not
specifying anything by hand.

Also, there's no reason to have the IRQ flags split between two places.
The SPI probing is the only entry point anyway.
Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bceb4839
  3. 18 12月, 2017 2 次提交
  5. 16 12月, 2017 12 次提交
  7. 28 11月, 2017 22 次提交