Skip to content

Conversation

JoseExposito
Copy link
Contributor

Hi @esmil,

This is a follow up on #66, including all the required code cleanups to make checkpatch.pl happy.

Jose

teknoraver and others added 30 commits October 6, 2022 16:02
Write a C version of memcpy() which uses the biggest data size allowed,
without generating unaligned accesses.

The procedure is made of three steps:
First copy data one byte at time until the destination buffer is aligned
to a long boundary.
Then copy the data one long at time shifting the current and the next u8
to compose a long at every cycle.
Finally, copy the remainder one byte at time.

On a BeagleV, the TCP RX throughput increased by 45%:

before:

$ iperf3 -c beaglev
Connecting to host beaglev, port 5201
[  5] local 192.168.85.6 port 44840 connected to 192.168.85.48 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  76.4 MBytes   641 Mbits/sec   27    624 KBytes
[  5]   1.00-2.00   sec  72.5 MBytes   608 Mbits/sec    0    708 KBytes
[  5]   2.00-3.00   sec  73.8 MBytes   619 Mbits/sec   10    451 KBytes
[  5]   3.00-4.00   sec  72.5 MBytes   608 Mbits/sec    0    564 KBytes
[  5]   4.00-5.00   sec  73.8 MBytes   619 Mbits/sec    0    658 KBytes
[  5]   5.00-6.00   sec  73.8 MBytes   619 Mbits/sec   14    522 KBytes
[  5]   6.00-7.00   sec  73.8 MBytes   619 Mbits/sec    0    621 KBytes
[  5]   7.00-8.00   sec  72.5 MBytes   608 Mbits/sec    0    706 KBytes
[  5]   8.00-9.00   sec  73.8 MBytes   619 Mbits/sec   20    580 KBytes
[  5]   9.00-10.00  sec  73.8 MBytes   619 Mbits/sec    0    672 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   736 MBytes   618 Mbits/sec   71             sender
[  5]   0.00-10.01  sec   733 MBytes   615 Mbits/sec                  receiver

after:

$ iperf3 -c beaglev
Connecting to host beaglev, port 5201
[  5] local 192.168.85.6 port 44864 connected to 192.168.85.48 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   109 MBytes   912 Mbits/sec   48    559 KBytes
[  5]   1.00-2.00   sec   108 MBytes   902 Mbits/sec    0    690 KBytes
[  5]   2.00-3.00   sec   106 MBytes   891 Mbits/sec   36    396 KBytes
[  5]   3.00-4.00   sec   108 MBytes   902 Mbits/sec    0    567 KBytes
[  5]   4.00-5.00   sec   106 MBytes   891 Mbits/sec    0    699 KBytes
[  5]   5.00-6.00   sec   106 MBytes   891 Mbits/sec   32    414 KBytes
[  5]   6.00-7.00   sec   106 MBytes   891 Mbits/sec    0    583 KBytes
[  5]   7.00-8.00   sec   106 MBytes   891 Mbits/sec    0    708 KBytes
[  5]   8.00-9.00   sec   106 MBytes   891 Mbits/sec   28    433 KBytes
[  5]   9.00-10.00  sec   108 MBytes   902 Mbits/sec    0    591 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.04 GBytes   897 Mbits/sec  144             sender
[  5]   0.00-10.01  sec  1.04 GBytes   894 Mbits/sec                  receiver

And the decreased CPU time of the memcpy() is observable with perf top.
This is the `perf top -Ue task-clock` output when doing the test:

before:

Overhead  Shared O  Symbol
  42.22%  [kernel]  [k] memcpy
  35.00%  [kernel]  [k] __asm_copy_to_user
   3.50%  [kernel]  [k] sifive_l2_flush64_range
   2.30%  [kernel]  [k] stmmac_napi_poll_rx
   1.11%  [kernel]  [k] memset

after:

Overhead  Shared O  Symbol
  45.69%  [kernel]  [k] __asm_copy_to_user
  29.06%  [kernel]  [k] memcpy
   4.09%  [kernel]  [k] sifive_l2_flush64_range
   2.77%  [kernel]  [k] stmmac_napi_poll_rx
   1.24%  [kernel]  [k] memset

Signed-off-by: Matteo Croce <mcroce@microsoft.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
When the destination buffer is before the source one, or when the
buffers doesn't overlap, it's safe to use memcpy() instead, which is
optimized to use a bigger data size possible.

Signed-off-by: Matteo Croce <mcroce@microsoft.com>
The generic memset is defined as a byte at time write. This is always
safe, but it's slower than a 4 byte or even 8 byte write.

Write a generic memset which fills the data one byte at time until the
destination is aligned, then fills using the largest size allowed,
and finally fills the remaining data one byte at time.

Signed-off-by: Matteo Croce <mcroce@microsoft.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
To improve human readability and enable automatic validation, the tuples
in the various properties containing interrupt specifiers should be
grouped.

Fix this by grouping the tuples of "interrupts-extended" properties
using angle brackets.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Add device tree node for the audio clocks on the StarFive JH7100 RISC-V
SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add all resets for the StarFive JH7100 audio reset controller.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add bindings for the audio reset controller on the StarFive JH7100
RISC-V SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This moves the StarFive JH7100 reset driver to a new subdirectory in
preparation for adding more StarFive reset drivers.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
The driver currently uses 64bit I/O on the 32bit registers. This works
because there are 4 assert registers and 4 status register, so they're
only ever accessed on 64bit boundaries.

There are however other reset controllers for audio and video on the SoC
with only one status register that isn't 64bit aligned so 64bit I/O
would result in an unaligned access exception.

Switch to 32bit I/O in preparation for supporting these resets too.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
The audio resets are almost identical to the system resets, there are
just fewer of them. So factor out and export a generic probe function,
so most of the reset controller implementation can be shared.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add device tree node for the audio resets on the StarFive JH7100 RISC-V
SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Current u-boot doesn't seem to take into account that some GPIOs are
configured as inputs/outputs of certain peripherals on power-up. This
means it ends up configuring some GPIOs as inputs to more than one
peripheral which the documentation explicitly says is illegal. Similarly
it also ends up configuring more than one GPIO as output of the same
peripheral. While not explicitly mentioned by the documentation this
also seems like a bad idea.

The easiest way to remedy this mess is to just disconnect all GPIOs from
peripherals and have our pinmux configuration set everything up
properly. This, however, means that we'd disconnect the serial console
from its pins for a while, so add a device tree property to keep
certain GPIOs from being reset.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This adds a compatible for the high speed UARTs on the StarFive JH7100
RISC-V SoC. Just like the regular uarts we also need to keep the input
clocks at their default rate and rely only on the divisor in the UART.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add bindings for the temperature sensor on the StarFive JH7100 SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Reviewed-by: Rob Herring <robh@kernel.org>
Register definitions and conversion constants based on sfctemp driver by
Samin in the StarFive 5.10 kernel.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This cache controller is also used on the StarFive JH7100 SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This adds support for the StarFive JH7100 SoC which also features this
SiFive cache controller.

Unfortunately the data corrected interrupt is broken and fires
continuously, so add a quirk to not register a handler for it.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add functions to flush the caches and handle non-coherent DMA.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This variant is used on the StarFive JH7100 SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
yiming.li: clear CNTR of PWM after setting period & duty_cycle
Emil: cleanups, clock, reset and div_u64

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
The first DMAC instance in the StarFive JH7100 SoC supports 16 DMA
channels.

FIXME Given there are more changes to the driver than just increasing
      DMAC_MAX_CHANNELS, we probably need a new compatible value, too.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Signed-off-by: Curry Zhang <curry.zhang@starfivetech.com>
Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This adds basic support for the Motorcomm YT8521 Gigabit Ethernet PHY.

Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
WalkerChenL and others added 16 commits October 6, 2022 16:02
Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Signed-off-by: Matteo Croce <mcroce@microsoft.com>
Signed-off-by: Michael Yan <michael.yan@starfivetech.com>
Signed-off-by: Jenny Zhang <jenny.zhang@starfivetech.com>
Signed-off-by: Walker Chen <walker.chen@starfivetech.com>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add starfive DRM Display driver framework

Signed-off-by: jack.zhu <jack.zhu@starfivetech.com>
Signed-off-by: keith.zhao <keith.zhao@starfivetech.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Link: https://lore.kernel.org/r/a8ca722539672d6369d6e4092e1e08cb6b58c546.1645535955.git.geert@linux-m68k.org
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
When creating dumb buffers with 32bpp and 24bit colour depth this is
default mode return by drm_mode_legacy_fb_format. So we need to support
this for common dumb buffers to just work.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
A proper solution to this hack should be found.

Signed-off-by: jack.zhu <jack.zhu@starfivetech.com>
Signed-off-by: keith.zhao <keith.zhao@starfivetech.com>
Additional update from Prashant Gaikwad <pgaikwad@nvidia.com>
Adapted for Linux 5.13 and the BeagleV Starlight board by
<cybergaszcz@gmail.com>

kernel test robot: fix platform_no_drv_owner.cocci warnings
Geert: Use div_u64() in dla_get_time_us()

Signed-off-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20220119060057.GA1143@7f39e361da8f
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2203090905560.780932@ramsan.of.borg
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
This IP is also used on the StarFive JH7100 riscv64 SoC and presumably
also the upcoming JH7110 SoC.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Based on the device tree in https://github.com/starfive-tech/u-boot/
with contributions from:
yanhong.wang <yanhong.wang@starfivetech.com>
Huan.Feng <huan.feng@starfivetech.com>
ke.zhu <ke.zhu@starfivetech.com>
yiming.li <yiming.li@starfivetech.com>
jack.zhu <jack.zhu@starfivetech.com>
Samin Guo <samin.guo@starfivetech.com>
Chenjieqin <Jessica.Chen@starfivetech.com>
bo.li <bo.li@starfivetech.com>

Rearranged, cleanups, fixes, pins and resets added by Emil.
Cleanups, fixes, clocks added by Geert.
Cleanups and GPIO fixes from Drew.
Thermal zone added by Stephen.
PWM pins added by Jianlong.
cpu-map added by Jonas.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Stephen L Arnold <nerdboy@gentoo.org>
Signed-off-by: Drew Fustini <drew@beagleboard.org>
Signed-off-by: Jianlong Huang <jianlong.huang@starfivetech.com>
Signed-off-by: Jonas Hahnfeld <hahnjo@hahnjo.de>
Signed-off-by: TekkamanV <tekkamanv@starfivetech.com>
For convenience this also adds a small visionfive_defconfig and the
firmware needed for the brcmfmac driver along with the signed regulatory
database.

The firmware is from the linux-firmware repo and the regulatory database
from the wireless-regdb Fedora package.

Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Drew Fustini <drew@beagleboard.org>
./scripts/checkpatch.pl warns about camel case usage in multiple
variables, fix them.

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Fix checkpatch.pl errors:

	- CHECK: Blank lines aren't necessary before a close brace '}'
	- CHECK: Please don't use multiple blank lines
	- CHECK: Please use a blank line after function/struct/union/enum declarations

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
As pointed out by checkpatch.pl:

	CHECK: Prefer kernel type 'u32' over 'uint32_t'

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
As pointed out by checkpatch.pl:

	CHECK: spaces preferred around that '|'

Signed-off-by: José Expósito <jose.exposito89@gmail.com>
@esmil
Copy link
Collaborator

esmil commented Oct 21, 2022

Thank! I've now squashed these changes into the latest version rebased on 6.1-rc1

@esmil esmil closed this Oct 21, 2022
hal-feng pushed a commit that referenced this pull request May 30, 2023
When using DMA mode we are facing with Oops:
[  396.458157] Unable to handle kernel access to user memory without uaccess routines at virtual address 000000000000000c
[  396.469374] Oops [#1]
[  396.471839] Modules linked in:
[  396.475144] CPU: 0 PID: 114 Comm: arecord Not tainted 6.0.0-00164-g9a8eccdaf2be-dirty #68
[  396.483619] Hardware name: YMP ELCT FPGA (DT)
[  396.488156] epc : dmaengine_pcm_open+0x1d2/0x342
[  396.493227]  ra : dmaengine_pcm_open+0x1d2/0x342
[  396.498140] epc : ffffffff807fe346 ra : ffffffff807fe346 sp : ffffffc804e138f0
[  396.505602]  gp : ffffffff817bf730 tp : ffffffd8042c8ac0 t0 : 6500000000000000
[  396.513045]  t1 : 0000000000000064 t2 : 656e69676e65616d s0 : ffffffc804e13990
[  396.520477]  s1 : ffffffd801b86a18 a0 : 0000000000000026 a1 : ffffffff816920f8
[  396.527897]  a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000
[  396.535319]  a5 : 0000000000000000 a6 : ffffffd801b87040 a7 : 0000000000000038
[  396.542740]  s2 : ffffffd801b94a00 s3 : 0000000000000000 s4 : ffffffd80427f5e8
[  396.550153]  s5 : ffffffd80427f5e8 s6 : ffffffd801b44410 s7 : fffffffffffffff5
[  396.557569]  s8 : 0000000000000800 s9 : 0000000000000001 s10: ffffffff8066d254
[  396.564978]  s11: ffffffd8059cf768 t3 : ffffffff817d5577 t4 : ffffffff817d5577
[  396.572391]  t5 : ffffffff817d5578 t6 : ffffffc804e136e8
[  396.577876] status: 0000000200000120 badaddr: 000000000000000c cause: 000000000000000d
[  396.586007] [<ffffffff806839f4>] snd_soc_component_open+0x1a/0x68
[  396.592439] [<ffffffff807fdd62>] __soc_pcm_open+0xf0/0x502
[  396.598217] [<ffffffff80685d86>] soc_pcm_open+0x2e/0x4e
[  396.603741] [<ffffffff8066cea4>] snd_pcm_open_substream+0x442/0x68e
[  396.610313] [<ffffffff8066d1ea>] snd_pcm_open+0xfa/0x212
[  396.615868] [<ffffffff8066d39c>] snd_pcm_capture_open+0x3a/0x60
[  396.622048] [<ffffffff8065b35a>] snd_open+0xa8/0x17a
[  396.627421] [<ffffffff801ae036>] chrdev_open+0xa0/0x218
[  396.632893] [<ffffffff801a5a28>] do_dentry_open+0x17c/0x2a6
[  396.638713] [<ffffffff801a6d9a>] vfs_open+0x1e/0x26
[  396.643850] [<ffffffff801b8544>] path_openat+0x96e/0xc96
[  396.649518] [<ffffffff801b9390>] do_filp_open+0x7c/0xf6
[  396.655034] [<ffffffff801a6ff2>] do_sys_openat2+0x8a/0x11e
[  396.660765] [<ffffffff801a735a>] sys_openat+0x50/0x7c
[  396.666068] [<ffffffff80003aca>] ret_from_syscall+0x0/0x2
[  396.674964] ---[ end trace 0000000000000000 ]---

It happens because of play_dma_data/capture_dma_data pointers are NULL.
Current implementation assigns these pointers at snd_soc_dai_driver
startup() callback and reset them back to NULL at shutdown(). But
soc_pcm_open() sequence uses DMA pointers in dmaengine_pcm_open()
before snd_soc_dai_driver startup().
Most generic DMA capable I2S drivers use snd_soc_dai_driver probe()
callback to init DMA pointers only once at probe. So move DMA init
to dw_i2s_dai_probe and drop shutdown() and startup() callbacks.

Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Link: https://lore.kernel.org/r/20230512110343.66664-1-fido_max@inbox.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
MichaIng pushed a commit to MichaIng/linux that referenced this pull request Jul 1, 2023
[ Upstream commit 011a871 ]

When using DMA mode we are facing with Oops:
[  396.458157] Unable to handle kernel access to user memory without uaccess routines at virtual address 000000000000000c
[  396.469374] Oops [#1]
[  396.471839] Modules linked in:
[  396.475144] CPU: 0 PID: 114 Comm: arecord Not tainted 6.0.0-00164-g9a8eccdaf2be-dirty starfive-tech#68
[  396.483619] Hardware name: YMP ELCT FPGA (DT)
[  396.488156] epc : dmaengine_pcm_open+0x1d2/0x342
[  396.493227]  ra : dmaengine_pcm_open+0x1d2/0x342
[  396.498140] epc : ffffffff807fe346 ra : ffffffff807fe346 sp : ffffffc804e138f0
[  396.505602]  gp : ffffffff817bf730 tp : ffffffd8042c8ac0 t0 : 6500000000000000
[  396.513045]  t1 : 0000000000000064 t2 : 656e69676e65616d s0 : ffffffc804e13990
[  396.520477]  s1 : ffffffd801b86a18 a0 : 0000000000000026 a1 : ffffffff816920f8
[  396.527897]  a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000
[  396.535319]  a5 : 0000000000000000 a6 : ffffffd801b87040 a7 : 0000000000000038
[  396.542740]  s2 : ffffffd801b94a00 s3 : 0000000000000000 s4 : ffffffd80427f5e8
[  396.550153]  s5 : ffffffd80427f5e8 s6 : ffffffd801b44410 s7 : fffffffffffffff5
[  396.557569]  s8 : 0000000000000800 s9 : 0000000000000001 s10: ffffffff8066d254
[  396.564978]  s11: ffffffd8059cf768 t3 : ffffffff817d5577 t4 : ffffffff817d5577
[  396.572391]  t5 : ffffffff817d5578 t6 : ffffffc804e136e8
[  396.577876] status: 0000000200000120 badaddr: 000000000000000c cause: 000000000000000d
[  396.586007] [<ffffffff806839f4>] snd_soc_component_open+0x1a/0x68
[  396.592439] [<ffffffff807fdd62>] __soc_pcm_open+0xf0/0x502
[  396.598217] [<ffffffff80685d86>] soc_pcm_open+0x2e/0x4e
[  396.603741] [<ffffffff8066cea4>] snd_pcm_open_substream+0x442/0x68e
[  396.610313] [<ffffffff8066d1ea>] snd_pcm_open+0xfa/0x212
[  396.615868] [<ffffffff8066d39c>] snd_pcm_capture_open+0x3a/0x60
[  396.622048] [<ffffffff8065b35a>] snd_open+0xa8/0x17a
[  396.627421] [<ffffffff801ae036>] chrdev_open+0xa0/0x218
[  396.632893] [<ffffffff801a5a28>] do_dentry_open+0x17c/0x2a6
[  396.638713] [<ffffffff801a6d9a>] vfs_open+0x1e/0x26
[  396.643850] [<ffffffff801b8544>] path_openat+0x96e/0xc96
[  396.649518] [<ffffffff801b9390>] do_filp_open+0x7c/0xf6
[  396.655034] [<ffffffff801a6ff2>] do_sys_openat2+0x8a/0x11e
[  396.660765] [<ffffffff801a735a>] sys_openat+0x50/0x7c
[  396.666068] [<ffffffff80003aca>] ret_from_syscall+0x0/0x2
[  396.674964] ---[ end trace 0000000000000000 ]---

It happens because of play_dma_data/capture_dma_data pointers are NULL.
Current implementation assigns these pointers at snd_soc_dai_driver
startup() callback and reset them back to NULL at shutdown(). But
soc_pcm_open() sequence uses DMA pointers in dmaengine_pcm_open()
before snd_soc_dai_driver startup().
Most generic DMA capable I2S drivers use snd_soc_dai_driver probe()
callback to init DMA pointers only once at probe. So move DMA init
to dw_i2s_dai_probe and drop shutdown() and startup() callbacks.

Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Link: https://lore.kernel.org/r/20230512110343.66664-1-fido_max@inbox.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants