Re: [linux-sunxi] why i'm unable to edit wiki page?

[Emilio López]

El 30/06/17 a las 10:36, Eyad Majali escribió:
> 
> 
> On Friday, June 30, 2017 at 4:33:56 PM UTC+3, Emilio López wrote:
> 
> Hi,
> 
> El 30/06/17 a las 10:25, Eyad Majali escribió:
> > Hi
> > i created a github repo for zet6221 complete touch driver for
> > linux-sunxi  and want to edit http://linux-sunxi.org/Touchscreen
> <http://linux-sunxi.org/Touchscreen> to add
> > my repo there,
> > thus version supports all zet62xx chips with firmwares here's the
> repo
> > https://github.com/xchetah/zet6221-sunxi
> <https://github.com/xchetah/zet6221-sunxi>
> > do i need special permissions ?
> 
> You need to create an account on the wiki and log in to edit pages,
> have
> you done so?
> 
> Cheers,
> Emilio
> 
> Yes of course I did ,I can save the changes but when I reload the page
> the changes are not applied

I can now see your edit on that wiki page, let me know if you still have
trouble seeing it. Maybe some cache system has gone awry.

https://linux-sunxi.org/index.php?title=Touchscreen=20209=19239

Cheers,
Emilio

-- 
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] why i'm unable to edit wiki page?

[Emilio López]

Hi,

El 30/06/17 a las 10:25, Eyad Majali escribió:
> Hi
> i created a github repo for zet6221 complete touch driver for
> linux-sunxi  and want to edit http://linux-sunxi.org/Touchscreen to add
> my repo there,
> thus version supports all zet62xx chips with firmwares here's the repo
> https://github.com/xchetah/zet6221-sunxi
> do i need special permissions ?

You need to create an account on the wiki and log in to edit pages, have
you done so?

Cheers,
Emilio

-- 
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] 'BUG: scheduling while atomic' inside thread threaded_irq

[Emilio López]

Hi,

El 30/03/17 a las 23:48, Vinicius Maciel escribió:
> Hi,
> 
> I'm calling spi_sync_transfer inside a threaded interrupt function and
> makes kernel crash. 
> Threaded interrupt functions are supposed can sleep. Could be a problem
> on sun4i_spi_transfer_one
> when call wait_for_completion_timeout?
> 
> kernel log: https://pastebin.com/RNAdGTHE

It's hard to say without looking at the code, is this max11043 driver
published somewhere? Is max11043_interrupt() the threaded part of the
interrupt handler? spi_sync_transfer() can sleep so you can't use it
inside the non-threaded part.

Cheers,
Emilio

-- 
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] [PATCH 3/4] ARM: sun7i: Convert to CCU

[Emilio López]

Hi,

I spotted a couple of things here on a quick look, see below

El 27/02/17 a las 18:09, Priit Laes escribió:
> Convert sun7i-a20.dtsi to new CCU driver.
> 
> Signed-off-by: Priit Laes 
> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 719 
> +--
>  1 file changed, 86 insertions(+), 633 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 04c9977..6f80cb8 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -47,7 +47,8 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -67,19 +68,19 @@
>   compatible = "allwinner,simple-framebuffer",
>"simple-framebuffer";
>   allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <_gates 36>, <_gates 43>,
> -  <_gates 44>, <_be0_clk>,
> -  <_ch1_clk>, <_gates 26>;
> + clocks = < CLK_AHB_LCD0>, < CLK_AHB_HDMI1>,
> +  < CLK_AHB_DE_BE0>, < CLK_DE_BE0>,
> +  < CLK_TCON0_CH1>, < CLK_DRAM_DE_BE0>;
>   status = "disabled";
>   };
>  
> - framebuffer@1 {
> + framebuffer@0 {

This looks like an unrelated change

> @@ -184,21 +185,11 @@
>  
>   osc24M: clk@01c20050 {
>   #clock-cells = <0>;
> - compatible = "allwinner,sun4i-a10-osc-clk";
> - reg = <0x01c20050 0x4>;
> + compatible = "fixed-clock";
>   clock-frequency = <2400>;
>   clock-output-names = "osc24M";
>   };

allwinner,sun4i-a10-osc-clk implements a gate apart from a fixed clock,
is the feature loss intended?

Cheers,
Emilio

-- 
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] [PATCH 2/3] net: phy: realtek: make define more concistent

[Emilio López]

Small nitpick:

El 08/11/16 a las 13:38, Olliver Schinagl escribió:
> All internal defines in the realtek phy are with a small X,
> except MIIM_RTL8211X_CTRL1000T_MASTER. Make this more concistent

s/concistent/consistent/ both here and on the subject :)

Cheers!
Emilio

-- 
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] [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users

[Emilio López]

Hi,

El 07/03/16 a las 12:47, Boris Brezillon escribió:
(...)
>> Does SPI refer the Serial Peripheral Interface?
>>
>> If yes, then I would point out that current sun4i SPI driver doesn't
>> actually use DMA [1]
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411
>> 722.html
> 
> I just moved this assignment and the associated comment in the driver,
> so maybe we should ask Emilio why he thinks SPI config should be the
> default one, and how he tested it...

When I was working on the dmaengine driver, I needed a way to test
mem<->dev and mem<->mem transfers. I used dmatest.ko for the latter, and
SPI was a good fit for the former as I had a logic analyzer. That's why
there's patches to support DMA on it (but, as Priit pointed out, are not
in mainline yet).

At first SPI was acting weird when using DMA, but the problems went away
when configuring the timings with these magic values you see on the
driver today. These timings turned out to also work for audio, so there
was no need for a mechanism to configure them.

And that's basically the story behind SUN4I_DDMA_MAGIC_SPI_PARAMETERS :)

Cheers,
Emilio

-- 
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 4/9] spi: sun4i: add DMA support

[Emilio López]

From: Emilio López emi...@elopez.com.ar

This patch adds support for 64 byte or bigger transfers on the
sun4i SPI controller. Said transfers will be performed via DMA.

Signed-off-by: Emilio López emi...@elopez.com.ar
Tested-by: Michal Suchanek hramr...@gmail.com
---
 drivers/spi/spi-sun4i.c | 145 +++-
 1 file changed, 130 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 4dda366..63242a7 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -14,6 +14,8 @@
 #include linux/clk.h
 #include linux/delay.h
 #include linux/device.h
+#include linux/dmaengine.h
+#include linux/dma-mapping.h
 #include linux/interrupt.h
 #include linux/io.h
 #include linux/module.h
@@ -34,6 +36,7 @@
 #define SUN4I_CTL_CPHA BIT(2)
 #define SUN4I_CTL_CPOL BIT(3)
 #define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
+#define SUN4I_CTL_DMAMC_DEDICATED  BIT(5)
 #define SUN4I_CTL_LMTF BIT(6)
 #define SUN4I_CTL_TF_RST   BIT(8)
 #define SUN4I_CTL_RF_RST   BIT(9)
@@ -51,6 +54,8 @@
 #define SUN4I_INT_STA_REG  0x10
 
 #define SUN4I_DMA_CTL_REG  0x14
+#define SUN4I_DMA_CTL_RF_READY BIT(0)
+#define SUN4I_DMA_CTL_TF_NOT_FULL  BIT(10)
 
 #define SUN4I_WAIT_REG 0x18
 
@@ -130,6 +135,13 @@ static inline void sun4i_spi_fill_fifo(struct sun4i_spi 
*sspi, int len)
}
 }
 
+static bool sun4i_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   return tfr-len = SUN4I_FIFO_DEPTH;
+}
+
 static void sun4i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(spi-master);
@@ -169,17 +181,12 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
  struct spi_transfer *tfr)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(master);
+   struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
unsigned int speed, mclk_rate, div, timeout;
unsigned int start, end, tx_time;
unsigned int tx_len = 0;
+   u32 reg, trigger = 0;
int ret = 0;
-   u32 reg;
-
-   /* We don't support transfer larger than the FIFO */
-   if (tfr-len  SUN4I_FIFO_DEPTH)
-   return -EINVAL;
-   if (tfr-tx_buf  tfr-len = SUN4I_FIFO_DEPTH)
-   return -EINVAL;
 
reinit_completion(sspi-done);
sspi-tx_buf = tfr-tx_buf;
@@ -277,14 +284,67 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
sun4i_spi_write(sspi, SUN4I_BURST_CNT_REG, SUN4I_BURST_CNT(tfr-len));
sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
-   /* Fill the TX FIFO */
-   /* Filling the fifo fully causes timeout for some reason
-* at least on spi2 on a10s */
-   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
-
/* Enable the interrupts */
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
 
+   if (sun4i_spi_can_dma(master, spi, tfr)) {
+   dev_dbg(sspi-master-dev, Using DMA mode for transfer\n);
+
+   if (sspi-tx_buf) {
+   desc_tx = dmaengine_prep_slave_sg(master-dma_tx,
+   tfr-tx_sg.sgl, tfr-tx_sg.nents,
+   DMA_TO_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!desc_tx) {
+   dev_err(sspi-master-dev,
+   Couldn't prepare dma slave\n);
+   return -EIO;
+   }
+
+   trigger |= SUN4I_DMA_CTL_TF_NOT_FULL;
+
+   dmaengine_submit(desc_tx);
+   dma_async_issue_pending(master-dma_tx);
+
+   }
+
+   if (sspi-rx_buf) {
+   desc_rx = dmaengine_prep_slave_sg(master-dma_rx,
+   tfr-rx_sg.sgl, tfr-rx_sg.nents,
+   DMA_FROM_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!desc_rx) {
+   dev_err(sspi-master-dev,
+   Couldn't prepare dma slave\n);
+   return -EIO;
+   }
+
+   trigger |= SUN4I_DMA_CTL_RF_READY;
+
+   dmaengine_submit(desc_rx);
+   dma_async_issue_pending(master-dma_rx);
+   }
+
+   /* Enable Dedicated DMA requests */
+   reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
+   reg

[linux-sunxi] Re: [PATCH v6] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

[Emilio López]

Hi Maxime, Vinod,

El 20/05/15 a las 18:17, Maxime Ripard escibió:

+static struct dma_async_tx_descriptor *
+sun4i_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf, size_t len,
+ size_t period_len, enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+   struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
+   struct dma_slave_config *sconfig = vchan-cfg;
+   struct sun4i_dma_promise *promise;
+   struct sun4i_dma_contract *contract;
+   dma_addr_t src, dest;
+   u32 endpoints;
+   int nr_periods, offset, plength, i;
+
+   if (!is_slave_direction(dir)) {
+   dev_err(chan2dev(chan), Invalid DMA direction\n);
+   return NULL;
+   }
+
+   if (vchan-is_dedicated) {
+   /*
+* As we are using this just for audio data, we need to use
+* normal DMA. There is nothing stopping us from supporting
+* dedicated DMA here as well, so if a client comes up and
+* requires it, it will be simple to implement it.
+*/
+   dev_err(chan2dev(chan),
+   Cyclic transfers are only supported on Normal DMA\n);
+   return NULL;
+   }
+
+   contract = generate_dma_contract();
+   if (!contract)
+   return NULL;
+
+   contract-is_cyclic = 1;
+
+   /* Figure out the endpoints and the address we need */
+   if (dir == DMA_MEM_TO_DEV) {
+   src = buf;
+   dest = sconfig-dst_addr;
+   endpoints = NDMA_CFG_SRC_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM) |
+   NDMA_CFG_DEST_DRQ_TYPE(vchan-endpoint) |
+   NDMA_CFG_DEST_FIXED_ADDR;
+   } else {
+   src = sconfig-src_addr;
+   dest = buf;
+   endpoints = NDMA_CFG_SRC_DRQ_TYPE(vchan-endpoint) |
+   NDMA_CFG_SRC_FIXED_ADDR |
+   NDMA_CFG_DEST_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM);
+   }
+
+   /*
+* We will be using half done interrupts to make two periods
+* out of a promise, so we need to program the DMA engine less
+* often
+*/
+   nr_periods = DIV_ROUND_UP(len / period_len, 2);


and why is that.. why don't you use actual period count here?


I must admit I don't really know on this one.

Emilio?


You mean why is it that I chose to divide len / period_len (is there 
some other way to get period count that I'm missing?) by 2 and use half 
done interrupts? The engine can interrupt on half-transfer, so we can 
use this feature to program the engine half as often as if we didn't use 
it (keep in mind the hardware doesn't support linked lists).


Say you have a set of periods (| marks the start/end, I for interrupt, P 
for programming the engine to do a new transfer), the easy but slow way 
would be to do


 |---|---|---|---| (periods / promises)
 P  I,P I,P I,P  I

Using half transfer interrupts you can do

 |---|---| (promises as configured on hw)
 |---|---|---|---| (periods)
 P   I  I,P  I   I

Which requires half the engine programming for the same functionality.

Feel free to include these drawings on the comment if you think they'll 
help.



+static struct dma_async_tx_descriptor *
+sun4i_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+   unsigned int sg_len, enum dma_transfer_direction dir,
+   unsigned long flags, void *context)
+{
+   struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
+   struct dma_slave_config *sconfig = vchan-cfg;
+   struct sun4i_dma_promise *promise;
+   struct sun4i_dma_contract *contract;
+   struct scatterlist *sg;
+   dma_addr_t srcaddr, dstaddr;
+   u32 endpoints, para;
+   int i;
+
+   if (!sgl)
+   return NULL;
+
+   if (!is_slave_direction(dir)) {
+   dev_err(chan2dev(chan), Invalid DMA direction\n);
+   return NULL;
+   }
+
+   contract = generate_dma_contract();
+   if (!contract)
+   return NULL;
+
+   /* Figure out endpoints */
+   if (vchan-is_dedicated  dir == DMA_MEM_TO_DEV) {
+   endpoints = DDMA_CFG_SRC_DRQ_TYPE(DDMA_DRQ_TYPE_SDRAM) |
+   DDMA_CFG_SRC_ADDR_MODE(DDMA_ADDR_MODE_LINEAR) |
+   DDMA_CFG_DEST_DRQ_TYPE(vchan-endpoint) |
+   DDMA_CFG_DEST_ADDR_MODE(DDMA_ADDR_MODE_IO);
+   } else if (!vchan-is_dedicated  dir == DMA_MEM_TO_DEV) {
+   endpoints = NDMA_CFG_SRC_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM) |
+   NDMA_CFG_DEST_DRQ_TYPE(vchan-endpoint) |
+   NDMA_CFG_DEST_FIXED_ADDR;
+   } else if (vchan-is_dedicated) {
+   endpoints = DDMA_CFG_SRC_DRQ_TYPE(vchan-endpoint) |
+   

[linux-sunxi] [PATCH 1/2] spi: sun4i: add DMA support

[Emilio López]

This patch adds support for 64 byte or bigger transfers on the
sun4i SPI controller. Said transfers will be performed via DMA.

Signed-off-by: Emilio López emi...@elopez.com.ar
Tested-by: Michal Suchanek hramr...@gmail.com
---
 drivers/spi/spi-sun4i.c | 140 +++-
 1 file changed, 128 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index fbb0a4d..d98f560 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -14,6 +14,8 @@
 #include linux/clk.h
 #include linux/delay.h
 #include linux/device.h
+#include linux/dmaengine.h
+#include linux/dma-mapping.h
 #include linux/interrupt.h
 #include linux/io.h
 #include linux/module.h
@@ -34,6 +36,7 @@
 #define SUN4I_CTL_CPHA BIT(2)
 #define SUN4I_CTL_CPOL BIT(3)
 #define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
+#define SUN4I_CTL_DMAMC_DEDICATED  BIT(5)
 #define SUN4I_CTL_LMTF BIT(6)
 #define SUN4I_CTL_TF_RST   BIT(8)
 #define SUN4I_CTL_RF_RST   BIT(9)
@@ -51,6 +54,8 @@
 #define SUN4I_INT_STA_REG  0x10
 
 #define SUN4I_DMA_CTL_REG  0x14
+#define SUN4I_DMA_CTL_RF_READY BIT(0)
+#define SUN4I_DMA_CTL_TF_NOT_FULL  BIT(10)
 
 #define SUN4I_WAIT_REG 0x18
 
@@ -130,6 +135,13 @@ static inline void sun4i_spi_fill_fifo(struct sun4i_spi 
*sspi, int len)
}
 }
 
+static bool sun4i_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   return tfr-len = SUN4I_FIFO_DEPTH;
+}
+
 static void sun4i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(spi-master);
@@ -169,14 +181,11 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
  struct spi_transfer *tfr)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(master);
+   struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
unsigned int mclk_rate, div, timeout;
unsigned int tx_len = 0;
+   u32 reg, trigger = 0;
int ret = 0;
-   u32 reg;
-
-   /* We don't support transfer larger than the FIFO */
-   if (tfr-len  SUN4I_FIFO_DEPTH)
-   return -EINVAL;
 
reinit_completion(sspi-done);
sspi-tx_buf = tfr-tx_buf;
@@ -186,7 +195,6 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
/* Clear pending interrupts */
sun4i_spi_write(sspi, SUN4I_INT_STA_REG, ~0);
 
-
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
 
/* Reset FIFOs */
@@ -269,12 +277,65 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
sun4i_spi_write(sspi, SUN4I_BURST_CNT_REG, SUN4I_BURST_CNT(tfr-len));
sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
-   /* Fill the TX FIFO */
-   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
-
/* Enable the interrupts */
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
 
+   if (sun4i_spi_can_dma(master, spi, tfr)) {
+   dev_dbg(sspi-master-dev, Using DMA mode for transfer\n);
+
+   if (sspi-tx_buf) {
+   desc_tx = dmaengine_prep_slave_sg(master-dma_tx,
+   tfr-tx_sg.sgl, tfr-tx_sg.nents,
+   DMA_TO_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!desc_tx) {
+   dev_err(sspi-master-dev,
+   Couldn't prepare dma slave\n);
+   return -EIO;
+   }
+
+   trigger |= SUN4I_DMA_CTL_TF_NOT_FULL;
+
+   dmaengine_submit(desc_tx);
+   dma_async_issue_pending(master-dma_tx);
+
+   }
+
+   if (sspi-rx_buf) {
+   desc_rx = dmaengine_prep_slave_sg(master-dma_rx,
+   tfr-rx_sg.sgl, tfr-rx_sg.nents,
+   DMA_FROM_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!desc_rx) {
+   dev_err(sspi-master-dev,
+   Couldn't prepare dma slave\n);
+   return -EIO;
+   }
+
+   trigger |= SUN4I_DMA_CTL_RF_READY;
+
+   dmaengine_submit(desc_rx);
+   dma_async_issue_pending(master-dma_rx);
+   }
+
+   /* Enable Dedicated DMA requests */
+   reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
+   reg |= SUN4I_CTL_DMAMC_DEDICATED

Re: [linux-sunxi] A10s Olinuxino mainline SPI

[Emilio López]

Hi,

El 24/03/15 a las 09:34, Michal Suchanek escibió:

6) I have no idea how to bind spidev (in DT?) even if spi worked



You need to declare your device, like with a properly supported device,
except your device's driver will be a spidev. See below for an example patch
from when I tested DMA on A10S


Unfortunately, spidev has no DT binding example I could find.

I got a DT node but cannot open it with my test program. It's
definitely a progress, though.

Thanks

Michal

https://github.com/hramrach/linux-sunxi/commit/18cf6cbbb63601fac50815046e002dfd8fe3a60c
https://github.com/hramrach/linux-sunxi/commit/4ccb40c2521933a737eb82b85019284ed7afb2ed


spidev is not a supported compatible

http://lxr.free-electrons.com/source/drivers/spi/spidev.c#L692

Have a second look at my example from earlier. You'll probably want to 
add your own compatible to the driver (unless you want to use a 
dh2228fv, that is).


Cheers,

Emilio

--
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] A10s Olinuxino mainline SPI

[Emilio López]

Hi,

El 23/03/15 a las 11:19, Michal Suchanek escibió:

Hello,

I tried to load the spidev driver with the 3.4 kernel and it did ..  nothing.

So I upgraded to linux 4.0rc4 and tried to convince it to boot on the
a10s olinuxino.

Problems

(...)

5) did not manage to get SPI working. I patched the DT with some
random values but the driver complains that there is unsupported
function

https://github.com/hramrach/linux-sunxi/commit/fba83a07ce3261b77f5cd3fac43f78adee4b33dd


The pins you're using, PB14-PB17, don't make sense - they're not SPI 
pins. Are you sure you didn't mean PB11-PB14 (CS0/CLK/MISO/MOSI, 
respectively)? Have a look at the User Manual as a reference:


http://dl.linux-sunxi.org/A10s/A10s%20User%20Manual%20V1.30.pdf


6) I have no idea how to bind spidev (in DT?) even if spi worked


You need to declare your device, like with a properly supported device, 
except your device's driver will be a spidev. See below for an example 
patch from when I tested DMA on A10S



---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 12 
 arch/arm/boot/dts/sun5i-a10s.dtsi|  7 +++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts

index ea9519d..3f19e57 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -68,6 +68,18 @@
status = okay;
};

+   spi2: spi@01c17000 {
+   pinctrl-names = default;
+   pinctrl-0 = spi2_pins_a;
+   status = okay;
+
+   dac0: dh2228@2 {
+   compatible = rohm,dh2228fv;
+   reg = 2;
+   spi-max-frequency = 10;
+   };
+   };
+
pinctrl@01c20800 {
mmc0_cd_pin_olinuxino_micro: mmc0_cd_pin@0 {
allwinner,pins = PG1;
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi

index 2ee786a..1404a55 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -506,6 +506,13 @@
allwinner,drive = 2;
allwinner,pull = 0;
};
+
+   spi2_pins_a: spi2@0 {
+   allwinner,pins = PB11, PB12, PB13, PB14;
+   allwinner,function = spi2;
+   allwinner,drive = 0;
+   allwinner,pull = 0;
+   };
};

timer@01c20c00 {

--
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] Improve Allwinner SoCs support on mainline Linux

[Emilio López]

Hi :)

El 10/02/15 a las 01:15, Saket Sinha escibió:

Hi,

I am interested in Improving Allwinner SoCs support on mainline
Linux  as a part of GSOC-2015.

Last year a similar project was taken by Emilio -
http://www.google-melange.com/gsoc/project/details/google/gsoc2014/emilio/5673385510043648
.

As updated on linux-sunxi wiki here,
http://linux-sunxi.org/Linux_mainlining_effort , there are a lot of
unfinished tasks still.

I am not very sure who actually should I contact regarding this project,
  so putting this question here.


linux-sunxi has never applied to be a GSoC mentoring organization in the 
past, but that could be discussed if there's a will. It'll need to be 
done quickly though, as we're currently in the org. application period.


Last year I proposed my project to the Linux Foundation, which was a 
participating org, and got to work on it via them. Maxime, part of the 
sunxi community, was my mentor. For mainline kernel work, LF is a good 
fit for an organization.



If I can be guided about the necessary TODOs that should be taken as the
part of this project, the mentors and guides I should be reaching out
to, I would be grateful.


I don't know if you have any experience collaborating on mainline Linux 
or doing kernel development. If you're new to it, I'd suggest taking a 
look at the edyptula challenge[1] so you can get to learn the basics - 
how to build Linux, make a patch, send it to the corresponding lists, etc.


To work on a project involving sunxi you'll also need sunxi hardware - 
and at the same time, that'll limit what you can work on, as not all 
devices exist on all SoCs and/or boards - bear that in mind when 
choosing a project.


If you want to talk more about this and maybe bounce off some ideas, you 
are more than welcome to reach out to us on IRC - we're on #linux-sunxi 
on freenode.


Cheers!

Emilio

[1] http://eudyptula-challenge.org/

--
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 v4] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

[Emilio López]

Hi,

El 01/02/15 a las 07:03, Priit Laes escibió:

On Sat, 2015-01-31 at 19:58 -0300, Emilio López wrote:

This patch adds support for the DMA engine present on Allwinner A10,
A13, A10S and A20 SoCs. This engine has two kinds of channels:
normal and dedicated. The main difference is in the mode of
operation; while a single normal channel may be operating at any
given time, dedicated channels may operate simultaneously provided
there is no overlap of source or destination.

Hardware documentation can be found on A10 User Manual (section 12),
A13 User Manual (section 14) and A20 User Manual (section 1.12)

Signed-off-by: Emilio López emi...@elopez.com.ar

(...)

diff --git a/Documentation/devicetree/bindings/dma/sun4i-dma.txt 
b/Documentation/devicetree/bindings/dma/sun4i-dma.txt
new file mode 100644
index 000..f1634a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sun4i-dma.txt
@@ -0,0 +1,46 @@
+Allwinner A10 DMA Controller


Don't you want to mention A13, A10S and A20 too?


What if a new SoC shows up with this controller? :) I'd rather give a
single name to the IP, like we do with the compatible strings.

(...)


diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 2022b54..675b98f 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,3 +50,4 @@ obj-y += xilinx/
 obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
 obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
+obj-$(CONFIG_SUN4I_DMA) += sun4i-dma.o
diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c new file mode 
100644
index 000..a025405
--- /dev/null
+++ b/drivers/dma/sun4i-dma.c
@@ -0,0 +1,1264 @@
+/*
+ * Copyright (C) 2014 Emilio López


2014, 2015 ?


I guess so :)

(...)

+static int convert_burst(u32 maxburst)
+{
+   if (maxburst  8)
+   return -EINVAL;

Would it make sense to add check for maxburst = 0 too?


I can add one if you feel it's needed.


+
+   /* 1 - 0, 4 - 1, 8 - 2 */
+   return (maxburst  2);
+}
+
+static int convert_buswidth(enum dma_slave_buswidth addr_width)
+{
+   if (addr_width  DMA_SLAVE_BUSWIDTH_4_BYTES)
+   return -EINVAL;
+
+   /* 8 (1 byte) - 0, 16 (2 bytes) - 1, 32 (4 bytes) - 2 */
+   return (addr_width  1);
+}
+
+static int choose_optimal_buswidth(dma_addr_t addr)
+{
+   /* On 32 bit aligned addresses, we can use a 32 bit bus width */
+   if (addr % 4 == 0)


Not sure, whether it makes sense to optimize or not, but this can be
calculated like this:

(addr  (4 - 1)) == 0


It looks like IS_ALIGNED() in linux/kernel.h is what we need here.


+static struct sun4i_dma_promise *
+generate_ddma_promise(struct dma_chan *chan, dma_addr_t src, dma_addr_t dest,
+   size_t len, 
struct dma_slave_config *sconfig)
+{
+   struct sun4i_dma_promise *promise;
+   int ret;
+
+   promise = kzalloc(sizeof(*promise), GFP_NOWAIT);
+   if (!promise)
+   return NULL;
+
+   promise-src = src;
+   promise-dst = dest;
+   promise-len = len;
+


No timing parameters or this is just a quirk required for SPI?


They're filled together with the endpoints, in case we need different
ones for some other device. There's a big comment block explaining the
situation on top of their assignment.


   promise-cfg = DDMA_CFG_LOADING |
DDMA_CFG_BYTE_COUNT_MODE_REMAIN;
+
+   /* Source burst */
+   ret = convert_burst(sconfig-src_maxburst);
+   if (IS_ERR_VALUE(ret))
+   goto fail;
+   promise-cfg |= DDMA_CFG_SRC_BURST_LENGTH(ret);
+


Thanks for reviewing this! :)

Emilio

--
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 v4] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

[Emilio López]

Hi,

El 03/02/15 a las 16:39, jonsm...@gmail.com escibió:

Did you fix multiple simultaneous DMA transfers in this? And easy test
is to start jack audio. Jack will start simultaneous cyclic transfers
on both the ALSA input and output. Since cyclic transfers never end,
multiple simultaneous transfers has to work. Last time I tried it I
got an immediate GPF when the second cyclic transfer was started.


I didn't get a chance to test with jack yet, but I don't see any reason 
why two cyclic transfers wouldn't work, assuming they're on different 
vchans.


Were you by any chance booting off of NAND by the way? That caused a GPF 
because the bootloader left the hardware in a dirty state, but it should 
be fixed now.


Cheers,

Emilio

--
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] Fwd: Link problem

[Emilio López]

Hi,

El 03/02/15 a las 17:38, FREDERIC MARTIN escibió:



On this page some links did not work:
http://linux-sunxi.org/A10


These:

  * A10 Supported DDR list
http://service.awbase.com:8000/faq/index.php/A10_DDR%E5%88%97%E8%A1%A8
  * A10 Supported NAND list
http://service.awbase.com:8000/faq/index.php/A10_NAND%E5%88%97%E8%A1%A8
  * A10 Supported LCD modules list

http://service.awbase.com:8000/faq/index.php/A10_LCD%E6%A8%A1%E7%BB%84%E5%88%97%E8%A1%A8
  * A10 Supported Capacitive touch sensor list

http://service.awbase.com:8000/faq/index.php/C-TOUCH%E6%A8%A1%E7%BB%84%E6%94%AF%E6%8C%81%E5%88%97%E8%A1%A8

Can you help me please?


These are links to external sites, you could try to see if they are 
still available via something like Google cache or the Internet Archive 
(archive.org)


Cheers,

Emilio

--
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] UART: Configure Custom Speed?

[Emilio López]

Hi,

El 31/01/15 a las 20:25, bruce bushby escibió:

Hi

I'm hoping a list member could offer some advice setting a UART with a
custom speed.

I was hoping to calculate the required divisor and use setserial to set
my speed (10), however both Python's pySerial and the setserial
command cause the following error:

[root@A20-SOM ~]# setserial /dev/ttyS1 spd_cust
[  697.027655] dw-apb-uart 1c29800.serial: setserial sets custom speed
on ttyS1. This is deprecated.
[root@A20-SOM ~]#


Deprecated in favor of?


It seems this has been deprecated for a couple of years now judging by 
Google results. Have you tried using stty?


On a 115200 terminal, the following makes it stop working

stty -F /dev/ttyS0 9600

And reattaching with 9600 makes it work again


I had a look in the dts:

 uart6: serial@01c29800 {
 compatible = snps,dw-apb-uart;
 reg = 0x01c29800 0x400;
 interrupts = 0 19 4;
 reg-shift = 2;
 reg-io-width = 4;
 clocks = apb1_gates 22;
 status = disabled;
 };


...however I don't understand the relationship between 22  and
  apb1_gates


It means that the gate feeding the UART hardware is the 22nd bit on the 
register where the gates are.



How do I set the divisor and/or configure my custom speed of 10 for
my UART6?


I've never heard of anyone using 10, are you sure you can't use 
115200 or one of the other standard speeds?


Cheers,

Emilio

--
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] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

[Emilio López]

This patch adds support for the DMA engine present on Allwinner A10,
A13, A10S and A20 SoCs. This engine has two kinds of channels: normal
and dedicated. The main difference is in the mode of operation;
while a single normal channel may be operating at any given time,
dedicated channels may operate simultaneously provided there is no
overlap of source or destination.

Hardware documentation can be found on A10 User Manual (section 12), A13
User Manual (section 14) and A20 User Manual (section 1.12)

Signed-off-by: Emilio López emi...@elopez.com.ar
---

(Partial?) changes from v3:
 * Drop threaded IRQ to get lower latency
 * Drop chancnt
 * Fix crash on first use when using a DMA-aware bootloader (eg., one
   that supports NAND)

Changes from v2:
 * Faster memcpy
 * Quicker cyclic transfers
 * Address some stylistic and locking comments from Maxime
 * probably some more stuff I'm forgetting

Changes from v1:
 * address comments from Chen-Yu and Maxime
 * fix issue converting bus width
 * switch to using a threaded IRQ instead of a tasklet on
   recommendation from Maxime
 * fix issue setting magic timing parameter for SPI transfers
 * fix an issue with list handling reported by the kbuild 0-DAY robot (thanks!)
 * drop a lot of unused #define
 * probably some more stuff I'm forgetting

 .../devicetree/bindings/dma/sun4i-dma.txt  |   46 +
 drivers/dma/Kconfig|   11 +
 drivers/dma/Makefile   |1 +
 drivers/dma/sun4i-dma.c| 1264 
 4 files changed, 1322 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/sun4i-dma.txt
 create mode 100644 drivers/dma/sun4i-dma.c

diff --git a/Documentation/devicetree/bindings/dma/sun4i-dma.txt 
b/Documentation/devicetree/bindings/dma/sun4i-dma.txt
new file mode 100644
index 000..f1634a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sun4i-dma.txt
@@ -0,0 +1,46 @@
+Allwinner A10 DMA Controller
+
+This driver follows the generic DMA bindings defined in dma.txt.
+
+Required properties:
+
+- compatible:  Must be allwinner,sun4i-a10-dma
+- reg: Should contain the registers base address and length
+- interrupts:  Should contain a reference to the interrupt used by this device
+- clocks:  Should contain a reference to the parent AHB clock
+- #dma-cells : Should be 2, first cell denoting normal or dedicated dma,
+   second cell holding the request line number.
+
+Example:
+   dma: dma-controller@01c02000 {
+   compatible = allwinner,sun4i-a10-dma;
+   reg = 0x01c02000 0x1000;
+   interrupts = 27;
+   clocks = ahb_gates 6;
+   #dma-cells = 2;
+   };
+
+Clients:
+
+DMA clients connected to the Allwinner A10 DMA controller must use the
+format described in the dma.txt file, using a three-cell specifier for
+each channel: a phandle plus two integer cells.
+The three cells in order are:
+
+1. A phandle pointing to the DMA controller.
+2. Whether it is using normal (0) or dedicated (1) channels
+3. The port ID as specified in the datasheet
+
+Example:
+   spi2: spi@01c17000 {
+   compatible = allwinner,sun4i-a10-spi;
+   reg = 0x01c17000 0x1000;
+   interrupts = 0 12 4;
+   clocks = ahb_gates 22, spi2_clk;
+   clock-names = ahb, mod;
+   dmas = dma 1 29, dma 1 28;
+   dma-names = rx, tx;
+   status = disabled;
+   #address-cells = 1;
+   #size-cells = 0;
+   };
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index f2b2c4e..a15374e 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -416,6 +416,17 @@ config NBPFAXI_DMA
help
  Support for Type-AXI NBPF DMA IPs from Renesas
 
+config SUN4I_DMA
+   tristate Allwinner A10 DMA support
+   depends on (MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || (COMPILE_TEST  
OF  ARM))
+   default (MACH_SUN4I || MACH_SUN5I || MACH_SUN7I)
+   select DMA_ENGINE
+   select DMA_OF
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for the DMA controller present in the sun4i,
+ sun5i and sun7i Allwinner ARM SoCs.
+
 config DMA_ENGINE
bool
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 2022b54..675b98f 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,3 +50,4 @@ obj-y += xilinx/
 obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
 obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
+obj-$(CONFIG_SUN4I_DMA) += sun4i-dma.o
diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
new file mode 100644
index 000..a025405
--- /dev/null
+++ b/drivers/dma/sun4i-dma.c
@@ -0,0 +1,1264 @@
+/*
+ * Copyright (C) 2014 Emilio López
+ * Emilio López emi...@elopez.com.ar
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under

[linux-sunxi] [PATCH v4] DMAEngine support for sun4i, sun5i sun7i

[Emilio López]

Hi everyone,

As part of Google Summer of Code 2014, I've worked on implementing
DMA support for the earlier Allwinner platforms. This fourth round of
patches is the result of said effort.

The previous versions of this set had some SPI patches, but I've
chosen to send them separately this time for the sake of clarity.
There were some DT patches as well, adding the corresponding nodes,
but those have been merged some time ago so I'm not including them
either. This leaves us with a single patch, which contains the actual
driver.

All comments, reviews and tests are welcome!

Thanks!

Emilio

Emilio López (1):
  dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

 .../devicetree/bindings/dma/sun4i-dma.txt  |   46 +
 drivers/dma/Kconfig|   11 +
 drivers/dma/Makefile   |1 +
 drivers/dma/sun4i-dma.c| 1264 
 4 files changed, 1322 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/sun4i-dma.txt
 create mode 100644 drivers/dma/sun4i-dma.c

-- 
2.2.2

-- 
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] [PATCH] sunxi watchdog: setting the system reset function correctly

[Emilio López]

Hi Tobias,

El 23/12/14 a las 10:28, Tobias Andresen escibió:

---
  drivers/watchdog/sunxi_wdt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/sunxi_wdt.c b/drivers/watchdog/sunxi_wdt.c
index b62301e..00de94b 100644
--- a/drivers/watchdog/sunxi_wdt.c
+++ b/drivers/watchdog/sunxi_wdt.c
@@ -184,7 +184,7 @@ static int sunxi_wdt_start(struct watchdog_device *wdt_dev)
/* Set system reset function */
reg = readl(wdt_base + regs-wdt_cfg);
reg = ~(regs-wdt_reset_mask);
-   reg |= ~(regs-wdt_reset_val);
+   reg |= (regs-wdt_reset_val);


You can drop the ()'s too, they're not needed now.


writel(reg, wdt_base + regs-wdt_cfg);

/* Enable watchdog */



What tree is this for? If this is a patch for mainline, please include 
your signoff and Cc the relevant maintainers and mailing lists[1]; in 
this case at least Maxime, Wim, linux-arm-kernel and linux-watchdog.


Cheers!

Emilio

[1] ./scripts/get_maintainer.pl on the kernel tree can help you figure 
out who to send it to.


--
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] [PATCH] sunxi watchdog: setting the system reset function correctly

[Emilio López]

Hi,

El 23/12/14 a las 18:05, tandresen1...@gmail.com escibió:

Hi,

thanks for your response. I will fix the remaining issues.

@Emilio: Do you have any news regarding audio for me?


Nothing really interesting to report; I've been improving the DMA driver 
a bit and I'll get back to the audio side after the holidays. Out of 
curiosity, what's your use case for audio?


Cheers!

Emilio

--
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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot

[Emilio López]

Hi Hans,

El 20/12/14 a las 15:27, Hans de Goede escibió:

Hi All,

There are 3 topics which I would like to cover in this mail:

1) Switching over to upstream u-boot for the linux-sunxi project

(...)

Here are some example instructions on how to build upstream u-boot for
the Cubietruck:

git clone git://git.denx.de/u-boot.git
cd u-boot
make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
# If you want to use an upstream kernel the next steps can be skipped (*)
make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
# skip to here if you're using an upstream kernel
make -j4 CROSS_COMPILE=arm-linux-gnu-

And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
usual.

(...)

So I thought it'd be a good idea to move over to mainline uboot, but it 
doesn't seem to be working at all on Cubietruck. When applying power to 
the board, all I get is


U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

...ad infinitum.

The hardware itself is fine, the NAND bootloader runs OK and I used the 
board with an old uboot-sunxi some days back. Any ideas on what may be 
going on?


Cheers!

Emilio

--
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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot

[Emilio López]

Hi,

El 21/12/14 a las 17:28, Siarhei Siamashka escibió:

On Sun, 21 Dec 2014 17:00:46 -0300
Emilio López emi...@elopez.com.ar wrote:


Hi Hans,

El 20/12/14 a las 15:27, Hans de Goede escibió:

Hi All,

There are 3 topics which I would like to cover in this mail:

1) Switching over to upstream u-boot for the linux-sunxi project

(...)

Here are some example instructions on how to build upstream u-boot for
the Cubietruck:

git clone git://git.denx.de/u-boot.git
cd u-boot
make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig
# If you want to use an upstream kernel the next steps can be skipped (*)
make -j4 CROSS_COMPILE=arm-linux-gnu- menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
make -j4 CROSS_COMPILE=arm-linux-gnu- spl/menuconfig
#  select ARM architecture - Enable workarounds for booting old
kernels
#  exit  save
# skip to here if you're using an upstream kernel
make -j4 CROSS_COMPILE=arm-linux-gnu-

And now you will have a u-boot-sunxi-with-spl.bin to dd to your sdcard as
usual.

(...)

So I thought it'd be a good idea to move over to mainline uboot, but it
doesn't seem to be working at all on Cubietruck. When applying power to
the board, all I get is

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

U-Boot SPL 2015.01-rc3-00163-gd8bec60 (Dec 21 2014 - 16:43:41)
DRAM:Timeout initialising DRAM

resetting ...

...ad infinitum.

The hardware itself is fine, the NAND bootloader runs OK and I used the
board with an old uboot-sunxi some days back. Any ideas on what may be
going on?


Thanks for reporting this.

First of all, please ensure that there is no obvious misconfiguration.
For example, whether you have really configured u-boot for Cubietruck.


Sorry for the noise, I messed up and was using the Cubieboard config 
instead of the Cubietruck one .


Seems to work fine other than this warning:

Error: dwmac.1c5 address ab:cd:ef:ab:cd:ef illegal value

Cheers!

Emilio

--
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] adding dram to u-boot-sunxi

[Emilio López]

El 15/09/14 a las 20:13, Julian Calaby escibió:

Hi Tim,

On Tue, Sep 16, 2014 at 6:52 AM, Tim Tisdall tisd...@gmail.com wrote:

At http://linux-sunxi.org/U-Boot#DRAM it says copy an existing file to a
filename relevant for your device and edit the entries manually but all of
those files also say this file is generated, don't edit it yourself.
Which do I believe?


The wiki.

As far as I'm aware, there's no tool to generate those automatically.
I believe that note is there for historical reasons or to discourage
people from messing with the values.


`fexc` in sunxi-tools (the tool behind bin2fex/fex2bin aliases) can do 
it. Note that for it to work, the fex file needs to have valid values.


Usage: ./fexc [-vq] [-I infmt] [-O outfmt] [input [output]]

infmt:  fex, bin  (default:fex)
outfmt: fex, bin, uboot  (default:bin)

For example

$ ./fexc -I fex -O uboot  ../sunxi-boards/sys_config/a10/mele_a1000.fex
/* this file is generated, don't edit it yourself */

#include common.h
#include asm/arch/dram.h

static struct dram_para dram_para = {
.clock = 360,
.type = 3,
.rank_num = 1,
.density = 2048,
.io_width = 16,
.bus_width = 32,
.cas = 6,
.zq = 123,
.odt_en = 0,
.size = 512,
.tpr0 = 0x30926692,
.tpr1 = 0x1090,
.tpr2 = 0x1a0c8,
.tpr3 = 0,
.tpr4 = 0,
.tpr5 = 0,
.emr1 = 0,
.emr2 = 0,
.emr3 = 0,
};

unsigned long sunxi_dram_init(void)
{
return dramc_init(dram_para);
}

Cheers,

Emilio

--
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] adding dram to u-boot-sunxi

[Emilio López]

El 15/09/14 a las 20:29, Julian Calaby escibió:

Hi Emilio,

On Tue, Sep 16, 2014 at 9:22 AM, Emilio López t...@linux-sunxi.org wrote:

(...)


`fexc` in sunxi-tools (the tool behind bin2fex/fex2bin aliases) can do it.
Note that for it to work, the fex file needs to have valid values.


Ah, thanks for that! The only problem is that I believe, in general,
fex files don't have valid values.


I believe most if not all of the ones on sunxi-boards have been filled 
in with the relevant information after using meminfo, as Tim points out.


Cheers,

Emilio

--
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] Report on recently added audio support

[Emilio López]

Hi!

El 06/09/14 a las 11:58, B.R. Oake escibió:

Hi,

I'm new to this group. I want to use analogue audio with a mainline kernel
on my Olinuxino A20, so I've been trying out the recent work of Emilio
López, Jon Smirl and others to add mainline audio support, and I'd like to
report my findings.

After applying the relevant changes from the sunxi-codec-v0 branch of
Emilio's repository https://bitbucket.org/emiliolopez/linux.git, I've
found that sound files play very well, except 16-bit mono. Although the
problem is not very noticeable at high sample rates like 44100Hz, at lower
rates like 8000Hz there is a very distinctive distortion in the sound. I
found I could closely simulate on a normal system the sound of this
distortion by zeroing out every alternate sample in a stream, so it seems
there is a processing error somewhere which is causing alternate samples to
be lost; perhaps some sort of 16/32-bit mismatch.

I looked for differences between Emilio's sound/soc/sunxi/sunxi-codec.c and
the equivalent in the sunxi-3.4 branch, which doesn't exhibit this
distortion, and I noticed that Emilio always sets TX_FIFO_MODE (i.e. bit 24
of register AC_DAC_FIFOC) to 0, whereas sunxi-3.4 appears to have it always
set to 1. According to Allwinner's A20 user manual (p.176 of
https://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf),
this bit controls what alignment the DAC expects the data in its TXDATA
register to have. I tried changing it to 1 and found this resolved the
problem for 16-bit streams. We wouldn't want to change it for 24-bit
streams though, since a setting of 1 in that case is Reserved and I've
found that 24-bit streams just play as white noise with that setting.

It would be good to understand why the 0 setting produces the effect it
does. I think Chen-Yu Tsai was onto something when he noticed in
https://www.mail-archive.com/linux-sunxi%40googlegroups.com/msg06152.html:


However, there is something puzzling about the FIFO modes. The manual
says that with TX FIFO modes 00/10, 16 bit audio should take the most
significant 2 bytes of the FIFO as the audio sample to convert. However
the DMA engine looks like it's writing the least significant 2 bytes.
I know the code as it is now works, but still I think we should get
this straightened out.


I'm new to most of this, so my mental model of the hardware and kernel may
well be wrong, but I think the audio stream is fed into the DAC through its
32-bit TXDATA register, from where it proceeds to the 24-bit FIFO within
the DAC, according to the data alignment rule specified in TX_FIFO_MODE.
And presumably the DMA engine is copying each 16-bit sample to the first
two memory-mapped bytes of the TXDATA register in the memory map, namely
locations 0x01c22c0c and 0x01c22c0d, which due to little-endianness are the
two least significant bytes of the register, i.e. bits [15:0], so
TX_FIFO_MODE needs to be 1. It's puzzling why TX_FIFO_MODE=0 produces any
sound at all for 16-bit streams, since it would take bits [31:16] from
TXDATA into the FIFO, and surely those bits would always be empty. Perhaps
the DMA engine always copies 4 bytes at a time? I'm just guessing.

Anyway, below is a patch that allows me to play undistorted 16-bit mono
without messing up 24-bit audio. It may not be the right solution but it
seems to work.

Thank you all for your work on linux-sunxi; I appreciate it very much.

Best wishes,
B.R. Oake.

P.S. My exact setup is as follows:

Hardware: Olimex Olinuxino-A20-Micro Revision F
OS: Debian Jessie
Kernel: Linux 3.16-1~exp1 armmp from Debian experimental repository, with
the following patches from Emilio's git repository:

9ee1da1 Audio codec support
ed103a8 Audio codec device tree
325ed71 PLL2 support
a08d5d8 PLL2 device tree
2808f1f Codec-clk support
f536e9a Codec-clk device tree
5a78102 DMA support
0a80f86 DMA device tree
628cd59 Hack to avoid duplicate widgets

Also the following patch, but for sun7i-a20-olinuxino-micro.dts rather than
sun7i-a20-cubietruck.dts:
e8d3803 Enable codec for Cubietruck

-
Patch to remove distortion on 16-bit mono

diff -Nur a/sound/soc/sunxi/sunxi-codec.c b/sound/soc/sunxi/sunxi-codec.c
--- a/sound/soc/sunxi/sunxi-codec.c 2014-09-04 23:16:06.921872000 +0100
+++ b/sound/soc/sunxi/sunxi-codec.c 2014-09-04 23:18:17.129872062 +0100
@@ -215,9 +215,6 @@
regmap_update_bits(priv-regmap, SUNXI_DAC_FIFOC, 0x1  
SUNXI_DAC_FIFOC_FIR_VERSION, 0x1  SUNXI_DAC_FIFOC_FIR_VERSION);
}

-   /* set TX FIFO MODE - 0 works for both 16 and 24 bits */
-   regmap_update_bits(priv-regmap, SUNXI_DAC_FIFOC, 0x1  
SUNXI_DAC_FIFOC_TX_FIFO_MODE, 0x0  SUNXI_DAC_FIFOC_TX_FIFO_MODE);
-
/* send last sample when DAC FIFO under run */
regmap_update_bits(priv-regmap, SUNXI_DAC_FIFOC, 0x1  
SUNXI_DAC_FIFOC_SEND_LASAT, 0x0  SUNXI_DAC_FIFOC_SEND_LASAT);
} else

[linux-sunxi] Audio codec driver status

[Emilio López]

Hi everyone,

Given that the firm pencils down date for GSoC 2014 is today, I need
to give the project a bit of formal closure. I will keep on working on
this (as well as DMA and related clocking), but it won't be as part of
GSoC any longer. For this reason, I've pushed a branch with the
current status of the codec driver earlier today, for everyone to
check out, try and comment on. It's named 'sunxi-codec-v0' and you can
find it on my usual git repo[0]. It comes with some caveats, though:

* Most of the testing I've done has been on sun7i, on Cubietruck in
particular, so if you see anything broken on the other platforms do
let me know
* With the move to DAPM, the codec is not nicely configured on boot,
so before playing something, you'll want to open alsamixer and turn up
the volume, set it to direct playback, or mux the channels
appropriately if you want to use the mixer.
* The capture routes haven't received DAPM changes yet (or much
testing for what it's worth). Do report any issues you hit.
* The A10 rev A volume control seems to be inverted from what I can
see on the Allwinner code, but I don't have a rev A to confirm. Their
code does not seem to worry much about it though.
* There's some issue between ASoC and this driver that seemingly
causes DAIs to be processed twice, so we end up with two pairs of
stream widgets, and that causes breakage. The branch includes a very
ugly hack to avoid the duplication, but an acceptable solution still
needs to be found. Mark had a couple of suggestions on what to try,
but I haven't had much luck yet.

Now that I've finished with my exams I'll have a bit more of time to
work on this - I'll keep on iterating over the driver until it's in a
better shape to consider it for merging. Hopefully I'll get some more
reviews on the DMA driver from the maintainers as well. I'll be
posting a final GSoC report/wrap-up to the lists later this week for
those interested.

Cheers!

Emilio

[0]: http://git.elopez.com.ar/linux/commits/branch/sunxi-codec-v0

-- 
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] [PATCH 2/7] meminfo: fix up printing

[Emilio López]

Hi Luc,

El 18/08/14 a las 03:34, Luc Verhaegen escibió:

Now we write out a dram file for u-boot directly.

Signed-off-by: Luc Verhaegen l...@skynet.be
---
  meminfo.c |   59 ---
  1 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/meminfo.c b/meminfo.c
index 6d87897..f926380 100644
--- a/meminfo.c
+++ b/meminfo.c
@@ -213,6 +213,44 @@ volatile void *map_physical_memory(uint32_t addr, size_t 
len)
  return mem;
  }

+/*
+ * Print a dram.c that can be stuck immediately into u-boot.
+ */
+void
+dram_para_print(struct dram_para *dram_para)
+{
+   printf(/* this file is generated, don't edit it yourself */\n);
+   printf(\n);
+   printf(#include \common.h\\n);
+   printf(#include asm/arch/dram.h\n);
+   printf(\n);
+   printf(static struct dram_para dram_para = {\n);
+   printf(\t.clock = %d,\n, dram_para-clock);
+   printf(\t.type = %d,\n, dram_para-type);
+   printf(\t.rank_num = %d,\n, dram_para-rank_num);
+   printf(\t.density = %d,\n, dram_para-density);
+   printf(\t.io_width = %d,\n, dram_para-io_width);
+   printf(\t.bus_width = %d,\n, dram_para-bus_width);
+   printf(\t.cas = %d,\n, dram_para-cas);
+   printf(\t.zq = 0x%02x,\n, dram_para-zq);
+   printf(\t.odt_en = %d,\n, dram_para-odt_en);
+   printf(\t.size = FIXME, /* in MiB */\n);
+   printf(\t.tpr0 = 0x%08x,\n, dram_para-tpr0);
+   printf(\t.tpr1 = 0x%04x,\n, dram_para-tpr1);
+   printf(\t.tpr2 = 0x%04x,\n, dram_para-tpr2);
+   printf(\t.tpr3 = 0x%02x,\n, dram_para-tpr3);
+   printf(\t.tpr4 = 0x%02x,\n, dram_para-tpr4);
+   printf(\t.tpr5 = 0x%02x,\n, dram_para-tpr5);
+   printf(\t.emr1 = 0x%02x,\n, dram_para-emr1);
+   printf(\t.emr2 = 0x%02x,\n, dram_para-emr2);
+   printf(\t.emr3 = 0x%02x,\n, dram_para-emr3);
+   printf(};\n);
+   printf(\n);
+   printf(unsigned long sunxi_dram_init(void)\n);
+   printf({\n);
+   printf(\treturn dramc_init(dram_para);\n);
+   printf(}\n);
+}

  int main(int argc, char **argv)
  {
@@ -265,25 +303,8 @@ int main(int argc, char **argv)
   (((ccm-pll5_cfg  CCM_PLL5_FACTOR_M)  CCM_PLL5_FACTOR_M_SIZE) + 1)
  );

-/* Print dram_para struct */
-printf(dram_clk  = %d\n, p.clock);
-printf(dram_type = %d\n, p.type);
-printf(dram_rank_num = %d\n, p.rank_num);
-printf(dram_chip_density = %d\n, p.density);
-printf(dram_io_width = %d\n, p.io_width);
-printf(dram_bus_width= %d\n, p.bus_width);
-printf(dram_cas  = %d\n, p.cas);
-printf(dram_zq   = 0x%x\n, p.zq);
-printf(dram_odt_en   = %d\n, p.odt_en);
-//printf(dram_size = %d\n, p.size);
-printf(dram_tpr0 = 0x%x\n, p.tpr0);
-printf(dram_tpr1 = 0x%x\n, p.tpr1);
-printf(dram_tpr2 = 0x%x\n, p.tpr2);
-printf(dram_tpr3 = 0x%x\n, p.tpr3);
-printf(dram_emr1 = 0x%x\n, p.emr1);
-printf(dram_emr2 = 0x%x\n, p.emr2);
-printf(dram_emr3 = 0x%x\n, p.emr3);


Can you preserve the old way of printing with a --flag or something? 
This matches the fex format and can be copied/pasted to it to preserve 
the information. I believe it's also used when building livesuit images 
with the BSP, but I'm not fully sure on that one.



-
+   dram_para_print(p);
+


Nitpick, maybe it's just my MUA but the whitespace looks off above.

Cheers!

Emilio

--
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] [PATCH 5/7] meminfo: various cleanups

[Emilio López]

El 18/08/14 a las 03:34, Luc Verhaegen escibió:

No functional changes.

Signed-off-by: Luc Verhaegen l...@skynet.be
---
  meminfo.c |   39 +--
  1 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/meminfo.c b/meminfo.c
index 44d5c78..0b7bfe2 100644
--- a/meminfo.c
+++ b/meminfo.c
@@ -1,29 +1,32 @@
  /*
- * A10-meminfo
- * Dumps DRAM controller settings
+ * Copyright (C) 2012  Floris Bos Floris Bos b...@je-eigen-domein.nl


Copy-paste went wrong? :)

--
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] Generating a clock from the A20

[Emilio López]

El 13/08/14 a las 13:34, jonsm...@gmail.com escibió:

Is there any way to generate a clock on a pin with the A20 other than
the two PWM units? I just need a simple, always on clock.

I need another clock because apparently you can't put I2S into slave
mode as long as MCLKEN (ie MCLK on a pin) is enabled.


There's two external output clocks on the A20, I believe the cubietruck 
uses one to clock the external wifi-bt combo chip.


You could also (ab)use one the SPI clock lines or something like that if 
you really need it.


--
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] GSoC 2014 #2 status report - Improving Allwinner SoC support

[Emilio López]

Hi everyone,

Here's a status update on my GSoC project for these last two weeks; you 
can find the two previous updates on the list archives[0][1]


First of all, I have started to prepare for university exams, so that 
has taken some of the time I was using to work on the project. I have 
not stopped working on this though - you will still see progress and 
receive some more of these emails :)


On the sound side, we now have normal volume 24 bit audio after Chen-Yu 
noticed it was an alignment problem and that we could get around it by 
using S32LE with 24 significant bits. I have also been working on 
rewriting the driver to use DAPM, and I can now manage several parts of 
the codec with it already. If no further obstacles show up, I expect to 
get it completed soon and in shape for a initial submission before the 
end of GSoC.


During this period I also sent some patches for the clock support we 
need for the codec and other audio blocks. I firstly did a RFC[2], as 
the PLL2 is different on the A10 revision A, and we'd need some sort of 
quirk handling for that. After settling for a DT-based handling, I sent 
a refreshed series implementing it[3], which is currently under review. 
This quirk handling is also going to be needed for the codec driver, as 
there's a couple of quirks there as well.


I've also sent an updated version[4] of the DMA engine driver addressing 
the comments I got on v2 and including the performance and cyclic 
improvements I mentioned on the previous report - they say third time's 
the charm, so hopefully I can get a review from the DMA maintainers this 
round :)


You can expect the next status report in about a week's time. There are 
two GSoC weeks remaining until the hard deadline, so that leaves time 
for another weekly report and a wrap-up one.


Cheers!

Emilio

[0] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271150.html

[1] https://groups.google.com/d/msg/linux-sunxi/Jx7HK3yaGVM/BqlZCJED2cMJ
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275676.html
[3] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/277136.html
[4] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/277746.html


--
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] conflict gpio-sunxi with gt811_ts

[Emilio López]

El 24/07/14 a las 08:36, behrooz vosough escibió:

hello
I am using goodix-gt811 ctp 7 inch and i have not problem to use this
module but when i modprobe gpio-sunxi , the interrupt of my ctp disable
1- when gt811_ts is intalled and i modprobe gpio-sunxi ,this message
shown on Putty
the message is :
  6sunxi_gpio driver init ver 1.3
3IRQ handler type mismatch for IRQ 60
3current handler: Goodix-TS


I haven't checked, but I'm pretty sure this is the PIO interrupt. It's 
probably being requested as shared on the GPIO driver and as not shared 
on the Goodix one.


As a workaround probably something like this would work

--- a/drivers/input/touchscreen/gt811_ts.c
+++ b/drivers/input/touchscreen/gt811_ts.c
@@ -1356,7 +1356,7 @@ err_gpio_request_failed:


 #ifdef INT_PORT
-   ret  = request_irq(client-irq, goodix_ts_irq_handler , 
irq_table[ts-int_trigger_type],
+   ret  = request_irq(client-irq, goodix_ts_irq_handler , 
irq_table[ts-int_trigger_type] | IRQF_SHARED,

client-name, ts);
 if (ret != 0)
 {


But on an ideal world, this would need to be rewritten to use the GPIO 
API for the external interrupt instead of an ad-hoc implementation.


Cheers,

Emilio

--
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] GSoC 2014 #1 status report - Improving Allwinner SoC support

[Emilio López]

Hi everyone,

Here's this week's update on my GSoC project; if you missed the first 
issue or you want a refresher of what this is about, you can read it on 
the list archives[0]


A couple of days after the last report, and with the help of Jon Smirl, 
I got the hardware working on mainline Linux, first on only 16 bit 
stereo mode, then mono as well, and later on, also on 24 bit mode. The 
first thing I had to do was rework the cyclic DMA code to make it 
perform decently and avoid underruns. The rest took a bit of playing 
with values and reading the Allwinner documentation. There is one 
unresolved issue with 24 bit audio still - for some reason, the volume 
is really low compared to the same track played on 16 bit. Unfortunately 
the SDK driver doesn't support 24 bit, so it's hard to compare with 
anything else.


Aside from the audio stuff, I worked a bit on the DMA driver, after 
realizing memcpy could be optimized a fair bit. By using proper 
alignment and choosing the best bus width and as big a burst as 
possible, I was able to go from a totally unscientifically measured 
~3MB/s to ~13MB/s on a single thread, single channel, 1000 iterations 
dmatest run with noverify=0. I will be sending a v3 with these new 
changes as well as addressing comments I received in the next few days.


To round up on this week's developments, I also worked on the audio 
clock representation, involving PLL2, the codec clock gate and module 
1 clocks (AC97, SPDIF, IIS) to enable Jon to work on IIS. Patches for 
these clocks will be out in the list soon as well.


You can expect the next status report in about a week's time.

Cheers!

Emilio

[0] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271150.html


--
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: GSoC 2014 #0 status report - Improving Allwinner SoC support

[Emilio López]

Hi,

El 10/07/14 17:39, Maxime Ripard escribió:

Lately, I have also been working on the audio part, now that I have
a working DMA driver. After implementing cyclic DMA transfers and
some clock code, and armed with a Buildroot image with mpg123 and an
OpenBSD release track[5] in mp3 format, I've been trying to get some
sound out of my Cubietruck's headphone jack, but without much
success so far. I have verified my userspace stack and hardware by
running these same binaries on top of the linux-sunxi 3.4 kernel,
and it worked fine. I have since then been dumping relevant
registers with devmem and comparing them, resolving issues as I see
them - hopefully this will yield some audible results.


What have you been working on? A new driver from scratch, tried to
take Allwinner's code and then cleant it up, or used the recently
published driver Jon made?


I've been working on top of Jon's codec patches. Seeing that the last 
series Jon published on his github produces some sound, I got a fresh 
copy of it today, and with some changes on DMAEngine, it's playing nicely.


As cyclic transactions are special (eg, they don't become empty) I 
rewrote the cyclic support Jon had, making it issue subsequent transfers
directly from the interrupt request, and minimizing the number of times 
this needs to be done. If we use the half done interrupt, we can get 
away with one hardware programming per two periods.


It's rather late now and I still need to clean up the code a bit, but 
I'll push a branch with these changes on my repo during the weekend.



Interestingly enough, Allwinner themselves do not seem to be using
cyclic DMA transfers on their driver[6]. I hope this is not a sign
of a hardware bug that's not documented.


So they just implement a cyclic-like behaviour in software?


Yep, they have this code to cycle through the buffer

https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L648

Cheers!

Emilio

--
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] GSoC 2014 #0 status report - Improving Allwinner SoC support

[Emilio López]

Hi everyone,

As some of you may know, I'm currently participating in Google Summer of 
Code under the Linux Foundation, working on a proposal titled Improve 
Allwinner SoCs support on mainline Linux. There is a great quantity of 
devices out there that are powered by Allwinner processors, including 
but not limited to the various Cubieboards, OLinuXinos, STBs, Tablets 
and “Mini PCs”. However, to date, support on mainline Linux is not yet 
feature complete. My proposal on particular focuses on DMA and analog 
audio on the earlier SoCs, and improved A23 support.


The idea here is to make a weekly status report of the project. As we 
are starting mid-program, this one will be a bit different and I'll 
outline what has been worked on so far since the beginning.


To date, I have been mainly working on the DMA driver for sun4i, sun5i 
and sun7i. Despite having completely different drivers on SDK kernels, 
the hardware block looks and behaves the same, so we are using a single 
driver for these three SoC families. I have sent a series of patches[1] 
as well as a follow-up v2[2], and I will keep iterating over it until 
it's accepted. I have also sent two trivial patches[3][4] as a side-effect.


The main challenges while writing this driver can be summarized as a 
lack of documentation. First of all, it took me a bit to get to know 
DMAEngine. As there is not much documentation on it, most of my learning 
took place by reading pre-existing drivers and consulting with my 
mentor. Secondly, as the Allwinner documentation is mostly a register 
list with bitfield details, I also had to read the SDK drivers and do 
some trial and error testing to discover magic values and understand others.


Lately, I have also been working on the audio part, now that I have a 
working DMA driver. After implementing cyclic DMA transfers and some 
clock code, and armed with a Buildroot image with mpg123 and an OpenBSD 
release track[5] in mp3 format, I've been trying to get some sound out 
of my Cubietruck's headphone jack, but without much success so far. I 
have verified my userspace stack and hardware by running these same 
binaries on top of the linux-sunxi 3.4 kernel, and it worked fine. I 
have since then been dumping relevant registers with devmem and 
comparing them, resolving issues as I see them - hopefully this will 
yield some audible results.


Interestingly enough, Allwinner themselves do not seem to be using 
cyclic DMA transfers on their driver[6]. I hope this is not a sign of a 
hardware bug that's not documented.


To give some closure to this status report, I'd like to thank Maxime for 
his mentoring so far, Ezequiel for letting me pick his brain, and the 
Linux Foundation and Google for giving me this opportunity, as well as 
everyone on the kernel and sunxi communities who have come forward to 
review and test patches. You can expect a new report soon, in about a 
week's time or less.


Emilio

[1] http://www.spinics.net/lists/dmaengine/msg01148.html
[2] http://www.spinics.net/lists/arm-kernel/msg344766.html
[3] https://lkml.org/lkml/2014/5/11/166
[4] https://lkml.org/lkml/2014/7/1/486
[5] http://www.openbsd.org/lyrics.html, maybe I should consider using 
some other song for better luck
[6] 
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L1137


--
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] A20: SPI Drivers

[Emilio López]

Hi there,

El 01/07/14 18:47, bruce bushby escribió:

Hi

I wanted to ask if anybody has tried to build spi-sun7.c for mainline
kernels?

I followed this excellent guide:
http://will-tm.com/spi-on-the-cubieboard2/


...but the compile fails with

drivers/spi/spi-sun7i.c:30:22: fatal error: mach/dma.h: No such file or
directory
  #include mach/dma.h
   ^
compilation terminated.
make[3]: *** [drivers/spi/spi-sun7i.o] Error 1
make[3]: *** Waiting for unfinished jobs


SPI on mainline is already supported on A20 via the SPI_SUN4I kconfig 
entry. It only supports PIO transfers for the moment.



I also noticed the Fedora 20 images doesn't support SPI for A20:
https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/README
* SPI (as module, not supported on A20)


This uses the linux-sunxi 3.4 kernel. I believe it has also recently 
gained SPI support on A20.



So now I'm a little worried as my entire project is built around 4 SPI
devices on an A20-SOM :)

Any secret plans for full DMA + SPI in the works?


As part of my work on DMA, I have worked on enabling DMA transfers on 
SPI, so it should be supported on mainline in the nearby future. I'll be 
sending a fresh second round of patches you can try really soon, so stay 
tuned.


Cheers,

Emilio

--
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] Wiki broken

[Emilio López]

Hi there,

El 27/06/14 08:05, Paul Jones escribió:

Hi,

If the wiki administrator is lurking here, just an FYI that the wiki is
slightly broken:

linux-sunxi.org could not send your confirmation mail. Please check your
email address for invalid characters.


I tried to send you an email through the wiki, but it insists on that 
you don't have an email address associated. Your account seems to be 
confirmed already.


Let us know here or on IRC if you have any further issues when trying to 
edit things.


Cheers,

Emilio

--
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: sun7i_tvd in kernel 3.4

[Emilio López]

El 17/06/14 09:45, Enrico escribió:

Il giorno martedì 17 giugno 2014 13:34:45 UTC+2, baani@gmail.com ha
scritto:


hi enrico,
are you able to fix the tvin drivers ?? can you pls send binaries
for 3.4.79 lubuntu to baani.harjeet [a] gmail.com http://gmail.com
please please


No i couldn't fix it and since there are no docs i gave up. I still hope
someone can make allwinner publish something


Is tvin some other hardware different from this?

http://dl.linux-sunxi.org/A10/A10%20Transport%20Stream%20Controller%20V1.00%2020120917.pdf

--
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] First try at A20 audio device tree entries

[Emilio López]

El 13/06/14 13:22, jonsm...@gmail.com escribió:

What should the clocks be?
Why are there three I2S devices?
Did I get interrupt and DMA values right?

spdif@1c21000 {
compatible = allwinner,sun7i-a20-spdif;
reg = 0x01C21000 0x20;
interrupts = 0 13 4;
clocks = apb1_gates 16;
dmas = dma 0 2, dma 0 2;
dma-names = rx, tx;


matches user manual


status = disabled;
}

ac97@1c21400 {
compatible = allwinner,sun7i-a20-ac97;
reg = 0x01C21400 0x20;
interrupts = 0 15 4;


Shouldn't this be 14? It's the next one after the SPDIF one according to 
the manual.



clocks = apb1_gates 16;
dmas = dma 0 5, dma 0 5;
dma-names = rx, tx;


matches user manual


status = disabled;
}

i2s0: i2s@1c22000 {
compatible = allwinner,sun7i-a20-i2s;
reg = 0x01C22000 0x20;
interrupts = 0 16 4;
clocks = apb1_gates 16;
dmas = dma 0 2, dma 0 3;


2 looks like a typo. 3 is IIS0 according to user manual


dma-names = rx, tx;
status = disabled;
}

i2s1: i2s@1c22400 {
compatible = allwinner,sun7i-a20-i2s;
reg = 0x01C22400 0x20;
interrupts = 0 87 4;
clocks = apb1_gates 16;
dmas = dma 0 4, dma 0 4;
dma-names = rx, tx;


matches user manual, assuming this is IIS1


status = disabled;
}

i2s2: i2s@1c24400 {
compatible = allwinner,sun7i-a20-i2s;
reg = 0x01C24400 0x20;
interrupts = 0 90 4;
clocks = apb1_gates 16;
dmas = dma 0 6, dma 0 6;


ditto, assuming it's IIS2


dma-names = rx, tx;
status = disabled;
}

codec@1c22c00 {
compatible = allwinner,sun7i-a20-codec;
reg = 0x01C22c00 0x20;
interrupts = 0 30 4;
clocks = apb1_gates 16;
dmas = dma 0 19, dma 0 19;
dma-names = rx, tx;


matches


status = disabled;
}


As for the clocks, you seem to have used apb1_gates 16 on all, but 
that's UART0's gate according to the manual. Note that most if not all 
of the audio clocks, most importantly PLL2, AC97 and IISx clocks are not 
supported on our clock driver yet, as there were no users for them.


--
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] First try at A20 audio device tree entries

[Emilio López]

El 13/06/14 23:55, jonsm...@gmail.com escribió:

So correct setting for codec clock is?

codec_clk: clk@01c20140 {
#clock-cells = 0;
compatible = allwinner,sun4i-a10-mod0-clk;


It does not look like a mod0 to me. User manual shows just 1 bit to gate 
the clock, so it should just be a simple gate clock with PLL2 as parent.



reg = 0x01c20140 0x4;
clocks = pll2 1;
clock-output-names = ir1;
};

And support for pll2 is missing?


Correct.

--
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] Detecting CPU type on 3.15 kernel

[Emilio López]

El 12/06/14 19:11, jonsm...@gmail.com escribió:

What has replaced sw_get_ic_ver() on 3.15?

Codec code varies on every chip revision A,B,C and A10/20.


A10/A20 can be determined by the compatible string. Chip revision is 
going to be trickier though, there is no direct replacement of 
sw_get_ic_ver() that I'm aware of. sw_get_ic_ver() seems to poke a timer 
register in the sun4i case, and SID (for which we do have a driver[1]) 
on the sun5i case.


[1] drivers/misc/eeprom/sunxi_sid.c

--
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] DMAEngine and audio support on A20

[Emilio López]

El 11/06/14 11:43, jonsm...@gmail.com escribió:

On Wed, Jun 11, 2014 at 10:25 AM, Chen-Yu Tsai w...@csie.org wrote:

On Wed, Jun 11, 2014 at 10:23 PM, jonsm...@gmail.com jonsm...@gmail.com wrote:

On Wed, Jun 11, 2014 at 10:17 AM, Chen-Yu Tsai w...@csie.org wrote:

On Wed, Jun 11, 2014 at 10:05 PM, jonsm...@gmail.com jonsm...@gmail.com wrote:

Is there a DMAEngine implementation for the A20?
Audio drivers will want that.


Emilio (CC-ed) has been working on one, and he pushed out a branch I think.

Depending on how much time it would take to implement the audio drivers,


Audio support is fairly easy if DMAEngine is there and cyclic buffers
have been implemented.

Audio does need a DMA feature that not all DMA hardware implements. It
needs to be able to ask the DMA hardware what address (or how far
along) the transfer is currently at.  That info is needed to implement
the mixer.

For example. You set audio up on a cyclic 16Kb DMA buffer playing
music. Now you want to make a beep that new email has arrived. The
audio system needs to be able to ask the DMA hardware where it is
inside that 16Kb buffer.  Once it knows where the DMA pointer is, it
will mix that beep into music already existing in the buffer that
hasn't played yet.

Without this capability audio drivers will implement lots of little
chained buffers. Then as each one completes if knows where the DMA
pointer is. Finally there is code in ALSA that just guesses where the
DMA pointer is based on the system clock.

Does the A20 DMA hardware expose the current DMA pointer address in a register?


There's a bit you can set on the configuration register so that the byte 
counter register (pages 165, 170 on A20 user manual) returns the amount 
of data left to transfer.


--
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] DMAEngine and audio support on A20

[Emilio López]

El 11/06/14 12:14, Chen-Yu Tsai escribió:

On Wed, Jun 11, 2014 at 11:11 PM, Emilio López emi...@elopez.com.ar wrote:

El 11/06/14 11:43, jonsm...@gmail.com escribió:


On Wed, Jun 11, 2014 at 10:25 AM, Chen-Yu Tsai w...@csie.org wrote:


On Wed, Jun 11, 2014 at 10:23 PM, jonsm...@gmail.com jonsm...@gmail.com
wrote:


On Wed, Jun 11, 2014 at 10:17 AM, Chen-Yu Tsai w...@csie.org wrote:


On Wed, Jun 11, 2014 at 10:05 PM, jonsm...@gmail.com
jonsm...@gmail.com wrote:


Is there a DMAEngine implementation for the A20?
Audio drivers will want that.



Emilio (CC-ed) has been working on one, and he pushed out a branch I
think.

Depending on how much time it would take to implement the audio
drivers,



Audio support is fairly easy if DMAEngine is there and cyclic buffers
have been implemented.

Audio does need a DMA feature that not all DMA hardware implements. It
needs to be able to ask the DMA hardware what address (or how far
along) the transfer is currently at.  That info is needed to implement
the mixer.

For example. You set audio up on a cyclic 16Kb DMA buffer playing
music. Now you want to make a beep that new email has arrived. The
audio system needs to be able to ask the DMA hardware where it is
inside that 16Kb buffer.  Once it knows where the DMA pointer is, it
will mix that beep into music already existing in the buffer that
hasn't played yet.

Without this capability audio drivers will implement lots of little
chained buffers. Then as each one completes if knows where the DMA
pointer is. Finally there is code in ALSA that just guesses where the
DMA pointer is based on the system clock.

Does the A20 DMA hardware expose the current DMA pointer address in a
register?



There's a bit you can set on the configuration register so that the byte
counter register (pages 165, 170 on A20 user manual) returns the amount of
data left to transfer.


I think the default setting is to return the amount of data transferred.
Add that to the base pointer, and that should do it.


According to the user manual, the default setting is to read the same 
thing that was written (ie, the buffer length).



I have no idea about cyclic buffers though. Maybe it's just an implementation
issue?


No idea either, we should check how did Allwinner implement it for audio 
on 3.4.


--
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] DMAEngine and audio support on A20

[Emilio López]

El 11/06/14 12:23, jonsm...@gmail.com escribió:

On Wed, Jun 11, 2014 at 11:14 AM, Chen-Yu Tsai w...@csie.org wrote:

On Wed, Jun 11, 2014 at 11:11 PM, Emilio López emi...@elopez.com.ar wrote:

El 11/06/14 11:43, jonsm...@gmail.com escribió:


On Wed, Jun 11, 2014 at 10:25 AM, Chen-Yu Tsai w...@csie.org wrote:


On Wed, Jun 11, 2014 at 10:23 PM, jonsm...@gmail.com jonsm...@gmail.com
wrote:


On Wed, Jun 11, 2014 at 10:17 AM, Chen-Yu Tsai w...@csie.org wrote:


On Wed, Jun 11, 2014 at 10:05 PM, jonsm...@gmail.com
jonsm...@gmail.com wrote:


Is there a DMAEngine implementation for the A20?
Audio drivers will want that.



Emilio (CC-ed) has been working on one, and he pushed out a branch I
think.

Depending on how much time it would take to implement the audio
drivers,



Audio support is fairly easy if DMAEngine is there and cyclic buffers
have been implemented.

Audio does need a DMA feature that not all DMA hardware implements. It
needs to be able to ask the DMA hardware what address (or how far
along) the transfer is currently at.  That info is needed to implement
the mixer.

For example. You set audio up on a cyclic 16Kb DMA buffer playing
music. Now you want to make a beep that new email has arrived. The
audio system needs to be able to ask the DMA hardware where it is
inside that 16Kb buffer.  Once it knows where the DMA pointer is, it
will mix that beep into music already existing in the buffer that
hasn't played yet.

Without this capability audio drivers will implement lots of little
chained buffers. Then as each one completes if knows where the DMA
pointer is. Finally there is code in ALSA that just guesses where the
DMA pointer is based on the system clock.

Does the A20 DMA hardware expose the current DMA pointer address in a
register?



There's a bit you can set on the configuration register so that the byte
counter register (pages 165, 170 on A20 user manual) returns the amount of
data left to transfer.


I think the default setting is to return the amount of data transferred.
Add that to the base pointer, and that should do it.

I have no idea about cyclic buffers though. Maybe it's just an implementation
issue?


Cyclic buffers are a power saving feature.  There's no real need for
an interrupt at the end of the buffer just to reset the buffer pointer
to the beginning of the buffer. DMA hardware that implements cyclic
transfers will reset the pointer without interrupting.


It's not clear from the user manual, but sounds like the continuous 
mode that the engine lets you enable.


--
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] DMAEngine and audio support on A20

[Emilio López]

El 11/06/14 12:30, jonsm...@gmail.com escribió:

On Wed, Jun 11, 2014 at 11:28 AM, Emilio López emi...@elopez.com.ar wrote:

So does this mythical DMAEngine implementation for the A20 exist?


It's under development, but yes it does :) I'll be sending a first round 
of patches to the respective lists later this week - if you want to play 
right now with it you can find a sunxi-dma branch on my repository.


--
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] DMAEngine and audio support on A20

[Emilio López]

El 11/06/14 14:37, jonsm...@gmail.com escribió:

On Wed, Jun 11, 2014 at 12:37 PM, Emilio López emi...@elopez.com.ar wrote:

El 11/06/14 12:30, jonsm...@gmail.com escribió:


On Wed, Jun 11, 2014 at 11:28 AM, Emilio López emi...@elopez.com.ar
wrote:

So does this mythical DMAEngine implementation for the A20 exist?



It's under development, but yes it does :) I'll be sending a first round of
patches to the respective lists later this week - if you want to play right
now with it you can find a sunxi-dma branch on my repository.


Is this you?
https://github.com/elopez/linux

you haven't pushed the branch


http://git.elopez.com.ar/linux/commits/branch/sunxi-dma

--
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] [PATCH v7] DMA: sun6i: Add driver for the Allwinner A31 DMA controller

[Emilio López]

Hi Maxime,

El 24/04/14 11:22, Maxime Ripard escribió:

The Allwinner A31 has a 16 channels DMA controller that it shares with the
newer A23. Although sharing some similarities with the DMA controller of the
older Allwinner SoCs, it's significantly different, I don't expect it to be
possible to share the driver for these two.

The A31 Controller is able to memory-to-memory or memory-to-device transfers on
the 16 channels in parallel.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Acked-by: Arnd Bergmann a...@arndb.de
---

(snip)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 5c5863842de9..360a10c71388 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -361,6 +361,14 @@ config FSL_EDMA
  multiplexing capability for DMA request sources(slot).
  This module can be found on Freescale Vybrid and LS-1 SoCs.

+config DMA_SUN6I
+   tristate Allwinner A31 SoCs DMA support
+   depends on ARCH_SUNXI
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS


I think you also need to select DMA_OF here as you are using 
of_dma_controller_register



+   help
+ Support for the DMA engine for Allwinner A31 SoCs.
+
  config DMA_ENGINE
bool


Cheers,

Emilio

--
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] [PATCH 0/6] sunxi: clk: Various cleanup and rework

[Emilio López]

El 12/05/14 22:12, Mike Turquette escribió:

Quoting Emilio López (2014-05-10 10:22:15)

Hi Maxime,

El 10/05/14 00:33, Maxime Ripard escribió:

Hi everyone,

This patchset fixes a few things that have been pending for quite a
while in the clock driver.

First, it removes the clk_put calls in the clock protection
part. Since it's not really something that should be done, I guess
this patch is not very controversial.

Then, it starts splitting the huge clock driver file into separate,
smaller drivers when it makes sense.

Finally, it reworks the clock protection mechanism to handle
differences between SoC in a better way. This has been pretty
controversial because the first approach has been to move this to the
machine code. This is another attempt that leaves all the
modifications in the driver itself.

Thanks,
Maxime


Overall the series looks good to me, other than the comment about clkdev
on patches 2 and 3.

@Mike, do you want me to take them in a pull as usual after you have a
look? Please let me know as we still haven't clarified the situation
with the two patches Hans sent.


A pull request would be great. Feel free to add my Acked-by to all of
the patches here (#1 already has it) since I looked at all of them and
the changes seem good.


Ok, I've taken them in sunxi-clk-for-mike with Mike's ack. I'll be 
sending the pull request soon.


Cheers,

Emilio

--
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 v5 0/5] mfd: add basic sun6i A31 PRCM support

[Emilio López]

Hi Boris,

El 15/05/14 05:55, Boris BREZILLON escribió:

Hello,

This patch series adds support for some functions provided by the PRCM
(Power/Reset/Clock Management) unit:
- AR100, AHB0 and APB0 clocks
- APB0 reset controller

(snip)

   clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support
   clk: sunxi: document PRCM clock compatible strings


I have taken these two on sunxi-clk-for-mike, and I'll be sending the 
pull to Mike soon.


Cheers,

Emilio

--
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] Sun5i USB Problem

[Emilio López]

Hi,

El 14/05/14 08:28, Paul Jones escribió:

Hi All,

I'm trying out the new 3.15 kernel on my A13-OLinuXino, but I'm having trouble 
getting usb to work.
After eventually finding the option to turn on the usb phy (Why can't usb 
options be in the usb menu??) there is a clock problem. (See the end of the 
dmesg output below).
The kernel boots and runs Debian fine, just no usb. Or rtc for that matter. I'm 
using sun5i-a13-olinuxino.dtb
Good job with all the upstreaming btw!


Have a look at this message

https://groups.google.com/d/msg/linux-sunxi/VNpagUJq4Ow/7XbikqWQwVYJ

It seems Hans has not pushed a fixed version yet, so you'll have to fix 
it manually for the time being (or revert the patch in question).


Cheers,

Emilio

--
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 v3 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support

[Emilio López]

Hi Boris,

First of all, thanks for working on this :)

While reading the code below I noticed a complete lack of comments. I 
think it would be good to have at least some to aid readability, 
considering these clocks are poorly documented on AW's material.


El 09/05/14 08:11, Boris BREZILLON escribió:

The PRCM (Power/Reset/Clock Management) unit provides several clock
devices:
- AR100 clk: used to clock the Power Management co-processor
- AHB0 clk: used to clock the AHB0 bus
- APB0 clk and gates: used to clk peripherals connected to the APB0 bus

Add support for these clks in a separate driver so that they can be probed
as platform devices instead of registered during early init.
This is needed to be able to probe PRCM MFD subdevices.

Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
---
  drivers/clk/sunxi/Makefile |   2 +
  drivers/clk/sunxi/clk-sun6i-prcm.c | 343 +
  2 files changed, 345 insertions(+)
  create mode 100644 drivers/clk/sunxi/clk-sun6i-prcm.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index b5bac91..ef8cdc9 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -3,3 +3,5 @@
  #

  obj-y += clk-sunxi.o clk-factors.o
+
+obj-$(CONFIG_MFD_SUN6I_PRCM) += clk-sun6i-prcm.o
diff --git a/drivers/clk/sunxi/clk-sun6i-prcm.c 
b/drivers/clk/sunxi/clk-sun6i-prcm.c
new file mode 100644
index 000..3efaf8f
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-prcm.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Boris BREZILLON boris.brezil...@free-electrons.com
+ *
+ * Allwinner PRCM (Power/Reset/Clock Management) driver
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+
+#define SUN6I_APB0_GATES_MAX_SIZE  32
+#define SUN6I_AR100_MAX_PARENTS4
+#define SUN6I_AR100_SHIFT_MASK 0x3
+#define SUN6I_AR100_SHIFT_MAX  SUN6I_AR100_SHIFT_MASK
+#define SUN6I_AR100_SHIFT_SHIFT4
+#define SUN6I_AR100_DIV_MASK   0x1f
+#define SUN6I_AR100_DIV_MAX(SUN6I_AR100_DIV_MASK + 1)
+#define SUN6I_AR100_DIV_SHIFT  8
+#define SUN6I_AR100_MUX_MASK   0x3
+#define SUN6I_AR100_MUX_SHIFT  16
+
+struct ar100_clk {
+   struct clk_hw hw;
+   void __iomem *reg;
+};
+
+static inline struct ar100_clk *to_ar100_clk(struct clk_hw *hw)
+{
+   return container_of(hw, struct ar100_clk, hw);
+}
+
+static unsigned long ar100_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct ar100_clk *clk = to_ar100_clk(hw);
+   u32 val = readl(clk-reg);
+   int shift = (val  SUN6I_AR100_SHIFT_SHIFT)  SUN6I_AR100_SHIFT_MASK;
+   int div = (val  SUN6I_AR100_DIV_SHIFT)  SUN6I_AR100_DIV_MASK;
+
+   return (parent_rate  shift) / (div + 1);
+}
+
+static long ar100_determine_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *best_parent_rate,
+struct clk **best_parent_clk)
+{
+   int nparents = __clk_get_num_parents(hw-clk);
+   long best_rate = -EINVAL;
+   int i;
+
+   *best_parent_clk = NULL;
+
+   for (i = 0; i  nparents; i++) {
+   unsigned long parent_rate;
+   unsigned long tmp_rate;
+   struct clk *parent;
+   unsigned long div;
+   int shift;
+
+   parent = clk_get_parent_by_index(hw-clk, i);
+   parent_rate = __clk_get_rate(parent);
+   div = DIV_ROUND_UP(parent_rate, rate);
+
+   shift = ffs(div) - 1;
+   if (shift  SUN6I_AR100_SHIFT_MAX)
+   shift = SUN6I_AR100_SHIFT_MAX;
+
+   div = shift;
+
+   while (div  SUN6I_AR100_DIV_MAX) {
+   shift++;
+   div = 1;
+   if (shift  SUN6I_AR100_SHIFT_MAX)
+   break;
+   }
+
+   if (shift  SUN6I_AR100_SHIFT_MAX)
+   continue;
+
+   tmp_rate = (parent_rate  shift) / div;
+   if (!*best_parent_clk || tmp_rate  best_rate) {
+   *best_parent_clk = parent;
+   *best_parent_rate = parent_rate;
+   best_rate = tmp_rate;
+   }
+   }
+
+   return best_rate;
+}
+
+static int ar100_set_parent(struct clk_hw *hw, u8 index)
+{
+   struct ar100_clk *clk = to_ar100_clk(hw);
+   u32 val = readl(clk-reg);
+
+   if (index = SUN6I_AR100_MAX_PARENTS)
+   return -EINVAL;
+
+   val = ~(SUN6I_AR100_MUX_MASK  SUN6I_AR100_MUX_SHIFT);
+   val |= (index  SUN6I_AR100_MUX_SHIFT);
+   writel(val, clk-reg);
+
+   return 0;
+}
+

[linux-sunxi] Re: [PATCH RESEND v4 1/8] clk: sunxi: Implement A31 USB clock

[Emilio López]

Hi Maxime,

El 13/05/14 12:44, Maxime Ripard escribió:

The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate for
all the phy.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Acked-by: Mike Turquette mturque...@linaro.org


I have queued this commit in sunxi-clk-for-mike for my 3.16 pull. I have 
also queued the trivial patch below to keep the new compatible documented.


Cheers,

Emilio

---8---

clk: sunxi: document new A31 USB clock compatible

Support for the USB gates and resets on A31 has been recently added
using a new compatible, so let's document it here.

Signed-off-by: Emilio López emi...@elopez.com.ar
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt

index a5160d8..1f6d3f4 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -41,6 +41,7 @@ Required properties:
allwinner,sun7i-a20-gmac-clk - for the GMAC clock module on A20/A31
allwinner,sun4i-a10-usb-clk - for usb gates + resets on A10 / A20
allwinner,sun5i-a13-usb-clk - for usb gates + resets on A13
+   allwinner,sun6i-a31-usb-clk - for usb gates + resets on A31

 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
--
1.9.2

--
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] [PATCH 3/6] clk: sunxi: Move the GMAC clock to a file of its own

[Emilio López]

Hi,

El 12/05/14 16:36, Maxime Ripard escribió:

On Sat, May 10, 2014 at 02:07:07PM -0300, Emilio López wrote:

+
+   clk = clk_register_composite(NULL, clk_name,
+   parents, SUN7I_A20_GMAC_PARENTS,
+   mux-hw, clk_mux_ops,
+   NULL, NULL,
+   gate-hw, clk_gate_ops,
+   0);
+
+   if (IS_ERR(clk))
+   goto iounmap_reg;
+
+   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   clk_register_clkdev(clk, clk_name, NULL);


As I mentioned on the other email, I don't think we are using
clkdev. Maybe we can drop it.


No we aren't, but we should not really modify code while moving it. I
can send another patch to do so, but that should not prevent this code
from going in.


That would be great :) The patches themselves are okay, I just thought 
I'd mention it so it's not forgotten.


Cheers,

Emilio

--
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/6] clk: sunxi: Move the 24M oscillator to a file of its own

[Emilio López]

--
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] [PATCH 3/6] clk: sunxi: Move the GMAC clock to a file of its own

[Emilio López]

Hi Maxime,

[let's hope this email goes through as non-empty]

El 10/05/14 00:33, Maxime Ripard escribió:

Since we have a folder of our own, we can actually make use of it by splitting
the huge clock file into several sub drivers.

The gmac clock is pretty easy to deal with, since it's pretty much isolated and
doesn't have any dependency on the other clocks.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---


Looks good to me, but see below.


  drivers/clk/sunxi/Makefile   |   3 +-
  drivers/clk/sunxi/clk-a20-gmac.c | 119 +++
  drivers/clk/sunxi/clk-sunxi.c|  98 
  3 files changed, 121 insertions(+), 99 deletions(-)
  create mode 100644 drivers/clk/sunxi/clk-a20-gmac.c


(snip)

+
+   clk = clk_register_composite(NULL, clk_name,
+   parents, SUN7I_A20_GMAC_PARENTS,
+   mux-hw, clk_mux_ops,
+   NULL, NULL,
+   gate-hw, clk_gate_ops,
+   0);
+
+   if (IS_ERR(clk))
+   goto iounmap_reg;
+
+   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   clk_register_clkdev(clk, clk_name, NULL);


As I mentioned on the other email, I don't think we are using clkdev. 
Maybe we can drop it.


Thanks for working on this!

Emilio

--
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] [PATCH 0/6] sunxi: clk: Various cleanup and rework

[Emilio López]

Hi Maxime,

El 10/05/14 00:33, Maxime Ripard escribió:

Hi everyone,

This patchset fixes a few things that have been pending for quite a
while in the clock driver.

First, it removes the clk_put calls in the clock protection
part. Since it's not really something that should be done, I guess
this patch is not very controversial.

Then, it starts splitting the huge clock driver file into separate,
smaller drivers when it makes sense.

Finally, it reworks the clock protection mechanism to handle
differences between SoC in a better way. This has been pretty
controversial because the first approach has been to move this to the
machine code. This is another attempt that leaves all the
modifications in the driver itself.

Thanks,
Maxime


Overall the series looks good to me, other than the comment about clkdev 
on patches 2 and 3.


@Mike, do you want me to take them in a pull as usual after you have a 
look? Please let me know as we still haven't clarified the situation 
with the two patches Hans sent.


Cheers, and thanks Maxime for working on cleaning this :)

Emilio

--
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/6] clk: sunxi: Move the 24M oscillator to a file of its own

[Emilio López]

El 11/05/14 01:35, Maxime Ripard escribió:

On Sat, May 10, 2014 at 01:46:38PM -0300, Emilio López wrote:

There was probably something interesting here, but both the messages
you sent are full of empty :)



My email client decided it was cool to drop my email body on my first 
email and my attempt to resend it. My reply to 3/6 didn't seem to be 
affected though, and the comment was basically the same so I didn't 
bother trying again :)


Cheers,

Emilio

--
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] sunxi-bsp and missing A20 support

[Emilio López]

Hi,

El 07/05/14 10:22, jonsm...@gmail.com escribió:

sunxi-bsp is missing support for the A20.  Has it not been
implemented, or did it get broken?

Anyone have a good build system for making Cubietruck images?


A20 support on the BSP should be working, with the exception of livesuit 
image building. It seems nobody has cared enough yet to hunt for the 
tools/files from the AW SDK and add support for it on the BSP. Patches 
and pull requests are welcome :)


Cheers,

Emilio

--
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 v10 01/15] clk: sunxi: factors: automatic reparenting support

[Emilio López]

Hi,

El 06/05/14 15:51, Maxime Ripard escribió:

Hi Emilio,

On Fri, May 02, 2014 at 05:57:15PM +0200, Hans de Goede wrote:

From: Emilio López emi...@elopez.com.ar

This commit implements .determine_rate, so that our factor clocks can be
reparented when needed.

Signed-off-by: Emilio López emi...@elopez.com.ar
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Maxime Ripard maxime.rip...@free-electrons.com


Any chance you merge this? Since it's pretty consensual, needed by
other drivers, and that you are the author, I can it can go in.


I merged it on my tree for Mike on April 22nd

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249259.html

It seems Mike has taken another copy for 3.16 though

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/253661.html

Mike, do you want to drop the patches and have me take both of them, or 
would you prefer it if I dropped my copy?


Cheers,

Emilio

--
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] i2c-sunxi: Fix support for TWI3 and TWI4 on A20

[Emilio López]

From: Emilio López t...@linux-sunxi.org

Although Hans had introduced support for TWI3 and TWI4, the functions
handling the clocks and pins were limited to only TWI0-2. Let's fix the
clock lists to include the new A20 names, as well as generalize the pin
functions to handle all 5 buses.

Reported-by: Sertac Tüllük stul...@gmail.com
Signed-off-by: Emilio López t...@linux-sunxi.org
---
 drivers/i2c/busses/i2c-sunxi.c | 58 ++
 1 file changed, 19 insertions(+), 39 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sunxi.c b/drivers/i2c/busses/i2c-sunxi.c
index 184d878..85345e0 100644
--- a/drivers/i2c/busses/i2c-sunxi.c
+++ b/drivers/i2c/busses/i2c-sunxi.c
@@ -373,31 +373,19 @@ static void aw_twi_disable_sys_clk(struct sunxi_i2c *i2c)
 
 static int aw_twi_request_gpio(struct sunxi_i2c *i2c)
 {
-   if(i2c-bus_num == 0) {
-   /* pb0-pb1 TWI0 SDA,SCK */
-   i2c_dbg(config i2c gpio with gpio_config api \n);
-
-   i2c-gpio_hdle = gpio_request_ex(twi0_para, NULL);
-   if(!i2c-gpio_hdle) {
-   pr_warning(twi0 request gpio fail!\n);
-   return -1;
-   }
-   }
-   else if(i2c-bus_num == 1) {
-   /* pb18-pb19 TWI1 scl,sda */
-   i2c-gpio_hdle = gpio_request_ex(twi1_para, NULL);
-   if(!i2c-gpio_hdle) {
-   pr_warning(twi1 request gpio fail!\n);
-   return -1;
-   }
-   }
-   else if(i2c-bus_num == 2) {
-   /* pb20-pb21 TWI2 scl,sda */
-   i2c-gpio_hdle = gpio_request_ex(twi2_para, NULL);
-   if(!i2c-gpio_hdle) {
-   pr_warning(twi2 request gpio fail!\n);
-   return -1;
-   }
+   char name[] = twi%d_para;
+
+   if (i2c-bus_num  4)
+   return 0;
+
+   sprintf(name, twi%d_para, i2c-bus_num);
+
+   i2c_dbg(config i2c gpio with gpio_config api\n);
+
+   i2c-gpio_hdle = gpio_request_ex(name, NULL);
+   if(!i2c-gpio_hdle) {
+   pr_warning(twi%d request gpio fail!\n, i2c-bus_num);
+   return -1;
}
 
return 0;
@@ -405,18 +393,10 @@ static int aw_twi_request_gpio(struct sunxi_i2c *i2c)
 
 static void aw_twi_release_gpio(struct sunxi_i2c *i2c)
 {
-   if(i2c-bus_num == 0) {
-   /* pb0-pb1 TWI0 SDA,SCK */
-   gpio_release(i2c-gpio_hdle, 0);
-   }
-   else if(i2c-bus_num == 1) {
-   /* pb18-pb19 TWI1 scl,sda */
-   gpio_release(i2c-gpio_hdle, 0);
-   }
-   else if(i2c-bus_num == 2) {
-   /* pb20-pb21 TWI2 scl,sda */
-   gpio_release(i2c-gpio_hdle, 0);
-   }
+   if (i2c-bus_num  4)
+   return;
+
+   gpio_release(i2c-gpio_hdle, 0);
 }
 
 
@@ -1006,8 +986,8 @@ static int i2c_sunxi_probe(struct platform_device *dev)
struct sunxi_i2c *i2c = NULL;
struct resource *res = NULL;
struct sunxi_i2c_platform_data *pdata = NULL;
-   char *i2c_clk[] ={twi0,twi1,twi2};
-   char *i2c_pclk[] ={apb_twi0,apb_twi1,apb_twi2};
+   char *i2c_clk[] = {twi0, twi1, twi2, twi3, twi4};
+   char *i2c_pclk[] = {apb_twi0, apb_twi1, apb_twi2, apb_twi3, 
apb_twi4};
int ret;
int irq;
 
-- 
1.9.2

-- 
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 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support

[Emilio López]

Hi Boris,

El 28/04/14 11:58, Boris BREZILLON escribió:

The PRCM (Power/Reset/Clock Management) unit provides several clock
devices:
- AR100 clk: used to clock the Power Management co-processor
- AHB0 clk: used to clock the AHB0 bus
- APB0 clk and gates: used to clk

Add support for these clks in a separate driver so that they can be probed
as platform devices instead of registered during early init.
We need this to be able to probe PRCM MFD subdevices.

Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
---

(..)

+
+MODULE_AUTHOR(Boris BREZILLON boris.brezil...@free-electrons.com);


There's a missing 


+MODULE_DESCRIPTION(Allwinner Reset Controller Driver);


Copy/paste leftover?


+MODULE_LICENSE(GPL v2);


I just skimmed through this now, I'll have a more detailed look later. 
Thanks for working on sun6i support :)


Cheers,

Emilio

--
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: How to Flash android in NAND in custom A20 Board (No OTG port)

[Emilio López]

El 26/04/14 02:14, Puneet B escribió:

Hi Emilio,

Can you tell how to make phonix card?.

Is there any software to make it?.


Yes, it's called PhoenixCard as I said earlier. Use Google and the wiki 
to learn more. I am not familiar with it.


--
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: How to Flash android in NAND in custom A20 Board (No OTG port)

[Emilio López]

El 25/04/14 10:50, Dave McLaughlin escribió:

I think this is very possible from a suitably written custom SD boot
option but you are going to have to write your own drivers to do this.

 From what I can tell, the A20 looks on the SD for a boot partition so
if you can create your own boot you could do this. Trouble is, I don't
know if there is much information on the internals of Phoenix Suite.

I have not seen anything off the shelf to do this.

I have an older FriendlyArm board that looks for a certain partition on
the SD that can the programme the NAND from SD.


PhoenixCard should be able to make a card that automatically installs a 
livesuit image to nand when you insert it on the device and boot it.


--
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 v8 00/17] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs

[Emilio López]

Hi Hans,

El 22/04/14 08:01, Hans de Goede escribió:

Hi All,

Here is v8 of the sunxi-mmc patch-set David Lanzendörfer and I have been
working on.

The first 2 patches are depenencies which should go in through the clk tree,
Mike can you pick these 2 up please ?  :

clk: sunxi: factors: automatic reparenting support
Is uncontroversial and has been favorably reviewed by various people.


I'll pick this one up for 3.16 if you're ok with that. Mike, let me know 
if you have any objection to the patch, but I'm pretty sure you 
(informally?) acked it in the past.



clk: sunxi: Implement MMC phase control
Is somewhat more controversial as there has been lots of discussion about
adding a generic phase control method to the clk framework. The problem is
that there has been a lot of talk about such a generic phase control method
but not a single patch. Therefor I would like to move forwards with using
a platform specific method for now. I hereby promise that once we've a generic
method I'll write patches to convert the sunxi code to that method.


Mike proposed a RFC for handling this better, and there were talks with 
Allwinner people to see what did these phase controls actually mean. We 
should be able to get a proper solution for it during this cycle. I'd 
prefer to work towards that instead of merging this, as we have more 
than a month to get it ready still.


Cheers,

Emilio

--
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] cpufreq support

[Emilio López]

Hi Stefan,

El 14/04/14 18:00, Stefan Monnier escribió:

The wiki page http://linux-sunxi.org/Linux_mainlining_effort
doesn't talk about cpufreq support, so I somehow assumed this support
for inherited from general ARM CPU support (for A8, A7, ...), but my
sunxi-devel build doesn't seem to have cpufreq support.


No, cpufreq is not something ARM-generic. There is currently no cpufreq 
support for sunxi platforms on mainline or mainline-based kernels. I did 
a forward port of the 3.4 driver to mainline some time ago. 
Unfortunately, that driver only works on sun4i/sun5i, and the 3.15 cycle 
introduced some changes in the cpufreq framework that require a bit of a 
code rework to make it usable (it'd probably be a wise idea to rewrite 
it entirely though, it's pretty ugly as it stands now).


Until very recently, there was not much point in having a cpufreq 
driver, as we were missing the PMU driver as well, so there was no 
chance of DVFS. We now have a driver for the AXP20x, so cpufreq now 
makes more sense.



I don't even know where to look to find the currently used frequency
(apparently, under ARM, /proc/cpuinfo doesn't have it).


The frequency is currently left alone, so the value set by uboot 
remains. You can check the uboot output to find it. Alternatively, if 
you enable DEBUG_FS on your kernel config, you can check the clock tree 
summary and read the cpu value.


Cheers,

Emilio

--
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 4/4] media: video: sun4i_csi: Fix build failure on mt9m112

[Emilio López]

From: Emilio López t...@linux-sunxi.org

The -Warray-bounds flag was triggering a build failure. Fix it.

Signed-off-by: Emilio López t...@linux-sunxi.org
---
 drivers/media/video/sun4i_csi/device/mt9m112.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/video/sun4i_csi/device/mt9m112.c 
b/drivers/media/video/sun4i_csi/device/mt9m112.c
index 090532d..1f8d993 100644
--- a/drivers/media/video/sun4i_csi/device/mt9m112.c
+++ b/drivers/media/video/sun4i_csi/device/mt9m112.c
@@ -928,7 +928,6 @@ static int sensor_detect(struct v4l2_subdev *sd)
}
 
regs.reg_num[0] = 0x00;
-   regs.reg_num[1] = 0x00;
ret = sensor_read(sd, regs.reg_num, regs.value);
if (ret  0) {
csi_dev_err(sensor_read err at sensor_detect!\n);
-- 
1.9.1

-- 
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 2/4] ARM: sunxi: enable KEYBOARD_SUN4I_KEYBOARD_FEX

[Emilio López]

From: Emilio López t...@linux-sunxi.org

This lets us specify keybindings on the fex using a [tabletkeys_para]
section.

Signed-off-by: Emilio López t...@linux-sunxi.org
---

This makes my volume keys work correctly, as the default driver mapping
doesn't match my hardware.

 arch/arm/configs/sun4i_defconfig | 1 +
 arch/arm/configs/sun5i_defconfig | 1 +
 arch/arm/configs/sun7i_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/configs/sun4i_defconfig b/arch/arm/configs/sun4i_defconfig
index b09d137..04ad67f 100644
--- a/arch/arm/configs/sun4i_defconfig
+++ b/arch/arm/configs/sun4i_defconfig
@@ -128,6 +128,7 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_INPUT_KEYRESET=y
 CONFIG_KEYBOARD_SUN4IKEYPAD=m
 CONFIG_KEYBOARD_SUN4I_KEYBOARD=m
+CONFIG_KEYBOARD_SUN4I_KEYBOARD_FEX=y
 CONFIG_KEYBOARD_HV2605_KEYBOARD=m
 CONFIG_IR_SUNXI=m
 CONFIG_INPUT_JOYSTICK=y
diff --git a/arch/arm/configs/sun5i_defconfig b/arch/arm/configs/sun5i_defconfig
index 25131d4..2638055 100644
--- a/arch/arm/configs/sun5i_defconfig
+++ b/arch/arm/configs/sun5i_defconfig
@@ -105,6 +105,7 @@ CONFIG_INPUT_POLLDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_SUN4IKEYPAD=m
 CONFIG_KEYBOARD_SUN4I_KEYBOARD=m
+CONFIG_KEYBOARD_SUN4I_KEYBOARD_FEX=y
 CONFIG_KEYBOARD_HV2605_KEYBOARD=m
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig
index a459ded..31a7e1e 100644
--- a/arch/arm/configs/sun7i_defconfig
+++ b/arch/arm/configs/sun7i_defconfig
@@ -586,6 +586,7 @@ CONFIG_INPUT_KEYRESET=y
 # CONFIG_KEYBOARD_ATKBD is not set
 CONFIG_KEYBOARD_SUN4IKEYPAD=m
 CONFIG_KEYBOARD_SUN4I_KEYBOARD=m
+CONFIG_KEYBOARD_SUN4I_KEYBOARD_FEX=y
 CONFIG_KEYBOARD_HV2605_KEYBOARD=y
 CONFIG_IR_SUNXI=m
 # CONFIG_MOUSE_PS2 is not set
-- 
1.9.1

-- 
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] A10/A13/A20 interface asyncroneous memory

[Emilio López]

Hi,

El 25/03/14 20:23, Dimitar Penev escribió:

  We need 16bit wide SRAM interface so NAND flash port doesn't suit
us.
  We plan to build SRAM on top of GPIO system.
  The interface is going to be used sporadically for a fraction of
second,
  so I guess we will be able to take the CPU fully (no DMA) while
it is
  active.
 
  Anyone implemented similar thing with AW?


I don't know what you're trying to achieve, but have you considered 
using SPI?


There are SRAM with SPI bus connectivity, like

http://ww1.microchip.com/downloads/en/DeviceDoc/22100D.pdf

Cheers,

Emilio

--
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] [PATCH u-boot-sunxi.git] sunxi: use a 4MB malloc pool

[Emilio López]

Hi Ian,

El vie 21 mar 2014 18:40:04 ART, Ian Campbell escribió:

As advised by Tom.

Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Tom Rini tr...@ti.com
---
  include/configs/sunxi-common.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index c76cf88..9070462 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -96,9 +96,9 @@

  /*
   * Size of malloc() pool
- * 1MB = 0x10, 0x10 = 1024 * 1024
+ * 4MB = 0x40, 0x40 = 1024 * 1024


The numbers don't add up on there there :)


   */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (1  20))
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + (4  20))

  /* Flat Device Tree (FDT/DT) support */
  #define CONFIG_OF_LIBFDT


Thanks for working on all this! :)

Emilio

--
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] No spl/sunxi-spl.bin for A31?

[Emilio López]

Hi Igor,

El 18/03/14 23:36, Igor Cardoso escribió:



Hello,

I was trying to make a bootable SD CARD for A31 from scratch but I have
a problem. A lot of places that helps build SD CARD for Allwinner
processors talk about a file called spl/sunxi-spl.bin, but that doesn't
exist on A31 folders...

I've manage to find the boot0_sdcard.fex and boot1_sdcard.fex and
u-boot.bin. I can load boot0 and boot1 like this:

dd if=boot0_sdcard.fex of=/dev/sdd seek=8 bs=1024
dd if=boot1_sdcard.fex of=/dev/sdd seek=19096 bs=1024

But then I don't know how to put u-boot. I have bootloader.fex,
boot.bin, a lot of boot's and I'm reallt confused.

The boot from NAND is on e FAT partition, this make me more confused...

Here is my questions:

1) What is bootloader.fex and what is the difference from boot.img and
u-boot.bin?
2) How can I load u-boot or bootloader to SD CARD manually? Formating
and creating partition with FDISK?

Thanks, sorry for the confusion.


We currently have no A31 support on the sunxi community U-Boot nor on 
linux-sunxi, so you'll probably need to use Allwinner's bootloaders.


Cheers,

Emilio

--
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: Auxtek-004 booting problems

[Emilio López]

Hi there,

El 19/03/14 14:14, Daniel Mosquera escribió:

Hi,

I have built the kernel directly using sun5i_defconfig, but it refuses
to boot.
I have tested with the last uboot and with the Fedora R18 uboot provided
by Hans de Goede,
and in both cases Hans' image boots but the one built with
sun5i_defconfig doesn't boot.


Can you try with sun5i_defconfig, with EARLY_PRINTK enabled and 
SW_DEBUG_UART configured to 0, and passing earlyprintk on your bootargs?


Cheers,

Emilio

--
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: Stk1160 driver

[Emilio López]

Hi there,

El 11/03/14 00:40, Ezequiel Garcia escribió:

André,

I'm leaving the question intact for context, and adding some folks.

On Mon, Mar 10, 2014 at 8:55 PM, André Kerber aker...@ymail.com wrote:


I am sorry to disturb you because of the old stk1160 driver, but I am very 
stuck and did not find any answer googling for more than 2 hours...

If you could give me a tip I would be very glad!  I am trying to use your 
driver on a cubieboard2 with ubuntu 12.04. If I try sudo make I always get the 
following error:

/lib/modules/3.4.79-sun7i+/build: No such file or directory.



You're probably using the backported driver, uh? Any chance you use a
newer kernel ( v3.7) ?


Probably not if you want a functional system :)


Do you have any idea? I definitely have a build in the modules directory...


You most likely have a broken symlink there. You (or someone else) 
probably cross-built the kernel but didn't install the kernel headers 
there. You should install them to build stk1160 on the cubieboard2 (or 
cross build stk1160 as well).



Emilio? Hans? Do you think the USB on the cubieboard2 can transfer
uncompressed (raw) video?
stk1160 needs as much as 20 MiB/sec. on isoc URBs and so far I haven't
seen many embedded systems
possible of that throughput...


Should be ok I suppose; with a USB hard drive I get these unscientific 
results:


emilio@mele:~$ echo 3|sudo tee /proc/sys/vm/drop_caches
3
emilio@mele:~$ LANG=C sudo -E dd if=/dev/sda of=/dev/null bs=4M count=200
200+0 records in
200+0 records out
838860800 bytes (839 MB) copied, 26.8201 s, 31.3 MB/s

(That's on a Host port; the OTG port is musb and would probably get 
around half that performance from what I've heard).


Cheers,

Emilio

--
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 1/5] clk: sun6i: Protect CPU clock

[Emilio López]

Hello Russell,

El 24/02/14 13:30, Russell King - ARM Linux escribió:

On Mon, Feb 24, 2014 at 05:22:43PM +0100, Maxime Ripard wrote:

Right now, AHB is an indirect child clock of the CPU clock. If that happens to
change, since the CPU clock has no other consumers declared in Linux, it would
be shut down, which is not really a good idea.

Prevent this by forcing it enabled.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
  drivers/clk/sunxi/clk-sunxi.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 23baad9..cedaf4b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1301,6 +1301,14 @@ static void __init sunxi_clock_protect(void)
clk_prepare_enable(clk);
clk_put(clk);
}
+
+   /* CPU clocks - sun6i */
+   clk = clk_get(NULL, cpu);
+   if (!IS_ERR(clk)) {
+   clk_prepare_enable(clk);
+   clk_put(clk);
+   }


This is broken.  I'm not sure what's difficult to grasp about the concept
of while a clock is in use, you should keep a reference to that clock.

That implies that if you get a clock, and then enable it, you don't
put the clock until you've disabled it.


Why is this so? Can't a clock be left enabled while nobody has a 
reference to it? I have looked around in Documentation/ (rather quickly 
I must say) and have not found any explicit mention that it is required 
to keep a reference to the clock while it's enabled. I'd appreciate it 
if you could explain this a bit more verbosely or point me to the 
relevant documents.


For what it's worth, I've seen this same pattern on 
enable/disable_clock() on drivers/base/power/clock_ops.c as well.


Cheers,

Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/5] clk: sun6i: Protect CPU clock

[Emilio López]

Hi Russell,

El 24/02/14 21:01, Russell King - ARM Linux escribió:

Hi Emilio.

On Mon, Feb 24, 2014 at 08:38:44PM -0300, Emilio López wrote:

Why is this so? Can't a clock be left enabled while nobody has a
reference to it? I have looked around in Documentation/ (rather quickly
I must say) and have not found any explicit mention that it is required
to keep a reference to the clock while it's enabled. I'd appreciate it
if you could explain this a bit more verbosely or point me to the
relevant documents.


First up, if you have a requirement that a clock be enabled, then is it
not unreasonable to ensure that the clock is referenced?


I was under the impression that the reference count was orthogonal to 
the clock status, but after getting that clarified, I can see your point.



Secondly, what if we have code which scans the clocks in the system,
shutting down those leaf clocks which appear to be unreferenced?


Indeed, that would break things.


Thirdly, the API (as I designed it) says so:

/**
  * clk_put  - free the clock source
  * @clk: clock source
  *
  * Note: drivers must ensure that all clk_enable calls made on this
  * clock source are balanced by clk_disable calls prior to calling
  * this function.
  *
  * clk_put should not be called from within interrupt context.
  */
void clk_put(struct clk *clk);

which has been there since the API was first created - it's part of the
contract between drivers using the API and implementers creating something
which conforms to the API - which today means CCF.


That's enough of a reason on its own :) I should have checked clk.h


The intention here is that while there are any users holding a clk_get()
reference on a clock, the clock is assumed to be required for some
device, and the struct clk may not be kfree'd, nor may its state be
changed in an unpredictable way to those drivers holding a reference
to it.


I understand now, thanks for the insight. I'll talk with Maxime and get 
this sorted out.


As a side note, should drivers/base/power/clock_ops.c be fixed too? I 
have added Rafael to Cc.


Cheers,

Emilio

--
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/groups/opt_out.

Re: [linux-sunxi] [Newbie] How difficult it can be to add support for a new device?

[Emilio López]

Hi there!

El 23/02/14 10:42, mati8...@gmail.com escribió:

Hi people,
First of all, thank you very much for all your work. =)

I'm thinking buying a laptop with a microprocessor Allwinner A20. There is not 
much information. Only this: http://www.kanjitech.com.ar/productos/display/157

Comes with android, and would like to use it as a desktop with fedora, only for 
browsing, listening to music, and maybe write some code.

So here's the main question:
Without knowing anything about the device, what are the chances of getting 
something usable? :S


As Luc explained, assuming it really is an A20, it should be easy on 
most cases and it'll require a bit more work on the rest.



Emm.
Will I be able to obtain the fex file, or will be blocked?.
..and now, that chances to be functional with mainline kernel? I know that now 
no support.. But it is difficult to convert the Fex to device tree?.


Maxime (on cc) is working on an automagic tool to make it happen. 
Currently, mainline has no display driver, so it wouldn't be any use to 
you if you intend to use it as a laptop.



.and finally.. a A20 with 1GB of RAM, it will be usable as laptop?.


It depends on what you want do do with it. If you're going to do some 
pdf reading, document editing, programming or ssh then it'll probably be 
fine, yes.


Saludos,

Emilio

--
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/groups/opt_out.

Re: [linux-sunxi] [Newbie] How difficult it can be to add support for a new device?

[Emilio López]

Hi,

Ok. Thanks for confirm it.
There is much confusion among Allwinner and Wondermedia?.
Vendors say allwinner A20. But I can never know.. I can confirm from android?


It's not uncommon for the chinese to mislabel the contents of their 
products. For example, Luc bought an A13 tablet some time ago, but it 
was in fact an Allwinner A23 one.


A relatively easy way to confirm would be to go to Settings - About 
Tablet, you should see a build number containing wing (Luc, is there 
any other names for A20 devices you've seen?). There is probably some 
system information apps you can download too that will tell you if the 
machine is sun7i.


Cheers,

Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH v4 0/8] ARM: sunxi: rename DT clock node names to clk@N

[Emilio López]

El 07/02/14 16:24, Maxime Ripard escribió:

On Mon, Feb 03, 2014 at 09:51:36AM +0800, Chen-Yu Tsai wrote:

Hi everyone,

This is v4 of the clock node renaming patch series, which renames
the clock nodes in sunxi dts to conform to device tree naming
conventions, i.e. clk@N. Dummy clocks that will be renamed/removed
later, or clocks sharing registers are not renamed.

Renamed clock nodes have clock-output-names properties added to
desginate their names. Support for this is added in the first
patch.


Applied the last 4 patches to sunxi/dt-for-3.15.


And I've applied the first 4 to sunxi-clk-for-mike some time ago.

Thanks for working on this!

Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH v4 1/5] clk: sunxi: Add support for PLL6 on the A31

[Emilio López]

El 05/02/14 10:05, Maxime Ripard escribió:

The A31 has a slightly different PLL6 clock. Add support for this new clock in
our driver.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com


Taken via sunxi-clk-for-mike.

Thanks!

Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH v4 0/8] Add Allwinner A20 GMAC ethernet support

[Emilio López]

El 10/02/14 16:47, Maxime Ripard escribió:

Hi Chen-Yu,

On Mon, Feb 10, 2014 at 06:35:46PM +0800, Chen-Yu Tsai wrote:

Hi,

This is the v4 of the remaining Allwinner A20 GMAC glue layer patches.
The stmmac driver changes have been merged through net-next. The
remaining bits are clock and DT patches. The patches should be applied
over my clock renaming patches.

The Allwinner A20 SoC integrates an early version of dwmac
IP from Synopsys. On top of that is a hardware glue layer.
This layer needs to be configured before the dwmac can be
used.

Part of the glue layer is a clock mux, which controls the
source and direction of the TX clock used by GMAC.


Just merged patches 2-8.


And I just merged patch 1 on my branch for Mike

Cheers,

Emilio

--
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/groups/opt_out.

Re: [linux-sunxi] Linux boots but Android fails to boot

[Emilio López]

Hi,

El 12/02/14 02:30, Dave McLaughlin escribió:

Hopefully this is the right place to post this as I have been tearing
out what little hair I have left with this.

I have an Olimex-A20 board and the Linux kernel boots ok but Android
fails to boot completely and I see this in the Logcat ouput. The code
was built from the Android 4.2.2 source provided and according to them,
is what was used to create their image that was preloaded.

It's the same for running from SD or NAND. During the Linux bootup I can
see the logo displayed on the LCD so I know the driver settings for the
display are correct.

The serial debug port shows the following, repeating all the time with a
different PID.

[  118.772127] init: untracked pid 2480 exited

The following is the Logcat output from the debug port.


Are you using the kernel provided within the Android SDK? Note that the 
Mali userspace libraries have to match the version used on the kernel, 
so if you swapped the android kernel on the SDK with linux-sunxi you'll 
need to replace the Mali libraries.




I/SurfaceFlinger( 2508): SurfaceFlinger is starting
I/SurfaceFlinger( 2508): SurfaceFlinger's main thread ready to run.
Initializing graphics H/W...
D/libEGL  ( 2508): loaded /system/lib/egl/libEGL_mali.so
D/libEGL  ( 2508): loaded /system/lib/egl/libGLESv1_CM_mali.so
D/libEGL  ( 2508): loaded /system/lib/egl/libGLESv2_mali.so


These are them. There's also libMali.so and libUMP.so, and I think 
that's it.


Cheers,

Emilio

--
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/groups/opt_out.

Re: [linux-sunxi] [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver

[Emilio López]

Hi Maxime,

El 29/01/14 08:10, Maxime Ripard escribió:

The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
SoCs.

It supports DMA, but the driver only does PIO for now, and DMA will be
supported eventually.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---

(snip)

+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+   int ret;
+
+   ret = clk_prepare_enable(sspi-hclk);
+   if (ret) {
+   dev_err(dev, Couldn't enable clock 'ahb spi'\n);
+   goto out;
+   }
+
+   ret = clk_prepare_enable(sspi-mclk);
+   if (ret) {
+   dev_err(dev, Couldn't enable clock 'ahb spi'\n);


A different message would be nice :)

Cheers,

Emilio

--
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/groups/opt_out.

Re: [linux-sunxi] [PATCH v2 1/5] clk: sunxi: Add support for USB clock-register reset bits

[Emilio López]

Hi Hans,

El 22/01/14 18:36, Hans de Goede escribió:

The usb-clk register is special in that it not only contains clk gate bits,
but also has a few reset bits. This commit adds support for this by allowing
gates type sunxi clks to also register a reset controller.

Signed-off-by: Hans de Goede hdego...@redhat.com
---

(snip)

  static const struct gates_data sun4i_axi_gates_data __initconst = {
@@ -818,6 +873,7 @@ static void __init sunxi_gates_clk_setup(struct device_node 
*node,
 struct gates_data *data)
  {
struct clk_onecell_data *clk_data;
+   struct gates_reset_data *reset_data;
const char *clk_parent;
const char *clk_name;
void *reg;
@@ -861,6 +917,21 @@ static void __init sunxi_gates_clk_setup(struct 
device_node *node,
clk_data-clk_num = i;

of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+
+   /* Register a reset controler for gates with reset bits */
+   if (data-reset_mask == 0)
+   return;
+
+   reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
+   if (!reset_data)
+   return;
+
+   reset_data-reg = reg;
+   reset_data-lock = clk_lock;
+   reset_data-rcdev.nr_resets = hweight32(data-reset_mask);


I know I made you change this, but after having a second look into 
nr_resets, I think your original implementation makes more sense. This 
will break if you use a mask with holes on it. Sorry :(



+   reset_data-rcdev.ops = sunxi_gates_reset_ops;
+   reset_data-rcdev.of_node = node;
+   reset_controller_register(reset_data-rcdev);
  }


Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH v3 2/8] clk: sunxi: update clock-output-names dt binding documentation

[Emilio López]

Hi,

El 09/01/14 05:52, Chen-Yu Tsai escribió:

clock-output-names is now required for most of sunxi clock nodes, to
provide the name of the corresponding clock. Add the new requirements,
exceptions, as well as examples.

Signed-off-by: Chen-Yu Tsai w...@csie.org
---
  Documentation/devicetree/bindings/clock/sunxi.txt | 36 +++
  1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 0c127cd..8a9147d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -44,10 +44,18 @@ Required properties for all clocks:
multiplexed clocks, the list order must match the hardware
programming order.
  - #clock-cells : from common clock binding; shall be set to 0 except for
-   allwinner,*-gates-clk where it shall be set to 1
+   allwinner,*-gates-clk, allwinner,sun4i-pll5-clk and
+   allwinner,sun4i-pll6-clk where it shall be set to 1

-Additionally, allwinner,*-gates-clk clocks require:
-- clock-output-names : the corresponding gate names that the clock controls
+Additionally, most clocks require clock-output-names:
+- allwinner,*-gates-clk : the corresponding gate names that the clock 
controls
+- allwinner,sun4i-pll5-clk : pll5_ddr, pll5_mbus
+- allwinner,sun4i-pll6-clk : pll6_sata, pll6_other
+- allwinner,sun4i-cpu-clk, allwinner,sun4i-axi-clk,
+  allwinner,sun4i-ahb-clk, allwinner,sun4i-ahb-clk,
+  allwinner,sun4i-apb1-mux-clk, allwinner,sun4i-apb1-clk
+  do not need clock-output-names
+- all others clocks : the corresponding module name of that clock


As we discussed on IRC, I wonder if such verbosity is actually needed. 
Maybe we should dictate that all clocks must list their corresponding 
outputs on clock-output-names (with it being the module name if it only 
has one output).


Cheers,

Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/5] clk: sunxi: Add support for USB clock-register reset bits

[Emilio López]

Hi Hans,

2014/1/10 Hans de Goede hdego...@redhat.com:
 The usb-clk register is special in that it not only contains clk gate bits,
 but also has a few reset bits. This commit adds support for this by allowing
 gates type sunxi clks to also register a reset controller.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  drivers/clk/sunxi/clk-sunxi.c | 71 
 +++
  1 file changed, 71 insertions(+)

 diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
 index 03bb8b8..b5d0a7a 100644
 --- a/drivers/clk/sunxi/clk-sunxi.c
 +++ b/drivers/clk/sunxi/clk-sunxi.c
 @@ -18,6 +18,7 @@
  #include linux/clkdev.h
  #include linux/of.h
  #include linux/of_address.h
 +#include linux/reset-controller.h

  #include clk-factors.h

 @@ -741,6 +742,59 @@ static void __init sunxi_divider_clk_setup(struct 
 device_node *node,


  /**
 + * gates_reset... - reset bits in leaf gate clk registers handling
 + */
 +
 +struct gates_reset_data {
 +   void __iomem*reg;
 +   spinlock_t  *lock;
 +   struct reset_controller_dev rcdev;
 +};
 +
 +static int gates_reset_assert(struct reset_controller_dev *rcdev,
 + unsigned long id)

They're static, so it's not a big deal, but I think these two should
have a prefix (sunxi_) like the rest of the functions.

 +{
 +   struct gates_reset_data *data = container_of(rcdev,
 +struct gates_reset_data,
 +rcdev);
 +   unsigned long flags;
 +   u32 reg;
 +
 +   spin_lock_irqsave(data-lock, flags);
 +
 +   reg = readl(data-reg);
 +   writel(reg  ~BIT(id), data-reg);
 +
 +   spin_unlock_irqrestore(data-lock, flags);
 +
 +   return 0;
 +}
 +
 +static int gates_reset_deassert(struct reset_controller_dev *rcdev,
 +   unsigned long id)
 +{
 +   struct gates_reset_data *data = container_of(rcdev,
 +struct gates_reset_data,
 +rcdev);
 +   unsigned long flags;
 +   u32 reg;
 +
 +   spin_lock_irqsave(data-lock, flags);
 +
 +   reg = readl(data-reg);
 +   writel(reg | BIT(id), data-reg);
 +
 +   spin_unlock_irqrestore(data-lock, flags);
 +
 +   return 0;
 +}
 +
 +static struct reset_control_ops gates_reset_ops = {
 +   .assert = gates_reset_assert,
 +   .deassert   = gates_reset_deassert,
 +};
 +
 +/**
   * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
   */

 @@ -748,6 +802,7 @@ static void __init sunxi_divider_clk_setup(struct 
 device_node *node,

  struct gates_data {
 DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
 +   u32 reset_mask;
  };

  static const struct gates_data sun4i_axi_gates_data __initconst = {
 @@ -818,6 +873,7 @@ static void __init sunxi_gates_clk_setup(struct 
 device_node *node,
  struct gates_data *data)
  {
 struct clk_onecell_data *clk_data;
 +   struct gates_reset_data *reset_data;
 const char *clk_parent;
 const char *clk_name;
 void *reg;
 @@ -861,6 +917,21 @@ static void __init sunxi_gates_clk_setup(struct 
 device_node *node,
 clk_data-clk_num = i;

 of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
 +
 +   /* Register a reset controler for gates with reset bits */
 +   if (data-reset_mask == 0)
 +   return;
 +
 +   reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
 +   if (!reset_data)
 +   return;
 +
 +   reset_data-reg = reg;
 +   reset_data-lock = clk_lock;
 +   reset_data-rcdev.nr_resets = __fls(data-reset_mask) + 1;

Maybe something like hweight32() would be a better fit here. fls would
only work if the reset bits are on the end.

 +   reset_data-rcdev.ops = gates_reset_ops;
 +   reset_data-rcdev.of_node = node;
 +   reset_controller_register(reset_data-rcdev);
  }

Cheers,

Emilio

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 2/5] clk: sunxi: Add USB clock register defintions

[Emilio López]

Hi Hans,

2014/1/10 Hans de Goede hdego...@redhat.com:
 From: arokux aro...@gmail.com

I thought this was settled already :) You should use a real name here.

 Add register definitions for the usb-clk register found on sun4i, sun5i and
 sun7i SoCs.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  Documentation/devicetree/bindings/clock/sunxi.txt |  5 +
  drivers/clk/sunxi/clk-sunxi.c | 12 
  2 files changed, 17 insertions(+)

 diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
 b/Documentation/devicetree/bindings/clock/sunxi.txt
 index 79c7197..8bccb6a 100644
 --- a/Documentation/devicetree/bindings/clock/sunxi.txt
 +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
 @@ -37,6 +37,8 @@ Required properties:
 allwinner,sun6i-a31-apb2-gates-clk - for the APB2 gates on A31
 allwinner,sun4i-mod0-clk - for the module 0 family of clocks
 allwinner,sun7i-a20-out-clk - for the external output clocks
 +   allwinner,sun4i-usb-gates-clk - for usb gates + resets on A10 / A20
 +   allwinner,sun5i-a13-usb-gates-clk - for usb gates + resets on A13

  Required properties for all clocks:
  - reg : shall be the control register address for the clock.
 @@ -49,6 +51,9 @@ Required properties for all clocks:
  Additionally, allwinner,*-gates-clk clocks require:
  - clock-output-names : the corresponding gate names that the clock controls

 +And allwinner,*-usb-gates-clk clocks also require:
 +- reset-cells : shall be set to 1
 +
  Clock consumers should specify the desired clocks they use with a
  clocks phandle cell. Consumers that are using a gated clock should
  provide an additional ID in their clock property. This ID is the
 diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
 index b5d0a7a..82d75c0 100644
 --- a/drivers/clk/sunxi/clk-sunxi.c
 +++ b/drivers/clk/sunxi/clk-sunxi.c
 @@ -813,6 +813,16 @@ static const struct gates_data sun4i_ahb_gates_data 
 __initconst = {
 .mask = {0x7F77FFF, 0x14FB3F},
  };

 +static const struct gates_data sun4i_usb_gates_data __initconst = {
 +   .mask = {0x1C0},
 +   .reset_mask = 0x07,
 +};
 +
 +static const struct gates_data sun5i_a13_usb_gates_data __initconst = {
 +   .mask = {0x140},
 +   .reset_mask = 0x03,
 +};
 +
  static const struct gates_data sun5i_a10s_ahb_gates_data __initconst = {
 .mask = {0x147667e7, 0x185915},
  };
 @@ -1159,6 +1169,8 @@ static const struct of_device_id clk_gates_match[] 
 __initconst = {
 {.compatible = allwinner,sun6i-a31-apb1-gates-clk, .data = 
 sun6i_a31_apb1_gates_data,},
 {.compatible = allwinner,sun7i-a20-apb1-gates-clk, .data = 
 sun7i_a20_apb1_gates_data,},
 {.compatible = allwinner,sun6i-a31-apb2-gates-clk, .data = 
 sun6i_a31_apb2_gates_data,},
 +   {.compatible = allwinner,sun4i-usb-gates-clk, .data = 
 sun4i_usb_gates_data,},
 +   {.compatible = allwinner,sun5i-a13-usb-gates-clk, .data = 
 sun5i_a13_usb_gates_data,},
 {}
  };

It looks ok otherwise.

Cheers,

Emilio

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i: external clock outputs

[Emilio López]

Hi,

El 23/12/13 05:37, Chen-Yu Tsai escribió:

This commit adds the two external clock outputs available on A20 to
its device tree. A dummy fixed factor clock is also added to serve as
the first input of the clock outputs, which according to AW's A20 user
manual, is the 24MHz oscillator divided by 750.

Signed-off-by: Chen-Yu Tsai w...@csie.org
---

(,,,)

+   clk_out_a: clk_out_a@01c201f0 {
+   #clock-cells = 0;
+   compatible = allwinner,sun7i-a20-out-clk;
+   reg = 0x01c201f0 0x4;
+   clocks = osc24M_32k, osc32k, osc24M;
+   };


These nodes should, as per Maxime's recommendation, look more like

clk_out_a: clk@01c201f0 {
#clock-cells = 0;
compatible = allwinner,sun7i-a20-out-clk;
reg = 0x01c201f0 0x4;
clocks = osc24M_32k, osc32k, osc24M;
clk-output-names = clk_out_a;
};

Cheers,

Emilio

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i: external clock outputs

[Emilio López]

El 23/12/13 13:43, Chen-Yu Tsai escribió:

Hi,

On Tue, Dec 24, 2013 at 12:21 AM, Emilio López emi...@elopez.com.ar wrote:

Hi,

El 23/12/13 05:37, Chen-Yu Tsai escribió:


This commit adds the two external clock outputs available on A20 to
its device tree. A dummy fixed factor clock is also added to serve as
the first input of the clock outputs, which according to AW's A20 user
manual, is the 24MHz oscillator divided by 750.

Signed-off-by: Chen-Yu Tsai w...@csie.org
---


(,,,)


+   clk_out_a: clk_out_a@01c201f0 {
+   #clock-cells = 0;
+   compatible = allwinner,sun7i-a20-out-clk;
+   reg = 0x01c201f0 0x4;
+   clocks = osc24M_32k, osc32k, osc24M;
+   };



These nodes should, as per Maxime's recommendation, look more like

 clk_out_a: clk@01c201f0 {
 #clock-cells = 0;
 compatible = allwinner,sun7i-a20-out-clk;
 reg = 0x01c201f0 0x4;

 clocks = osc24M_32k, osc32k, osc24M;
 clk-output-names = clk_out_a;
 };


I see. I was following the structure for the main clocks,
such as pll* or axi/ahb/apb, as the output clocks do not
have a specific device tied to them, and no worries that
a node name collision might happen. Do you plan to convert
the other clocks to this scheme as well? Or are they
considered reserved or special names?


Yes, with time they should be renamed. A quote from 
http://devicetree.org/Device_Tree_Usage to give a bit of background



It is worth taking a moment to talk about naming conventions. Every node 
must have a name in the form name[@unit-address].
name is a simple ascii string and can be up to 31 characters in 
length. In general, nodes are named according to what kind of device it 
represents. ie. A node for a 3com Ethernet adapter would be use the name 
ethernet, not 3com509. [...]
Sibling nodes must be uniquely named, but it is normal for more than one 
node to use the same generic name so long as the address is different 
(ie, serial@101f1000  serial@101f2000).



Have a look at the last iteration of my patches, where I remade all the 
mod0 nodes to fit with this.


Cheers,

Emilio

--
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/groups/opt_out.