Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/5] i2c: i2c-sh_mobile: calculate clock parameters at driver probing time
From: Shinya Kuribayashi @ 2012-10-24 10:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5087C93F.6080601@renesas.com>

Currently SCL clock parameters (ICCH/ICCL) are calculated in
activate_ch(), which gets called every time sh_mobile_i2c_xfer() is
processed, while each I2C bus speed is system-defined and in general
those parameters do not have to be updated over I2C transactions.

The only reason I could see having it transaction-time is to adjust
ICCH/ICCL values according to the operating frequency of the I2C
hardware block, in the face of DFS (Dynamic Frequency Scaling).

However, this won't be necessary.

The operating frequency of the I2C hardware block can change _even_
in the middle of I2C transactions.  There is no way to prevent it
from happening, and I2C hardware block can work with such dynamic
frequency change, of course.

Another is that ICCH/ICCL clock parameters optimized for the faster
operating frequency, can also be applied to the slower operating
frequency, as long as slave devices work.  However, the converse is
not true.  It would violate SCL timing specs of the I2C standard.

What we can do now is to calculate the ICCH/ICCL clock parameters
according to the fastest operating clock of the I2C hardware block.
And if that's the case, that calculation should be done just once
at driver-module-init time.

This patch moves ICCH/ICCL calculating part from activate_ch() into
sh_mobile_i2c_init(), and call it from sh_mobile_i2c_probe().

Note that sh_mobile_i2c_init() just prepares clock parameters using
the clock rate and platform data provided, but does _not_ make any
hardware I/O accesses.  We don't have to care about run-time PM
maintenance here.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
 drivers/i2c/busses/i2c-sh_mobile.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 8110ca4..309d0d5 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -187,18 +187,15 @@ static void iic_set_clr(struct sh_mobile_i2c_data *pd, int offs,
 	iic_wr(pd, offs, (iic_rd(pd, offs) | set) & ~clr);
 }
 
-static void activate_ch(struct sh_mobile_i2c_data *pd)
+static void sh_mobile_i2c_init(struct sh_mobile_i2c_data *pd)
 {
 	unsigned long i2c_clk;
 	u_int32_t num;
 	u_int32_t denom;
 	u_int32_t tmp;
 
-	/* Wake up device and enable clock */
-	pm_runtime_get_sync(pd->dev);
-	clk_enable(pd->clk);
-
 	/* Get clock rate after clock is enabled */
+	clk_enable(pd->clk);
 	i2c_clk = clk_get_rate(pd->clk);
 
 	/* Calculate the value for iccl. From the data sheet:
@@ -239,6 +236,15 @@ static void activate_ch(struct sh_mobile_i2c_data *pd)
 			pd->icic &= ~ICIC_ICCHB8;
 	}
 
+	clk_disable(pd->clk);
+}
+
+static void activate_ch(struct sh_mobile_i2c_data *pd)
+{
+	/* Wake up device and enable clock */
+	pm_runtime_get_sync(pd->dev);
+	clk_enable(pd->clk);
+
 	/* Enable channel and configure rx ack */
 	iic_set_clr(pd, ICCR, ICCR_ICE, 0);
 
@@ -632,6 +638,8 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
 	if (size > 0x17)
 		pd->flags |= IIC_FLAG_HAS_ICIC67;
 
+	sh_mobile_i2c_init(pd);
+
 	/* Enable Runtime PM for this device.
 	 *
 	 * Also tell the Runtime PM core to ignore children
-- 
1.7.12.4

^ permalink raw reply related

* [PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
From: Péter Ujfalusi @ 2012-10-24 10:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5087BCA6.1020602@ti.com>

On 10/24/2012 12:02 PM, Benoit Cousson wrote:
> The interrupt-parent attribute does not have to be added in each
> node since the DT framework will check for the parent as well to get it.
> 
> Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
> attributes from every nodes that were using it.
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Sebastien Guiriec <s-guiriec@ti.com>

Thanks Benoit, looks good from my side.

Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

^ permalink raw reply

* [PATCH 0/5] i2c-sh_mobile non-urgent changes
From: Shinya Kuribayashi @ 2012-10-24 10:55 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

This is the first batch to fix the i2c-sh_mobile driver.  As a first
step, this comprises of the SCL optimization work and a simple fix to
annoying spurious WAIT interrupt issue; in other words, this does not
change tx/rx data handling logic.

This driver has an architectural problem with send/receive procedures
and needs a fundamental overhaul.  I've been working on splitting into
logical chunks, but not yet completed.

Patches are prepared against the vanilla v3.6.  I don't have a chance
to give it a try with v3.6+ kernels myself, but tend to be optimistic
about that.  I have been cooking these patches over a year, and they
work perfectly fine with older kernels ..v3.4 so far.


Shinya Kuribayashi (5):
      i2c: i2c-sh_mobile: calculate clock parameters at driver probing time
      i2c: i2c-sh_mobile: optimize ICCH/ICCL values according to I2C bus speed
      i2c: i2c-sh_mobile: fix ICCH to avoid violation of the tHD;STA timing spec
      i2c: i2c-sh_mobile: support I2C hardware block with a faster operating clock
      i2c: i2c-sh_mobile: fix spurious transfer request timed out

 drivers/i2c/busses/i2c-sh_mobile.c | 150 ++++++++++++++++++++++++-------------
 include/linux/i2c/i2c-sh_mobile.h  |   1 +
 2 files changed, 98 insertions(+), 53 deletions(-)

--
Shinya Kuribayashi
Renesas Electronics

^ permalink raw reply

* Possible regression in arm/io.h
From: Will Deacon @ 2012-10-24 10:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CABYn4syj0GZAsDYVQfXg_qKAFkbrxPLoZWpKRzwf3gfRkMGZkQ@mail.gmail.com>

On Wed, Oct 24, 2012 at 11:38:14AM +0100, Bastian Hecht wrote:
> Hello Will,

Hello,

> your introduction of the "+Qo" in arch/arm/include/asm/io.h makes some
> drivers fail to compile on newer gnu ARM gccs. Like in
> drivers/mtd/nand/docg4.c there is an offset of 0x800 from a pointer
> used to address I/O memory. This leads to the error message:
> 
> /tmp/ccwLMdCy.s: Error: bad immediate value for 8-bit offset (2048)

Urgh.

> The gnu gcc people tracked it down to the asm directive "+Qo". Do we
> really want to enforce to allow only addresses that are offsetable
> with one byte? If I understand it correctly from the gnu gcc docs, the
> "o" is doing this.
> 
> excerpt from asm/io.h:
> static inline void __raw_writew(u16 val, volatile void __iomem *addr)
> {
>         asm volatile("strh %1, %0"
>                      : "+Qo" (*(volatile u16 __force *)addr)
>                      : "r" (val));
> }
> 
> Bug report:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983
> 
> So do we want to remove the "o" from all __raw_readX and __raw_writeX
> functions? I've tried it and stuff compiles again without errors.

I was under the impression that specifying multiple constraints would mean
that it would try "o", then if that didn't work it would fall back to "Q".
That's certainly the behaviour we've seen in the past... has this changed
with recent toolchains?

The problem with using "Q" on its own is that the compiler tends to generate
the address computation twice: once for "Q" and once for "r" -- this doesn't
happen with "o", where the address is computed once. This leads to an
increase in register pressure and I have seen the compiler choke claiming
that the inline asm block contains "impossible constraints" because it
insists on generating the address twice.

It sounds like we need to:

	(a) Understand what has changed in GCC to cause this error to start
	    cropping up.

	(b) Have a look at the impact of using only "Q" on the generated
	    code (especially register usage for the address).

Will

^ permalink raw reply

* Possible regression in arm/io.h
From: Bastian Hecht @ 2012-10-24 10:38 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Will,

your introduction of the "+Qo" in arch/arm/include/asm/io.h makes some
drivers fail to compile on newer gnu ARM gccs. Like in
drivers/mtd/nand/docg4.c there is an offset of 0x800 from a pointer
used to address I/O memory. This leads to the error message:

/tmp/ccwLMdCy.s: Error: bad immediate value for 8-bit offset (2048)

The gnu gcc people tracked it down to the asm directive "+Qo". Do we
really want to enforce to allow only addresses that are offsetable
with one byte? If I understand it correctly from the gnu gcc docs, the
"o" is doing this.

excerpt from asm/io.h:
static inline void __raw_writew(u16 val, volatile void __iomem *addr)
{
        asm volatile("strh %1, %0"
                     : "+Qo" (*(volatile u16 __force *)addr)
                     : "r" (val));
}

Bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983

So do we want to remove the "o" from all __raw_readX and __raw_writeX
functions? I've tried it and stuff compiles again without errors.

cheers,

Bastian Hecht

^ permalink raw reply

* [PATCH v2 3/3] ARM: dts: enable dma support for auart0 in mx28
From: Huang Shijie @ 2012-10-24 10:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351074456-25863-1-git-send-email-b32955@freescale.com>

enable the dma support for auart0 in mx28.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 arch/arm/boot/dts/imx28.dtsi |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index e16d631..73d1a9f 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -798,6 +798,7 @@
 				compatible = "fsl,imx28-auart", "fsl,imx23-auart";
 				reg = <0x8006a000 0x2000>;
 				interrupts = <112 70 71>;
+				fsl,auart-dma-channel = <8 9>;
 				clocks = <&clks 45>;
 				status = "disabled";
 			};
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 2/3] serial: mxs-auart: add the DMA support for mx28
From: Huang Shijie @ 2012-10-24 10:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351074456-25863-1-git-send-email-b32955@freescale.com>

Only we meet the following conditions, we can enable the DMA support for
auart:

  (1) We enable the DMA support in the dts file, such as
      arch/arm/boot/dts/imx28.dtsi.

  (2) We enable the hardware flow control.

  (3) We use the mx28, not the mx23. Due to hardware bug(see errata: 2836),
      we can not add the DMA support to mx23.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 .../bindings/tty/serial/fsl-mxs-auart.txt          |    8 +
 drivers/tty/serial/mxs-auart.c                     |  318 +++++++++++++++++++-
 2 files changed, 321 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index 2ee903f..273a8d5 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -6,11 +6,19 @@ Required properties:
 - reg : Address and length of the register set for the device
 - interrupts : Should contain the auart interrupt numbers
 
+Optional properties:
+- fsl,auart-dma-channel : The DMA channels, the first is for RX, the other
+		is for TX. If you add this property, it also means that you
+		will enable the DMA support for the auart.
+		Note: due to the hardware bug in imx23(see errata : 2836),
+		only the imx28 can enable the DMA support for the auart.
+
 Example:
 auart0: serial at 8006a000 {
 	compatible = "fsl,imx28-auart", "fsl,imx23-auart";
 	reg = <0x8006a000 0x2000>;
 	interrupts = <112 70 71>;
+	fsl,auart-dma-channel = <8 9>;
 };
 
 Note: Each auart port should have an alias correctly numbered in "aliases"
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 06d7271..d593e0a 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -34,6 +34,8 @@
 #include <linux/io.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/of_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/fsl/mxs-dma.h>
 
 #include <asm/cacheflush.h>
 
@@ -71,6 +73,15 @@
 
 #define AUART_CTRL0_SFTRST			(1 << 31)
 #define AUART_CTRL0_CLKGATE			(1 << 30)
+#define AUART_CTRL0_RXTO_ENABLE			(1 << 27)
+#define AUART_CTRL0_RXTIMEOUT(v)		(((v) & 0x7ff) << 16)
+#define AUART_CTRL0_XFER_COUNT(v)		((v) & 0xffff)
+
+#define AUART_CTRL1_XFER_COUNT(v)		((v) & 0xffff)
+
+#define AUART_CTRL2_DMAONERR			(1 << 26)
+#define AUART_CTRL2_TXDMAE			(1 << 25)
+#define AUART_CTRL2_RXDMAE			(1 << 24)
 
 #define AUART_CTRL2_CTSEN			(1 << 15)
 #define AUART_CTRL2_RTSEN			(1 << 14)
@@ -111,6 +122,7 @@
 #define AUART_STAT_BERR				(1 << 18)
 #define AUART_STAT_PERR				(1 << 17)
 #define AUART_STAT_FERR				(1 << 16)
+#define AUART_STAT_RXCOUNT_MASK			0xffff
 
 static struct uart_driver auart_driver;
 
@@ -122,7 +134,10 @@ enum mxs_auart_type {
 struct mxs_auart_port {
 	struct uart_port port;
 
-	unsigned int flags;
+#define MXS_AUART_DMA_CONFIG	0x1
+#define MXS_AUART_DMA_ENABLED	0x2
+#define MXS_AUART_DMA_TX_SYNC	2  /* bit 2 */
+	unsigned long flags;
 	unsigned int ctrl;
 	enum mxs_auart_type devtype;
 
@@ -130,6 +145,20 @@ struct mxs_auart_port {
 
 	struct clk *clk;
 	struct device *dev;
+
+	/* for DMA */
+	struct mxs_dma_data dma_data;
+	int dma_channel_rx, dma_channel_tx;
+	int dma_irq_rx, dma_irq_tx;
+	int dma_channel;
+
+	struct scatterlist tx_sgl;
+	struct dma_chan	*tx_dma_chan;
+	void *tx_dma_buf;
+
+	struct scatterlist rx_sgl;
+	struct dma_chan	*rx_dma_chan;
+	void *rx_dma_buf;
 };
 
 static struct platform_device_id mxs_auart_devtype[] = {
@@ -155,14 +184,107 @@ static inline int is_imx28_auart(struct mxs_auart_port *s)
 	return s->devtype == IMX28_AUART;
 }
 
+static inline bool auart_dma_enabled(struct mxs_auart_port *s)
+{
+	return s->flags & MXS_AUART_DMA_ENABLED;
+}
+
 static void mxs_auart_stop_tx(struct uart_port *u);
 
 #define to_auart_port(u) container_of(u, struct mxs_auart_port, port)
 
-static inline void mxs_auart_tx_chars(struct mxs_auart_port *s)
+static void mxs_auart_tx_chars(struct mxs_auart_port *s);
+
+static void dma_tx_callback(void *param)
 {
+	struct mxs_auart_port *s = param;
 	struct circ_buf *xmit = &s->port.state->xmit;
 
+	dma_unmap_sg(s->dev, &s->tx_sgl, 1, DMA_TO_DEVICE);
+
+	/* clear the bit used to serialize the DMA tx. */
+	clear_bit(MXS_AUART_DMA_TX_SYNC, &s->flags);
+	smp_mb__after_clear_bit();
+
+	/* wake up the possible processes. */
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(&s->port);
+
+	mxs_auart_tx_chars(s);
+}
+
+static int mxs_auart_dma_tx(struct mxs_auart_port *s, int size)
+{
+	struct dma_async_tx_descriptor *desc;
+	struct scatterlist *sgl = &s->tx_sgl;
+	struct dma_chan *channel = s->tx_dma_chan;
+	u32 pio;
+
+	/* [1] : send PIO. Note, the first pio word is CTRL1. */
+	pio = AUART_CTRL1_XFER_COUNT(size);
+	desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)&pio,
+					1, DMA_TRANS_NONE, 0);
+	if (!desc) {
+		dev_err(s->dev, "step 1 error\n");
+		return -EINVAL;
+	}
+
+	/* [2] : set DMA buffer. */
+	sg_init_one(sgl, s->tx_dma_buf, size);
+	dma_map_sg(s->dev, sgl, 1, DMA_TO_DEVICE);
+	desc = dmaengine_prep_slave_sg(channel, sgl,
+			1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc) {
+		dev_err(s->dev, "step 2 error\n");
+		return -EINVAL;
+	}
+
+	/* [3] : submit the DMA */
+	desc->callback = dma_tx_callback;
+	desc->callback_param = s;
+	dmaengine_submit(desc);
+	dma_async_issue_pending(channel);
+	return 0;
+}
+
+static void mxs_auart_tx_chars(struct mxs_auart_port *s)
+{
+	struct circ_buf *xmit = &s->port.state->xmit;
+
+	if (auart_dma_enabled(s)) {
+		int i = 0;
+		int size;
+		void *buffer = s->tx_dma_buf;
+
+		if (test_and_set_bit(MXS_AUART_DMA_TX_SYNC, &s->flags))
+			return;
+
+		while (!uart_circ_empty(xmit) && !uart_tx_stopped(&s->port)) {
+			size = min_t(u32, UART_XMIT_SIZE - i,
+				     CIRC_CNT_TO_END(xmit->head,
+						     xmit->tail,
+						     UART_XMIT_SIZE));
+			memcpy(buffer + i, xmit->buf + xmit->tail, size);
+			xmit->tail = (xmit->tail + size) & (UART_XMIT_SIZE - 1);
+
+			i += size;
+			if (i >= UART_XMIT_SIZE)
+				break;
+		}
+
+		if (uart_tx_stopped(&s->port))
+			mxs_auart_stop_tx(&s->port);
+
+		if (i) {
+			mxs_auart_dma_tx(s, i);
+		} else {
+			clear_bit(MXS_AUART_DMA_TX_SYNC, &s->flags);
+			smp_mb__after_clear_bit();
+		}
+		return;
+	}
+
+
 	while (!(readl(s->port.membase + AUART_STAT) &
 		 AUART_STAT_TXFF)) {
 		if (s->port.x_char) {
@@ -316,10 +438,155 @@ static u32 mxs_auart_get_mctrl(struct uart_port *u)
 	return mctrl;
 }
 
+static bool mxs_auart_dma_filter(struct dma_chan *chan, void *param)
+{
+	struct mxs_auart_port *s = param;
+
+	if (!mxs_dma_is_apbx(chan))
+		return false;
+
+	if (s->dma_channel == chan->chan_id) {
+		chan->private = &s->dma_data;
+		return true;
+	}
+	return false;
+}
+
+static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s);
+static void dma_rx_callback(void *arg)
+{
+	struct mxs_auart_port *s = (struct mxs_auart_port *) arg;
+	struct tty_struct *tty = s->port.state->port.tty;
+	int count;
+	u32 stat;
+
+	stat = readl(s->port.membase + AUART_STAT);
+	stat &= ~(AUART_STAT_OERR | AUART_STAT_BERR |
+			AUART_STAT_PERR | AUART_STAT_FERR);
+
+	count = stat & AUART_STAT_RXCOUNT_MASK;
+	tty_insert_flip_string(tty, s->rx_dma_buf, count);
+
+	writel(stat, s->port.membase + AUART_STAT);
+	tty_flip_buffer_push(tty);
+
+	/* start the next DMA for RX. */
+	mxs_auart_dma_prep_rx(s);
+}
+
+static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s)
+{
+	struct dma_async_tx_descriptor *desc;
+	struct scatterlist *sgl = &s->rx_sgl;
+	struct dma_chan *channel = s->rx_dma_chan;
+	u32 pio[1];
+
+	/* [1] : send PIO */
+	pio[0] = AUART_CTRL0_RXTO_ENABLE
+		| AUART_CTRL0_RXTIMEOUT(0x80)
+		| AUART_CTRL0_XFER_COUNT(UART_XMIT_SIZE);
+	desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)pio,
+					1, DMA_TRANS_NONE, 0);
+	if (!desc) {
+		dev_err(s->dev, "step 1 error\n");
+		return -EINVAL;
+	}
+
+	/* [2] : send DMA request */
+	sg_init_one(sgl, s->rx_dma_buf, UART_XMIT_SIZE);
+	dma_map_sg(s->dev, sgl, 1, DMA_FROM_DEVICE);
+	desc = dmaengine_prep_slave_sg(channel, sgl, 1, DMA_DEV_TO_MEM,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc) {
+		dev_err(s->dev, "step 2 error\n");
+		return -1;
+	}
+
+	/* [3] : submit the DMA, but do not issue it. */
+	desc->callback = dma_rx_callback;
+	desc->callback_param = s;
+	dmaengine_submit(desc);
+	dma_async_issue_pending(channel);
+	return 0;
+}
+
+static void mxs_auart_dma_exit_channel(struct mxs_auart_port *s)
+{
+	if (s->tx_dma_chan) {
+		dma_release_channel(s->tx_dma_chan);
+		s->tx_dma_chan = NULL;
+	}
+	if (s->rx_dma_chan) {
+		dma_release_channel(s->rx_dma_chan);
+		s->rx_dma_chan = NULL;
+	}
+
+	kfree(s->tx_dma_buf);
+	kfree(s->rx_dma_buf);
+	s->tx_dma_buf = NULL;
+	s->rx_dma_buf = NULL;
+}
+
+static void mxs_auart_dma_exit(struct mxs_auart_port *s)
+{
+
+	writel(AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE | AUART_CTRL2_DMAONERR,
+		s->port.membase + AUART_CTRL2_CLR);
+
+	mxs_auart_dma_exit_channel(s);
+	s->flags &= ~MXS_AUART_DMA_ENABLED;
+}
+
+static int mxs_auart_dma_init(struct mxs_auart_port *s)
+{
+	dma_cap_mask_t mask;
+
+	if (auart_dma_enabled(s))
+		return 0;
+
+	/* We do not get the right DMA channels. */
+	if (s->dma_channel_rx == -1 || s->dma_channel_rx == -1)
+		return -EINVAL;
+
+	/* init for RX */
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_SLAVE, mask);
+	s->dma_channel = s->dma_channel_rx;
+	s->dma_data.chan_irq = s->dma_irq_rx;
+	s->rx_dma_chan = dma_request_channel(mask, mxs_auart_dma_filter, s);
+	if (!s->rx_dma_chan)
+		goto err_out;
+	s->rx_dma_buf = kzalloc(UART_XMIT_SIZE, GFP_KERNEL | GFP_DMA);
+	if (!s->rx_dma_buf)
+		goto err_out;
+
+	/* init for TX */
+	s->dma_channel = s->dma_channel_tx;
+	s->dma_data.chan_irq = s->dma_irq_tx;
+	s->tx_dma_chan = dma_request_channel(mask, mxs_auart_dma_filter, s);
+	if (!s->tx_dma_chan)
+		goto err_out;
+	s->tx_dma_buf = kzalloc(UART_XMIT_SIZE, GFP_KERNEL | GFP_DMA);
+	if (!s->tx_dma_buf)
+		goto err_out;
+
+	/* set the flags */
+	s->flags |= MXS_AUART_DMA_ENABLED;
+	dev_dbg(s->dev, "enabled the DMA support.");
+
+	return 0;
+
+err_out:
+	mxs_auart_dma_exit_channel(s);
+	return -EINVAL;
+
+}
+
 static void mxs_auart_settermios(struct uart_port *u,
 				 struct ktermios *termios,
 				 struct ktermios *old)
 {
+	struct mxs_auart_port *s = to_auart_port(u);
 	u32 bm, ctrl, ctrl2, div;
 	unsigned int cflag, baud;
 
@@ -391,10 +658,23 @@ static void mxs_auart_settermios(struct uart_port *u,
 		ctrl |= AUART_LINECTRL_STP2;
 
 	/* figure out the hardware flow control settings */
-	if (cflag & CRTSCTS)
+	if (cflag & CRTSCTS) {
+		/*
+		 * The DMA has a bug(see errata:2836) in mx23.
+		 * So we can not implement the DMA for auart in mx23,
+		 * we can only implement the DMA support for auart
+		 * in mx28.
+		 */
+		if (is_imx28_auart(s) && (s->flags & MXS_AUART_DMA_CONFIG)) {
+			if (!mxs_auart_dma_init(s))
+				/* enable DMA tranfer */
+				ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
+				       | AUART_CTRL2_DMAONERR;
+		}
 		ctrl2 |= AUART_CTRL2_CTSEN | AUART_CTRL2_RTSEN;
-	else
+	} else {
 		ctrl2 &= ~(AUART_CTRL2_CTSEN | AUART_CTRL2_RTSEN);
+	}
 
 	/* set baud rate */
 	baud = uart_get_baud_rate(u, termios, old, 0, u->uartclk);
@@ -406,6 +686,17 @@ static void mxs_auart_settermios(struct uart_port *u,
 	writel(ctrl2, u->membase + AUART_CTRL2);
 
 	uart_update_timeout(u, termios->c_cflag, baud);
+
+	/* prepare for the DMA RX. */
+	if (auart_dma_enabled(s)) {
+		if (!mxs_auart_dma_prep_rx(s)) {
+			/* Disable the normal RX interrupt. */
+			writel(AUART_INTR_RXIEN, u->membase + AUART_INTR_CLR);
+		} else {
+			mxs_auart_dma_exit(s);
+			dev_err(s->dev, "We can not start up the DMA.\n");
+		}
+	}
 }
 
 static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
@@ -484,6 +775,9 @@ static void mxs_auart_shutdown(struct uart_port *u)
 {
 	struct mxs_auart_port *s = to_auart_port(u);
 
+	if (auart_dma_enabled(s))
+		mxs_auart_dma_exit(s);
+
 	writel(AUART_CTRL2_UARTEN, u->membase + AUART_CTRL2_CLR);
 
 	writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
@@ -717,6 +1011,7 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 		struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
+	u32 dma_channel[2];
 	int ret;
 
 	if (!np)
@@ -730,6 +1025,20 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 	}
 	s->port.line = ret;
 
+	s->dma_irq_rx = platform_get_irq(pdev, 1);
+	s->dma_irq_tx = platform_get_irq(pdev, 2);
+
+	ret = of_property_read_u32_array(np, "fsl,auart-dma-channel",
+					dma_channel, 2);
+	if (ret == 0) {
+		s->dma_channel_rx = dma_channel[0];
+		s->dma_channel_tx = dma_channel[1];
+
+		s->flags |= MXS_AUART_DMA_CONFIG;
+	} else {
+		s->dma_channel_rx = -1;
+		s->dma_channel_tx = -1;
+	}
 	return 0;
 }
 
@@ -787,7 +1096,6 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
 	s->port.type = PORT_IMX;
 	s->port.dev = s->dev = get_device(&pdev->dev);
 
-	s->flags = 0;
 	s->ctrl = 0;
 
 	s->irq = platform_get_irq(pdev, 0);
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 1/3] serial: mxs-auart: distinguish the different SOCs
From: Huang Shijie @ 2012-10-24 10:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351074456-25863-1-git-send-email-b32955@freescale.com>

The current mxs-auart driver is used for both mx23 and mx28.

But in mx23, the DMA has a bug(see errata:2836). We can not add the
DMA support in mx23, but we can add DMA support to auart in mx28.

So in order to add the DMA support for the auart in mx28, we should
distinguish the distinguish SOCs.

This patch adds a new platform_device_id table and a inline function
is_imx28_auart() to distinguish the mx23 and mx28.

Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/tty/serial/mxs-auart.c |   42 ++++++++++++++++++++++++++++++++++-----
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 6db3baa..06d7271 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -114,11 +114,17 @@
 
 static struct uart_driver auart_driver;
 
+enum mxs_auart_type {
+	IMX23_AUART,
+	IMX28_AUART,
+};
+
 struct mxs_auart_port {
 	struct uart_port port;
 
 	unsigned int flags;
 	unsigned int ctrl;
+	enum mxs_auart_type devtype;
 
 	unsigned int irq;
 
@@ -126,6 +132,29 @@ struct mxs_auart_port {
 	struct device *dev;
 };
 
+static struct platform_device_id mxs_auart_devtype[] = {
+	{ .name = "mxs-auart-imx23", .driver_data = IMX23_AUART },
+	{ .name = "mxs-auart-imx28", .driver_data = IMX28_AUART },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, mxs_auart_devtype);
+
+static struct of_device_id mxs_auart_dt_ids[] = {
+	{
+		.compatible = "fsl,imx28-auart",
+		.data = &mxs_auart_devtype[IMX28_AUART]
+	}, {
+		.compatible = "fsl,imx23-auart",
+		.data = &mxs_auart_devtype[IMX23_AUART]
+	}, { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_auart_dt_ids);
+
+static inline int is_imx28_auart(struct mxs_auart_port *s)
+{
+	return s->devtype == IMX28_AUART;
+}
+
 static void mxs_auart_stop_tx(struct uart_port *u);
 
 #define to_auart_port(u) container_of(u, struct mxs_auart_port, port)
@@ -706,6 +735,8 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
 
 static int __devinit mxs_auart_probe(struct platform_device *pdev)
 {
+	const struct of_device_id *of_id =
+			of_match_device(mxs_auart_dt_ids, &pdev->dev);
 	struct mxs_auart_port *s;
 	u32 version;
 	int ret = 0;
@@ -730,6 +761,11 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
 		goto out_free;
 	}
 
+	if (of_id) {
+		pdev->id_entry = of_id->data;
+		s->devtype = pdev->id_entry->driver_data;
+	}
+
 	s->clk = clk_get(&pdev->dev, NULL);
 	if (IS_ERR(s->clk)) {
 		ret = PTR_ERR(s->clk);
@@ -805,12 +841,6 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static struct of_device_id mxs_auart_dt_ids[] = {
-	{ .compatible = "fsl,imx23-auart", },
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, mxs_auart_dt_ids);
-
 static struct platform_driver mxs_auart_driver = {
 	.probe = mxs_auart_probe,
 	.remove = __devexit_p(mxs_auart_remove),
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 0/3] serial: mxs-auart: add DMA support for auart in mx28
From: Huang Shijie @ 2012-10-24 10:27 UTC (permalink / raw)
  To: linux-arm-kernel

This patch set adds the DMA support for auart in mx28.
patch 1:
	In mx23, the DMA has a bug(see errata:2836). We can not add the
	DMA support in mx23, but we can add DMA support to auart in mx28.
	So in order to add the DMA support for the auart in mx28, we should add
	the platform_device_id to distinguish the distinguish SOCs.

patch 2: add the DMA support for mx28
	Only we meet the following conditions, we can enable the DMA support
	for auart:
        (1) We enable the DMA support in the dts file, such as
            arch/arm/boot/dts/imx28.dtsi.
        (2) We enable the hardware flow control.
        (3) We use the mx28, not the mx23. Due to hardware bug(see errata: 2836),
            we can not add the DMA support to mx23.

patch 3: enable the DMA support in dts for mx28 
	You can use the /ttyAPP0 to test this patch set. 
	I tested this patch in mx28-evk board.

v1 --> v2:
	[1] use the inline function, not a macro, to distinguish the SOCs.
	[2] remove the "inline" for mxs_auart_tx_chars().
	[3] use the `pio`, not the `pio[1]` to fill the DMA descriptor.
	[4] use bit operation to serialize the DMA TX.
	[5] use the RX/TX DMA channel to enable the DMA support, remove the
	    "fsl,auart-enable-dma".

Huang Shijie (3):
  serial: mxs-auart: distinguish the different SOCs
  serial: mxs-auart: add the DMA support for mx28
  ARM: dts: enable dma support for auart0 in mx28

 .../bindings/tty/serial/fsl-mxs-auart.txt          |    8 +
 arch/arm/boot/dts/imx28.dtsi                       |    1 +
 drivers/tty/serial/mxs-auart.c                     |  360 +++++++++++++++++++-
 3 files changed, 358 insertions(+), 11 deletions(-)

^ permalink raw reply

* [PATCH 2/2] ASoC: ux500_msp_i2s: Fix devm_* and return code merge error
From: Mark Brown @ 2012-10-24 10:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPDyKFqrS0QT+UO0L3B29UcnjX0bSv3XvWTmC6E_ubgr8NTDiQ@mail.gmail.com>

On Wed, Oct 24, 2012 at 11:34:00AM +0200, Ulf Hansson wrote:
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> 
> I assume this shall go into 3.7, right?
> 
> Kind regards
> Ulf Hansson

You may recall that only yesterday I reminded you not to top post...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/82c742ad/attachment.sig>

^ permalink raw reply

* [PATCH] ARM: at91: dt: evk-pro3: enable uart0 and uart2
From: Fabio Porcedda @ 2012-10-24 10:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121023104212.GD18964@game.jcrosoft.org>

On Tue, Oct 23, 2012 at 12:42 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Hi,
>
>         You will have to wait a few I prepare a patch series for pinctrl
>
>         so most of the current drivers will support pinctrl and requere it
>
>         this will availabe rc3 or rc4 max
>
>         then I will merge more update and boards

Ok, i will wait.

Best regards
-- 
Fabio Porcedda

^ permalink raw reply

* [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
From: Benoit Cousson @ 2012-10-24 10:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5087B47B.8080009@ti.com>

On 10/24/2012 11:27 AM, Sebastien Guiriec wrote:
> Hi Benoit,
> 
> On 10/24/2012 11:15 AM, Benoit Cousson wrote:
>> Hi Seb,
>>
>> Sorry, I missed your previous email, your v2 was the right one.
>> We do have a single INTC in every OMAP, there is no point to repeat the
>> same data hundred times.
>> The DTS are already big enough.
> 
> So in such case we should send a series for audio IP interrupt-parent
> removal for OMAP3/4/5 dtsi file in order to be coherent.

Yes. AM33xx was as well using that in some other IPs.

> Do you want me to do it?

Thanks, but I've just done the patch, I'll sent it in a couple of minutes.

Benoit

> 
>>
>> On 10/24/2012 09:07 AM, Sebastien Guiriec wrote:
>>> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can
>>> add the address space
>>> and interrupt line description inside dtsi file for OMAP5. This serie
>>> is updating the
>>> current OMAP5 IP with missing entry.
>>>
>>> It has been tested on OMAP5 with 3.7-audio-display feature tree.
>>> - MMC is probing and functional
>>> - TWL6041 probing (GPIO/I2C)
>>> - booting (UART)
>>>
>>> Update since v1:
>>> - Add Ack and review
>>> - Fix up commit messages.
>>>
>>> Update since v2:
>>> - Add interrupt-parent.
>>
>> I will take the previous one to avoid the duplication of attributes.
>>
>> On top of that I will remove the ones introduce in audio IPs for
>> consistency on OMAP3/4/5 platforms.
>>
>> Regards,
>> Benoit
>>
> 

^ permalink raw reply

* [PATCH] Revert "serial: omap: fix software flow control"
From: Felipe Balbi @ 2012-10-24 10:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121016151357.GN15569@atomide.com>

Hi Greg,

On Tue, Oct 16, 2012 at 08:13:59AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121016 07:16]:
> > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
> > (serial: omap: fix software flow control).
> > 
> > As Russell has pointed out, that commit isn't fixing
> > Software Flow Control at all, and it actually makes
> > it even more broken.
> > 
> > It was agreed to revert this commit and use Russell's
> > latest UART patches instead.
> > 
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> This seems like the best way to go for the -rc series:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Any chance you can pick this one up for v3.7-rc3 ?

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/f432c6f3/attachment.sig>

^ permalink raw reply

* [PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
From: Benoit Cousson @ 2012-10-24 10:02 UTC (permalink / raw)
  To: linux-arm-kernel

The interrupt-parent attribute does not have to be added in each
node since the DT framework will check for the parent as well to get it.

Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
attributes from every nodes that were using it.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Sebastien Guiriec <s-guiriec@ti.com>
---

This patch was triggered by the thread about Seb's patch [1].
So let's clean the current OMAP/AM stuff right now to be consistent.

The patch applies on top of the for_3.8/dts [2] branch.

Regards,
Benoit

[1] https://lkml.org/lkml/2012/10/24/85
[2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git


 arch/arm/boot/dts/am33xx.dtsi   |   17 +----------------
 arch/arm/boot/dts/omap2.dtsi    |    1 +
 arch/arm/boot/dts/omap2420.dtsi |    2 --
 arch/arm/boot/dts/omap2430.dtsi |    5 -----
 arch/arm/boot/dts/omap3.dtsi    |    6 +-----
 arch/arm/boot/dts/omap4.dtsi    |    6 ------
 arch/arm/boot/dts/omap5.dtsi    |    5 -----
 7 files changed, 3 insertions(+), 39 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 64c2efe..4709269 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -12,6 +12,7 @@
 
 / {
 	compatible = "ti,am33xx";
+	interrupt-parent = <&intc>;
 
 	aliases {
 		serial0 = &uart1;
@@ -94,7 +95,6 @@
 			interrupt-controller;
 			#interrupt-cells = <1>;
 			reg = <0x44e07000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <96>;
 		};
 
@@ -106,7 +106,6 @@
 			interrupt-controller;
 			#interrupt-cells = <1>;
 			reg = <0x4804c000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <98>;
 		};
 
@@ -118,7 +117,6 @@
 			interrupt-controller;
 			#interrupt-cells = <1>;
 			reg = <0x481ac000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <32>;
 		};
 
@@ -130,7 +128,6 @@
 			interrupt-controller;
 			#interrupt-cells = <1>;
 			reg = <0x481ae000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <62>;
 		};
 
@@ -139,7 +136,6 @@
 			ti,hwmods = "uart1";
 			clock-frequency = <48000000>;
 			reg = <0x44e09000 0x2000>;
-			interrupt-parent = <&intc>;
 			interrupts = <72>;
 			status = "disabled";
 		};
@@ -149,7 +145,6 @@
 			ti,hwmods = "uart2";
 			clock-frequency = <48000000>;
 			reg = <0x48022000 0x2000>;
-			interrupt-parent = <&intc>;
 			interrupts = <73>;
 			status = "disabled";
 		};
@@ -159,7 +154,6 @@
 			ti,hwmods = "uart3";
 			clock-frequency = <48000000>;
 			reg = <0x48024000 0x2000>;
-			interrupt-parent = <&intc>;
 			interrupts = <74>;
 			status = "disabled";
 		};
@@ -169,7 +163,6 @@
 			ti,hwmods = "uart4";
 			clock-frequency = <48000000>;
 			reg = <0x481a6000 0x2000>;
-			interrupt-parent = <&intc>;
 			interrupts = <44>;
 			status = "disabled";
 		};
@@ -179,7 +172,6 @@
 			ti,hwmods = "uart5";
 			clock-frequency = <48000000>;
 			reg = <0x481a8000 0x2000>;
-			interrupt-parent = <&intc>;
 			interrupts = <45>;
 			status = "disabled";
 		};
@@ -189,7 +181,6 @@
 			ti,hwmods = "uart6";
 			clock-frequency = <48000000>;
 			reg = <0x481aa000 0x2000>;
-			interrupt-parent = <&intc>;
 			interrupts = <46>;
 			status = "disabled";
 		};
@@ -200,7 +191,6 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c1";
 			reg = <0x44e0b000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <70>;
 			status = "disabled";
 		};
@@ -211,7 +201,6 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c2";
 			reg = <0x4802a000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <71>;
 			status = "disabled";
 		};
@@ -222,7 +211,6 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c3";
 			reg = <0x4819c000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <30>;
 			status = "disabled";
 		};
@@ -231,7 +219,6 @@
 			compatible = "ti,omap3-wdt";
 			ti,hwmods = "wd_timer2";
 			reg = <0x44e35000 0x1000>;
-			interrupt-parent = <&intc>;
 			interrupts = <91>;
 		};
 
@@ -240,7 +227,6 @@
 			ti,hwmods = "d_can0";
 			reg = <0x481cc000 0x2000>;
 			interrupts = <52>;
-			interrupt-parent = <&intc>;
 			status = "disabled";
 		};
 
@@ -249,7 +235,6 @@
 			ti,hwmods = "d_can1";
 			reg = <0x481d0000 0x2000>;
 			interrupts = <55>;
-			interrupt-parent = <&intc>;
 			status = "disabled";
 		};
 	};
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 581cb08..f366482 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -12,6 +12,7 @@
 
 / {
 	compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
+	interrupt-parent = <&intc>;
 
 	aliases {
 		serial0 = &uart1;
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index bfd76b4..4d5ce91 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -30,7 +30,6 @@
 			interrupts = <59>, /* TX interrupt */
 				     <60>; /* RX interrupt */
 			interrupt-names = "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,hwmods = "mcbsp1";
 		};
 
@@ -41,7 +40,6 @@
 			interrupts = <62>, /* TX interrupt */
 				     <63>; /* RX interrupt */
 			interrupt-names = "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,hwmods = "mcbsp2";
 		};
 	};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 4565d97..fa84532 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -32,7 +32,6 @@
 				     <60>, /* RX interrupt */
 				     <61>; /* RX overflow interrupt */
 			interrupt-names = "common", "tx", "rx", "rx_overflow";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp1";
 		};
@@ -45,7 +44,6 @@
 				     <62>, /* TX interrupt */
 				     <63>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp2";
 		};
@@ -58,7 +56,6 @@
 				     <89>, /* TX interrupt */
 				     <90>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp3";
 		};
@@ -71,7 +68,6 @@
 				     <54>, /* TX interrupt */
 				     <55>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp4";
 		};
@@ -84,7 +80,6 @@
 				     <81>, /* TX interrupt */
 				     <82>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp5";
 		};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f38ea87..955cbdc 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -12,6 +12,7 @@
 
 / {
 	compatible = "ti,omap3430", "ti,omap3";
+	interrupt-parent = <&intc>;
 
 	aliases {
 		serial0 = &uart1;
@@ -240,7 +241,6 @@
 				     <59>, /* TX interrupt */
 				     <60>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp1";
 		};
@@ -255,7 +255,6 @@
 				     <63>, /* RX interrupt */
 				     <4>;  /* Sidetone */
 			interrupt-names = "common", "tx", "rx", "sidetone";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <1280>;
 			ti,hwmods = "mcbsp2";
 		};
@@ -270,7 +269,6 @@
 				     <90>, /* RX interrupt */
 				     <5>;  /* Sidetone */
 			interrupt-names = "common", "tx", "rx", "sidetone";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp3";
 		};
@@ -283,7 +281,6 @@
 				     <54>, /* TX interrupt */
 				     <55>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp4";
 		};
@@ -296,7 +293,6 @@
 				     <81>, /* TX interrupt */
 				     <82>; /* RX interrupt */
 			interrupt-names = "common", "tx", "rx";
-			interrupt-parent = <&intc>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp5";
 		};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 812461e..2ab6e68 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -340,7 +340,6 @@
 			      <0x49032000 0x7f>; /* L3 Interconnect */
 			reg-names = "mpu", "dma";
 			interrupts = <0 112 0x4>;
-			interrupt-parent = <&gic>;
 			ti,hwmods = "mcpdm";
 		};
 
@@ -350,7 +349,6 @@
 			      <0x4902e000 0x7f>; /* L3 Interconnect */
 			reg-names = "mpu", "dma";
 			interrupts = <0 114 0x4>;
-			interrupt-parent = <&gic>;
 			ti,hwmods = "dmic";
 		};
 
@@ -361,7 +359,6 @@
 			reg-names = "mpu", "dma";
 			interrupts = <0 17 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp1";
 		};
@@ -373,7 +370,6 @@
 			reg-names = "mpu", "dma";
 			interrupts = <0 22 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp2";
 		};
@@ -385,7 +381,6 @@
 			reg-names = "mpu", "dma";
 			interrupts = <0 23 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp3";
 		};
@@ -396,7 +391,6 @@
 			reg-names = "mpu";
 			interrupts = <0 16 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp4";
 		};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..61a4f2e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -287,7 +287,6 @@
 			      <0x49032000 0x7f>; /* L3 Interconnect */
 			reg-names = "mpu", "dma";
 			interrupts = <0 112 0x4>;
-			interrupt-parent = <&gic>;
 			ti,hwmods = "mcpdm";
 		};
 
@@ -297,7 +296,6 @@
 			      <0x4902e000 0x7f>; /* L3 Interconnect */
 			reg-names = "mpu", "dma";
 			interrupts = <0 114 0x4>;
-			interrupt-parent = <&gic>;
 			ti,hwmods = "dmic";
 		};
 
@@ -308,7 +306,6 @@
 			reg-names = "mpu", "dma";
 			interrupts = <0 17 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp1";
 		};
@@ -320,7 +317,6 @@
 			reg-names = "mpu", "dma";
 			interrupts = <0 22 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp2";
 		};
@@ -332,7 +328,6 @@
 			reg-names = "mpu", "dma";
 			interrupts = <0 23 0x4>;
 			interrupt-names = "common";
-			interrupt-parent = <&gic>;
 			ti,buffer-size = <128>;
 			ti,hwmods = "mcbsp3";
 		};
-- 
1.7.0.4

^ permalink raw reply related

* pwm pin stays on 1 on mxs after pwm_config(pwm, 0, period); pwm_disable(pwm);
From: Uwe Kleine-König @ 2012-10-24  9:56 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

the leds-pwm driver does the following in its led_pwm_set routine:

	if (brightness == 0) {
		pwm_config(led_dat->pwm, 0, period);
		pwm_disable(led_dat->pwm);
	} else {
		pwm_config(led_dat->pwm, brightness * period / max, period);
		pwm_enable(led_dat->pwm);
	}

The effect on setting brightness = 0 on an i.MX28 based machine after
having brightness = max = 255 before is:

pwm_config(..., 0, period) doesn't disable the output at once because of
some logic (in hardware) to prevent glitches. According to the Hardware
manual the new values take effect after the current period (which has the
output on 1). Now pwm_disable stopps the counter, the current period
doesn't run out and the output keeps the 1. So the LED stays on.

Where do I fix that? In the pwm driver (somehow block in pwm_config
until the current period is over, don't know how yet), remove the
pwm_disable in the brightness == 0 case (and then probably making the
whole if block a simple pwm_config(led_dat->pwm, brightness * period /
max, period)) or do we need a new API for that introducing a wait flag
or something different I didn't think of?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH 2/2] ASoC: ux500_msp_i2s: Fix devm_* and return code merge error
From: Ulf Hansson @ 2012-10-24  9:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350306806-5688-2-git-send-email-lee.jones@linaro.org>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

I assume this shall go into 3.7, right?

Kind regards
Ulf Hansson

On 15 October 2012 15:13, Lee Jones <lee.jones@linaro.org> wrote:
> Some ux500_msp_i2s patches clashed with:
>
> b18e93a493626c1446f9788ebd5844d008bbf71c
> ASoC: ux500_msp_i2s: better use devm functions and fix error return code
>
> ... leaving the driver uncompilable. This patch fixes the
> issues encountered.
>
> Cc: alsa-devel at alsa-project.org
> Cc: Liam Girdwood <lrg@ti.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  sound/soc/ux500/ux500_msp_i2s.c |    8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/sound/soc/ux500/ux500_msp_i2s.c b/sound/soc/ux500/ux500_msp_i2s.c
> index b7c996e..a26c6bf 100644
> --- a/sound/soc/ux500/ux500_msp_i2s.c
> +++ b/sound/soc/ux500/ux500_msp_i2s.c
> @@ -18,6 +18,7 @@
>  #include <linux/pinctrl/consumer.h>
>  #include <linux/delay.h>
>  #include <linux/slab.h>
> +#include <linux/io.h>
>  #include <linux/of.h>
>
>  #include <mach/hardware.h>
> @@ -697,14 +698,11 @@ int ux500_msp_i2s_init_msp(struct platform_device *pdev,
>                         platform_data = devm_kzalloc(&pdev->dev,
>                                 sizeof(struct msp_i2s_platform_data), GFP_KERNEL);
>                         if (!platform_data)
> -                               ret = -ENOMEM;
> +                               return -ENOMEM;
>                 }
>         } else
>                 if (!platform_data)
> -                       ret = -EINVAL;
> -
> -       if (ret)
> -               goto err_res;
> +                       return -EINVAL;
>
>         dev_dbg(&pdev->dev, "%s: Enter (name: %s, id: %d).\n", __func__,
>                 pdev->name, platform_data->id);
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] ARM: PMU: fix runtime PM enable
From: Will Deacon @ 2012-10-24  9:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351024268-26734-1-git-send-email-jon-hunter@ti.com>

Hi Jon,

On Tue, Oct 23, 2012 at 09:31:08PM +0100, Jon Hunter wrote:
> Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
> use runtime PM which was prototyped and validated on the OMAP devices. In this
> commit, there is no call pm_runtime_enable() and for OMAP devices
> pm_runtime_enable() is currently being called from the OMAP PMU code when the
> PMU device is created. However, there are two problems with this:
> 
> 1. For any other ARM device wishing to use runtime PM for PMU they will need
>    to call pm_runtime_enable() for runtime PM to work.
> 2. When booting with device-tree and using device-tree to create the PMU
>    device, pm_runtime_enable() needs to be called from within the ARM PERF
>    driver as we are no longer calling any device specific code to create the
>    device. Hence, PMU does not work on OMAP devices that use the runtime PM
>    callbacks when using device-tree to create the PMU device.
> 
> Therefore, add a new platform data variable to indicate whether runtime PM is
> used and if so call pm_runtime_enable() when the PMU device is registered. Note
> that devices using runtime PM may not use the runtime_resume/suspend callbacks
> and so we cannot use the presence of these handlers in the platform data to
> determine whether we should call pm_runtime_enable().

[...]

> diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
> index a26170d..50a6c3b 100644
> --- a/arch/arm/include/asm/pmu.h
> +++ b/arch/arm/include/asm/pmu.h
> @@ -36,6 +36,7 @@
>  struct arm_pmu_platdata {
>  	irqreturn_t (*handle_irq)(int irq, void *dev,
>  				  irq_handler_t pmu_handler);
> +	bool use_runtime_pm;
>  	int (*runtime_resume)(struct device *dev);
>  	int (*runtime_suspend)(struct device *dev);

Can we not just use the presence of the resume/suspend function pointers to
indicate whether we should enable runtime pm or not? i.e. if they're not
NULL, then enable the thing?

Cheers,

Will

^ permalink raw reply

* [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
From: Sebastien Guiriec @ 2012-10-24  9:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5087B196.7090804@ti.com>

Hi Benoit,

On 10/24/2012 11:15 AM, Benoit Cousson wrote:
> Hi Seb,
>
> Sorry, I missed your previous email, your v2 was the right one.
> We do have a single INTC in every OMAP, there is no point to repeat the
> same data hundred times.
> The DTS are already big enough.

So in such case we should send a series for audio IP interrupt-parent 
removal for OMAP3/4/5 dtsi file in order to be coherent.

Do you want me to do it?

>
> On 10/24/2012 09:07 AM, Sebastien Guiriec wrote:
>> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space
>> and interrupt line description inside dtsi file for OMAP5. This serie is updating the
>> current OMAP5 IP with missing entry.
>>
>> It has been tested on OMAP5 with 3.7-audio-display feature tree.
>> - MMC is probing and functional
>> - TWL6041 probing (GPIO/I2C)
>> - booting (UART)
>>
>> Update since v1:
>> - Add Ack and review
>> - Fix up commit messages.
>>
>> Update since v2:
>> - Add interrupt-parent.
>
> I will take the previous one to avoid the duplication of attributes.
>
> On top of that I will remove the ones introduce in audio IPs for
> consistency on OMAP3/4/5 platforms.
>
> Regards,
> Benoit
>

^ permalink raw reply

* [PATCH 1/1] gpio/at91: auto request and configure the pio as input when the interrupt is used via DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-24  9:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdY6xJt2Xob8DHF==LYxNMpocEkbEhy-8DmQpZjZ4VPOXw@mail.gmail.com>

On 09:44 Wed 24 Oct     , Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 3:56 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> 
> > If we do this
> >
> >         interrupt-parent = <&pioA>;
> >         interrupts = <7 0x0>;
> >
> > The current core map the irq correctly but the gpio is not configured as input.
> > The pinctrl configure the pin as gpio with the correct mux parameter but is
> > not responsible to configure it as input.
> >
> > So do it during the xlate
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> 
> Looks OK to me: do you want me to just apply it on my AT91 branch
> on the pinctrl tree?
if 3.8 I prefer via at91 if you don't mind

Best Regards,
J.

^ permalink raw reply

* [PATCH 1/1] pinctrl: at91: fix typo on PULL_UP
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-24  9:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdbVFnDPu1dfYgTaiz48ioDLJxxSmFXkeQiej157DFZRQw@mail.gmail.com>

On 09:45 Wed 24 Oct     , Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 6:28 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> 
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > ---
> >  drivers/pinctrl/pinctrl-at91.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> > index c87c2c5..0757e94 100644
> > --- a/drivers/pinctrl/pinctrl-at91.c
> > +++ b/drivers/pinctrl/pinctrl-at91.c
> > @@ -58,7 +58,7 @@ static struct at91_gpio_chip *gpio_chips[MAX_GPIO_BANKS];
> >
> >  static int gpio_banks;
> >
> > -#define PULL_UP                (0 << 1)
> > +#define PULL_UP                (1 << 0)
> 
> Makes perfect sense. Shall I just apply this to the at91 branch too?
yeah but can the at91 is for 3.7? or 3.8?

Best Regards,
J.
> 
> Yours,
> Linus Walleij

^ permalink raw reply

* [PATCH] arm: mvebu: update defconfig with 3.7 changes
From: Andrew Lunn @ 2012-10-24  9:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5087A94E.4000706@free-electrons.com>

On Wed, Oct 24, 2012 at 10:39:42AM +0200, Gregory CLEMENT wrote:
> On 10/23/2012 10:17 AM, Thomas Petazzoni wrote:
> > The split of 370 and XP into two Kconfig options and the multiplatform
> > kernel support has changed a few Kconfig symbols, so let's update the
> > mvebu_defconfig file with the latest changes.
> 
> Indeed this patch fixes the mvebu_defconfig which was broken.
> But as now mvebu is part of multi_v7_defconfig, shouldn't we just
> removed mvebu_defconfig ?

Hi Gregory

It is probably useful for kisskb.

   Andrew

^ permalink raw reply

* [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
From: Benoit Cousson @ 2012-10-24  9:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1351062434-22514-1-git-send-email-s-guiriec@ti.com>

Hi Seb,

Sorry, I missed your previous email, your v2 was the right one.
We do have a single INTC in every OMAP, there is no point to repeat the
same data hundred times.
The DTS are already big enough.

On 10/24/2012 09:07 AM, Sebastien Guiriec wrote:
> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space
> and interrupt line description inside dtsi file for OMAP5. This serie is updating the
> current OMAP5 IP with missing entry.
> 
> It has been tested on OMAP5 with 3.7-audio-display feature tree.
> - MMC is probing and functional
> - TWL6041 probing (GPIO/I2C)
> - booting (UART)
> 
> Update since v1:
> - Add Ack and review
> - Fix up commit messages.
> 
> Update since v2:
> - Add interrupt-parent.

I will take the previous one to avoid the duplication of attributes.

On top of that I will remove the ones introduce in audio IPs for
consistency on OMAP3/4/5 platforms.

Regards,
Benoit

^ permalink raw reply

* OMAP baseline test results for v3.7-rc2
From: Igor Grinberg @ 2012-10-24  9:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87objt8305.fsf@deeprootsystems.com>

On 10/23/12 20:19, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
>> +Igor
>>
>> Paul Walmsley <paul@pwsan.com> writes:
>>
>>> Here are some basic OMAP test results for Linux v3.7-rc2.
>>> Logs and other details at:
>>>
>>>     http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>>
>> [...]
>>
>>> * 37xx EVM: CORE not entering dynamic off-idle
>>>   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
>>>     off works
>>
>> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
>> SPI1 was not idle when going off.  A quick hack disabling the
>> touchscreen showed that after that, core was hitting idle just fine.
>>
>> I ran out of time today debugging this, but it's definitely realted to
>> the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
>> makes CORE hit retention again in idle.
> 
> OK, found the root cause of this in the GPIO driver.  Patch submitted:
> 
>     http://marc.info/?l=linux-omap&m=135101577925972&w=2

Ok that one looks good.

> 
> however...
> 
>> Igor, I'm hoping you might know what's going on here since we already
>> had some problems with this ads7846 init stuff and you're more familiar
>> with this debounce init.
> 
> ... board files that are setting debounce values for ads7846 will no
> longer work.  
> 
> Currently, omap_ads7846_init() in common-board-devices.c does this:
> 
>    gpio_request_one()
>    gpio_set_debounce()
>    gpio_free()                    
> 
> because of a bug in the GPIO driver, the debounce settings were sticky
> and lingered even after the gpio_free().  That bug has been fixed by the
> above patch, which means the above gpio_set_debounce() is completely
> pointless because it's followed immediately by a gpio_free().
> 
> IMO, the whole GPIO init for the ads7846 needs a rethink as it's
> currently partially done by common-board-devices.c and done (again) in
> the ads7846 driver.  If the gpio_free() isn't done in
> common-board-devices, then the ads7846 driver will currently fail to
> probe/load becasue it can't request a GPIO line.
> 
> Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
> somone else.

Ok, understood, I'll look into this one soon.


-- 
Regards,
Igor.

^ permalink raw reply

* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Gregory CLEMENT @ 2012-10-24  8:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350980365-6698-1-git-send-email-thomas.petazzoni@free-electrons.com>

On 10/23/2012 10:19 AM, Thomas Petazzoni wrote:
> This platform, available in Japan from PlatHome, has a dual-core
> Armada XP, the MV78260. For now, only the two serial ports and the
> three front LEDs are supported. Support for network, SATA, USB and
> other peripherals will be added as drivers for them become available
> for Armada XP in mainline.
And don't forget the SMP support too, MV78260 is supposed to have 2 cores.

Besides this, this patch looks good. I have applied it on a v3.7-rc2
without any problem, and managed to build it also.
So you can add my
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> ---
> This is 3.8 material.
> ---
>  arch/arm/boot/dts/Makefile           |    3 +-
>  arch/arm/boot/dts/openblocks-ax3.dts |   69 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-mvebu/armada-370-xp.c  |    1 +
>  3 files changed, 72 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/openblocks-ax3.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f37cf9f..b7814b9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
>  dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>  	msm8960-cdp.dtb
>  dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> -	armada-xp-db.dtb
> +	armada-xp-db.dtb \
> +	openblocks-ax3.dtb
>  dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
>  	imx53-ard.dtb \
>  	imx53-evk.dtb \
> diff --git a/arch/arm/boot/dts/openblocks-ax3.dts b/arch/arm/boot/dts/openblocks-ax3.dts
> new file mode 100644
> index 0000000..f757116
> --- /dev/null
> +++ b/arch/arm/boot/dts/openblocks-ax3.dts
> @@ -0,0 +1,69 @@
> +/*
> + * Device Tree file for OpenBlocks AX3 board
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "armada-xp-mv78260.dtsi"
> +
> +/ {
> +	model = "PlatHome OpenBlocks AX3 board";
> +	compatible = "plathome,openblocks-ax3", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x40000000>; /* 1 GB */
> +	};
> +
> +	soc {
> +		serial at d0012000 {
> +			clock-frequency = <250000000>;
> +			status = "okay";
> +		};
> +		serial at d0012100 {
> +			clock-frequency = <250000000>;
> +			status = "okay";
> +		};
> +		pinctrl {
> +			led_pins: led-pins-0 {
> +				  marvell,pins = "mpp49", "mpp51", "mpp53";
> +				  marvell,function = "gpio";
> +			};
> +		};
> +		leds {
> +		        compatible = "gpio-leds";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&led_pins>;
> +
> +			red_led {
> +				   label = "red_led";
> +				   gpios = <&gpio1 17 1>;
> +				   default-state = "off";
> +			};
> +
> +			yellow_led {
> +				   label = "yellow_led";
> +				   gpios = <&gpio1 19 1>;
> +				   default-state = "off";
> +			};
> +
> +			green_led {
> +				   label = "green_led";
> +				   gpios = <&gpio1 21 1>;
> +				   default-state = "off";
> +				   linux,default-trigger = "heartbeat";
> +			};
> +		};
> +	};
> +};
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index 49d7915..cd2717b 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
>  static const char * const armada_370_xp_dt_board_dt_compat[] = {
>  	"marvell,a370-db",
>  	"marvell,axp-db",
> +	"plathome,openblocks-ax3",
>  	NULL,
>  };
>  
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Igor Grinberg @ 2012-10-24  8:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdb_zO0G5hsU5hTqnmD6Zju_xBwdmnk6C=Ok1R7-oNT_iQ@mail.gmail.com>

On 10/24/12 10:16, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 8:09 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
> 
>> From: Kevin Hilman <khilman@ti.com>
>>
>> When debounce clocks are disabled, ensure that the banks
>> dbck_enable_mask is cleared also.  Otherwise, context restore on
>> subsequent off-mode transition will restore previous value from the
>> shadow copies (bank->context.debounce*) leading to mismatch state
>> between driver state and hardware state.
>>
>> This was discovered when board code was doing
>>
>>   gpio_request_one()
>>   gpio_set_debounce()
>>   gpio_free()
>>
>> which was leaving the GPIO debounce settings in a confused state.
>> Then, enabling off mode causing bogus state to be restored, leaving
>> GPIO debounce enabled which then prevented the CORE powerdomain from
>> transitioning.
>>
>> Reported-by: Paul Walmsley <paul@pwsan.com>
>> Cc: Igor Grinberg <grinberg@compulab.co.il>
>> Signed-off-by: Kevin Hilman <khilman@ti.com>
> 
> Thanks! Applied with Felipe's and Santosh's ACKs.

If not too late:
Acked-by: Igor Grinberg <grinberg@compulab.co.il>

Kevin, thanks for the patch and sorry I could not respond on time.

-- 
Regards,
Igor.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox