- Jan 20, 2021
-
-
Tero Kristo authored
commit 2672b94d upstream. My employment with TI is ending tomorrow, so update the email address entry in the maintainers file. Also, I don't expect to spend that much time with maintaining TI code anymore, so downgrade the status level to odd fixes only on areas where I remain as the main contact point for now, and move myself as secondary contact point where someone else has taken over the maintainership. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
Tero Kristo <kristo@kernel.org> Signed-off-by:
Nishanth Menon <nm@ti.com> Acked-by:
Suman Anna <s-anna@ti.com>
-
Peter Ujfalusi authored
commit 747ee57b upstream. The ret does not need to be initialized to 0 in the tisci channel config functions. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20210113114923.9231-4-peter.ujfalusi@gmail.com Signed-off-by:
Vinod Koul <vkoul@kernel.org> [s-anna@ti.com: cherry-pick linux-next commit '747ee57b ' for v5.12] Signed-off-by:
-
Peter Ujfalusi authored
commit 046d679b upstream. The UDMA and BCDMA can provide higher throughput if the burst_size of the channel is changed from it's default (which is 64 bytes) for Ultra-high and high capacity channels. This performance benefit is even more visible when the buffers are aligned with the burst_size configuration. The am654 does not have a way to change the burst size, but it is using 64 bytes burst, so increasing the copy_align from 8 bytes to 64 (and clients taking that into account) can increase the throughput as well. Numbers gathered on j721e: echo 8000000 > /sys/module/dmatest/parameters/test_buf_size echo 2000 > /sys/module/dmatest/parameters/timeout echo 50 > /sys/module/dmatest/parameters/iterations echo 1 > /sys/module/dmatest/parameters/max_channels Prior this patch: ~1.3 GB/s After this patch: ~1.8 GB/s with 1 byte alignment: ~1.7 GB/s Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20210113114923.9231-3-peter.ujfalusi@gmail.com Signed-off-by:
-
Peter Ujfalusi authored
commit 660343d0 upstream. Some DMA device can benefit with higher order of alignment than the maximum of 64 bytes currently defined. Define 128 and 256 bytes alignment for these devices. Signed-off-by:
-
Vignesh Raghavendra authored
commit aecf9d38 upstream. BCDMA RX channels have one flow per channel, therefore set the rflow_cnt to rchan_cnt. Without this patch, request for BCDMA RX channel allocation fails as rflow_cnt is 0 thus fails to reserve a rflow for the channel. Fixes: 88448980 ("dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling") Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Acked-by:
-
Peter Ujfalusi authored
commit 26b614fa upstream. Instead of initializing the rchan_tpl the initial commit re-initialized the tchan_tpl. Fixes: d2abc982 ("dmaengine: ti: k3-udma: Initial support for K3 PKTDMA") Signed-off-by:
-
Peter Ujfalusi authored
commit cc465fa2 upstream. My employment with TI is coming to an end, add the copyright and author comments as they due and change the maintainer mail address. Signed-off-by:
-
Peter Ujfalusi authored
commit 28d8e07f upstream. My employment with TI is coming to an end, it is my intention to look after the DMA drivers I have worked with over the years. Signed-off-by:
-
Peter Ujfalusi authored
commit 61fc03b6 upstream. My employment with TI is coming to an end, add the copyright and author comments as they due and change the maintainer mail address. Signed-off-by:
Mark Brown <broonie@kernel.org> [s-anna@ti.com: cherry-pick commit '61fc03b6 ' from v5.11] Signed-off-by:
-
Peter Ujfalusi authored
commit fe6ce6c3 upstream. My employment with TI is coming to an end, it is my intention to look after the drivers I have worked with over the years. Signed-off-by:
-
Aswath Govindraju authored
commit 88ebce92 upstream. Add compatible string in j721e-usb binding file as the same USB subsystem is present in AM64. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20201215042549.7956-1-a-govindraju@ti.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [s-anna@ti.com: cherry-pick commit '88ebce92 ' from v5.11] Signed-off-by:
-
Roger Quadros authored
commit 421da941 upstream. Updates my email address for Cadence USB3 driver. Signed-off-by:
Roger Quadros <rogerq@ti.com> Link: https://lore.kernel.org/r/20201218105736.17667-1-rogerq@ti.com Signed-off-by:
-
Aswath Govindraju authored
commit 8435ff0f upstream. I would like to help in reviewing CADENCE USB3 DRD IP DRIVER patches Signed-off-by:
Peter Chen <peter.chen@nxp.com> [s-anna@ti.com: cherry-pick commit '8435ff0f ' from v5.11] Signed-off-by:
-
Aswath Govindraju authored
commit cbfa5b39 upstream. Add compatible string for AM64 SoC in device tree binding of OMAP I2C modules as the same IP is used. Signed-off-by:
Wolfram Sang <wsa@kernel.org> [s-anna@ti.com: cherry-pick commit 'cbfa5b39 ' from v5.11] Signed-off-by:
-
Grygorii Strashko authored
commit 3cc1fb73 upstream. The gpiochip may have dependencies from pinmux and so got deferred. Now it will print error message every time -EPROBE_DEFER is returned which is unnecessary: "gpiochip_add_data_with_key: GPIOs 0..31 (gpio-0-31) failed to register, -517" Hence, do suppress error message for -EPROBE_DEFER case. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> [s-anna@ti.com: cherry-pick commit '3cc1fb73 ' from v5.11] Signed-off-by:
-
Grygorii Strashko authored
commit 2ae136a3 upstream. The gpiochip_add_data() may return -EPROBE_DEFER which is not handled properly by TI GPIO driver and causes unnecessary boot log messages. Hence, add proper deferred probe handling with new dev_err_probe() API. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Vignesh Raghavendra authored
commit 441494ec upstream. AM64 uses a UART controller that is compatible with AM654 UART. Introduce a specific compatible to help handle the differences if necessary. Reviewed-by:
-
Alexander Sverdlin authored
commit d96f04d3 upstream. It has been observed that once per 300-1300 port openings the first transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared as "e" on the wire). It only happened if single byte has been transmitted right after port open, which means, DMA is not used for this transfer and the corruption never happened afterwards. Therefore I've carefully re-read the MDR1 errata (link below), which says "when accessing the MDR1 registers that causes a dummy under-run condition that will freeze the UART in IrDA transmission. In UART mode, this may corrupt the transferred data". Strictly speaking, omap_8250_mdr1_errataset() performs a read access and if the value is the same as should be written, exits without errata-recommended FIFO reset. A brief check of the serial_omap_mdr1_errataset() from the competing omap-serial driver showed it has no read access of MDR1. After removing the read access from omap_8250_mdr1_errataset() the data corruption never happened any more. Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf Fixes: 61929cf0 ("tty: serial: Add 8250-core based omap driver") Cc: stable@vger.kernel.org Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com Signed-off-by:
-
Vignesh Raghavendra authored
commit 6f991850 upstream. With commit 439c7183 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable"), below warning is seen with W=1 and CONFIG_SERIAL_8250_DMA is disabled: drivers/tty/serial/8250/8250_omap.c:1199:42: warning: unused variable 'k3_soc_devices' [-Wunused-const-variable] Fix this by moving the code using k3_soc_devices array to omap_serial_fill_features_erratas() that handles other errata flags as well. Fixes: 439c7183 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Vignesh Raghavendra authored
commit d4548b14 upstream. k3_soc_devices array is missing a sentinel entry which may result in out of bounds access as reported by kernel KASAN. Fix this by adding a sentinel entry. Fixes: 439c7183 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
-
Vignesh Raghavendra authored
commit 439c7183 upstream. UARTs on TI SoCs prior to J7200 don't provide independent control over RX FIFO not empty interrupt (RHR_IT) and RX timeout interrupt. Starting with J7200 SoC, its possible to disable RHR_IT independent of RX timeout interrupt using bit 2 of IER2 register. So disable RHR_IT once RX DMA is started so as to avoid spurious interrupt being raised when data is in the RX FIFO but is yet to be drained by DMA (a known errata in older SoCs). Signed-off-by:
-
Peter Ujfalusi authored
commit 115ff12a upstream. Use ERR_CAST() when devm_ioremap_resource() fails. Reported-by:
-
Vignesh Raghavendra authored
commit 5b65781d upstream. This commit adds support for PKTDMA in k3-udma glue driver. Use new psil_endpoint_config struct to get static data for a given channel or a flow during setup. Make sure that the RX flows being mapped to a RX channel is within the range of flows that is been allocated to that RX channel. Signed-off-by:
-
Peter Ujfalusi authored
commit d2abc982 upstream. One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA). It serves similar purpose as K3 UDMAP channels in packet mode, but with notable differences, like tflow support and channels being allocated to service specific peripherals. The rings for the PKTDMA is integrated within the DMA itself instead of using rings from the general purpose ringacc. PKTDMA can be used to service PSI-L peripherals, similarly to K3 UDMA channels. Most of the driver code can be reused for PKTDMA tchan/rchan support but new setup and allocation functions are needed to handle the differences between the DMAs. Signed-off-by:
-
Peter Ujfalusi authored
commit 88448980 upstream. Unlike UDMAP the BCDMA defines the channel TPL levels per channel type. In UDMAP the number of high and ultra-high channels applies to both tchan and rchan. BCDMA defines the TPL per channel types: bchan, tchan and rchan can have different number of high and ultra-high channels. In order to support BCDMA channel TPL we need to move the tpl information as per channel type property for the DMAs. Signed-off-by:
-
Peter Ujfalusi authored
commit 01779473 upstream. One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA). It serves similar purpose as K3 UDMAP channels in TR mode. The rings for the BCDMA is integrated within the DMA itself instead of using rings from the general purpose ringacc. A BCDMA have two different type of channels: - Block Copy Channels (bchan) - Split Channels (tchan and rchan) tchan and rchan can be used to service PSI-L peripherals, similarly to K3 UDMA channels. bchan can be only used for block copy operation (TR type15) like the paired K3 UDMA tchan/rchan configured in block copy mode. bchans can be also used to service peripherals directly if an external trigger is selected for the channel. Most of the driver code can be reused for BCDMA bchan/tchan/rchan support but new setup and allocation functions are needed to handle the differences between the DMAs. Signed-off-by:
-
Grygorii Strashko authored
commit d782298c upstream. The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a separate and generic ringacc is used. The ring SW interface is similar to ringacc with some major architectural differences, like They are part of the DMA (BCDMA or PKTDMA). They are dual mode rings are modeled as pair of Rings objects which has common configuration and memory buffer, but separate real-time control register sets for each direction mem2dev (forward) and dev2mem (reverse). The ringacc driver must be initialized for DMA rings use with k3_ringacc_dmarings_init() as it is not an independent device as ringacc is. AM64 rings must be requested only using k3_ringacc_request_rings_pair(), and forward ring must always be initialized/configured. After this any other Ringacc APIs can be used without any callers changes. Signed-off-by:
-
Peter Ujfalusi authored
commit fc373e47 upstream. In k3 architecture a DMA channel (in TR momde) can be triggered by global events, origination from different modules. The events for triggers can be sent from any module which is connected to PSI-L fabric, but the event number to be sent is DMA channel specific, it is only known after the channel itself is requested. The router operation needs to be split up: - route_allocate: configure the dma_spec for the DMA and store the configuration which is needed for the router's input - set_event: callback used by the DMA driver to set the event number for the channel and enable the routing Signed-off-by:
-
Peter Ujfalusi authored
commit 2329725d upstream. Add initial PSI-L map file for AM64. Signed-off-by:
-
Peter Ujfalusi authored
commit b9366e25 upstream. Additional fields needed for K3 PKTDMA to be able to handle the mapped channels (channels are locked to handle specific threads) and flow ranges for these mapped threads. PKTDMA also introduces tflow for tx channels which can not be found in K3 UDMA architecture. Signed-off-by:
-
Peter Ujfalusi authored
commit 1d92cec6 upstream. New binding document for Texas Instruments K3 Packet DMA (PKTDMA). PKTDMA is introduced as part of AM64. Signed-off-by:
-
Peter Ujfalusi authored
commit 991b96e0 upstream. New binding document for Texas Instruments K3 Block Copy DMA (BCDMA). BCDMA is introduced as part of AM64. Signed-off-by:
-
Peter Ujfalusi authored
commit adc0f941 upstream. By using the dmaengine_get_dma_device() to get the device for dma_api use, the dmatest can support per channel coherency if it is supported by the DMA controller. Signed-off-by:
-
Peter Ujfalusi authored
commit f082c6df upstream. Client drivers should use the dmaengine_get_dma_device(chan) to get the device pointer which should be used for DMA API for allocations and mapping. Signed-off-by:
-
Peter Ujfalusi authored
commit ab650ef6 upstream. If the DMA device supports per channel coherency configuration (a channel can be configured to have coherent or not coherent view) then a single device (the DMA controller's device) can not be used for dma_api for all channels as channels can have different coherency. Introduce custom_dma_mapping flag for the dma_chan and a new helper to get the device pointer to be used for dma_api for the given channel. Client drivers should be updated to be able to support per channel coherency by: - dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE); Signed-off-by:
-
Peter Ujfalusi authored
commit 4f910c03 upstream. Additional configuration for the DMA event router might be needed for a channel which can not be done during device_alloc_chan_resources callback since the router information is not yet present for the drivers. If there is a need for additional configuration for the channel if DMA router is in use, then the driver can implement the device_router_config callback. Signed-off-by:
-
Peter Ujfalusi authored
commit d553e2ab upstream. Rings in RING mode should be using the DMA device for DMA API as in this mode the ringacc will not access the ring memory in any ways, but the DMA is. Fix up the ring configuration and set the dma_dev unconditionally and let the ringacc driver to select the correct device to use for DMA API. Signed-off-by:
-
Peter Ujfalusi authored
commit aa8a4c4e upstream. If of_xudma_dev_get() returns with the valid udma_dev then the driver already got the ringacc, there is no need to execute of_k3_ringacc_get_by_phandle() for each channel via the glue layer. Signed-off-by:
-
Peter Ujfalusi authored
commit 426506a7 upstream. Glue layer users should use the device of the DMA for DMA mapping and allocations as it is the DMA which accesses to descriptors and buffers, not the clients Signed-off-by:
-
Peter Ujfalusi authored
commit 1609c15a upstream. Resource allocation via sysfw can use up to two ranges per resource subtype to support more complex resource assignment, mainly for DMA channels. Take the second range also into consideration when setting up the maps for available resources. Signed-off-by:
-
