Commit graph

11 commits

Author SHA1 Message Date
Sven Eckelmann
3adb820779 realtek: rtl931x: Add SPI_CTRL0 as pinmux
The RTL931x has next to its SPI flash controller a SPI master interface. It
is connected to

* SPI_CS#[1,0]: AH22 , AK22 (aka: GPIO 12, 11)
* SPI_CLK:      AL23 (aka: GPIO 8)
* SPI_MISO:     AM23 (aka: GPIO 9)
* SPI_MOSI:     AL22 (aka: GPIO 10)

It is not the same as the SPI flash controller which uses pins:

* SPI_CS#[1,0]: B24, A24
* SPI_SCLK:     A23
* SPI_SDI/SIO0: B21
* SPO_SDO_SIO1: B21
* SPI_SIO2:     A22
* SPI_SIO3:     B22
* SPI_RSTN:     B23

As shown above, the SPI master controller shares its pin with GPIO 8, 9,
10, 11, 12. In some upcoming devices (like the Plasma Cloud PSX28/ESX28),
they will be used for SFP cage signaling. These pins must therefore be
switched manually to the GPIO mode.

The SPI_CTRL0 register provides all necessary configuration to enforce the
GPIO mode of the pins. And until more requirements (and a correct driver)
for the SPI master controller arise, it is therefore possible to use
pinctrl-single to configure it using the devicetree.

Previously the ethernet driver did configure the SPI master controller for
31.25 MHz. It is unknown for which kind of device this was originally made
and what was actually connected there. But this manual write to the
register conflicts potentially with the write of the pinctrl driver to the
same register. Luckily, we don't need this SPI speed configuration in the
ethernet driver. Still, to allow this device an easy migration, the
`spi0-31mhz` configuration was already prepared.

Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20263
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-10-02 10:30:16 +02:00
Markus Stockhausen
76cfd5b8b7 realtek: cleanup mach include
A lot of definitions in the global mach include have been taken over
to the individual drivers. Only a few of the definitions are really
used nowadays. Remove all the unneeded lines.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19995
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-09-10 13:49:44 +02:00
Markus Stockhausen
070d8eb4d5 realtek: mdio: rtl931x: move functions over to bus
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
This commit repeats the mdio function relocation from the other targets.
In short that means:

- phy read/write functions are moved away from the phy driver
- SerDes read/write functions are moved away from the dsa driver
- All gets consolidated into the mdio driver (inside the ethernet driver)

This is mostly a copy/paste to keep the changes small. The SerDes phy mapping
and the simplification of the central bus functions will come later.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19743
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-19 20:06:08 +02:00
Markus Stockhausen
07a04d8485 realtek: RTL930x: reorganize mdio functions and SerDes register layout
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
Build and Push prebuilt tools container / Build and Push all prebuilt containers (push) Waiting to run
Build Toolchains / Build Toolchains for each target (push) Waiting to run
The RTL930x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver). With this change
the phy identification looks into the proper registers. The SerDes
phy identifier (register 2/3) must be changed.

Additionally provide a consistent SerDes register access through the
mdio bus. Until now when a SerDes directly drives a SFP module there
is no clear rule of how to handle its register set that consists of
two parts:

- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after

The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.

Adapt the bus to the new consistent phy interface that mixes the
SerDes register set like classic Realtek phys do it.

- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
  registers 16-23 according to the page select register (31).

That gives a register mapping as follows:

+-----------------------+-----------------------+---------------+-------------+
| reg 0x00-0x0f         | reg 0x10-0x17         | reg 0x18-0x1e | reg 0x1f    |
+-----------------------+-----------------------+---------------+-------------+
| SerDes fiber page (3) | real SerDes registers | zero          | SerDes page |
| registers 0 - 15      | in packages of 8      |               | select reg  |
+-----------------------+-----------------------+---------------+-------------+

Example to make it as clear as possible.

SerDes registers on a RTL930x show

Page / Reg   | 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B ...
-------------+----------------------------------------------------------------
0 - SDS      | 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248 0000 0F80 0000 ...
1 - SDS_EXT  | 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA 8C64 00C3 1482 ...
2 - FIB      | 1140 6189 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
3 - FIB_EXT  | 1140 6109 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...

This translates to this phy layout

             | SerDes fiber registers  normal SerDes registers  zero     p.sel
Page / Reg   | 0x00 0x01 0x02 0x03 ... 0x10 0x11 0x12 0x13 ...  0x18 ... 0x1f
-------------+---------------------------------------------------------------
0            | 1140 6189 001C CA40 ... 0C03 0F00 7060 7106 ...  0000 ... 0000
1            | 1140 6189 001C CA40 ... 5248 0000 0F80 0000 ...  0000 ... 0001
...
4            | 1140 6189 001C CA40 ... 0000 0000 85FA 8C6D ...  0000 ... 0004

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19692
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-10 11:47:30 +02:00
Harshal Gohel
4c4cecab2f realtek: rtl93xx: Add GPIO access register definitions
mach-rtl83xx.h contained the required register definitions for older SoC
families but was missing it for RTL930x and RTL931x.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 18:40:30 +02:00
Jan Hoffmann
2a9f0db76f realtek: extend SoC information
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Add SoC revision, CPU part number, and a flag for engineering samples to
the rtl83xx_soc_info structure.

Also extend the system type string to include this information.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 13:41:51 +02:00
Jan Hoffmann
368dab7c7a realtek: move and clean up CHIP_INFO register definitions
Move the definitions to mach-rtl83xx.h, so they can be used during init
to read more detailed SoC information. Also rename the RTL931X register,
as it has the same address on all RTL93xx.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 13:41:51 +02:00
Jan Hoffmann
d469690b83 realtek: simplify SoC detection
Read model name from the register instead of using hard-coded values.

Also remove detection of the unsupported Realtek ESW/SSW SoCs. The Fast
Ethernet variants of the Maple and Cypress series stay for now, but are
moved to the RTL8380/RTL8390 families.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 13:41:51 +02:00
Markus Stockhausen
21d3722c40 realtek: don't disable MIPS counter on secondary VPEs
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
After observation that timer interrupt 7 always fires on secondary VPEs
the counter was disabled in the startup code. This is a bad idea when
building the kernel with jitterentropy. To generate entropy it makes use
of function random_get_entropy(). On MIPS architecture this simply reads
the counter register on the current core. With a disabled counter it
always returns the same value and the entropy initialization stalls the
core if it runs on a secondary VPE. See backtrace

[   21.736246] rcu: INFO: rcu_sched self-detected stall on CPU
[   21.736246] rcu: INFO: rcu_sched self-detected stall on CPU
[   21.748594] rcu:     1-....: (2100 ticks this GP) idle=064c/1/0x40000002 softirq=7/7 fqs=1050
[   21.748594] rcu:     1-....: (2100 ticks this GP) idle=064c/1/0x40000002 softirq=7/7 fqs=1050
[   21.766871] rcu:     (t=2102 jiffies g=-1187 q=25 ncpus=2)
[   21.766871] rcu:     (t=2102 jiffies g=-1187 q=25 ncpus=2)
[   21.778429] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.39 #482
[   21.778429] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.39 #482
[   21.778461] Hardware name: Zyxel GS1900-48
[   21.778461] Hardware name: Zyxel GS1900-48
...
[   21.779757] [<8029b968>] jent_measure_jitter+0xc8/0x10c
[   21.779757] [<8029b968>] jent_measure_jitter+0xc8/0x10c
[   21.779779] [<8029b9e8>] jent_gen_entropy+0x3c/0xb0
[   21.779779] [<8029b9e8>] jent_gen_entropy+0x3c/0xb0
[   21.779800] [<8029bcc0>] jent_entropy_collector_alloc+0x104/0x118
[   21.779800] [<8029bcc0>] jent_entropy_collector_alloc+0x104/0x118
[   21.779822] [<8029bd6c>] jent_entropy_init+0x4c/0x2ec
[   21.779822] [<8029bd6c>] jent_entropy_init+0x4c/0x2ec
[   21.779844] [<8086f184>] jent_mod_init+0x58/0xac
[   21.779844] [<8086f184>] jent_mod_init+0x58/0xac
[   21.779865] [<80100200>] do_one_initcall+0x70/0x250
[   21.779865] [<80100200>] do_one_initcall+0x70/0x250
[   21.779883] [<8085c018>] kernel_init_freeable+0x1f0/0x280
[   21.779883] [<8085c018>] kernel_init_freeable+0x1f0/0x280
[   21.779905] [<8067cba4>] kernel_init+0x20/0xb0
[   21.779905] [<8067cba4>] kernel_init+0x20/0xb0
[   21.779926] [<80101158>] ret_from_kernel_thread+0x14/0x1c
[   21.779926] [<80101158>] ret_from_kernel_thread+0x14/0x1c

This bit of entropy is helpful on these low end devices. Reenable the
counter and simply disable the interrupt.

Fixes: b7aab19585 ("realtek: SMP handling of R4K timer interrupts")
Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19499
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-26 15:51:23 +02:00
Markus Stockhausen
e124859587 realtek: 6.12: relocate R4K deactivation to late CPU init
To avoid unneeded interrupts the R4K timer is deactivated during
secondary cpu initialization. This is currently done during
phase init_secondary(). With the upgrade to 6.12 the kernel runs
a primary/secondary cpu timer/counter synchronization to verify the
proper setup in synchronise_count_slave(). That runs at a later
point in time and expects the secondary counter to be fully
functional. Finding a deactivated counter results in the following
messages:

WARNING: CPU: 1 PID: 0 at arch/mips/kernel/sync-r4k.c:99 check_counter_warp+0x220/0x254
Warning: zero counter calibration delta: 0 [max: 6500000]
Counter synchronization [CPU#0 -> CPU#1]:
Measured 278760029 cycles counter warp between CPUs

Relocate the deactivation to smp_finsh() at the end of the cpu
startup sequence. Additionally polish the startup code and remove
all unneeded parts.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-11 22:27:22 +02:00
Markus Stockhausen
ac1be95438 realtek: 6.12: create files-6.12 from files-6.6
Automatically generated commit.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18935
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-11 22:27:21 +02:00