<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-op-linux/drivers/dma/ti, branch master</title>
<subtitle>Talos™ II Linux sources for OpenPOWER</subtitle>
<id>https://git.raptorcs.com/git/talos-op-linux/atom?h=master</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-op-linux/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/'/>
<updated>2020-02-08T21:58:44+00:00</updated>
<entry>
<title>Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc</title>
<updated>2020-02-08T21:58:44+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-02-08T21:58:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=1afa9c3b7c9bdcb562e2afe9f58cc99d0b071cdc'/>
<id>urn:sha1:1afa9c3b7c9bdcb562e2afe9f58cc99d0b071cdc</id>
<content type='text'>
Pull ARM Device-tree updates from Olof Johansson:
 "New SoCs:

   - Atmel/Microchip SAM9X60 (ARM926 SoC)

   - OMAP 37xx gets split into AM3703/AM3715/DM3725, who are all
     variants of it with different GPU/media IP configurations.

   - ST stm32mp15 SoCs (1-2 Cortex-A7, CAN, GPU depending on SKU)

   - ST Ericsson ab8505 (variant of ab8500) and db8520 (variant of
     db8500)

   - Unisoc SC9863A SoC (8x Cortex-A55 mobile chipset w/ GPU, modem)

   - Qualcomm SC7180 (8-core 64bit SoC, unnamed CPU class)

  New boards:

   - Allwinner:
      + Emlid Neutis SoM (H3 variant)
      + Libre Computer ALL-H3-IT
      + PineH64 Model B

   - Amlogic:
      + Libretech Amlogic GX PC (s905d and s912-based variants)

   - Atmel/Microchip:
      + Kizboxmini, sam9x60 EK, sama5d27 Wireless SOM (wlsom1)

   - Marvell:
      + Armada 385-based SolidRun Clearfog GTR

   - NXP:
      + Gateworks GW59xx boards based on i.MX6/6Q/6QDL
      + Tolino Shine 3 eBook reader (i.MX6sl)
      + Embedded Artists COM (i.MX7ULP)
      + SolidRun CLearfog CX/ITX and HoneyComb (LX2160A-based systems)
      + Google Coral Edge TPU (i.MX8MQ)

   - Rockchip:
      + Radxa Dalang Carrier (supports rk3288 and rk3399 SOMs)
      + Radxa Rock Pi N10 (RK3399Pro-based)
      + VMARC RK3399Pro SOM

   - ST:
      + Reference boards for stm32mp15

   - ST Ericsson:
      + Samsung Galaxy S III mini (GT-I8190)
      + HREF520 reference board for DB8520

   - TI OMAP:
      + Gen1 Amazon Echo (OMAP3630-based)

   - Qualcomm:
      + Inforce 6640 Single Board Computer (msm8996-based)
      + SC7180 IDP (SC7180-based)"

* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (623 commits)
  dt-bindings: fix compilation error of the example in marvell,mmp3-hsic-phy.yaml
  arm64: dts: ti: k3-am654-base-board: Add CSI2 OV5640 camera
  arm64: dts: ti: k3-am65-main Add CAL node
  arm64: dts: ti: k3-j721e-main: Add McASP nodes
  arm64: dts: ti: k3-am654-main: Add McASP nodes
  arm64: dts: ti: k3-j721e: DMA support
  arm64: dts: ti: k3-j721e-main: Move secure proxy and smmu under main_navss
  arm64: dts: ti: k3-j721e-main: Correct main NAVSS representation
  arm64: dts: ti: k3-j721e: Correct the address for MAIN NAVSS
  arm64: dts: ti: k3-am65: DMA support
  arm64: dts: ti: k3-am65-main: Move secure proxy under cbass_main_navss
  arm64: dts: ti: k3-am65-main: Correct main NAVSS representation
  ARM: dts: aspeed: rainier: Add UCD90320 power sequencer
  ARM: dts: aspeed: rainier: Switch PSUs to unknown version
  arm64: dts: rockchip: Kill off "simple-panel" compatibles
  ARM: dts: rockchip: Kill off "simple-panel" compatibles
  arm64: dts: rockchip: rename dwmmc node names to mmc
  ARM: dts: rockchip: rename dwmmc node names to mmc
  arm64: dts: exynos: Rename Samsung and Exynos to lowercase
  arm64: dts: uniphier: add reset-names to NAND controller node
  ...
</content>
</entry>
<entry>
<title>dmaengine: ti: k3-udma: fix spelling mistake "limted" -&gt; "limited"</title>
<updated>2020-01-23T11:33:29+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2020-01-22T09:38:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=6c0157be02f02c490dbe74af0d469ed1ddc30b1e'/>
<id>urn:sha1:6c0157be02f02c490dbe74af0d469ed1ddc30b1e</id>
<content type='text'>
There are spelling mistakes in dev_err messages. Fix them.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Link: https://lore.kernel.org/r/20200122093818.2800743-1-colin.king@canonical.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: k3-psil: make symbols static</title>
<updated>2020-01-21T07:40:24+00:00</updated>
<author>
<name>Peter Ujfalusi</name>
<email>peter.ujfalusi@ti.com</email>
</author>
<published>2020-01-21T07:01:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=2bd8010a618c9181dd8d49097a1c72fd396c632e'/>
<id>urn:sha1:2bd8010a618c9181dd8d49097a1c72fd396c632e</id>
<content type='text'>
Fixe the following warnings by making these static

drivers/dma/ti/k3-psil-j721e.c:62:16: warning: symbol 'j721e_src_ep_map' was not declared. Should it be static?
drivers/dma/ti/k3-psil-j721e.c:172:16: warning: symbol 'j721e_dst_ep_map' was not declared. Should it be static?
drivers/dma/ti/k3-psil-j721e.c:216:20: warning: symbol 'j721e_ep_map' was not declared. Should it be static?
  CC      drivers/dma/ti/k3-psil-j721e.o
drivers/dma/ti/k3-psil-am654.c:52:16: warning: symbol 'am654_src_ep_map' was not declared. Should it be static?
drivers/dma/ti/k3-psil-am654.c:127:16: warning: symbol 'am654_dst_ep_map' was not declared. Should it be static?
drivers/dma/ti/k3-psil-am654.c:169:20: warning: symbol 'am654_ep_map' was not declared. Should it be static?

Reported-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Link: https://lore.kernel.org/r/20200121070104.4393-1-peter.ujfalusi@ti.com
[vkoul: updated patch title]
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: k3-udma: Add glue layer for non DMAengine users</title>
<updated>2020-01-21T05:36:12+00:00</updated>
<author>
<name>Grygorii Strashko</name>
<email>grygorii.strashko@ti.com</email>
</author>
<published>2019-12-23T11:04:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=d702419134133db1eab2067dc6ea5723467fd917'/>
<id>urn:sha1:d702419134133db1eab2067dc6ea5723467fd917</id>
<content type='text'>
Certain users can not use right now the DMAengine API due to missing
features in the core. Prime example is Networking.

These users can use the glue layer interface to avoid misuse of DMAengine
API and when the core gains the needed features they can be converted to
use generic API.

The most prominent features the glue layer clients are depending on:

- most PSI-L native peripheral use extra rflow ranges on a receive channel
   and depending on the peripheral's configuration packets from a single
   free descriptor ring is going to be received to different receive ring
  - it is also possible to have different free descriptor rings per rflow
    and an rflow can also support 4 additional free descriptor ring based
    on the size of the incoming packet
- out of order completion of descriptors on a channel
 - when we have several queues to handle different priority packets the
   descriptors will be completed 'out-of-order'
- the notion of prep_slave_sg is not matching with what the streaming type
   of operation is demanding for networking
- Streaming type of operation
 - Ability to fill the free descriptor ring with descriptors in
   anticipation of incoming traffic and when a packet arrives UDMAP will
   form a packet and gives it to the client driver
 - the descriptors are not backed with exact size data buffers as we don't
   know the size of the packet we will receive, but as a generic pool of
   buffers to be used by the receive channel
- NAPI type of operation (polling instead of interrupt driven transfer)
 - without this we can not sustain gigabit speeds and we need to support NAPI
 - not to limit this to networking, but other high performance operations

Signed-off-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Tested-by: Keerthy &lt;j-keerthy@ti.com&gt;
Link: https://lore.kernel.org/r/20191223110458.30766-12-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: New driver for K3 UDMA</title>
<updated>2020-01-21T05:36:12+00:00</updated>
<author>
<name>Peter Ujfalusi</name>
<email>peter.ujfalusi@ti.com</email>
</author>
<published>2019-12-23T11:04:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=25dcb5dd7b7ce5587c1df18f584ff78f51a68a94'/>
<id>urn:sha1:25dcb5dd7b7ce5587c1df18f584ff78f51a68a94</id>
<content type='text'>
Split patch for review containing: defines, structs, io and low level
functions and interrupt callbacks.

DMA driver for
Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P)

The UDMA-P is intended to perform similar (but significantly upgraded) functions
as the packet-oriented DMA used on previous SoC devices. The UDMA-P module
supports the transmission and reception of various packet types. The UDMA-P is
architected to facilitate the segmentation and reassembly of SoC DMA data
structure compliant packets to/from smaller data blocks that are natively
compatible with the specific requirements of each connected peripheral. Multiple
Tx and Rx channels are provided within the DMA which allow multiple segmentation
or reassembly operations to be ongoing. The DMA controller maintains state
information for each of the channels which allows packet segmentation and
reassembly operations to be time division multiplexed between channels in order
to share the underlying DMA hardware. An external DMA scheduler is used to
control the ordering and rate at which this multiplexing occurs for Transmit
operations. The ordering and rate of Receive operations is indirectly controlled
by the order in which blocks are pushed into the DMA on the Rx PSI-L interface.

The UDMA-P also supports acting as both a UTC and UDMA-C for its internal
channels. Channels in the UDMA-P can be configured to be either Packet-Based or
Third-Party channels on a channel by channel basis.

The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet / TR mode)
- MEM_TO_DEV (Packet / TR mode)
- Cyclic (Packet / TR mode)
- Metadata for descriptors

Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Tested-by: Keerthy &lt;j-keerthy@ti.com&gt;
Reviewed-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Link: https://lore.kernel.org/r/20191223110458.30766-11-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: k3 PSI-L remote endpoint configuration</title>
<updated>2020-01-21T05:36:12+00:00</updated>
<author>
<name>Peter Ujfalusi</name>
<email>peter.ujfalusi@ti.com</email>
</author>
<published>2019-12-23T11:04:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=8c6bb62f6b4a24c446511e8f894251946dcc2ef1'/>
<id>urn:sha1:8c6bb62f6b4a24c446511e8f894251946dcc2ef1</id>
<content type='text'>
In K3 architecture the DMA operates within threads. One end of the thread
is UDMAP, the other is on the peripheral side.

The UDMAP channel configuration depends on the needs of the remote
endpoint and it can be differ from peripheral to peripheral.

This patch adds database for am654 and j721e and small API to fetch the
PSI-L endpoint configuration from the database which should only used by
the DMA driver(s).

Another API is added for native peripherals to give possibility to pass new
configuration for the threads they are using, which is needed to be able to
handle changes caused by different firmware loaded for the peripheral for
example.

Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Tested-by: Keerthy &lt;j-keerthy@ti.com&gt;
Reviewed-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Link: https://lore.kernel.org/r/20191223110458.30766-9-peter.ujfalusi@ti.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: omap-dma: don't allow a null od-&gt;plat pointer to be dereferenced</title>
<updated>2020-01-13T17:36:45+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2020-01-09T13:19:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=994772632f006e97addd20277a820058bb0fd481'/>
<id>urn:sha1:994772632f006e97addd20277a820058bb0fd481</id>
<content type='text'>
Currently when the call to dev_get_platdata returns null the driver issues
a warning and then later dereferences the null pointer.  Avoid this issue
by returning -ENODEV error rather when the platform data is null and
change the warning to an appropriate error message.

Addresses-Coverity: ("Dereference after null check")
Fixes: 211010aeb097 ("dmaengine: ti: omap-dma: Pass sdma auxdata to driver and use it")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: omap-dma: Use cpu notifier to block idle for omap2</title>
<updated>2019-12-30T17:46:34+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2019-12-16T22:41:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=f4cfa36dab6734466cd5639e0a1d7d753297cba4'/>
<id>urn:sha1:f4cfa36dab6734466cd5639e0a1d7d753297cba4</id>
<content type='text'>
For omap2, we need to block idle if SDMA is busy. Let's do this with a
cpu notifier and remove the custom call.

Cc: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Cc: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Cc: Vinod Koul &lt;vkoul@kernel.org&gt;
Acked-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Tested-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: omap-dma: Allocate channels directly</title>
<updated>2019-12-30T17:46:17+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2019-12-16T22:41:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=61ecb53952f0ab670ada5e1d71511543963a0948'/>
<id>urn:sha1:61ecb53952f0ab670ada5e1d71511543963a0948</id>
<content type='text'>
With the legacy IRQ handling gone, we can now start allocating channels
directly in the dmaengine driver for device tree based SoCs.

Cc: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Cc: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Cc: Vinod Koul &lt;vkoul@kernel.org&gt;
Acked-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Tested-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: omap-dma: Pass sdma auxdata to driver and use it</title>
<updated>2019-12-30T17:46:01+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2019-12-16T22:41:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-op-linux/commit/?id=211010aeb097d7932809c3bb2144163900a91738'/>
<id>urn:sha1:211010aeb097d7932809c3bb2144163900a91738</id>
<content type='text'>
We can now start passing sdma auxdata to the dmaengine driver to start
removing the platform based sdma init.

Cc: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Cc: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Cc: Vinod Koul &lt;vkoul@kernel.org&gt;
Acked-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Tested-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Acked-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
</entry>
</feed>
