Re: [linux-sunxi] Re: 100% free binary blob board
Hi, On 04/01/2016 11:36 PM, z4v4l wrote: пʼятниця, 1 квітня 2016 р. 21:58:53 UTC+3 користувач Hans de Goede написав: > Regarding TrustZone, I am not aware of it being used on Allwinner. For all 32 bit SoCs it is not used, I'm not sure what the situation is on the A64. You mean it's not used by linux-sunxi or there is no Monitor software on the 32 bit Allwinner SoC's? If the Security extension is present on a cpu, then there should be at least a trivial monitor code and services. And Secure world may restrict Non-secure world significantly in what that may do with the hardware. Some configuration things are only accessible from the Secure state. If TZ isn't used at all, how those things are configured? Ah a good question. I was wrong to mention that we do not use secure mode on 32 bits Allwinner SoCs, this is not true we've a tiny bit of secure mode firmware implementing PSCI so that we can boot the kernel in non secure mode and it can use hyp mode for hardware virtualization. This secure mode firmware is part of the upstream u-boot Allwinner code and fully open-source. We do not limit which hardware the kernel can reach at all, on some SoCs where some hardware is blocked from access from non-secure mode by default, we actually open it up so that the kernel has full hardware access. And in general, maybe you know this, I'm on the beginning of learning arm internals, and I can not get it, - is it possible for an arbitrary software writer to implement and put it into the SoC his own Secure World software stack with the Monitor includingly? AFAIK this depends on the hardware, if the hardware comes with its own secure firmware in the bootrom this in general is not possible, but the 32 bit Allwinner SoCs boot the bootloader in secure mode, so the bootloader can do anything including starting the kernel in secure mode, but we actually want to boot the kernel in non-secure mode so that it can use hw virt, hence we provide our own (very minimal) secure firmware and boot the kernel hyp mode. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 3/3] sunxi: A20-OLinuXino-LIME2: Add i2c2 bus in DTS
Hello Maxime,
thank you for taking the time to review this patch set.
On 04/02/2016 12:34 PM, Maxime Ripard wrote:
> Hi,
>
> On Fri, Mar 25, 2016 at 08:04:07PM +0100, Michael Haas wrote:
>> The A20 processor provides a third I2C bus on pins PB20 and PB21.
>> The A20-OLinuXino-LIME2 exposes this bus via its GPIO1 port.
>>
>> Olimex also provide a breakout board called the
>> A20-OLinuXino-LIME2-UEXT. This change is required to properly
>> support I2C on the UEXT connector found there.
>>
>> Signed-off-by: Michael Haas
>
> What are the other options on that pin? Is it something exclusively
> dedicated to i2c on the pin headers and the documentation, or is
> anyone free to use that pin for whatever he wishes?
>
> Thanks,
> Maxime
I assume you are talking about the UEXT connector, not about PB20 and
PB21. These are regular GPIO pins multiplexed with I2C, but no other
function.
Regarding UEXT: the A20-OLinuXino-LIME2-UEXT breakout board supports two
use cases here.
The first one: provide a simple adapter from the 0.05" pin headers on
the olinuxino to the more common world of 0.1" headers. In this use
case, you can plug the A20-OLinuXino-LIME2-UEXT intoany of LCD_CON or
GIO-{1,2,3} and you're good to go.
The second one: here, you want to use UEXT modules provided by Olimex.
It's a simple connector exposing I2C, SPI and UART as mentioned by
Priit. To use UEXT, you have to use GPIO-1 to get the correct pin mapping.
Regarding the official documentation provided by Olimex. The
A20-OLinuXino-Lime2_Rev_c.pdf shows the pins on GPIO-1 as PB20 and PB21.
In the schematics for the breakout board,
A20-OLinuXino-Lime2-UEXT_sch.pdf, the pins for the UEXT connector are
labeled as PB20/SCK and PB21/SDA. This acknowledges the double use.
However, PB20 and PB21 have pull-ups by default according to
A20-OLinuXino-Lime2_Rev_c.pdf,
which makes them a lot more useful as I2C than as GPIO.
What originally prompted me to submit this patch: I bought a breakout
board and a small LCD with UEXT connector together with my board. Then I
found out that it doesn't work out of the box because i2c2 is not
enabled. Since using UEXT is probably common for that particular
vendor, I believe it should be enabled by default.
Michael
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 2/3] sunxi: A20-OLinuXino-LIME2: Add usb-power-supply
Hello Maxime, On 04/02/2016 12:36 PM, Maxime Ripard wrote: > Hi, > > On Fri, Mar 25, 2016 at 08:04:06PM +0100, Michael Haas wrote: >> The A20-OLinuXino-LIME2 uses the AXP209 PMIC. This patch adds the >> corresponding usb-power-supply node to the DTS. >> If CONFIG_AXP20X_POWER is set, this patch enables the >> /sys/class/power_supply/ >> diirectory. >> >> Signed-off-by: Michael Haas > Is there *any* reason to not use the AXP209 dtsi where it's already > defined? > > Thanks, > Maxime > are you asking why usb-power-supply is not enabled by default? It is entirely possible that there will never be USB power supply connected to a particular board. There is also the possibility of using just the ACIN part, for which I will be submitting a driver soon (courtesy of Bruno Prémont). On the other hand, the USB supply is probably so common that we could just enable it. A board may choose to disable it or simply ignore the issue. After all, the driver will correctly report on POWER_SUPPLY_PROP_PRESENT and POWER_SUPPLY_PROP_ONLINE. Michael -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Allwinner dev board code names
Pine 64 has an android/lichee Allwinner code drop from 1/13/16. http://wiki.pine64.org/index.php/Pine_A64_Software_Release Is these anything interesting in it? Looks likes there is only H3 support in their 3.4 kernel, not the 3.10 one. Don't see Android 5.1 for H3 either. On Sat, Apr 2, 2016 at 10:33 AM, Thomas Kaiser wrote: > Jon Smirl wrote: >> >> I was looking for H3. > > > What about dolphin then? > > https://github.com/friendlyarm/h3_lichee/tree/master/tools/pack/chips/sun8iw7p1/configs > > Thomas > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 3/3] sunxi: A20-OLinuXino-LIME2: Add i2c2 bus in DTS
On Sat, 2016-04-02 at 12:34 +0200, Maxime Ripard wrote: > Hi, > > On Fri, Mar 25, 2016 at 08:04:07PM +0100, Michael Haas wrote: > > > > The A20 processor provides a third I2C bus on pins PB20 and PB21. > > The A20-OLinuXino-LIME2 exposes this bus via its GPIO1 port. > > > > Olimex also provide a breakout board called the > > A20-OLinuXino-LIME2-UEXT. This change is required to properly > > support I2C on the UEXT connector found there. Documentation for Olimex UEXT interface: https://www.olimex.com/Products/Modules/UEXT/resources/UEXT_rev_B.pdf Basically it *should* by default work as a board to board connector which supports three serial communication interfaces: I2C, SPI and UART (original document mentions RS232, but official modules work only with 3.3V logic levels). > > > > Signed-off-by: Michael Haas > What are the other options on that pin? Is it something exclusively > dedicated to i2c on the pin headers and the documentation, or is > anyone free to use that pin for whatever he wishes? > > Thanks, > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Allwinner dev board code names
Jon Smirl wrote: > > I was looking for H3. > What about dolphin then? https://github.com/friendlyarm/h3_lichee/tree/master/tools/pack/chips/sun8iw7p1/configs Thomas -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/3] sunxi: A20-OLinuXino-LIME2: Add usb-power-supply
Hi, On Fri, Mar 25, 2016 at 08:04:06PM +0100, Michael Haas wrote: > The A20-OLinuXino-LIME2 uses the AXP209 PMIC. This patch adds the > corresponding usb-power-supply node to the DTS. > If CONFIG_AXP20X_POWER is set, this patch enables the /sys/class/power_supply/ > diirectory. > > Signed-off-by: Michael Haas Is there *any* reason to not use the AXP209 dtsi where it's already defined? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 3/3] sunxi: A20-OLinuXino-LIME2: Add i2c2 bus in DTS
Hi, On Fri, Mar 25, 2016 at 08:04:07PM +0100, Michael Haas wrote: > The A20 processor provides a third I2C bus on pins PB20 and PB21. > The A20-OLinuXino-LIME2 exposes this bus via its GPIO1 port. > > Olimex also provide a breakout board called the > A20-OLinuXino-LIME2-UEXT. This change is required to properly > support I2C on the UEXT connector found there. > > Signed-off-by: Michael Haas What are the other options on that pin? Is it something exclusively dedicated to i2c on the pin headers and the documentation, or is anyone free to use that pin for whatever he wishes? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] [PATCH v4 3/3] dmaengine: sun6i: Add cyclic capability
DMA cyclic transfers are required by audio streaming.
Acked-by: Maxime Ripard
Signed-off-by: Jean-Francois Moine
---
drivers/dma/sun6i-dma.c | 129 +---
1 file changed, 122 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 821fc4f..0c1ea8b 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -146,6 +146,8 @@ struct sun6i_vchan {
struct dma_slave_config cfg;
struct sun6i_pchan *phy;
u8 port;
+ u8 irq_type;
+ boolcyclic;
};
struct sun6i_dma_dev {
@@ -254,6 +256,30 @@ static inline s8 convert_buswidth(enum dma_slave_buswidth
addr_width)
return addr_width >> 1;
}
+static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
+{
+ struct sun6i_desc *txd = pchan->desc;
+ struct sun6i_dma_lli *lli;
+ size_t bytes;
+ dma_addr_t pos;
+
+ pos = readl(pchan->base + DMA_CHAN_LLI_ADDR);
+ bytes = readl(pchan->base + DMA_CHAN_CUR_CNT);
+
+ if (pos == LLI_LAST_ITEM)
+ return bytes;
+
+ for (lli = txd->v_lli; lli; lli = lli->v_lli_next) {
+ if (lli->p_lli_next == pos) {
+ for (lli = lli->v_lli_next; lli; lli = lli->v_lli_next)
+ bytes += lli->len;
+ break;
+ }
+ }
+
+ return bytes;
+}
+
static void *sun6i_dma_lli_add(struct sun6i_dma_lli *prev,
struct sun6i_dma_lli *next,
dma_addr_t next_phy,
@@ -342,8 +368,12 @@ static int sun6i_dma_start_desc(struct sun6i_vchan *vchan)
irq_reg = pchan->idx / DMA_IRQ_CHAN_NR;
irq_offset = pchan->idx % DMA_IRQ_CHAN_NR;
+ vchan->irq_type = vchan->cyclic ? DMA_IRQ_PKG : DMA_IRQ_QUEUE;
+
irq_val = readl(sdev->base + DMA_IRQ_EN(irq_reg));
- irq_val |= DMA_IRQ_QUEUE << (irq_offset * DMA_IRQ_CHAN_WIDTH);
+ irq_val &= ~((DMA_IRQ_HALF | DMA_IRQ_PKG | DMA_IRQ_QUEUE) <<
+ (irq_offset * DMA_IRQ_CHAN_WIDTH));
+ irq_val |= vchan->irq_type << (irq_offset * DMA_IRQ_CHAN_WIDTH);
writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
writel(pchan->desc->p_lli, pchan->base + DMA_CHAN_LLI_ADDR);
@@ -440,11 +470,12 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void
*dev_id)
writel(status, sdev->base + DMA_IRQ_STAT(i));
for (j = 0; (j < DMA_IRQ_CHAN_NR) && status; j++) {
- if (status & DMA_IRQ_QUEUE) {
- pchan = sdev->pchans + j;
- vchan = pchan->vchan;
-
- if (vchan) {
+ pchan = sdev->pchans + j;
+ vchan = pchan->vchan;
+ if (vchan && (status & vchan->irq_type)) {
+ if (vchan->cyclic) {
+ vchan_cyclic_callback(&pchan->desc->vd);
+ } else {
spin_lock(&vchan->vc.lock);
vchan_cookie_complete(&pchan->desc->vd);
pchan->done = pchan->desc;
@@ -650,6 +681,78 @@ err_lli_free:
return NULL;
}
+static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
+ struct dma_chan *chan,
+ dma_addr_t buf_addr,
+ size_t buf_len,
+ size_t period_len,
+ enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(chan->device);
+ struct sun6i_vchan *vchan = to_sun6i_vchan(chan);
+ struct dma_slave_config *sconfig = &vchan->cfg;
+ struct sun6i_dma_lli *v_lli, *prev = NULL;
+ struct sun6i_desc *txd;
+ dma_addr_t p_lli;
+ u32 lli_cfg;
+ unsigned int i, periods = buf_len / period_len;
+ int ret;
+
+ ret = set_config(sdev, sconfig, dir, &lli_cfg);
+ if (ret) {
+ dev_err(chan2dev(chan), "Invalid DMA configuration\n");
+ return NULL;
+ }
+
+ txd = kzalloc(sizeof(*txd), GFP_NOWAIT);
+ if (!txd)
+ return NULL;
+
+ for (i = 0; i < periods; i++){
+ v_lli = dma_pool_alloc(sdev->pool, GFP_NOWAIT, &p_lli);
+ if (!v_lli) {
+ dev_err(sdev->slave.dev, "Failed to alloc lli
memory\n");
+ goto err_lli_free;
+ }
+
+ v_lli->len = period_len;
+ v_lli->para = NORMAL_WAIT;
+
+ if (dir == DMA_MEM_TO_DEV) {
+ v_lli->src
[linux-sunxi] [PATCH v4 2/3] dmaengine: sun6i: Set default maxburst size and bus width
Some DMA clients, as audio, don't set the maxburst size and bus width
on the memory side when starting DMA transfers.
This patch prevents such transfers to be aborted by providing system
default values to the lacking ones.
Signed-off-by: Jean-Francois Moine
---
drivers/dma/sun6i-dma.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index b08245e..821fc4f 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -470,10 +470,25 @@ static int set_config(struct sun6i_dma_dev *sdev,
{
s8 src_width, dst_width, src_burst, dst_burst;
- src_burst = convert_burst(sconfig->src_maxburst);
- src_width = convert_buswidth(sconfig->src_addr_width);
- dst_burst = convert_burst(sconfig->dst_maxburst);
- dst_width = convert_buswidth(sconfig->dst_addr_width);
+ if (direction == DMA_MEM_TO_DEV) {
+ src_burst = convert_burst(sconfig->src_maxburst ?
+ sconfig->src_maxburst : 8);
+ src_width = convert_buswidth(sconfig->src_addr_width !=
+ DMA_SLAVE_BUSWIDTH_UNDEFINED ?
+ sconfig->src_addr_width :
+ DMA_SLAVE_BUSWIDTH_4_BYTES);
+ dst_burst = convert_burst(sconfig->dst_maxburst);
+ dst_width = convert_buswidth(sconfig->dst_addr_width);
+ } else {/* DMA_DEV_TO_MEM */
+ src_burst = convert_burst(sconfig->src_maxburst);
+ src_width = convert_buswidth(sconfig->src_addr_width);
+ dst_burst = convert_burst(sconfig->dst_maxburst ?
+ sconfig->dst_maxburst : 8);
+ dst_width = convert_buswidth(sconfig->dst_addr_width !=
+ DMA_SLAVE_BUSWIDTH_UNDEFINED ?
+ sconfig->dst_addr_width :
+ DMA_SLAVE_BUSWIDTH_4_BYTES);
+ }
if (src_burst < 0)
return src_burst;
--
2.8.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v4 1/3] dmaengine: sun6i: Simplify lli setting
Checking the DMA config before setting the lli list avoids to do tests
inside the setting loop.
Signed-off-by: Jean-Francois Moine
---
drivers/dma/sun6i-dma.c | 102 ++--
1 file changed, 47 insertions(+), 55 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 3579ee7..b08245e 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -276,45 +276,6 @@ static void *sun6i_dma_lli_add(struct sun6i_dma_lli *prev,
return next;
}
-static inline int sun6i_dma_cfg_lli(struct sun6i_dma_lli *lli,
- dma_addr_t src,
- dma_addr_t dst, u32 len,
- struct dma_slave_config *config)
-{
- s8 src_width, dst_width, src_burst, dst_burst;
-
- if (!config)
- return -EINVAL;
-
- src_burst = convert_burst(config->src_maxburst);
- if (src_burst < 0)
- return src_burst;
-
- dst_burst = convert_burst(config->dst_maxburst);
- if (dst_burst < 0)
- return dst_burst;
-
- src_width = convert_buswidth(config->src_addr_width);
- if (src_width < 0)
- return src_width;
-
- dst_width = convert_buswidth(config->dst_addr_width);
- if (dst_width < 0)
- return dst_width;
-
- lli->cfg = DMA_CHAN_CFG_SRC_BURST(src_burst) |
- DMA_CHAN_CFG_SRC_WIDTH(src_width) |
- DMA_CHAN_CFG_DST_BURST(dst_burst) |
- DMA_CHAN_CFG_DST_WIDTH(dst_width);
-
- lli->src = src;
- lli->dst = dst;
- lli->len = len;
- lli->para = NORMAL_WAIT;
-
- return 0;
-}
-
static inline void sun6i_dma_dump_lli(struct sun6i_vchan *vchan,
struct sun6i_dma_lli *lli)
{
@@ -502,6 +463,35 @@ static irqreturn_t sun6i_dma_interrupt(int irq, void
*dev_id)
return ret;
}
+static int set_config(struct sun6i_dma_dev *sdev,
+ struct dma_slave_config *sconfig,
+ enum dma_transfer_direction direction,
+ u32 *p_cfg)
+{
+ s8 src_width, dst_width, src_burst, dst_burst;
+
+ src_burst = convert_burst(sconfig->src_maxburst);
+ src_width = convert_buswidth(sconfig->src_addr_width);
+ dst_burst = convert_burst(sconfig->dst_maxburst);
+ dst_width = convert_buswidth(sconfig->dst_addr_width);
+
+ if (src_burst < 0)
+ return src_burst;
+ if (src_width < 0)
+ return src_width;
+ if (dst_burst < 0)
+ return dst_burst;
+ if (dst_width < 0)
+ return dst_width;
+
+ *p_cfg = DMA_CHAN_CFG_SRC_BURST(src_burst) |
+ DMA_CHAN_CFG_SRC_WIDTH(src_width) |
+ DMA_CHAN_CFG_DST_BURST(dst_burst) |
+ DMA_CHAN_CFG_DST_WIDTH(dst_width);
+
+ return 0;
+}
+
static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_memcpy(
struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
size_t len, unsigned long flags)
@@ -569,6 +559,7 @@ static struct dma_async_tx_descriptor
*sun6i_dma_prep_slave_sg(
struct sun6i_desc *txd;
struct scatterlist *sg;
dma_addr_t p_lli;
+ u32 lli_cfg;
int i, ret;
if (!sgl)
@@ -579,6 +570,12 @@ static struct dma_async_tx_descriptor
*sun6i_dma_prep_slave_sg(
return NULL;
}
+ ret = set_config(sdev, sconfig, dir, &lli_cfg);
+ if (ret) {
+ dev_err(chan2dev(chan), "Invalid DMA configuration\n");
+ return NULL;
+ }
+
txd = kzalloc(sizeof(*txd), GFP_NOWAIT);
if (!txd)
return NULL;
@@ -588,14 +585,14 @@ static struct dma_async_tx_descriptor
*sun6i_dma_prep_slave_sg(
if (!v_lli)
goto err_lli_free;
- if (dir == DMA_MEM_TO_DEV) {
- ret = sun6i_dma_cfg_lli(v_lli, sg_dma_address(sg),
- sconfig->dst_addr,
sg_dma_len(sg),
- sconfig);
- if (ret)
- goto err_cur_lli_free;
+ v_lli->len = sg_dma_len(sg);
+ v_lli->para = NORMAL_WAIT;
- v_lli->cfg |= DMA_CHAN_CFG_DST_IO_MODE |
+ if (dir == DMA_MEM_TO_DEV) {
+ v_lli->src = sg_dma_address(sg);
+ v_lli->dst = sconfig->dst_addr;
+ v_lli->cfg = lli_cfg |
+ DMA_CHAN_CFG_DST_IO_MODE |
DMA_CHAN_CFG_SRC_LINEAR_MODE |
DMA_CHAN_CFG_SRC_DRQ(DRQ_SDRAM) |
DMA_CHAN_CFG_DST_DRQ(vchan->port);
@@ -607,13 +604,10 @@ static struct dma_async_tx_descriptor
*sun6i_dma_prep_slave_s
[linux-sunxi] [PATCH v4 0/3] dmaengine: sun6i: Upgrade for audio transfers
This patch series contains most of the required changes to the sun6i DMA driver for audio streaming (tested in a Allwinner H3 - Orange PI 2). It is based on the previous series 'dmaengine: sun6i: Fixes' (2016-03-18). The lacking patch (Add 4 as a possible burst value for H3) will be submitted when a consensus with Maxime Ripard will be found. v4 - remove 'Add 4 as a possible burst value for H3' (no consensus yet) - remove 'Simplify some macros' (Maxime Ripard) - remove 'Compact a bit some config constants' (not critical) - split 'lli setting' into 'simplify' and 'default burst and bus width' (Maxime Ripard) v3 - do some optimizations - add a check about the maxburst value '4' (Maxime Ripard) - remove the driver fixes v2 (comments from Vinod Koul and Sergei Shtylyov - thanks) - typo fixes - change some comments - better handling of burst and bus width - remove useless code in the cyclic capability patch Jean-Francois Moine (3): dmaengine: sun6i: Simplify lli setting dmaengine: sun6i: Set default maxburst size and bus width dmaengine: sun6i: Add cyclic capability drivers/dma/sun6i-dma.c | 246 1 file changed, 184 insertions(+), 62 deletions(-) -- 2.8.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
