- 15 Sep, 2021 37 commits
-
-
Sukadev Bhattiprolu authored
Rather than releasing the tx pools on every close and reallocating them on open, reuse the tx pools unless the pool parameters (number of pools, size of each pool or size of each buffer in a pool) have changed. If the pool parameters changed, then release the old pools (if any) and allocate new ones. Specifically release tx pools, if: - adapter is removed, - pool parameters change during reset, - we encounter an error when opening the adapter in response to a user request (in ibmvnic_open()). and don't release them: - in __ibmvnic_close() or - on errors in __ibmvnic_open() in the hope that we can reuse them during this or next reset. With these changes reset_tx_pools() can be dropped because its optimization is now included in init_tx_pools() itself. cleanup_tx_pools() releases all the skbs associated with the pool and is called from ibmvnic_cleanup(), which is called on every reset. Since we want to reuse skbs across resets, move cleanup_tx_pools() out of ibmvnic_cleanup() and call it only when user closes the adapter. Add two new adapter fields, ->prev_mtu, ->prev_tx_pool_size to track the previous values and use them to decide whether to reuse or realloc the pools. Reviewed-by:
Rick Lindsley <ricklind@linux.vnet.ibm.com> Reviewed-by:
Dany Madden <drt@linux.ibm.com> Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sukadev Bhattiprolu authored
Rather than releasing the rx pools on and reallocating them on every reset, reuse the rx pools unless the pool parameters (number of pools, size of each pool or size of each buffer in a pool) have changed. If the pool parameters changed, then release the old pools (if any) and allocate new ones. Specifically release rx pools, if: - adapter is removed, - pool parameters change during reset, - we encounter an error when opening the adapter in response to a user request (in ibmvnic_open()). and don't release them: - in __ibmvnic_close() or - on errors in __ibmvnic_open() in the hope that we can reuse them on the next reset. With these, reset_rx_pools() can be dropped because its optimzation is now included in init_rx_pools() itself. cleanup_rx_pools() releases all the skbs associated with the pool and is called from ibmvnic_cleanup(), which is called on every reset. Since we want to reuse skbs across resets, move cleanup_rx_pools() out of ibmvnic_cleanup() and call it only when user closes the adapter. Add two new adapter fields, ->prev_rx_buf_sz, ->prev_rx_pool_size to keep track of the previous values and use them to decide whether to reuse or realloc the pools. Reviewed-by:
-
Sukadev Bhattiprolu authored
Reuse the long term buffer during a reset as long as its size has not changed. If the size has changed, free it and allocate a new one of the appropriate size. When we do this, alloc_long_term_buff() and reset_long_term_buff() become identical. Drop reset_long_term_buff(). Reviewed-by:
-
Sukadev Bhattiprolu authored
In a follow-on patch, we will reuse long term buffers when possible. When doing so we have to be careful to properly assign map ids. We can no longer assign them sequentially because a lower map id may be available and we could wrap at 255 and collide with an in-use map id. Instead, use a bitmap to track active map ids and to find a free map id. Don't need to take locks here since the map_id only changes during reset and at that time only the reset worker thread should be using the adapter. Noticed this when analyzing an error Dany Madden ran into with the patch set. Reported-by:
-
Sukadev Bhattiprolu authored
In init_tx_pools() move some loop-invariant code out of the loop. Reviewed-by:
-
Sukadev Bhattiprolu authored
Use/rename local variables in init_tx_pools() for consistency with init_rx_pools() and for readability. Also add some comments Reviewed-by:
-
Sukadev Bhattiprolu authored
To make the code more readable, use/rename some local variables. Basically we have a set of pools, num_pools. Each pool has a set of buffers, pool_size and each buffer is of size buff_size. pool_size is a bit ambiguous (whether size in bytes or buffers). Add a comment in the header file to make it explicit. Reviewed-by:
-
Sukadev Bhattiprolu authored
Add/update some comments/function headers and fix up some messages. Reviewed-by:
-
Sukadev Bhattiprolu authored
For better readability, consolidate related code in replenish_rx_pool() and add some comments. Reviewed-by:
-
David S. Miller authored
Jonathan Lemon says: ==================== timecard updates for v13 firmware This update mainly deals with features for the TimeCard v13 firmware. The signals provided from the external SMA connectors can be steered to different locations, and the generated SMA signals can be chosen. Future timecard revisions will allow selectable I/O on any of the SMA connectors, so name the attributes appropriately, and set up the ABI in preparation for the new features. The update also adds support for IRIG-B and DCF formats, as well as NMEA output. A ts_window_adjust tunable is also provided to fine-tune the PHC:SYS time mapping. -- v1: Earlier reviewed series was for v10 firmware, this is expanded to include the v13 features. ==================== Signed-off-by: -
Jonathan Lemon authored
This patch describes the sysfs interface implemented by the ptp_ocp driver, under /sys/class/timecard. Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by:
-
Jonathan Lemon authored
The following process is used to read the PHC clock and correlate the reading with the "correct" system time. - get starting timestamp - issue PCI write command - issue PCI read command - get ending timestamp - read latched sec/nsec registers The write command is posted to PCI bus and returns. When the write arrives at the FPGA, the PHC time is latched into the sec/nsec registers, and a flag is set indicating the registers are valid. The read command returns this flag, and the time retrieval proceeds. Below is a non-scaled picture of the timing diagram involved. The PHC time corresponds to some SYS time between [start, end]. Userspace usually uses the midpoint between [start, end] to estimate the PCI delay and match this with the PHC time. [start] | | write |-------+ | | \ | read |----+ +----->| | \ * PHC time latched into register | \ | midpoint | +------->| | | | | | +----| | / | |<--------+ | [end] | | As the diagram indicates, the PHC time is latched before the midpoint, so the system clock time is slightly off the real PHC time. This shows up as a phase error with an oscilliscope. The workaround here is to provide a tunable which reduces (shrinks) the end time in the above diagram. This in turn moves the calculated midpoint so the system time and PHC time are in agreemment. Currently, the adjustment reduces the end time by 3/16th of the entire window. E.g.: [start, end] ==> [start, (end - (3/16 * end)], which produces reasonably good results. Also reduce delays by just writing to the clock control register instead of performing a read/modify/write sequence, as the contents of the control register are known. Signed-off-by: -
Jonathan Lemon authored
The current implementation of adjtime uses gettime/settime to perform nanosecond adjustments. This introduces addtional phase errors due to delays. Instead, use the FPGA's ability to just apply the nanosecond adjustment to the clock directly. Signed-off-by:
-
Jonathan Lemon authored
A 4th timestamper is added which timestamps the output of the PHC. The clock nanosecond offset is not always zero, so when compared to other timestampers, this provides precise measurements. Also, the timestamper interrupt from the PHC can be used to generate a PPS signal for /dev/pps. Also allow PTP_CLK_REQ_PEROUT requests for a 1PPS output, but do not actually configure any output pins, this is done via sysfs. Signed-off-by:
-
Jonathan Lemon authored
Upcoming boards may have a second GNSS receiver, getting information from a different constellation than the first receiver, which provides some measure of anti-spoofing. Expose the sysfs attribute for this device, if detected. Signed-off-by:
-
Jonathan Lemon authored
The timecard can provide a NMEA-1083 ZDA (time and date) output string on a serial port, which can be used to drive other devices. Add the NMEA resources, and the serial port as a sysfs attribute. Signed-off-by:
-
Jonathan Lemon authored
Provide a view into the timecard internals for debugging. Signed-off-by:
-
Jonathan Lemon authored
On startup, parts of the FPGA need to be initialized - break these out into their own functions, separate from the purely informational blocks. On startup, distrbute the UTC:TAI offset from the NMEA GNSS parser, if it is available. Signed-off-by:
-
Jonathan Lemon authored
IRIG and DCF output time in UTC, but the timecard operates on TAI internally. Add an attribute node which allows adding an offset to these modes before output. Signed-off-by:
-
Jonathan Lemon authored
IRIG-B has several different output formats, the timecard defaults to using B007. Add a control which selects different output modes. Signed-off-by:
-
Jonathan Lemon authored
IRIG (Inter-range Instrumentation Group) timecode format on one of the SMA output channels is provided by the IRIG master FPGA block. Enable the master when the IRIG output format is selected on either one of the output channels. By default, the output is in B007 format. DCF output format is provided by the DCF master block. Also enable the IRIG and DCF slaves, which parse an incoming signal from the external SMA connectors, and may be used to adjust the PHC. Signed-off-by:
-
Jonathan Lemon authored
The latest firmware for the TimeCard adds selectable signals for the SMA input/outputs. Add support for SMA selectors, and the GPIO controls needed for steering signals. Signed-off-by:
-
Jonathan Lemon authored
The firmware may provide a third signal timestamper, so make it available for use. Signed-off-by:
-
Jonathan Lemon authored
If a resource could not be registered, report the name of the resource and the error code. Signed-off-by:
-
Jonathan Lemon authored
The TimeCard exposes different resources, which may have their own irqs. Space for the irqs is allocated through a MSI or MSI-X interrupt vector. On some platforms, the interrupt allocation fails. Rather than making this fatal, just skip exposing those resources. The main timecard functionality (that of a PTP clock) will work without the additional resources. Signed-off-by:
-
Jonathan Lemon authored
If an I2C controller isn't present, don't try and read the I2C flash. Signed-off-by:
-
Jonathan Lemon authored
Only display the TOD information if there is a corresponding TOD resource. Signed-off-by:
-
Jonathan Lemon authored
Move the xilinx i2c driver parameters to the resource block instead of hardcoding things in the registration functions. Signed-off-by:
-
Aleksander Jan Bajkowski authored
The new added properties are used for configuring burst length. Signed-off-by:
Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by:
-
Aleksander Jan Bajkowski authored
Document the Lantiq Xway SoC series External Bus Unit (ETOP) bindings. Signed-off-by:
-
Aleksander Jan Bajkowski authored
Convert the Lantiq PMAC Device Tree binding documentation to json-schema. Signed-off-by:
-
Aleksander Jan Bajkowski authored
Configure the burst length in Ethernet drivers. This improves Ethernet performance by 58%. According to the vendor BSP, 8W burst length is supported by ar9 and newer SoCs. The NAT benchmark results on xRX200 (Down/Up): * 2W: 330 Mb/s * 4W: 432 Mb/s 372 Mb/s * 8W: 520 Mb/s 389 Mb/s Tested on xRX200 and xRX330. Signed-off-by:
-
Aleksander Jan Bajkowski authored
Make the burst length configurable by the drivers. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Aleksander Jan Bajkowski authored
The current definition of 2W burst length is invalid. This patch fixes it. Current downstream DEU driver doesn't use DMA. An incorrect burst length value doesn't cause any errors. This patch also adds other burst length values. Fixes: dfec1a82 ("MIPS: Lantiq: Add DMA support") Signed-off-by:
-
Aleksander Jan Bajkowski authored
Different SoCs have a different number of channels, e.g .: * amazon-se has 10 channels, * danube+ar9 have 20 channels, * vr9 has 28 channels, * ar10 has 24 channels. We can read the ID register and, depending on the reported number of channels, reset the appropriate number of channels. Signed-off-by:
-
Aleksander Jan Bajkowski authored
Reading the DMA registers immediately after the reset causes Data Bus Error. Adding a small delay fixes this issue. Signed-off-by:
-
Linus Walleij authored
This drops the code setting bit 9 on egress frames on the Realtek "type A" (RTL8366RB) frames. This bit was set on ingress frames for unknown reason, and was set on egress frames as the format of ingress and egress frames was believed to be the same. As that assumption turned out to be false, and since this bit seems to have zero effect on the behaviour of the switch let's drop this bit entirely. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210913143156.1264570-1-linus.walleij@linaro.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 14 Sep, 2021 3 commits
-
-
David S. Miller authored
Guangbin Huang says: ==================== PF support get MAC address space assigned by firmware This series add support PF to get unicast/multicast MAC address space assigned by firmware for the HNS3 ethernet driver. ==================== Signed-off-by: -
Guangbin Huang authored
The new firmware supports to divides the whole multicast MAC address space equally to functions of all PFs, and calculates the space size of each PF according to its function number. To support this feature, PF driver adds querying multicast MAC address space size from firmware and limits used number according to space size. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Guangbin Huang authored
Currently, there are two ways for PF to set the unicast MAC address space size: specified by config parameters in firmware or set to default value. That's mean if the config parameters in firmware is zero, driver will divide the whole unicast MAC address space equally to 8 PFs. However, in this case, the unicast MAC address space will be wasted a lot when the hardware actually has less then 8 PFs. And in the other hand, if one PF has much more VFs than other PFs, then each function of this PF will has much less address space than other PFs. In order to ameliorate the above two situations, introduce the third way of unicast MAC address space assignment: firmware divides the whole unicast MAC address space equally to functions of all PFs, and calculates the space size of each PF according to its function number. PF queries the space size by the querying device specification command when in initialization process. The third way assignment is lower priority than specified by config parameters, only if the config parameters is zero can be used, and if firmware does not support the third way assignment, then driver still divides the whole unicast MAC address space equally to 8 PFs. Signed-off-by:
-
