| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
|
|
Baikal-T1 SoC updates for LANDAU Linux v7.0
This merge adds MIPS Baikal-T1 platform support, extensive STMMAC/EDAC
updates, new board support, and various driver fixes/improvements.
Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
|
|
Amlogic SoC updates for LANDAU Linux v7.0
This merge brings support for new A1 CPU/audio clocks, Amlogic BBT parser,
AW200xx LED enhancements, and new board defconfigs.
Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
|
|
'pcie-lo', 'edac-bt1', 'xgmac-bt1', 'mips-bpf', 'mips-eva' and 'bsp' into for-landau-next
|
|
Baikal-T1 is equipped with two DW GMAC v3.73a controllers synthesized with
RGMII interface, MDIO bus, 16KB MTL Rx/Tx FIFO, 8 MAC address perfect
filter slots, HW-based SA/VLAN/CRC insertion, 1xGPO and 1xGPI, EEE logic,
IEEE 1588 Timestamping with Advanced capabilities, PMT capability with
MagicPacket and Remote Wake-up support, Full Tx/Rx CSUM, IPv4 ARP offload,
no hash-table and no L3/L4 filter logic. In addition to that there is DW
XGMAC v2.11a and DW XPCS 3.11b synthesized with 10GBase-KR and 10GBase-KX4
physical interface, no MDIO bus, 32KB MTL Rx/Tx FIFO, 8 MAC address
perfect filter slots, 64 slot in the Hash-based DA filter, VLAN Hash-based
filter, 2x L3/L4 filters, 2x TCs, 2x Tx MTL Queues, 4x Rx MTL Queues, DCB
feature, TSO and SPH for TCP/IP packets, Full Tx/Rx CSUM Offload, IPv4 ARP
offload, 64-entries RSS table, IEEE 1588 Timestamping with Advanced
capabilities, no PMT.
Most of that is more-or-less supported by the STMMAC driver. The only
thing left to do is to add the Baikal-T1 platform-specific glue driver for
it.
The LLDD is mainly responsible for the standard STMMAC driver
pre-initialization and the platform device probing. There are some
peculiar Baikal-T1 GMAC-specific actions performed aside of that though.
First of all we need to enable/disable the RGMII Tx clock and tune its
rate up based on the RGMII interface mode. Secondly due to the having the
most of the Baikal-T1 platforms using the embedded GPO for the attached
PHYs reset we have to make sure the DW GMAC core isn't reset after the
device is probed otherwise any PHY initializations performed afterwards
will be lost. In order to do that the custom DW GMAC software reset
callback is introduced. Finally for the same reason we've added a custom
MDIO bus reset method so the GPO would be set to a mainly valid value
before the platform Ethernet PHYs are actually probed.
Note the custom MDIO/COre reset methods is a temporary solution until we
get to clean the STMMAC driver up and introduce a fully generic GPIO
interface for the driver core.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Baikal-T1 SoC is equipped with one DW XGMAC v2.11a-based 10GBE interface
synthesized with: XGMII-bus connected to DW XPCS v3.11b, AXI3-DMA and APB3
CSR, 32KB Tx/Rx MTL FIFOs with up two 4 MTL Rx Queues and 2 MTL Tx Queue
using two DMA-interfaces for Tx and Rx, PTP, PMT, TCP/IP CoE, TSO, up to 8
outstanding AXI read/write requests, maximum AXI burst length of 16 beats
(due to AXI3 constraints), up to eight MAC address slots and 64-bits hash
-based MAC-address filter.
Let's add the respective DT-bindings so the device tree sources could be
correctly verified. The STMMAC/Baikal XGMAC platform driver will be added
next.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Baikal-T1 SoC is equipped with two DW GMAC v3.73a-based 1GBE Ethernet
interfaces synthesized with: RGMII PHY interface, AXI-DMA and APB3 CSR,
16KB Tx/Rx FIFOs and PBL up to half of that, PTP, PMT, TCP/IP CoE, up to 4
outstanding AXI read/write requests, maximum AXI burst length of 16 beats,
up to eight MAC address slots, one GPI and one GPO ports.
Let's add the respective DT-bindings so the device tree sources could be
correctly verified. The STMMAC/Baikal GMAC platform driver will be added
next.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
|
|
It might get to be handy to print out the DMA descriptors content during
the initial DMA interface initialization. Thus let's add the
display_ring() callback then in the similar way as it's done for the rest
of the DW {XG}MAC controllers.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The INTM=0 interrupt mode causes both respective per-channel
sbd_perch_[tx|rx]_intr_o and common sbd_intr_o signals being triggered on
the RI/TI status bits change. The later event is not only redundant in
this case but less efficient since both IRQs handlers will be called due
to a single event thus wasting the CPU resources. Let's enable the INTM=1
mode which implies triggering the per-channel signals only on the normal
RI/TI IRQs.
Note a similar fix has been incorporated to the DW GMAC4 sub-module in the
commit 6ccf12ae111e ("net: stmmac: use interrupt mode INTM=1 for
multi-MSI").
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In accordance with [1] the phy_intf_sel_i[1:0] signal is encoded as
follows:
00: non-RGMII interface (XGMII/GMII/MII)
01: RGMII interface
10: RMII Interface
11: Reserved
So convert convert PHY_INTF_GMII to being PHY_INTF_XGMII with
multi-variant MII-based name and add PHY_INTF_RMII interface name to
comply with the official DW XGMAC databook.
[1] DesignWare® Cores XGMAC - 10G Ethernet MAC, Revision 3.20a,
October 2022, p. 424.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
It's possible to have more than a single DMA-channel supporting the
TCP-segmentation offloading. The driver currently doesn't support anything
to detected and utilize that. In the meantime the feature may greatly
improve the TCP/IP traffic transfer performance.
Let's fix that by introducing a platform-specific flag
STMMAC_FLAG_TSO_FULL which would indicate such feature availability and
permit selecting any Tx-channel to send TCP/UDP/IP traffic with the
TSO engine.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The main part of the functionality was added in the framework of the
commit b42446b9b37b ("stmmac: intel: add support for multi-vector msi and
msi-x"). But for some reason it was done for the PCI-based netword device
only meanwhile the per-DMA-channel IRQs can be available on the normal
platforms too. Let's fix the stmmac_get_platform_resources() method so one
would request the DMA Tx/Rx platform IRQs. The DW *MAC DT-bindings
requires them to have the names "(rx|tx)-queue-[0-9]". The IRQs request
and per-channel ISR setup will be performed later in the stmmac_main.c
driver.
Note even though the driver and DT-bindings call them per-MTL-queue IRQs
in fact these are the DMA per-channel IRQs. The driver just maps DMA
channel and MTL queues one-on-one so the IRQs turn out to be raised as if
for the respective queues too. Alas nothing can be done at this stage to
fix the naming since the DT-bindings has already being defined. Changing
the names would make the DT-schema even more messy than it already is.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In accordance with [1] the MDC clock frequency is supposed to be selected
with respect to the CSR clock frequency. CSR clock can be either tied to
the DW MAC system clock (GMAC main clock) or supplied via a dedicated
clk_csr_i signal. Current MDC clock selection procedure handles the former
case while having no support of the later one. That's wrong for the
devices which have separate system and CSR clocks. Let's fix it by first
trying to get the synchro-signal rate from the "pclk" clock, if it hasn't
been specified then fall-back to the "stmmaceth" clock.
[1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a,
October 2013, p. 424.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Indeed there is nothing DW MAC v3.x-specific in that property, while MTU
can be platform-specific for any DW MAC IP-core. Move the "max-frame-size"
DT-property read operation to the root path of the
stmmac_probe_config_dt() method.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
At least for DW GMAC and DW x(L)GMAC it is possible to have the imperfect
filtering disabled during the IP-core synthesize. In that case the
functionality of the DA hash-based filter will be just unavailable. Let's
cover that case by permitting the "snps,multicast-filter-bins" property to
have a zero value. That will effectively disable the multicast filtering
in the core-ops->set_filter() methods.
Note this modification won't affect for the DW MAC100 HW code since by
design it assumes that the hash-based filtering is always available with
the table of 64-bins size. Without the HW-manual I can't say whether it's
right or wrong so we have to leave it as is for now.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW QoS Ether and DW XGMAC/XLGMAC can be optionally equipped with a IPv4
ARP-offload engine. When the feature is enabled, the controller generates
the ARP reply packets for broadcast ARP request packets. The ARP packet
for IPv4 is L2 layer packet with Length/Type of 0x0806.
It's not that comprehensive supporting a single IPv4 configured and a
single ARP-request handling at a time. So if an ARP-request with an
unknown IP-address received it will be passed to the application as just
an ordinary IPv4 packet with no ARP-type recognized. If a recognized
ARP-request received while another ARP-request being handled it will be
passed to the application with the RDES2.RPNG flag set. In the other case
if the ARP-request has been recognized and handled the respective frame
will be delivered to the application anyway but the RDES4.LT=ARP-req-type.
Taking all the above into account let's introduce the IPv4 ARP-offload
engine support to the STMMAC driver. It will support only a first primary
IPv4 address configured with falling back to another primary IPv4 address
if the previous one has been removed. Note the implementation provides the
offloaded ARP-requests counter which can be used to checkout whether the
engine actually works.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Marvell 88x2222 PHY is equipped with a basic TWSI/SMBus controller which
SDA/SCL pins are multiplexed with GPIO pins 10 and 11. The main purpose of
the interface is to access the externally attached modules EEPROM (for
that sake there is even an internal cache which if enabled can be filled
with the EEPROM data) but in general it can be used to access any I2C
peripheral device as long as it supports the SMBus transfers the
I2C-controller provides. Alas the SMBus controller functionality is very
limited. It's just SMBus byte data read and write transfers, which should
be enough for the EEPROM IO operations but won't provide a full support of
the SFP+ equipments like MDIO-I2C-based PHY or thermal sensors. Anyway if
a respective platform is already designed to rely on the Marvell 88x2222
I2C-interface it will be handy to have the interface registered in kernel
so the SFP-port driver would at least access the module EEPROM.
The provided driver first probes whether the I2C-interface functionality
is available and supported by the current platform setup. That is it makes
sure that there is no GPIO-function activated on the SDA/SCL pins and
there is no device hard-reset capability. Then it pre-initializes the
I2C-interface: disables the EEPROM caching and Read-after-write
functionality. After that the I2C-adapter is ready to be registered and
utilized then by the client drivers (mainly by the SFP-port driver) for
the basic SMBus Byte Data Read/Write operations.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Marvell 88x2222 PHY is equipped with 11 general purpose pins, which can be
configured to work either as a special-function pins (LEDs, TWSI SDA/SCL,
SFP+, etc) or as GPIOs. In the later case they can be registered in the
kernel GPIO subsystem and used then either for some platform-specific sake
or as the SFP+ port GPIOs seeing there is no MMD-based SFP+ implementation
currently supported by the kernel.
All eleven GPIOs can support input and output (open-drain) modes
determined by the TRISTATE control register. In case of the input mode the
state change is reported by means of the PHY IRQ line. Each GPIO interrupt
can be individually enabled/disabled by the IRQ Enable register. There are
all five interrupt types supported: high/low level triggered,
rising/falling/both edges triggered. Note GPIO IRQs are handled in a
separate ISR instead of doing that in the phy_driver.handle_interrupt()
function. The later handler is utilized only if the PHY is attached to a
network device. It's unacceptable for the general-purpose IO pins since
they can be utilized anytime the device is successfully probed. For a
similar reason the GPIOs aren't supported if the device-specific
hard-reset line is specified. It's toggled during the PHY re-attachment
which will clear the entire device state out and will break the GPIOs
driver functionality for sure.
Note 1. In case of some of the GPIOs are marked as invalid the respective
pins special-function is activated/preserved. The pins can be defined as
reserved for instance by means of the "gpio-reserved-ranges" property. It
will be useful for the platforms which rely on the special-functions, like
LEDs, activated.
Note 2. The private data caches are utilized in order to implement the
access to some of the GPIO CSRs. It's done for several reasons: in order
to implement the IRQ-chip support for a device living on a slow
asynchronous bus; in order speed up the CSRs access; in order to overcome
a race condition around the GPIO Data register RMW-access (see the commit
body for details).
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
At least on debug-stage it gets to be handy to know what side causes the
link being unavailable: host or line side. Add debug printouts activated
depending on the respective conditional statement being true in the
Marvell 88x2222 status read procedure.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
It's possible to have the controller reporting the device events via an
IRQ line. It's polarity is active-low by default, but also can be
configured by means of the Chip-level Global Interrupt Control register
(out of this change scope). There are three types of events reported by
the interrupt: line-side PCS link state, host-side PCS link state and
GPIOs. This update concerns the first two events as they are of the
particular PHY subsystem interest.
As it's intended by the Network PHY subsystem two callbacks are
implemented: config_intr() and handle_interrupt(). The former one is
responsible for activating/de-activating the host-side (XAUI and
10GBase-R) and line-side (1000Base-X/SGMII and 10GBase-R) link state
interrupts. The host-side IRQs are configured depending on the selected
interface mode meanwhile all relevant line-side IRQs are just enabled
since there is no info regarding the line-side link type at the moment of
the configuration procedure and might get to be available only after the
auto-negation is completed or when a SFP module is inserted. The later
callback is responsible for the IRQs handling. If there is a MDIO-based
communication is detected to be malfunction PHY will get to be halted by
means of the phy_error() method. Otherwise the Port-level Interrupt
Status value will be utilized to check whether the device has any pending
interrupt. Any link state change or errors detection will cause the PHY
state machine been triggered. Info regarding the detected errors will be
also sent to the system log as a debug-message for now since the errors
may happen due to normal link up/down procedures.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Prepare the driver to adding the interrupts support by making sure that
the actual status is handled during the network link state machine work.
Currently it concerns the link status flags in various PHY MMD registers.
They are latched-low so the respective CSRs need to be read twice to get
the actual flag state at the moment of the event handling.
Note there are other latched flags can be discovered in the Marvell
88x2222 registers. For instance AN Page Received status or 1GBase-X Remote
fault status. Since the semantic of the respective events handling may
differ from the link up/down handling procedure, the
mv2222_read_mmd_latched() function is defined to accept an additional
argument forcing the registers double read if it's required by the caller.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Depending on the setups nature it isn't always required to fully
soft-reset the PHY-device. For instance the config_init() procedure
implies the interface-type setups. Thus the host-side need to be only
performed. Meanwhile the external link settings like Auto-negotiation
configs or link protocol (type, speed, duplex, etc) need to be followed by
the line-reset only. Thus the setup procedures can be sped up a bit by
splitting the resets up into the host- or line-side resets performed after
the setups which require one or another reset only. Note the soft_reset()
PHY-driver callback still implies a full soft-reset.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Marvell 88x2222 provides 10GBase-X4/XAUI, 10GBase-R, 1000Base-X and SGMII
host interfaces. Fill in the phy_device::possible_interfaces field with
the currently supported by the driver modes: XAUI and 10GBase-R.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Aside with XAUI it's possible enable the 10GBase-R link between MAC/PCS
and Marvell 88x2222 Host-side (XFI). It doesn't require much driver
modification. The 10GBse-R host-side PCS must be selected in the Port PCS
configuration register. It can be done in the config_init() phy_device
callback. Due to that the locally defined mv2222_config_line() method must
be modified in order not to override the activated interface mode.
Note the read_status() callback is altered to take the host-side link
state into account.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
bits.h and bitfield.h provides useful helpers with the bit fields
operations. Let's use them in driver instead of hard-coded bitwise shift
operation. The update concerns the PCS Host/Line mode select procedure
only.
Note while at it let's convert the mv2222_config_line() method to
collecting the fields in the local variable and then calling the
phy_write_mmd() method from a single place of the function. Thus it will
look a bit more coherent and the generated code smaller.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
There is a Marvell 88X2222 PHY revision with R suffix, which is mainly
compatible with the original PHY but has different ID. Let's add it to the
known Marvell PHY IDs table defined in the marvell_phy.h file.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DT-bindings wise the Marvell 88X2222 transceiver is a normal 10G PHY with
up to four host-side ports (support 10GBASE-R, XAUI/RXAUI, 1000BASE-X
protocols) and two line-side ports (support 10GBASE-R and 1000BASE-X
interfaces). Besides it is equipped with 12 GPIOs multiplexed with the
special functions like LEDs, TWSI SDA/SCL, etc. They can be used to
communicate with the SFP+ ports soldered to the device line-side
interfaces.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Baikal-T1 SoC is synthesized with the DW XPCS v3.11b IP-core attached to
DW xGMAC v2.11a over the XGMII interface. DW XPCS is configured to be of
the Back-plane multi-mode with KR/KX4 speeds support (no 1G speed). Thus
the PCS sublayer supports Clause 73 and 72 auto-negotiations performed
over the 10GBASE-KR and 10GBASE-KX4 link modes.
So in order to have the denoted features enabled for the Baikal-T1
XGMAC/XPCS chain the DW XPCS driver is updated with the Baikal-T1
XPCS-specific compat-list. It will be selected in case if the platform
detects the "baikal,bt1-xpcs" compatible device or a device with the
custom BT1_XGMAC_XPCS_ID id.
Note the XPCS device is synthesized with the Synopsys 10G Gen5 PMA. Thus
the corresponding PMA-id is specified in order activate the PMA-specific
config methods.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Baikal-T1 SoC is synthesized with the DW XPCS v3.11b IP-core attached to
DW xGMAC v2.11a over the XGMII interface. Externally it's equipped with
the Synopsys Enterprise 10G Gen5 PMA working with the KR/KX4 links. XPCS
can deliver events by means of a single IRQ line. In addition it can be
clocked either from the internal clock source ("core" mode) or from the
external pad ("pad" mode).
Note using internal clock source may cause link instability. It's
preferable to have an externally generated clock signal.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The drivers/net/pcs/pcs-xpcs-pma.c file has just been added to the DW XPCS
driver. It contains the DW XPCS PMA layer initialization functions called
from the main part of the driver. Add it to the list of the files
maintained in the framework of the generic DW XPCS driver parts.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW XPCS can be synthesized with 10GBASE-X/XAUI link support. In that case
xGMAC is still connected to the XPCS device by means of normally
multi-lane high-speed interface (XGMII, USXGMII, etc) meanwhile an
external interface is defined as 10GBASE-X. From the network subsystem
point of view it's as if DW XPCS is fully integrated into the MAC with no
need in setting any intermediate interface up.
Similarly to the 10GBASE-R, in accordance with the IEEE 802.3 standard
10GBASE-X doesn't intent any auto-negotiations but it's defined as also
being utilized by XGXS (Clause 47). Thus a new AN-less mode is defined
DW_10GBASEX in the driver. It implies PCS and PMA setups required for the
device to work in the denoted mode. The respective actions are executed in
the xpcs_do_config() method. At the same time xpcs_link_up() makes sure
that the PCS/PMA<->PHY link actually works and it has compatible speed and
duplex: 10Gbps speed and full-duplex mode.
Note 1. Synopsys 10G Gen5 PMA requires the reference clock switch in case
if the respective flag doesn't correspond to the specified clock sources.
Note 2. XPCS 10GBASE-X interface features list contains all
speed-compatible link modes in order to have the pcs_validate() permitting
these modes for the externally attached PHYs.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The interface is defined by IEEE 802.3 Clause 48 as a PCS and PMA
sublayer. It is normally utilized to connect XGMII with the 10GBASE-CX4
(Clause 54), 10GBASE-KX4 (Clause 71), and 10GBASE-LX4 (Clause 53) PHYs.
It's an independent four Tx and Rx lanes interface with 8b/10b coding of
the full-duplex stream with constant 10Gb/s speed. 10GBASE-X PCS/PMA is
utlized by the XGXS/XAUI specifications (Clause 47).
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Add 10gbase-x to the list of accepted PHY connection types between MAC and
a physical PHY. It's physically compatible with xaui but defines PCS and
PMA interface (Clause 48) towards the 10GBASE-CX4 (see Clause 54),
10GBASE-KX4 (see Clause 71), and 10GBASE-LX4 (see Clause 53). Network
subsystem will be updated in the next commit.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW XPCS can be synthesized with 10GBASE-R link support. In that case xGMAC
is still connected to the XPCS device by means of normally multi-lane
interface meanwhile an external interface is defined as 10GBASE-R. From
network subsystem point of view it's as if DW XPCS is fully integrated
into the MAC with no need in setting any intermediate interface up.
So based on the IEEE 802.3 standard 10GBASE-R doesn't intent any
auto-negotiations. Instead it works with the 10Gbps speed and in the
Full-duplex mode. Thus a new AN-less mode is defined DW_10GBASER in the
driver. It implies PCS and PMA setups required for the device to work in
the denoted mode. The respective actions are executed in the
xpcs_do_config() method. At the same time xpcs_link_up() makes sure that
the PCS/PMA<->PHY link actually works and it has compatible speed and
duplex (though having the pcs_link_up() method returning the operation
status would look better or at least having pcs_get_state() working for
the non-inband setups).
Note 1. 10GBASE-R PMA config implies reference clock switch in case if the
respective flag doesn't correspond to the specified clock sources.
Note 2. XPCS 10GBASE-R interface features list contains all
speed-compatible link modes in order to have the pcs_validate() permitting
these modes for the externally attached PHYs.
Note 3. Soft-reset and poll-mode are activated on the XPCS-descriptor
create procedure since the interface initialization is now comprehensive
enough to configure device from scratch.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
In order have the XPCS CSRs read, write, modify, poll and device
soft-reset methods accessible from separate objects let's globally define
them. They will be utilized from the PMA-config methods which in its
turned will be later defined separately in order to simplify the main
driver object file.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Various DW XPCS setups require vendor-specific reset procedure
implementation, i.e. PCS type (KR, KX4, KX, etc) selection. It implies the
reset of all DWC_xpcs internal blocks except the Management interface and
CSR blocks (the standard reset clears the CSR block too). Since a
multi-type XPCS support is about to be added let's add the vendor-specific
reset as a preparation before that.
Note 1. Since vendor-specific reset doesn't imply the CSR blocks reset we
can't just write the flag to the corresponding register because thus we
may override/clear some valuable CSR fields. Instead the MDIO-device
modify method is utilized.
Note 2. xpcs_poll_reset() method is converted to accepting CSR and flag to
poll. It is done intentionally even though currently it's used to poll
BIT(15) in the specified register. It may and will be used to poll some
other fields in the DW XPCS space like reference clock stabilization, etc.
Thus the renaming.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
It's very much inconvenient to have the soft-reset method requiring the
xpcs_compat structure instance passed. The later one is found based on the
PHY-interface type which isn't always available. Such design makes an
ordinary reset-method context depended and unnecessary limits its usage
area. Indeed based on [1,2] all Soft-RST flags exported by the PMA/PMD,
PCS, AN or MII MMDs are _shared_. It means it resets all the DWX_xpcs
internal blocks including CSRs, but except the Management Interface (MDIO,
MCI, APB). Thus it doesn't really matter which MMDs soft-reset flag is
set, the result will be the same. So the AN-mode-depended code can be
freely dropped from the soft-reset method. But depending on the DW XPCS
device capabilities (basically it depends on the IP-core synthesize
parameters) it can lack some of the MMDs. In order to solve that
difficulty the Vendor-Specific 1 MMD can be utilized. It is also called as
Control MMD and exports some generic device info about the device
including a list of the available MMDs: PMA/PMD, XS/PCS, AN or MII. This
MMD persists on all the DW XPCS device [3]. Thus it can be freely utilize
to cross-platformly determine actual MMD to perform the soft-reset.
[1] DesignWare® Cores Ethernet PCS, Version 3.11b, June 2015, p.111.
[2] DesignWare® Cores Ethernet PCS, Version 3.11b, June 2015, p.268.
[3] DesignWare® Cores Ethernet PCS, Version 3.11b, June 2015, p.269.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Natively DW XPCS (v3.xx) supports two upstream interfaces: XGMII and
GMII/MII. Former one is responsible for the 10G link speed. It's a 32-bits
interface normally connected to MAC and which is supposed to be used for
the PCS-R and 10G PCS-X data paths. Despite of the USXGMII it doesn't
support speed change. So just the only thing what needs to be done is to
add the interface and features for the XGMII interface and rely on the
auto-negotiation procedure to establish the link.
Note DW xGMII PHY-mode support must be added to the STMMAC driver in order
to have DW XGMAC/XPCS chain working correctly.
TODO add some configs to the xpcs_config_xgmii() method.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
XGMII is an interface between MAC and PCS. So it's a subject of the PCS
device implementation whether it supports passing link information in-band
between PHY and MAC PCS. Anyway add XGMII to the list of protocols that
support in-band AN mode and let the PCS driver to decide the supported
link modes.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Based on the IEEE Std 802.3 Clause 73 specification 10GBASE-KR interface
must support auto-negotiation for any KR and legacy R links (see Table
72–1 in the spec). Thus the link speed is supposed to be determined based
on the link-partner modes retrieved on the negotiation stage. Let's fix
that by adding the Autoneg flag to the list of the 10GBASE-KR features so
the xpcs_get_state_c73() procedure would initialize the phylink state
descriptor based on the link-partner abilities.
Note since the max link speed is now determined based on the modes
retrieved from the remote device there is no need in manual speed setting
up in the xpcs_resolve_pma() method. So the respective case clause can be
freely dropped from there.
Fixes: fcb26bd2b6ca ("net: phy: Add Synopsys DesignWare XPCS MDIO module")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The phylink_link_state->pause field can have some flags being pre-set
(i.e. MLO_PAUSE_AN) by the phylink core before it's passed to the
phylink_pcs_ops.pcs_get_state() callback. Moreover based on the
phylink_pcs_ops.pcs_get_state() kernel doc it is intended to update the
MLO_PAUSE_RX and MLO_PAUSE_TX flags state only. So drop zeroing out the
phylink_link_state->pause field from the xpcs_get_state_c37_sgmii() method
as pointless and potentially harmful.
Link: https://lore.kernel.org/netdev/ZTuvwnGZKEueGDwa@shell.armlinux.org.uk
Fixes: b97b5331b8ab ("net: pcs: add C37 SGMII AN support for intel mGbE controller")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Besides of MLO_PAUSE_RX and MLO_PAUSE_TX flags the
phylink_link_state->pause field can have other flags set (i.e.
MLO_PAUSE_AN) by the phylink core. Moreover based on the
phylink_pcs_ops.pcs_get_state() kernel doc the later callback is intended
to update the MLO_PAUSE_RX and MLO_PAUSE_TX flags state only. So drop
overriding the entire phylink_link_state->pause field from the
xpcs_resolve_pma() method as pointless and potentially harmful.
Link: https://lore.kernel.org/netdev/ZTuvwnGZKEueGDwa@shell.armlinux.org.uk
Fixes: fcb26bd2b6ca ("net: phy: Add Synopsys DesignWare XPCS MDIO module")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
By default CSR clock is disabled upon request. It makes the PM-runtime
state matching the default PM-state of the device - suspended. Thus let's
drop the PM-runtime setting up to be active as incorrect. Otherwise the
clock-subsystem will be unhappily printing a big fat warning about
n-preparing an already unprepared clock.
Fixes: f6bb3e9d98c2 ("net: pcs: xpcs: Add Synopsys DW xPCS platform device driver")
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
The PCS module currently supports in-band getting the PHY link status for
the SGMII interface only. But the DW GMAC and DW QoS Ether controllers are
also capable to use in-band signals of RGMII. Let's convert the STMMAC PCS
module to supporting it.
Basically it means to permit the integrated PCS initialization in case if
the RGMII interface is enabled. That's done by checking the ActPhyIF
capability detected from the GMAC.
Note the link status is now determined irrespective to the PCS negotiation
mode. It's fine since in case or SGMII the AN mode is always enabled so
the PHY link status will be always reported in-band-ly. In case of RGMII
there is no MAC-PHY negotiation and the PHY link status will be delivered
for as long as the PHY supports reporting it (MLO_AN_INBAND mode is on).
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
DW GMAC and DW QoS Ether controllers support getting PHY link status
reported via the RGMII, SGMII or SMII interfaces. The status reading has
already been added in the commit 083757866735 ("net: stmmac: add support
for reading inband SGMII status"). The interface link change support has
been implemented long before that but just recently has been converted to
properly working with phylink. What has been missing is the SRGMII IRQ
enabling and handling in case if in-band getting the status is supported.
Let's do that in the framework of so well prepared PCS module.
Note the stmmac_integrated_pcs_irq() method doesn't pass the link state to
the PCS core intentionally, so to be compatible with the case when
PCS-based AN isn't support. It's relevant for the RGMII in-band PHY-link
status signaling which is going to be added in one of the next commits.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Report the link, speed and duplex for SGMII links, read from the
SGMII, RGMII and SMII status and control register.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
We need to describe one more register (offset and field bitmask) to
the PCS code. Move the existing PCS offset and interrupt enable bits
to a new struct and pass that in to stmmac_integrated_pcs_init().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
|
|
Synopsys DW GMAC v3.7x can be synthesized with up to four GPIs and four GPOs
support, which in case if enabled can be configured via a MAC CSR 0xe0.
In order to have the DW GMAC GPIO interface supported in the STMMAC GPIO
driver the GPIO CSR accessors and MAC/DMA gentle stop/cleanup methods are
introduced. These are utilized as the low-level feature implementation
abstracting out the DW GMAC GPIO-specifics. The GPIO-chip related code
using that infrastructure has already been added to the driver.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Synopsys DesignWare Ethernet controllers can be synthesized with
General-Purpose IOs support. GPIOs are divided into two ports: gpi_i -
inputs and gpo_o - outputs. While the GPIOs semantics is identical on all
DW Ethernet controllers the ports width (number of possible
inputs/outputs) and the configuration registers layout depend on the
IP-core version. For instance, DW GMAC can have from 0 to 4 GPIs and from
0 to 4 GPOs, while DW QoS Ether/xGMAC/etc have a wider ports width up to
16 pins of each one. In the framework of provided implementation any
DesignWare Ethernet controllers GPIO block can be supported as soon as the
GPIO registers accessors and the cleanup methods are defined for the
respective IP-core.
Total number of GPIOs MAC supports is supposed to be passed via the
platform descriptor. If it's an OF-based platform, then the standard
"ngpios" DT-property will be parsed for it as well.
Before registering the GPIO-chip in the kernel, the driver will try to
auto-detect the number of GPIs and GPOs by writing 1s into the GPI type
config register. Reading the written value back and calculating the number
of actually set bits will give the GPI port width the device has been
synthesized with.
If GPIs have been detected then GPIO IRQ-chip will be also initialized and
only in that case the GPIO IRQs handling will be activated. Since the
pending events are cleared just by reading from the GPI event status
register, only the edged IRQs type can be implemented. For the same reason
and for the reason of having the rest of GPIO configs reside in the same
CSR, the GPI type, GPI mask and GPO state caches have been added. So the
driver would avoid RMW CSR update code to minimize the pending GPI events
clearing.
Note in case of GPIOs being available the core soft-resetting mustn't be
executed otherwise the GPIO configs will be reset to the initial state. Instead
MAC/DMA stop and CSRs cleanup has been added.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
|
Synopsys DesignWare Ethernet controllers can be synthesized with
General-Purpose IOs support. In general these GPIOs can be used for
anything (but most likely for the network-specific stuff). Thus the
subsequent commits will add the STMMAC sub-module registering a respective
GPIO-chip. But before it's done the STMMAC low-level programming interface
must be extended.
First of all the GPIO data accessors is added. Even though all DW *MAC
GPIOs are semantically equivalent their CSR-wise implementation might be
different. That is the GPI type set/get, GPI IRQ en/dis, GPI get and GPO
set/get functions are either exposed via a single CSR (DW GMAC v3.7x case)
or as two control/status registers (DW QoS/XGMAC/etc case). So in order to
implement a generic GPIO-chip sub-module in the STMMAC driver these
differences will be abstracted out by the stmmac_gpio_ops accessors.
Secondly there is an issue connected with the controller resets. The GPIOs
embedded into the DW MACs are a subject of the reset-related actions. That
is if any hard- or soft-reset of the controller is performed the GPIO
settings will be reset as well. If the hard-reset is happening on the
device probing stage the soft-reset is executed on each network device
open. So should the GPIOs support is added as is to the driver, their
hardware implementation will be reset on each network device open cycle.
This is definitely not how generic GPIO-chip supposed to work.
The only way to fix that is to avoid the soft-reset procedure anyhow. But
the rest of the driver code relies on the controller being in a default
state on each device opening. Thus the best approach to solve the denoted
issue is to replace the controller soft-reset with a proper device cleanup
procedure. That's what the second part of the change about - to provide
such infrastructure.
So the provided programming interface is dedicated to solve the denoted
issues above and to prepare the driver for further GPIO-related
extensions. It's left unused for now up until the DW MAC GPIO-chip support
is added to the driver.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
|
