<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/dma/Kconfig, branch v5.3.2</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>Merge tag 'dmaengine-5.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma</title>
<updated>2019-07-17T16:55:43+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2019-07-17T16:55:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=47ebe00b684c2bc183a766bc33c8b5943bc0df85'/>
<id>47ebe00b684c2bc183a766bc33c8b5943bc0df85</id>
<content type='text'>
Pull dmaengine updates from Vinod Koul:

 - Add support in dmaengine core to do device node checks for DT devices
   and update bunch of drivers to use that and remove open coding from
   drivers

 - New driver/driver support for new hardware, namely:
     - MediaTek UART APDMA
     - Freescale i.mx7ulp edma2
     - Synopsys eDMA IP core version 0
     - Allwinner H6 DMA

 - Updates to axi-dma and support for interleaved cyclic transfers

 - Greg's debugfs return value check removals on drivers

 - Updates to stm32-dma, hsu, dw, pl330, tegra drivers

* tag 'dmaengine-5.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (68 commits)
  dmaengine: Revert "dmaengine: fsl-edma: add i.mx7ulp edma2 version support"
  dmaengine: at_xdmac: check for non-empty xfers_list before invoking callback
  Documentation: dmaengine: clean up description of dmatest usage
  dmaengine: tegra210-adma: remove PM_CLK dependency
  dmaengine: fsl-edma: add i.mx7ulp edma2 version support
  dt-bindings: dma: fsl-edma: add new i.mx7ulp-edma
  dmaengine: fsl-edma-common: version check for v2 instead
  dmaengine: fsl-edma-common: move dmamux register to another single function
  dmaengine: fsl-edma: add drvdata for fsl-edma
  dmaengine: Revert "dmaengine: fsl-edma: support little endian for edma driver"
  dmaengine: rcar-dmac: Reject zero-length slave DMA requests
  dmaengine: dw: Enable iDMA 32-bit on Intel Elkhart Lake
  dmaengine: dw-edma: fix semicolon.cocci warnings
  dmaengine: sh: usb-dmac: Use [] to denote a flexible array member
  dmaengine: dmatest: timeout value of -1 should specify infinite wait
  dmaengine: dw: Distinguish -&gt;remove() between DW and iDMA 32-bit
  dmaengine: fsl-edma: support little endian for edma driver
  dmaengine: hsu: Revert "set HSU_CH_MTSR to memory width"
  dmagengine: pl330: add code to get reset property
  dt-bindings: pl330: document the optional resets property
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull dmaengine updates from Vinod Koul:

 - Add support in dmaengine core to do device node checks for DT devices
   and update bunch of drivers to use that and remove open coding from
   drivers

 - New driver/driver support for new hardware, namely:
     - MediaTek UART APDMA
     - Freescale i.mx7ulp edma2
     - Synopsys eDMA IP core version 0
     - Allwinner H6 DMA

 - Updates to axi-dma and support for interleaved cyclic transfers

 - Greg's debugfs return value check removals on drivers

 - Updates to stm32-dma, hsu, dw, pl330, tegra drivers

* tag 'dmaengine-5.3-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (68 commits)
  dmaengine: Revert "dmaengine: fsl-edma: add i.mx7ulp edma2 version support"
  dmaengine: at_xdmac: check for non-empty xfers_list before invoking callback
  Documentation: dmaengine: clean up description of dmatest usage
  dmaengine: tegra210-adma: remove PM_CLK dependency
  dmaengine: fsl-edma: add i.mx7ulp edma2 version support
  dt-bindings: dma: fsl-edma: add new i.mx7ulp-edma
  dmaengine: fsl-edma-common: version check for v2 instead
  dmaengine: fsl-edma-common: move dmamux register to another single function
  dmaengine: fsl-edma: add drvdata for fsl-edma
  dmaengine: Revert "dmaengine: fsl-edma: support little endian for edma driver"
  dmaengine: rcar-dmac: Reject zero-length slave DMA requests
  dmaengine: dw: Enable iDMA 32-bit on Intel Elkhart Lake
  dmaengine: dw-edma: fix semicolon.cocci warnings
  dmaengine: sh: usb-dmac: Use [] to denote a flexible array member
  dmaengine: dmatest: timeout value of -1 should specify infinite wait
  dmaengine: dw: Distinguish -&gt;remove() between DW and iDMA 32-bit
  dmaengine: fsl-edma: support little endian for edma driver
  dmaengine: hsu: Revert "set HSU_CH_MTSR to memory width"
  dmagengine: pl330: add code to get reset property
  dt-bindings: pl330: document the optional resets property
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: tegra210-adma: remove PM_CLK dependency</title>
<updated>2019-07-05T06:30:47+00:00</updated>
<author>
<name>Sameer Pujar</name>
<email>spujar@nvidia.com</email>
</author>
<published>2019-06-20T15:54:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3145d73e69ba0ab58cb302d3e6a80232bf373b7e'/>
<id>3145d73e69ba0ab58cb302d3e6a80232bf373b7e</id>
<content type='text'>
Tegra ADMA does not use pm-clk interface now and hence the dependency
is removed from Kconfig.

Signed-off-by: Sameer Pujar &lt;spujar@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Tegra ADMA does not use pm-clk interface now and hence the dependency
is removed from Kconfig.

Signed-off-by: Sameer Pujar &lt;spujar@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: axi-dmac: add regmap support</title>
<updated>2019-06-14T05:53:47+00:00</updated>
<author>
<name>Alexandru Ardelean</name>
<email>alexandru.ardelean@analog.com</email>
</author>
<published>2019-06-06T10:45:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fc15be39a827e6e417431a8dc5ca2612d0b3e944'/>
<id>fc15be39a827e6e417431a8dc5ca2612d0b3e944</id>
<content type='text'>
The registers for AXI DMAC are detailed at:
  https://wiki.analog.com/resources/fpga/docs/axi_dmac#register_map

This change adds regmap support for these registers, in case some wants to
have a more direct access to them via this interface.

Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
[vkoul: fixed code style issue]
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The registers for AXI DMAC are detailed at:
  https://wiki.analog.com/resources/fpga/docs/axi_dmac#register_map

This change adds regmap support for these registers, in case some wants to
have a more direct access to them via this interface.

Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
[vkoul: fixed code style issue]
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: Add Synopsys eDMA IP core driver</title>
<updated>2019-06-10T07:40:39+00:00</updated>
<author>
<name>Gustavo Pimentel</name>
<email>Gustavo.Pimentel@synopsys.com</email>
</author>
<published>2019-06-04T13:29:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e63d79d1ffcd2201a2dbff1d7a1184b8f3ec74cf'/>
<id>e63d79d1ffcd2201a2dbff1d7a1184b8f3ec74cf</id>
<content type='text'>
Add Synopsys PCIe Endpoint eDMA IP core driver to kernel.

This IP is generally distributed with Synopsys PCIe Endpoint IP (depends
of the use and licensing agreement).

This core driver, initializes and configures the eDMA IP using vma-helpers
functions and dma-engine subsystem.

This driver can be compile as built-in or external module in kernel.

To enable this driver just select DW_EDMA option in kernel configuration,
however it requires and selects automatically DMA_ENGINE and
DMA_VIRTUAL_CHANNELS option too.

In order to transfer data from point A to B as fast as possible this IP
requires a dedicated memory space containing linked list of elements.

All elements of this linked list are continuous and each one describes a
data transfer (source and destination addresses, length and a control
variable).

For the sake of simplicity, lets assume a memory space for channel write
0 which allows about 42 elements.

+---------+
| Desc #0 |-+
+---------+ |
            V
       +----------+
       | Chunk #0 |-+
       |  CB = 1  | |  +----------+  +-----+  +-----------+  +-----+
       +----------+ +-&gt;| Burst #0 |-&gt;| ... |-&gt;| Burst #41 |-&gt;| llp |
            |          +----------+  +-----+  +-----------+  +-----+
            V
       +----------+
       | Chunk #1 |-+
       |  CB = 0  | |  +-----------+  +-----+  +-----------+  +-----+
       +----------+ +-&gt;| Burst #42 |-&gt;| ... |-&gt;| Burst #83 |-&gt;| llp |
            |          +-----------+  +-----+  +-----------+  +-----+
            V
       +----------+
       | Chunk #2 |-+
       |  CB = 1  | |  +-----------+  +-----+  +------------+  +-----+
       +----------+ +-&gt;| Burst #84 |-&gt;| ... |-&gt;| Burst #125 |-&gt;| llp |
            |          +-----------+  +-----+  +------------+  +-----+
            V
       +----------+
       | Chunk #3 |-+
       |  CB = 0  | |  +------------+  +-----+  +------------+  +-----+
       +----------+ +-&gt;| Burst #126 |-&gt;| ... |-&gt;| Burst #129 |-&gt;| llp |
                       +------------+  +-----+  +------------+  +-----+

Legend:
 - Linked list, also know as Chunk
 - Linked list element*, also know as Burst *CB*, also know as Change Bit,
it's a control bit (and typically is toggled) that allows to easily
identify and differentiate between the current linked list and the
previous or the next one.
 - LLP, is a special element that indicates the end of the linked list
element stream also informs that the next CB should be toggle

On every last Burst of the Chunk (Burst #41, Burst #83, Burst #125 or
even Burst #129) is set some flags on their control variable (RIE and
LIE bits) that will trigger the send of "done" interruption.

On the interruptions callback, is decided whether to recycle the linked
list memory space by writing a new set of Bursts elements (if still
exists Chunks to transfer) or is considered completed (if there is no
Chunks available to transfer).

On scatter-gather transfer mode, the client will submit a scatter-gather
list of n (on this case 130) elements, that will be divide in multiple
Chunks, each Chunk will have (on this case 42) a limited number of
Bursts and after transferring all Bursts, an interrupt will be
triggered, which will allow to recycle the all linked list dedicated
memory again with the new information relative to the next Chunk and
respective Burst associated and repeat the whole cycle again.

On cyclic transfer mode, the client will submit a buffer pointer, length
of it and number of repetitions, in this case each burst will correspond
directly to each repetition.

Each Burst can describes a data transfer from point A(source) to point
B(destination) with a length that can be from 1 byte up to 4 GB. Since
dedicated the memory space where the linked list will reside is limited,
the whole n burst elements will be organized in several Chunks, that
will be used later to recycle the dedicated memory space to initiate a
new sequence of data transfers.

The whole transfer is considered has completed when it was transferred
all bursts.

Currently this IP has a set well-known register map, which includes
support for legacy and unroll modes. Legacy mode is version of this
register map that has multiplexer register that allows to switch
registers between all write and read channels and the unroll modes
repeats all write and read channels registers with an offset between
them. This register map is called v0.

The IP team is creating a new register map more suitable to the latest
PCIe features, that very likely will change the map register, which this
version will be called v1. As soon as this new version is released by
the IP team the support for this version in be included on this driver.

According to the logic, patches 1, 2 and 3 should be squashed into 1
unique patch, but for the sake of simplicity of review, it was divided
in this 3 patches files.

Signed-off-by: Gustavo Pimentel &lt;gustavo.pimentel@synopsys.com&gt;
Cc: Vinod Koul &lt;vkoul@kernel.org&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Cc: Joao Pinto &lt;jpinto@synopsys.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add Synopsys PCIe Endpoint eDMA IP core driver to kernel.

This IP is generally distributed with Synopsys PCIe Endpoint IP (depends
of the use and licensing agreement).

This core driver, initializes and configures the eDMA IP using vma-helpers
functions and dma-engine subsystem.

This driver can be compile as built-in or external module in kernel.

To enable this driver just select DW_EDMA option in kernel configuration,
however it requires and selects automatically DMA_ENGINE and
DMA_VIRTUAL_CHANNELS option too.

In order to transfer data from point A to B as fast as possible this IP
requires a dedicated memory space containing linked list of elements.

All elements of this linked list are continuous and each one describes a
data transfer (source and destination addresses, length and a control
variable).

For the sake of simplicity, lets assume a memory space for channel write
0 which allows about 42 elements.

+---------+
| Desc #0 |-+
+---------+ |
            V
       +----------+
       | Chunk #0 |-+
       |  CB = 1  | |  +----------+  +-----+  +-----------+  +-----+
       +----------+ +-&gt;| Burst #0 |-&gt;| ... |-&gt;| Burst #41 |-&gt;| llp |
            |          +----------+  +-----+  +-----------+  +-----+
            V
       +----------+
       | Chunk #1 |-+
       |  CB = 0  | |  +-----------+  +-----+  +-----------+  +-----+
       +----------+ +-&gt;| Burst #42 |-&gt;| ... |-&gt;| Burst #83 |-&gt;| llp |
            |          +-----------+  +-----+  +-----------+  +-----+
            V
       +----------+
       | Chunk #2 |-+
       |  CB = 1  | |  +-----------+  +-----+  +------------+  +-----+
       +----------+ +-&gt;| Burst #84 |-&gt;| ... |-&gt;| Burst #125 |-&gt;| llp |
            |          +-----------+  +-----+  +------------+  +-----+
            V
       +----------+
       | Chunk #3 |-+
       |  CB = 0  | |  +------------+  +-----+  +------------+  +-----+
       +----------+ +-&gt;| Burst #126 |-&gt;| ... |-&gt;| Burst #129 |-&gt;| llp |
                       +------------+  +-----+  +------------+  +-----+

Legend:
 - Linked list, also know as Chunk
 - Linked list element*, also know as Burst *CB*, also know as Change Bit,
it's a control bit (and typically is toggled) that allows to easily
identify and differentiate between the current linked list and the
previous or the next one.
 - LLP, is a special element that indicates the end of the linked list
element stream also informs that the next CB should be toggle

On every last Burst of the Chunk (Burst #41, Burst #83, Burst #125 or
even Burst #129) is set some flags on their control variable (RIE and
LIE bits) that will trigger the send of "done" interruption.

On the interruptions callback, is decided whether to recycle the linked
list memory space by writing a new set of Bursts elements (if still
exists Chunks to transfer) or is considered completed (if there is no
Chunks available to transfer).

On scatter-gather transfer mode, the client will submit a scatter-gather
list of n (on this case 130) elements, that will be divide in multiple
Chunks, each Chunk will have (on this case 42) a limited number of
Bursts and after transferring all Bursts, an interrupt will be
triggered, which will allow to recycle the all linked list dedicated
memory again with the new information relative to the next Chunk and
respective Burst associated and repeat the whole cycle again.

On cyclic transfer mode, the client will submit a buffer pointer, length
of it and number of repetitions, in this case each burst will correspond
directly to each repetition.

Each Burst can describes a data transfer from point A(source) to point
B(destination) with a length that can be from 1 byte up to 4 GB. Since
dedicated the memory space where the linked list will reside is limited,
the whole n burst elements will be organized in several Chunks, that
will be used later to recycle the dedicated memory space to initiate a
new sequence of data transfers.

The whole transfer is considered has completed when it was transferred
all bursts.

Currently this IP has a set well-known register map, which includes
support for legacy and unroll modes. Legacy mode is version of this
register map that has multiplexer register that allows to switch
registers between all write and read channels and the unroll modes
repeats all write and read channels registers with an offset between
them. This register map is called v0.

The IP team is creating a new register map more suitable to the latest
PCIe features, that very likely will change the map register, which this
version will be called v1. As soon as this new version is released by
the IP team the support for this version in be included on this driver.

According to the logic, patches 1, 2 and 3 should be squashed into 1
unique patch, but for the sake of simplicity of review, it was divided
in this 3 patches files.

Signed-off-by: Gustavo Pimentel &lt;gustavo.pimentel@synopsys.com&gt;
Cc: Vinod Koul &lt;vkoul@kernel.org&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Cc: Joao Pinto &lt;jpinto@synopsys.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>treewide: Add SPDX license identifier - Makefile/Kconfig</title>
<updated>2019-05-21T08:50:46+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2019-05-19T12:07:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ec8f24b7faaf3d4799a7c3f4c1b87f6b02778ad1'/>
<id>ec8f24b7faaf3d4799a7c3f4c1b87f6b02778ad1</id>
<content type='text'>
Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: axi-dmac: extend support for ZynqMP arch</title>
<updated>2019-03-25T16:22:28+00:00</updated>
<author>
<name>Michael Hennerich</name>
<email>michael.hennerich@analog.com</email>
</author>
<published>2019-02-28T12:39:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=23b846396b9501f9500cd8fb033a866f8c01f1a6'/>
<id>23b846396b9501f9500cd8fb033a866f8c01f1a6</id>
<content type='text'>
The AXI DMAC driver is currently supported also on the Xilinx ZynqMP
architecture. This change allows this driver to be enabled &amp; used on it as
well.

Signed-off-by: Michael Hennerich &lt;michael.hennerich@analog.com&gt;
Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The AXI DMAC driver is currently supported also on the Xilinx ZynqMP
architecture. This change allows this driver to be enabled &amp; used on it as
well.

Signed-off-by: Michael Hennerich &lt;michael.hennerich@analog.com&gt;
Signed-off-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs</title>
<updated>2019-01-07T04:20:16+00:00</updated>
<author>
<name>Peng Ma</name>
<email>peng.ma@nxp.com</email>
</author>
<published>2018-10-30T02:36:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b092529e0aa09829a6404424ce167bf3ce3235e2'/>
<id>b092529e0aa09829a6404424ce167bf3ce3235e2</id>
<content type='text'>
NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel
virtuallization by allowing DMA jobs to be enqueued into different
command queues.

Signed-off-by: Wen He &lt;wen.he_1@nxp.com&gt;
Signed-off-by: Jiaheng Fan &lt;jiaheng.fan@nxp.com&gt;
Signed-off-by: Peng Ma &lt;peng.ma@nxp.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel
virtuallization by allowing DMA jobs to be enqueued into different
command queues.

Signed-off-by: Wen He &lt;wen.he_1@nxp.com&gt;
Signed-off-by: Jiaheng Fan &lt;jiaheng.fan@nxp.com&gt;
Signed-off-by: Peng Ma &lt;peng.ma@nxp.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver</title>
<updated>2018-11-24T14:12:59+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2018-10-11T16:41:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=32e74aabebc8d045a11452d2de0ac9d2625fcd45'/>
<id>32e74aabebc8d045a11452d2de0ac9d2625fcd45</id>
<content type='text'>
The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Pro4, and sLD8 SoCs.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Pro4, and sLD8 SoCs.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'topic/jz' into for-linus</title>
<updated>2018-10-24T08:16:04+00:00</updated>
<author>
<name>Vinod Koul</name>
<email>vkoul@kernel.org</email>
</author>
<published>2018-10-24T08:16:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=81c3ee027e5d79eb184d2b225a67b06e9e5b9271'/>
<id>81c3ee027e5d79eb184d2b225a67b06e9e5b9271</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>dmaengine: dma-jz4780: Don't depend on MACH_JZ4780</title>
<updated>2018-09-11T07:29:26+00:00</updated>
<author>
<name>Paul Cercueil</name>
<email>paul@crapouillou.net</email>
</author>
<published>2018-08-29T21:32:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c558ecd21c852c97ff98dc6c61f715ba420ec251'/>
<id>c558ecd21c852c97ff98dc6c61f715ba420ec251</id>
<content type='text'>
If we make this driver depend on MACH_JZ4780, that means it can be
enabled only if we're building a kernel specially crafted for a
JZ4780-based board, while most GNU/Linux distributions will want one
generic MIPS kernel that works on multiple boards.

Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we make this driver depend on MACH_JZ4780, that means it can be
enabled only if we're building a kernel specially crafted for a
JZ4780-based board, while most GNU/Linux distributions will want one
generic MIPS kernel that works on multiple boards.

Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
