* [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
From: Vinod Koul @ 2012-11-16 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509D6108.1060304@ti.com>
On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote:
> Hi Vinod,
>
> A few people have been asking me if getting device-tree support for DMA
> engine is plan for record for v3.8. I know that you were working through
> implementing a common interface and so I wanted to check how that is
> going. Do you have any insight to when device-tree support may get added?
>
I have not been able to do much work on this for last couple of weeks. I
hope to do it in by this weekend. If not I will merge yours and then
uppdate.
Anyway, DT would be there in 3.8 with or without my changes.
--
~Vinod
^ permalink raw reply
* [PATCH v2 00/10] serial: sh-sci fixes - console PM, SCIFB, SMP lockup, etc.
From: Shinya Kuribayashi @ 2012-11-16 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121116010107.GA6068@kroah.com>
Hi Greg,
On 11/16/2012 10:01 AM, Greg KH wrote:> On Wed, Nov 07, 2012 at 04:18:38PM +0900, Shinya Kuribayashi wrote:
>> On 11/7/2012 3:57 PM, Shinya Kuribayashi wrote:
>>> Hi Paul and serial forks,
>> [...]
>>> Takashi YOSHII (4):
>>> serial: sh-sci: fix condition test to set SCBRR
>>> serial: sh-sci: support lower baud rate
>>> serial: sh-sci: mask SCTFDR/RFDR according to fifosize
>>> serial: sh-sci: fix common SCIFB regmap definition
>>>
>>> Teppei Kamijou (1):
>>> serial: sh-sci: console runtime PM support (revisit)
>>>
>>> drivers/tty/serial/sh-sci.c | 140 ++++++++++++++++++--------------------------
>>> 1 file changed, 56 insertions(+), 84 deletions(-)
>>
>> Oops, I forgot to append proper From: author lines in five commits
>> (patch 04/10 to 09/10). Didn't mean to supersede your authoship.
>>
>> I'd respin the patchset later, waiting for some feedback.
>
> Can you please resend this with this fixed up if you want to get this
> into 3.8?
Thanks for your kind reminder. Here's v2, providing From: authorship
lines in five patches (04 to 08). No logical change in the patches.
--- 8< ---
V2: provide missing authorship From: lines in five patches (04 to 08)
Here are sh-sci serial driver fixes that have been cooking for months
privately on my end:
* rework console PM with the help of serial-core's uart_change_pm()
* provide missing piece in SCIFB support (from Yoshii-san)
* address console write function vs. SMP lockup issue
and so on. Comments and suggestions are welcome.
Build tested with vanilla v3.6, but not boot- nor PM-tested with
newer kernels after v3.4. Anyone with can-sleep shmobile systems,
please give it try.
Thanks in advance,
----------------------------------------------------------------
Shinya Kuribayashi (5):
Revert "sh-sci / PM: Avoid deadlocking runtime PM"
Revert "sh-sci / PM: Use power.irq_safe"
Partially revert "serial: sh-sci: console Runtime PM support"
serial: sh-sci: add locking to console write function to avoid SMP lockup
serial: sh-sci: fix possible race cases on SCSCR register accesses
Takashi YOSHII (4):
serial: sh-sci: fix condition test to set SCBRR
serial: sh-sci: support lower baud rate
serial: sh-sci: mask SCTFDR/RFDR according to fifosize
serial: sh-sci: fix common SCIFB regmap definition
Teppei Kamijou (1):
serial: sh-sci: console runtime PM support (revisit)
drivers/tty/serial/sh-sci.c | 140 ++++++++++++++++++--------------------------
1 file changed, 56 insertions(+), 84 deletions(-)
--
Shinya Kuribayashi
Renesas Electronics
^ permalink raw reply
* [PATCH v2 01/10] Revert "sh-sci / PM: Avoid deadlocking runtime PM"
From: Shinya Kuribayashi @ 2012-11-16 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
This reverts commit 048be431e4 (sh-sci / PM: Avoid deadlocking runtime
PM, from Rafael J. Wysocki <rjw@sisk.pl>, 2012-03-09).
In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9be296c..526ad04 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1752,8 +1752,6 @@ static int sci_startup(struct uart_port *port)
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
- pm_runtime_put_noidle(port->dev);
-
sci_port_enable(s);
ret = sci_request_irq(s);
@@ -1781,8 +1779,6 @@ static void sci_shutdown(struct uart_port *port)
sci_free_irq(s);
sci_port_disable(s);
-
- pm_runtime_get_noresume(port->dev);
}
static unsigned int sci_scbrr_calc(unsigned int algo_id, unsigned int bps,
@@ -2121,7 +2117,6 @@ static int __devinit sci_init_single(struct platform_device *dev,
sci_init_gpios(sci_port);
pm_runtime_irq_safe(&dev->dev);
- pm_runtime_get_noresume(&dev->dev);
pm_runtime_enable(&dev->dev);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 02/10] Revert "sh-sci / PM: Use power.irq_safe"
From: Shinya Kuribayashi @ 2012-11-16 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
This reverts commit 5a50a01bf0 (sh-sci / PM: Use power.irq_safe, from
Rafael J. Wysocki <rjw@sisk.pl>, 2011-08-24).
In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 526ad04..9abe977 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2116,7 +2116,6 @@ static int __devinit sci_init_single(struct platform_device *dev,
sci_init_gpios(sci_port);
- pm_runtime_irq_safe(&dev->dev);
pm_runtime_enable(&dev->dev);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 03/10] Partially revert "serial: sh-sci: console Runtime PM support"
From: Shinya Kuribayashi @ 2012-11-16 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
This partially reverts commit 1ba7622094 (serial: sh-sci: console
Runtime PM support, from Magnus Damm <damm@opensource.se>, 2011-08-03).
The generic 'serial_core' can take care of console PM maintenance,
so all (or at least the first thing) we have to do to get console PM
work properly, is to implement uart_ops ->pm() operation in the sh-sci
serial client driver.
This patch partially reverts the commit above, but leaving sci_reset()
change in place, because sci_reset() is already part of another commit
(73c3d53f38 serial: sh-sci: Avoid FIFO clear for MCE toggle.).
A revised version of console PM support follows next.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 53 +--------------------------------------------
1 file changed, 1 insertion(+), 52 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9abe977..e9e8883 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -99,12 +99,6 @@ struct sci_port {
#endif
struct notifier_block freq_transition;
-
-#ifdef CONFIG_SERIAL_SH_SCI_CONSOLE
- unsigned short saved_smr;
- unsigned short saved_fcr;
- unsigned char saved_brr;
-#endif
};
/* Function prototypes */
@@ -2247,8 +2241,7 @@ static int __devinit serial_console_setup(struct console *co, char *options)
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
- sci_port_disable(sci_port);
-
+ /* TODO: disable clock */
return uart_set_options(port, co, baud, parity, bits, flow);
}
@@ -2291,46 +2284,6 @@ static int __devinit sci_probe_earlyprintk(struct platform_device *pdev)
return 0;
}
-#define uart_console(port) ((port)->cons->index == (port)->line)
-
-static int sci_runtime_suspend(struct device *dev)
-{
- struct sci_port *sci_port = dev_get_drvdata(dev);
- struct uart_port *port = &sci_port->port;
-
- if (uart_console(port)) {
- struct plat_sci_reg *reg;
-
- sci_port->saved_smr = serial_port_in(port, SCSMR);
- sci_port->saved_brr = serial_port_in(port, SCBRR);
-
- reg = sci_getreg(port, SCFCR);
- if (reg->size)
- sci_port->saved_fcr = serial_port_in(port, SCFCR);
- else
- sci_port->saved_fcr = 0;
- }
- return 0;
-}
-
-static int sci_runtime_resume(struct device *dev)
-{
- struct sci_port *sci_port = dev_get_drvdata(dev);
- struct uart_port *port = &sci_port->port;
-
- if (uart_console(port)) {
- sci_reset(port);
- serial_port_out(port, SCSMR, sci_port->saved_smr);
- serial_port_out(port, SCBRR, sci_port->saved_brr);
-
- if (sci_port->saved_fcr)
- serial_port_out(port, SCFCR, sci_port->saved_fcr);
-
- serial_port_out(port, SCSCR, sci_port->cfg->scscr);
- }
- return 0;
-}
-
#define SCI_CONSOLE (&serial_console)
#else
@@ -2340,8 +2293,6 @@ static inline int __devinit sci_probe_earlyprintk(struct platform_device *pdev)
}
#define SCI_CONSOLE NULL
-#define sci_runtime_suspend NULL
-#define sci_runtime_resume NULL
#endif /* CONFIG_SERIAL_SH_SCI_CONSOLE */
@@ -2459,8 +2410,6 @@ static int sci_resume(struct device *dev)
}
static const struct dev_pm_ops sci_dev_pm_ops = {
- .runtime_suspend = sci_runtime_suspend,
- .runtime_resume = sci_runtime_resume,
.suspend = sci_suspend,
.resume = sci_resume,
};
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 04/10] serial: sh-sci: console runtime PM support (revisit)
From: Shinya Kuribayashi @ 2012-11-16 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
From: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
The commit 1ba7622094 (serial: sh-sci: console Runtime PM support,
from Magnus Damm <damm@opensource.se>, 2011-08-03), tried to support
console runtime PM, but unfortunately it didn't work for us for some
reason. We did not investigated further at that time, instead would
like to propose a different approach.
In Linux tty/serial world, to get console PM work properly, a serial
client driver does not have to maintain .runtime_suspend()/..resume()
calls itself, but can leave console power power management handling to
the serial core driver.
This patch moves the sh-sci driver in that direction.
Notes:
* There is room to optimize console runtime PM more aggressively by
maintaining additional local runtime PM calls, but as a first step
having .pm() operation would suffice.
* We still have a couple of direct calls to sci_port_enable/..disable
left in the driver. We have to live with them, because they're out
of serial core's help.
Signed-off-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e9e8883..e65e546 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1746,8 +1746,6 @@ static int sci_startup(struct uart_port *port)
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
- sci_port_enable(s);
-
ret = sci_request_irq(s);
if (unlikely(ret < 0))
return ret;
@@ -1771,8 +1769,6 @@ static void sci_shutdown(struct uart_port *port)
sci_free_dma(port);
sci_free_irq(s);
-
- sci_port_disable(s);
}
static unsigned int sci_scbrr_calc(unsigned int algo_id, unsigned int bps,
@@ -1921,6 +1917,21 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
sci_port_disable(s);
}
+static void sci_pm(struct uart_port *port, unsigned int state,
+ unsigned int oldstate)
+{
+ struct sci_port *sci_port = to_sci_port(port);
+
+ switch (state) {
+ case 3:
+ sci_port_disable(sci_port);
+ break;
+ default:
+ sci_port_enable(sci_port);
+ break;
+ }
+}
+
static const char *sci_type(struct uart_port *port)
{
switch (port->type) {
@@ -2042,6 +2053,7 @@ static struct uart_ops sci_uart_ops = {
.startup = sci_startup,
.shutdown = sci_shutdown,
.set_termios = sci_set_termios,
+ .pm = sci_pm,
.type = sci_type,
.release_port = sci_release_port,
.request_port = sci_request_port,
@@ -2195,16 +2207,12 @@ static void serial_console_write(struct console *co, const char *s,
struct uart_port *port = &sci_port->port;
unsigned short bits;
- sci_port_enable(sci_port);
-
uart_console_write(port, s, count, serial_console_putchar);
/* wait until fifo is empty and last bit has been transmitted */
bits = SCxSR_TDxE(port) | SCxSR_TEND(port);
while ((serial_port_in(port, SCxSR) & bits) != bits)
cpu_relax();
-
- sci_port_disable(sci_port);
}
static int __devinit serial_console_setup(struct console *co, char *options)
@@ -2236,12 +2244,9 @@ static int __devinit serial_console_setup(struct console *co, char *options)
if (unlikely(ret != 0))
return ret;
- sci_port_enable(sci_port);
-
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
- /* TODO: disable clock */
return uart_set_options(port, co, baud, parity, bits, flow);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 05/10] serial: sh-sci: fix condition test to set SCBRR
From: Shinya Kuribayashi @ 2012-11-16 1:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
From: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
SCBRR == 0 is valid value (divide by 1).
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e65e546..ffeca65 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1853,7 +1853,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
dev_dbg(port->dev, "%s: SMR %x, t %x, SCSCR %x\n", __func__, smr_val, t,
s->cfg->scscr);
- if (t > 0) {
+ if (t >= 0) {
if (t >= 256) {
serial_port_out(port, SCSMR, (serial_port_in(port, SCSMR) & ~3) | 1);
t >>= 2;
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 06/10] serial: sh-sci: support lower baud rate
From: Shinya Kuribayashi @ 2012-11-16 1:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
From: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Support prescaler 1/16 and 1/64, in addition to current 1 and 1/4.
Supporting below 2400bps was dropped long time ago in mainline.
Since then, setting lower rate has been resulting in erroneous
register value, without indicating any errors through API.
This patch adds more prescaler to support lower rates again.
This still doesn't check range, but we won't hit the case because
even 50bps at 48MHz clock is now supported.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index ffeca65..3021912 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1814,7 +1814,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
{
struct sci_port *s = to_sci_port(port);
struct plat_sci_reg *reg;
- unsigned int baud, smr_val, max_baud;
+ unsigned int baud, smr_val, max_baud, cks;
int t = -1;
/*
@@ -1848,21 +1848,18 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
uart_update_timeout(port, termios->c_cflag, baud);
- serial_port_out(port, SCSMR, smr_val);
+ for (cks = 0; t >= 256 && cks <= 3; cks++)
+ t >>= 2;
- dev_dbg(port->dev, "%s: SMR %x, t %x, SCSCR %x\n", __func__, smr_val, t,
- s->cfg->scscr);
+ dev_dbg(port->dev, "%s: SMR %x, cks %x, t %x, SCSCR %x\n",
+ __func__, smr_val, cks, t, s->cfg->scscr);
if (t >= 0) {
- if (t >= 256) {
- serial_port_out(port, SCSMR, (serial_port_in(port, SCSMR) & ~3) | 1);
- t >>= 2;
- } else
- serial_port_out(port, SCSMR, serial_port_in(port, SCSMR) & ~3);
-
+ serial_port_out(port, SCSMR, (smr_val & ~3) | cks);
serial_port_out(port, SCBRR, t);
udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
- }
+ } else
+ serial_port_out(port, SCSMR, smr_val);
sci_init_pins(port, termios->c_cflag);
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 07/10] serial: sh-sci: mask SCTFDR/RFDR according to fifosize
From: Shinya Kuribayashi @ 2012-11-16 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
From: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Current mask 0xff to SCTFDR/RFDR damages SCIFB, because the
registers on SCIFB have 9-bit data (0 to 256).
This patch changes the mask according to port->fifosize.
Though I'm not sure if the mask is really needed (I don't know if
there are variants which have non-zero upper bits), it is safer.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 3021912..63a3bd0 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -485,7 +485,7 @@ static int sci_txfill(struct uart_port *port)
reg = sci_getreg(port, SCTFDR);
if (reg->size)
- return serial_port_in(port, SCTFDR) & 0xff;
+ return serial_port_in(port, SCTFDR) & ((port->fifosize << 1) - 1);
reg = sci_getreg(port, SCFDR);
if (reg->size)
@@ -505,7 +505,7 @@ static int sci_rxfill(struct uart_port *port)
reg = sci_getreg(port, SCRFDR);
if (reg->size)
- return serial_port_in(port, SCRFDR) & 0xff;
+ return serial_port_in(port, SCRFDR) & ((port->fifosize << 1) - 1);
reg = sci_getreg(port, SCFDR);
if (reg->size)
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 08/10] serial: sh-sci: fix common SCIFB regmap definition
From: Shinya Kuribayashi @ 2012-11-16 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
From: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
About FIFO count, there are two variants of SCIFs which show
a) TX count in upper, RX count in lower byte of FDR register
b) TX count in TFDR register, RX count in RFDR register
Common SCIFB regmap in current source code is defined as "a".
At least 7372 and 73a0 HW manual say their SICFB are "b".
This patch alters the definition to "b", considering the current
one has come from a mistake. The reason is as follows.
The flag SCIFB sh-sci driver means it has 256 byte FIFO.
The count is from 0(empty) to 256(full), that makes 9-bit.
Because FDR is 16-bit register, it can not hold two 9-bits.
That's why, SCIFB can not be "a".
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 63a3bd0..502fa47 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -196,9 +196,9 @@ static struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
[SCxSR] = { 0x14, 16 },
[SCxRDR] = { 0x60, 8 },
[SCFCR] = { 0x18, 16 },
- [SCFDR] = { 0x1c, 16 },
- [SCTFDR] = sci_reg_invalid,
- [SCRFDR] = sci_reg_invalid,
+ [SCFDR] = sci_reg_invalid,
+ [SCTFDR] = { 0x38, 16 },
+ [SCRFDR] = { 0x3c, 16 },
[SCSPTR] = sci_reg_invalid,
[SCLSR] = sci_reg_invalid,
},
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 09/10] serial: sh-sci: add locking to console write function to avoid SMP lockup
From: Shinya Kuribayashi @ 2012-11-16 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
Symptom:
When entering the suspend with Android logcat running, printk() call
gets stuck and never returns. The issue can be observed at printk()s
on nonboot CPUs when going to offline with their interrupts disabled,
and never seen at boot CPU (core0 in our case).
Details:
serial_console_write() lacks of appropriate spinlock handling.
In SMP systems, as long as sci_transmit_chars() is being processed
at one CPU core, serial_console_write() can stuck at the other CPU
core(s), when it tries to access to the same serial port _without_
a proper locking. serial_console_write() waits for the transmit FIFO
getting empty, while sci_transmit_chars() writes data to the FIFO.
In general, peripheral interrupts are routed to boot CPU (core0) by
Linux ARM standard affinity settings. SCI(F) interrupts are handled
by core0, so sci_transmit_chars() is processed on core0 as well.
When logcat is running, it writes enormous log data to the kernel at
every moment, forever. So core0 can repeatedly continue to process
sci_transmit_chars() in its interrupt handler, which eventually makes
the other CPU core(s) stuck at serial_console_write().
Looking at serial/8250.c, this is a known console write lockup issue
with SMP kernels. Fix the sh-sci driver in the same way 8250.c does.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
Similar fixes can be found at:
|commit ef605fdb33883d687cff5ba75095a91b313b4966
|Author: Rabin Vincent <rabin.vincent@stericsson.com>
|Date: Tue Jan 17 11:52:28 2012 +0100
|
| serial: amba-pl011: lock console writes against interrupts
|commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d
|Author: Xinyu Chen <xinyu.chen@freescale.com>
|Date: Mon Aug 27 09:36:51 2012 +0200
|
| tty: serial: imx: console write routing is unsafe on SMP
drivers/tty/serial/sh-sci.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 502fa47..0b8d029 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2202,7 +2202,21 @@ static void serial_console_write(struct console *co, const char *s,
{
struct sci_port *sci_port = &sci_ports[co->index];
struct uart_port *port = &sci_port->port;
- unsigned short bits;
+ unsigned short bits, ctrl;
+ unsigned long flags;
+ int locked = 1;
+
+ local_irq_save(flags);
+ if (port->sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&port->lock);
+ else
+ spin_lock(&port->lock);
+
+ /* first save the SCSCR then disable the interrupts */
+ ctrl = serial_port_in(port, SCSCR);
+ serial_port_out(port, SCSCR, sci_port->cfg->scscr);
uart_console_write(port, s, count, serial_console_putchar);
@@ -2210,6 +2224,13 @@ static void serial_console_write(struct console *co, const char *s,
bits = SCxSR_TDxE(port) | SCxSR_TEND(port);
while ((serial_port_in(port, SCxSR) & bits) != bits)
cpu_relax();
+
+ /* restore the SCSCR */
+ serial_port_out(port, SCSCR, ctrl);
+
+ if (locked)
+ spin_unlock(&port->lock);
+ local_irq_restore(flags);
}
static int __devinit serial_console_setup(struct console *co, char *options)
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 10/10] serial: sh-sci: fix possible race cases on SCSCR register accesses
From: Shinya Kuribayashi @ 2012-11-16 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
In the previous commit, console write function (serial_console_write)
is changed to disable SCI interrupts while printing console strings.
This introduces possible race cases in the serial startup / shutdown
functions on SMP systems.
This patch fixes the sh-sci in the same way as commit 9ec1882df2
(tty: serial: imx: console write routing is unsafe on SMP, from
Xinyu Chen <xinyu.chen@freescale.com>, 2012-08-27) did.
There could be several consumers of the console,
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which opens /dev/console and writes with sys_write()
The shell goes into the normal UART open() and write() system calls,
while the other two go into the console operations. The open() call
invokes serial startup function (sci_startup), which will write to
the SCSCR register (to enable or disable SCI interrupts) without any
locking. This will conflict with the console serial function.
Add spinlock protections in sci_startup() and sci_shutdown() properly.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 0b8d029..8e3c7f7 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1742,6 +1742,7 @@ static inline void sci_free_dma(struct uart_port *port)
static int sci_startup(struct uart_port *port)
{
struct sci_port *s = to_sci_port(port);
+ unsigned long flags;
int ret;
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
@@ -1752,8 +1753,10 @@ static int sci_startup(struct uart_port *port)
sci_request_dma(port);
+ spin_lock_irqsave(&port->lock, flags);
sci_start_tx(port);
sci_start_rx(port);
+ spin_unlock_irqrestore(&port->lock, flags);
return 0;
}
@@ -1761,11 +1764,14 @@ static int sci_startup(struct uart_port *port)
static void sci_shutdown(struct uart_port *port)
{
struct sci_port *s = to_sci_port(port);
+ unsigned long flags;
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
+ spin_lock_irqsave(&port->lock, flags);
sci_stop_rx(port);
sci_stop_tx(port);
+ spin_unlock_irqrestore(&port->lock, flags);
sci_free_dma(port);
sci_free_irq(s);
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 00/10] serial: sh-sci fixes - console PM, SCIFB, SMP lockup, etc.
From: Greg KH @ 2012-11-16 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A59B9B.2010501@renesas.com>
On Fri, Nov 16, 2012 at 10:49:15AM +0900, Shinya Kuribayashi wrote:
> Hi Greg,
>
> On 11/16/2012 10:01 AM, Greg KH wrote:> On Wed, Nov 07, 2012 at 04:18:38PM +0900, Shinya Kuribayashi wrote:
> >> On 11/7/2012 3:57 PM, Shinya Kuribayashi wrote:
> >>> Hi Paul and serial forks,
> >> [...]
> >>> Takashi YOSHII (4):
> >>> serial: sh-sci: fix condition test to set SCBRR
> >>> serial: sh-sci: support lower baud rate
> >>> serial: sh-sci: mask SCTFDR/RFDR according to fifosize
> >>> serial: sh-sci: fix common SCIFB regmap definition
> >>>
> >>> Teppei Kamijou (1):
> >>> serial: sh-sci: console runtime PM support (revisit)
> >>>
> >>> drivers/tty/serial/sh-sci.c | 140 ++++++++++++++++++--------------------------
> >>> 1 file changed, 56 insertions(+), 84 deletions(-)
> >>
> >> Oops, I forgot to append proper From: author lines in five commits
> >> (patch 04/10 to 09/10). Didn't mean to supersede your authoship.
> >>
> >> I'd respin the patchset later, waiting for some feedback.
> >
> > Can you please resend this with this fixed up if you want to get this
> > into 3.8?
>
> Thanks for your kind reminder. Here's v2, providing From: authorship
> lines in five patches (04 to 08). No logical change in the patches.
All now applied, thanks.
greg k-h
^ permalink raw reply
* [PATCH 01/10] ARM: imx6q: print silicon version on boot
From: Shawn Guo @ 2012-11-16 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <72B629D8-8CD8-42E2-91A3-CF0532B15E5F@mentor.com>
On Thu, Nov 15, 2012 at 06:09:31PM +0000, Moseley, Drew wrote:
> On Oct 23, 2012, at 11:22 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > i.MX6Q has 3 revisions 1.0, 1.1 and 1.2. Print revision on boot.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > ---
> > arch/arm/mach-imx/mach-imx6q.c | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
>
> Hi Shawn,
>
> An addition to this patch to add some error checking. Thoughts?
>
It looks good. I just squashed the changes into the original patch
with your sob added. Thanks.
Note, the patch series will probably postponed to 3.9 due to the
dependency on other tree and the fact that I wait for a TO1.2 hardware
to test the power gating state.
Shawn
> Drew
>
>
>
>
> Add error checking to imx6q_revision()
>
> Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
> ---
> arch/arm/mach-imx/mach-imx6q.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 265c311..072e32a 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -54,9 +54,16 @@ static int imx6q_revision(void)
>
> if (!rev) {
> np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
> + if (!np)
> + return IMX_CHIP_REVISION_UNKNOWN;
> base = of_iomap(np, 0);
> + if (!base) {
> + of_node_put(np);
> + return IMX_CHIP_REVISION_UNKNOWN;
> + }
> rev = readl_relaxed(base + IMX6Q_ANALOG_DIGPROG);
> iounmap(base);
> + of_node_put(np);
> }
>
> switch (rev & 0xff) {
> --
> 1.8.0
>
^ permalink raw reply
* [Patch v6 1/4] ARM: at91: atmel-ssc: add pinctrl support
From: Bo Shen @ 2012-11-16 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121116010310.GG4387@opensource.wolfsonmicro.com>
Hi J,
On 11/16/2012 9:03, Mark Brown wrote:
> On Wed, Nov 14, 2012 at 06:09:08PM +0800, Bo Shen wrote:
>> Add pinctrl support for atmel ssc peripheral
>>
>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>
> This generates lots of conflicts in the pinctrl stuff in the DTS - looks
> like it was generated against -next. Can you please regenerate against
> my atmel branch with just the changes to add the pinmux information on
> the SSC nodes? Or possbily this can just be applied direct to the
> pinctrl branch (we'll get an add/add conflict with the SSC nodes though
> that should be simple to resolve, a cross merge might be helpful).
As Mark suggested, would this patch be split into 2 patches? One is for
atmel ssc add pinmux information go into ASoC tree, and the other add
ssc node into dts file go into pinctrl tree. Would this be ok?
Thanks.
Best Regards,
Bo Shen
^ permalink raw reply
* Incorrect RAM memory size
From: Woody Wu @ 2012-11-16 2:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
In general, I want to know how the ram memory size is determined by the
kernel. The relevant kernel log info is something like: "Memory: xxMB =
xxMB total".
In my s3c2410 board, it has 64MB, but the kernel reports only 16MB. The
kernel version is 2.6.36.
Is there any configuration file I should go modify to tell the kernel or
that's is automatically detected at kernel initialization phase?
Thanks in advance.
--
-woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [RFC] dt/platform: Use cell-index for device naming if available
From: Stepan Moskovchenko @ 2012-11-16 2:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115161020.3205E3E194B@localhost>
On 11/15/2012 8:10 AM, Grant Likely wrote:
> On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko <stepanm@codeaurora.org> wrote:
>> On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote:
>>>
>>>> On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring <robherring2@gmail.com>
>>>> wrote:
>>>>> On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
>>>>>> Use the cell-index property to construct names for platform
>>>>>> devices, falling back on the existing scheme of using the
>>>>>> device register address if cell-index is not specified.
>>>>>>
>>>>>> The cell-index property is a more useful device identifier,
>>>>>> especially in systems containing several numbered instances
>>>>>> of a particular hardware block, since it more easily
>>>>>> illustrates how devices relate to each other.
>>>>>>
>>>>>> Additionally, userspace software may rely on the classic
>>>>>> <name>.<id> naming scheme to access device attributes in
>>>>>> sysfs, without having to know the physical addresses of
>>>>>> that device on every platform the userspace software may
>>>>>> support. Using cell-index for device naming allows the
>>>>>> device addresses to be hidden from userspace and to be
>>>>>> exposed by logical device number without having to rely on
>>>>>> auxdata to perform name overrides. This allows userspace to
>>>>>> make assumptions about which sysfs nodes map to which
>>>>>> logical instance of a specific hardware block.
>>>>>>
>>>>>> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
>>>>>> ---
>>>>>> I had also considered using something like the linux,label property to
>>>>>> allow
>>>>>> custom names for platform devices without resorting to auxdata, but the
>>>>>> cell-index approach seems more in line with what cell-index was
>>>>>> intended for
>>>>>> and with what the pre-DT platform device naming scheme used to be.
>>>>>> Please let
>>>>>> me know if you think there is a better way to accomplish this.
>>>>>>
>>>>>> This is just being sent out as an RFC for now. If there are no
>>>>>> objections, I
>>>>>> will send this out as an official patch, along with (or combined with)
>>>>>> a patch
>>>>>> to fix up the device names in things like clock tables of any affected
>>>>>> platforms.
>>>>>
>>>>> cell-index is basically deprecated. This has been discussed multiple
>>>>> times in the past. You can use auxdata if you really need to have the
>>>>> old name.
>>>>
>>>> Actually, I think it would be fine to use an /aliases entry to set the
>>>> device name. That's the place to put global namespace information.
>>>>
>>>> g.
>>>>
>>>
>>> Ah, thank you. I would prefer to stay away from auxdata, since it involves
>>> placing more platform-specific data into the kernel, and it is my
>>> understanding that auxdata is intended as a temporary measure. The
>>> /aliases approach looks interesting, and I'll see what I can do with it -
>>> hopefully I can have an RFC / patch soon. It looks like we would want an
>>> "inverse" alias lookup- that is, we would need to know which alias
>>> corresponds to a given node. Is it possible for a node to have multiple
>>> aliases?
>
> yes
>
>>> If so, which shall we use to create the device name? Anyway, I
>>> will further look into how these aliases work.
>
> Well, why exactly do you want to control the names of devices? Is it so
> that devices match up with what they are, or is it to make things match
> up with things like clocks and regulators. If it is the latter, then no,
> don't do this. Use auxdata. When the kernel requires a specific name for
> a device it is very much a kernel *internal* detail. It does not make
> sense to encode that into the device tree when it isn't something part
> of the binding.
>
>
>>>
>>> Steve
>>
>> Hi Grant,
>>
>> Looking through the alias code, I see that the stem and the alias ID are
>> stored and parsed separately. For the current way of using aliases, this
>> makes sense. However, can you please clarify what you meant by using an
>> /aliases entry to set the device name?
>>
>> The first and most straightforward approach would be to use the entire
>> alias name as the device name, making no distinction between the alias
>> stem and ID. However, since it is possible to have multiple aliases to
>> the same device, which of the aliases shall we use to construct the
>> device name? Additionally, this may cause possible problems for legacy
>> software that expects names in the format of <name>.<ID>, since '.' is
>> not a valid character for alias names as defined by the DT spec,
>> although strictly speaking this approach would successfully solve the
>> problem of giving devices predictable and controllable names.
>>
>> Another way an /aliases entry could be used to set the device name is to
>> have a <name>.<ID> naming scheme, where the name comes from node->name
>> (as is done in of_device_make_bus_id) and the ID gets queried using
>> of_alias_get_id(). We would need to create a new alias stem for this
>> purpose, and suppose that something like "platform" would work. The
>> name-setting code would then roughly look as follows:
>>
>> + alias_id = of_alias_get_id(node, "platform");
>> + if (alias_id != -ENODEV) {
>> + dev_set_name(dev, "%s.%d", node->name, alias_id);
>> + return;
>> + }
>>
>> The downside to this approach is that it imposes the restriction that
>> device ID numbers now have to be unique throughout the system, whereas
>> before only the <name>.<ID> combinations had to be unique. This is the
>> result of only the ID number being present in the alias table, with each
>> such ID number having the "platform" stem, and the restriction that node
>> properties shall have unique names.
>
> Again, this all looks like trying to manipulate names to keep the kernel
> happy. Since the kernel has the restrictions on naming, that is where
> the fixups should be made. Either by devres or by changing the expected
> name in the clk/regulator tables.
>
>> A third possible solution is to use an alias stem prefix for defining
>> the device name. That is, the alias to set the device name would have
>> some prefix (such as "platform-" for example) and the aliases would look
>> something like platform-<name><ID>. The code to assign device names
>> would find the matching alias containing the "platform-" prefix, strip
>> the prefix, and use the resulting name and ID to construct the device
>> name. This approach would make it more obvious as to which of several
>> aliases is used to set the device name, but it imposes additional
>> structure on the stem names and causes any aliases starting with
>> "platform-" to become magical, which bothers me slightly.
>
> And specific to the current Linux implementation details.
>
>> Do any of these describe what you intended when you suggested using the
>> /aliases node to set device names, or is there another approach that I
>> have missed? Can you please elaborate further?
>
> Really, all I was thinking about was allowing the device that has an
> alias "eth0" to be given a name with 'eth0' in it somewhere. Since names
> like that are a global namespace, /aliases is the place to get them
> because there is no chance of colision with that approach.
>
> g.
>
Hi Grant,
I realize that auxdata is the correct thing to use for keeping the
kernel happy (for things like clocks and regulator consumers) but this
is not the problem I am trying to solve. My goal is to try to keep
userspace happy by trying to create common and predictable names for
functionally equivalent devices across different hardware platforms.
For instance, two similar SoCs may have an SDCC controller which may be
logically referred to as "the first SDCC device", though the physical
address of this device may be different on the two SoCs. And, due to the
<reg>.<name> naming convention, the sysfs entries associated with a
particular device will be a dependent on the physical address of the device.
If userspace wants to touch the sysfs entries of what can logically be
described as "the first SDCC device", then userspace needs to know the
physical address of this device on each SoC variant it may be running
on, since the path to the sysfs entries for this device will be based on
the physical address of the device. By using a device naming scheme that
replaces the physical address with a logical device number, the
userspace-facing interface for each device (such as sysfs entries) could
be kept common across SoC variants even when device physical addresses
can move around but devices still have the same logical assignments.
I realize that this problem can be solved by using auxdata to set the
device name, but in this case the only purpose of the auxdata would be
to keep userspace happy, since all the other in-kernel relationships
(for things like clocks and regulators) can already work without having
to rely on auxdata. So, introducing auxdata just for consistency of
userspace-facing names seems silly and, I am trying to come up with a
more appropriate solution.
What do you think?
Steve
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* high resolution EhrPWM with Ubuntu Linux on BeagleBone
From: Sameer Parekh @ 2012-11-16 3:18 UTC (permalink / raw)
To: linux-arm-kernel
Hello--
Apologies if this is the wrong list for this question-- if someone could point me to the right list, I would appreciate it.
I am trying to get high resolution PWM out of my beagle bone running ubuntu 12.10 to control servos and other hobby RC gear. I have successfully been able to use the /sys/class/pwm/ehrpwm to create PWM output, however I am having trouble with the resolution.
The RC standard is to run at 50Hz with each PWM signal lasting from 1000-2000us. I have set the frequency to 50, however it appears that the duty_cycle must be passed as an integer percentage. Therefore in order to get 1ms I set the duty cycle to 5 and to get 2ms I set the duty cycle to 10. This gives me only 200us resolution, while I would prefer resolution closer to 1us,
Is that possible using the standard pwm support?
Thanks,
--
Sameer Parekh
Falkor Systems, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121115/8c4a6ae2/attachment-0001.html>
^ permalink raw reply
* Decoding the PTM traces
From: Arun KS @ 2012-11-16 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKZGPANSW9EEN6tRW7cPxDQkicKBWC9eK9A3dQSH1d61nXsHKQ@mail.gmail.com>
Hello Arve,
On Thu, Nov 15, 2012 at 9:11 AM, Arun KS <arunks.linux@gmail.com> wrote:
> Hello Arve,
>
> On Thu, Nov 15, 2012 at 4:55 AM, Arve Hj?nnev?g <arve@android.com> wrote:
>> On Wed, Nov 14, 2012 at 6:04 AM, Arun KS <arunks.linux@gmail.com> wrote:
>>> Hello,
>>>
>>> I m trying to capture and decode PTM trace from Cortex A9 dual core.
>>>
>>> I m successful in configuring the driver(arch/arm/kernel/etm.c) and
>>> setting the funnel to get data in ETB.
>>> But I don't know how to decode these traces.
>>>
>>> Anyone has any pointers?
>>>
>>> Thanks,
>>> Arun
>>
>> I attached some tools I use to decode the traces. I have used this on
>> the A8, A9 and A15. I assume since you cc-ed me you have already
>> applied the kernel patches I posted a while back. Without them you
>> will not get useful trace data from a dual core processor.
>
> Thank you very much for the tools. Hope I have taken all your patches.
>
> Here is how my git log --oneline looks on arch/arm/kernel/etm.c
>
> 75cbaea ARM: etm: Add sysfs entry to enable return stack if supported
> 434032a ARM: etm: Add sysfs entry to disable branch_output flag
> c6b1c35 ARM: etm: Add sysfs entry to set context-id-size
> cfb8dc5 ARM: etm: Add sysfs entry to enable timestamps if supported
> d263bc7 ARM: etm: Check arch version and disable data tracing for ptm
> eff62a8 ARM: etm: Wait for etm/ptm(s) to stop before requesting PowerDown
> 4246983 ARM: etm: Power down etm(s) when tracing is not enabled
> 992cd59 ARM: etm: Support multiple ETMs/PTMs.
> 3a91f3e ARM: etm: Return the entire trace buffer if it is empty after reset
> fe05bda ARM: etm: Add some missing locks and error checks
> 0c3da53 ARM: etm: Configure data tracing
> d71c695 ARM: etm: Allow range selection
> f13ae47 ARM: etm: Don't try to clear the buffer full status after
> reading the buffer
> 8511b5b ARM: etm: Don't limit tracing to only non-secure code.
> d387659 ARM: etm: Don't require clock control
> 73017a5 arm: fix implicit module.h users by adding it to arch/arm as required.
> 8e88069 ARM: 6838/1: etm: fix section mismatch warning
> aa25afa ARM: amba: make probe() functions take const id tables
> 092e0e7 Merge branch 'llseek' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/bkl
> 6038f37 llseek: automatically add .llseek fop
> 8234eae ARM: 6291/1: coresight: move struct tracectx inside etm driver
> 1495cc9 Input: sysrq - drop tty argument from sysrq ops handlers
> 988257c ARM: 6294/1: etm: do a dummy read from OSSRR during initialization
> 9e354ea ARM: 6292/1: coresight: add ETM management registers
> c5d6c77 ARM: 5841/1: a driver for on-chip ETM and ETB
>
> I ll let you know the results.
I m able to see decoded ptm traces using the following command,
python3.1 etm-objdump.py --trace-decoder=./etm
--trace-decoder-options="--pft-1.1 --sourceid-match 2" ptm.bin
Thanks,
Arun
>
> thanks,
> Arun
>>
>> --
>> Arve Hj?nnev?g
^ permalink raw reply
* [PATCH 7/8] ata: highbank: mark ahci_highbank_probe as __devinit
From: Jeff Garzik @ 2012-11-16 4:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352238933-4886-8-git-send-email-arnd@arndb.de>
On 11/06/2012 04:55 PM, Arnd Bergmann wrote:
> The ahci_highbank_probe function is incorrectly marked as __init,
> which means it can get discarded at boot time, which might be
> a problem if for some reason the device only becomes operational
> after loading another module.
>
> Using __devinit instead avoids seeing this warning for every build:
>
> WARNING: vmlinux.o(.data+0xf7b0): Section mismatch in reference from the
> variable ahci_highbank_driver to the function .init.text:ahci_highbank_probe()
> The variable ahci_highbank_driver references
> the function __init ahci_highbank_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Jeff Garzik <jgarzik@redhat.com>
> ---
> drivers/ata/sata_highbank.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
^ permalink raw reply
* [Patch v6 1/4] ARM: at91: atmel-ssc: add pinctrl support
From: Mark Brown @ 2012-11-16 4:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A5A843.2060902@atmel.com>
On Fri, Nov 16, 2012 at 10:43:15AM +0800, Bo Shen wrote:
> On 11/16/2012 9:03, Mark Brown wrote:
> >This generates lots of conflicts in the pinctrl stuff in the DTS - looks
> >like it was generated against -next. Can you please regenerate against
> >my atmel branch with just the changes to add the pinmux information on
> >the SSC nodes? Or possbily this can just be applied direct to the
> >pinctrl branch (we'll get an add/add conflict with the SSC nodes though
> >that should be simple to resolve, a cross merge might be helpful).
> As Mark suggested, would this patch be split into 2 patches? One is
> for atmel ssc add pinmux information go into ASoC tree, and the
> other add ssc node into dts file go into pinctrl tree. Would this be
> ok?
It's more of an either/or thing but the two patches would be OK, then we
can work out which to apply.
-------------- 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/20121116/9be1c5b7/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dt: tegra: cardhu: Add drm components
From: Mark Zhang @ 2012-11-16 5:00 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds the rgb and hdmi nodes which are necessary for
tegra drm driver.
Signed-off-by: Mark Zhang <markz@nvidia.com>
---
arch/arm/boot/dts/tegra30-cardhu.dtsi | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index bdb2a66..9af6987 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -27,6 +27,25 @@
model = "NVIDIA Tegra30 Cardhu evaluation board";
compatible = "nvidia,cardhu", "nvidia,tegra30";
+ host1x {
+ dc at 54200000 {
+ rgb {
+ status = "okay";
+ nvidia,ddc-i2c-bus = <&rgbddc>;
+ };
+ };
+
+ hdmi {
+ status = "okay";
+
+ vdd-supply = <&sys_3v3_reg>;
+ pll-supply = <&vio_reg>;
+
+ nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
+ nvidia,ddc-i2c-bus = <&hdmiddc>;
+ };
+ };
+
memory {
reg = <0x80000000 0x40000000>;
};
@@ -114,7 +133,7 @@
clock-frequency = <408000000>;
};
- i2c at 7000c000 {
+ rgbddc: i2c at 7000c000 {
status = "okay";
clock-frequency = <100000>;
};
@@ -137,7 +156,7 @@
};
};
- i2c at 7000c700 {
+ hdmiddc: i2c at 7000c700 {
status = "okay";
clock-frequency = <100000>;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 01/16] gpio: SPEAr: add spi chipselect control driver
From: Viresh Kumar @ 2012-11-16 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a92290e8a3b1a19c3a5e864edfa7badfc2af5d0.1352608333.git.viresh.kumar@linaro.org>
From: Shiraz Hashim <shiraz.hashim@st.com>
SPEAr platform provides a provision to control chipselects of ARM PL022
Prime Cell spi controller through its system registers, which otherwise
remains under PL022 control which some protocols do not want.
This commit intends to provide the spi chipselect control in software over
gpiolib interface. spi chip drivers can use the exported gpiolib interface to
define their chipselect through DT or platform data.
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
Reviewed-by: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Hi Grant,
This patch was earlier sent as part of drivers/pinctrl/spear directory and after
some discussion over mainline it is moved to gpio now. It is already reviewed by
Linus and Arnd, though they haven't given their Reviewed-by's.
.../devicetree/bindings/gpio/spear_spics.txt | 50 +++++
arch/arm/plat-spear/Kconfig | 1 +
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-spear-spics.c | 217 +++++++++++++++++++++
5 files changed, 276 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/spear_spics.txt
create mode 100644 drivers/gpio/gpio-spear-spics.c
diff --git a/Documentation/devicetree/bindings/gpio/spear_spics.txt b/Documentation/devicetree/bindings/gpio/spear_spics.txt
new file mode 100644
index 0000000..96c37eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/spear_spics.txt
@@ -0,0 +1,50 @@
+=== ST Microelectronics SPEAr SPI CS Driver ===
+
+SPEAr platform provides a provision to control chipselects of ARM PL022 Prime
+Cell spi controller through its system registers, which otherwise remains under
+PL022 control. If chipselect remain under PL022 control then they would be
+released as soon as transfer is over and TxFIFO becomes empty. This is not
+desired by some of the device protocols above spi which expect (multiple)
+transfers without releasing their chipselects.
+
+Chipselects can be controlled by software by turning them as GPIOs. SPEAr
+provides another interface through system registers through which software can
+directly control each PL022 chipselect. Hence, it is natural for SPEAr to export
+the control of this interface as gpio.
+
+Required properties:
+
+ * compatible: should be defined as "st,spear-spics-gpio"
+ * reg: mentioning address range of spics controller
+ * st-spics,peripcfg-reg: peripheral configuration register offset
+ * st-spics,sw-enable-bit: bit offset to enable sw control
+ * st-spics,cs-value-bit: bit offset to drive chipselect low or high
+ * st-spics,cs-enable-mask: chip select number bit mask
+ * st-spics,cs-enable-shift: chip select number program offset
+ * gpio-controller: Marks the device node as gpio controller
+ * #gpio-cells: should be 1 and will mention chip select number
+
+All the above bit offsets are within peripcfg register.
+
+Example:
+-------
+spics: spics at e0700000{
+ compatible = "st,spear-spics-gpio";
+ reg = <0xe0700000 0x1000>;
+ st-spics,peripcfg-reg = <0x3b0>;
+ st-spics,sw-enable-bit = <12>;
+ st-spics,cs-value-bit = <11>;
+ st-spics,cs-enable-mask = <3>;
+ st-spics,cs-enable-shift = <8>;
+ gpio-controller;
+ #gpio-cells = <2>;
+};
+
+
+spi0: spi at e0100000 {
+ status = "okay";
+ num-cs = <3>;
+ cs-gpios = <&gpio1 7 0>, <&spics 0>,
+ <&spics 1>;
+ ...
+}
diff --git a/arch/arm/plat-spear/Kconfig b/arch/arm/plat-spear/Kconfig
index f8db7b2..87dbd81 100644
--- a/arch/arm/plat-spear/Kconfig
+++ b/arch/arm/plat-spear/Kconfig
@@ -12,6 +12,7 @@ config ARCH_SPEAR13XX
bool "ST SPEAr13xx with Device Tree"
select ARM_GIC
select CPU_V7
+ select GPIO_SPEAR_SPICS
select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
select PINCTRL
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d055cee..b846f60 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -181,6 +181,13 @@ config GPIO_PXA
help
Say yes here to support the PXA GPIO device
+config GPIO_SPEAR_SPICS
+ bool "ST SPEAr13xx SPI Chip Select as GPIO support"
+ depends on PLAT_SPEAR
+ select GENERIC_IRQ_CHIP
+ help
+ Say yes here to support ST SPEAr SPI Chip Select as GPIO device
+
config GPIO_STA2X11
bool "STA2x11/ConneXt GPIO support"
depends on MFD_STA2X11
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 9aeed67..2699355 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_PLAT_SAMSUNG) += gpio-samsung.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SCH) += gpio-sch.o
obj-$(CONFIG_GPIO_SODAVILLE) += gpio-sodaville.o
+obj-$(CONFIG_GPIO_SPEAR_SPICS) += gpio-spear-spics.o
obj-$(CONFIG_GPIO_STA2X11) += gpio-sta2x11.o
obj-$(CONFIG_GPIO_STMPE) += gpio-stmpe.o
obj-$(CONFIG_GPIO_STP_XWAY) += gpio-stp-xway.o
diff --git a/drivers/gpio/gpio-spear-spics.c b/drivers/gpio/gpio-spear-spics.c
new file mode 100644
index 0000000..5f45fc4
--- /dev/null
+++ b/drivers/gpio/gpio-spear-spics.c
@@ -0,0 +1,217 @@
+/*
+ * SPEAr platform SPI chipselect abstraction over gpiolib
+ *
+ * Copyright (C) 2012 ST Microelectronics
+ * Shiraz Hashim <shiraz.hashim@st.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.
+ */
+
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+/* maximum chipselects */
+#define NUM_OF_GPIO 4
+
+/*
+ * Provision is available on some SPEAr SoCs to control ARM PL022 spi cs
+ * through system registers. This register lies outside spi (pl022)
+ * address space into system registers.
+ *
+ * It provides control for spi chip select lines so that any chipselect
+ * (out of 4 possible chipselects in pl022) can be made low to select
+ * the particular slave.
+ */
+
+/**
+ * struct spear_spics - represents spi chip select control
+ * @base: base address
+ * @perip_cfg: configuration register
+ * @sw_enable_bit: bit to enable s/w control over chipselects
+ * @cs_value_bit: bit to program high or low chipselect
+ * @cs_enable_mask: mask to select bits required to select chipselect
+ * @cs_enable_shift: bit pos of cs_enable_mask
+ * @use_count: use count of a spi controller cs lines
+ * @last_off: stores last offset caller of set_value()
+ * @chip: gpio_chip abstraction
+ */
+struct spear_spics {
+ void __iomem *base;
+ u32 perip_cfg;
+ u32 sw_enable_bit;
+ u32 cs_value_bit;
+ u32 cs_enable_mask;
+ u32 cs_enable_shift;
+ unsigned long use_count;
+ int last_off;
+ struct gpio_chip chip;
+};
+
+/* gpio framework specific routines */
+static int spics_get_value(struct gpio_chip *chip, unsigned offset)
+{
+ return -ENXIO;
+}
+
+static void spics_set_value(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct spear_spics *spics = container_of(chip, struct spear_spics,
+ chip);
+ u32 tmp;
+
+ /* select chip select from register */
+ tmp = readl_relaxed(spics->base + spics->perip_cfg);
+ if (spics->last_off != offset) {
+ spics->last_off = offset;
+ tmp &= ~(spics->cs_enable_mask << spics->cs_enable_shift);
+ tmp |= offset << spics->cs_enable_shift;
+ }
+
+ /* toggle chip select line */
+ tmp &= ~(0x1 << spics->cs_value_bit);
+ tmp |= value << spics->cs_value_bit;
+ writel_relaxed(tmp, spics->base + spics->perip_cfg);
+}
+
+static int spics_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+ return -ENXIO;
+}
+
+static int spics_direction_output(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ spics_set_value(chip, offset, value);
+ return 0;
+}
+
+static int spics_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct spear_spics *spics = container_of(chip, struct spear_spics,
+ chip);
+ u32 tmp;
+
+ if (!spics->use_count++) {
+ tmp = readl_relaxed(spics->base + spics->perip_cfg);
+ tmp |= 0x1 << spics->sw_enable_bit;
+ tmp |= 0x1 << spics->cs_value_bit;
+ writel_relaxed(tmp, spics->base + spics->perip_cfg);
+ }
+
+ return 0;
+}
+
+static void spics_free(struct gpio_chip *chip, unsigned offset)
+{
+ struct spear_spics *spics = container_of(chip, struct spear_spics,
+ chip);
+ u32 tmp;
+
+ if (!--spics->use_count) {
+ tmp = readl_relaxed(spics->base + spics->perip_cfg);
+ tmp &= ~(0x1 << spics->sw_enable_bit);
+ writel_relaxed(tmp, spics->base + spics->perip_cfg);
+ }
+}
+
+static int spics_gpio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct spear_spics *spics;
+ struct resource *res;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "invalid IORESOURCE_MEM\n");
+ return -EBUSY;
+ }
+
+ spics = devm_kzalloc(&pdev->dev, sizeof(*spics), GFP_KERNEL);
+ if (!spics) {
+ dev_err(&pdev->dev, "memory allocation fail\n");
+ return -ENOMEM;
+ }
+
+ spics->base = devm_request_and_ioremap(&pdev->dev, res);
+ if (!spics->base) {
+ dev_err(&pdev->dev, "request and ioremap fail\n");
+ return -ENOMEM;
+ }
+
+ if (of_property_read_u32(np, "st-spics,peripcfg-reg",
+ &spics->perip_cfg))
+ goto err_dt_data;
+ if (of_property_read_u32(np, "st-spics,sw-enable-bit",
+ &spics->sw_enable_bit))
+ goto err_dt_data;
+ if (of_property_read_u32(np, "st-spics,cs-value-bit",
+ &spics->cs_value_bit))
+ goto err_dt_data;
+ if (of_property_read_u32(np, "st-spics,cs-enable-mask",
+ &spics->cs_enable_mask))
+ goto err_dt_data;
+ if (of_property_read_u32(np, "st-spics,cs-enable-shift",
+ &spics->cs_enable_shift))
+ goto err_dt_data;
+
+ platform_set_drvdata(pdev, spics);
+
+ spics->chip.ngpio = NUM_OF_GPIO;
+ spics->chip.base = -1;
+ spics->chip.request = spics_request;
+ spics->chip.free = spics_free;
+ spics->chip.direction_input = spics_direction_input;
+ spics->chip.direction_output = spics_direction_output;
+ spics->chip.get = spics_get_value;
+ spics->chip.set = spics_set_value;
+ spics->chip.label = dev_name(&pdev->dev);
+ spics->chip.dev = &pdev->dev;
+ spics->chip.owner = THIS_MODULE;
+ spics->last_off = -1;
+
+ ret = gpiochip_add(&spics->chip);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to add gpio chip\n");
+ return ret;
+ }
+
+ dev_info(&pdev->dev, "spear spics registered\n");
+ return 0;
+
+err_dt_data:
+ dev_err(&pdev->dev, "DT probe failed\n");
+ return -EINVAL;
+}
+
+static const struct of_device_id spics_gpio_of_match[] = {
+ { .compatible = "st,spear-spics-gpio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, spics_gpio_of_match);
+
+static struct platform_driver spics_gpio_driver = {
+ .probe = spics_gpio_probe,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "spear-spics-gpio",
+ .of_match_table = spics_gpio_of_match,
+ },
+};
+
+static int __init spics_gpio_init(void)
+{
+ return platform_driver_register(&spics_gpio_driver);
+}
+subsys_initcall(spics_gpio_init);
+
+MODULE_AUTHOR("Shiraz Hashim <shiraz.hashim@st.com>");
+MODULE_DESCRIPTION("ST Microlectronics SPEAr SPI Chip Select Abstraction");
+MODULE_LICENSE("GPL");
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [Resend v6 PATCH 1/2] ARM: at91: atmel-ssc: add pinctrl nodes
From: Bo Shen @ 2012-11-16 6:03 UTC (permalink / raw)
To: linux-arm-kernel
Add pinctrl nodes for atmel ssc peripheral
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Resend:
Split one patch into two.
- one add pinctrl nodes
- one add pinctrl consumer
---
arch/arm/boot/dts/at91sam9260.dtsi | 18 ++++++++++++++++++
arch/arm/boot/dts/at91sam9263.dtsi | 36 ++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/at91sam9g45.dtsi | 36 ++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/at91sam9n12.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/at91sam9x5.dtsi | 32 +++++++++++++++++++++++++-------
5 files changed, 141 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 3164dcd..f9dc7db 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -217,6 +217,22 @@
};
};
+ ssc0 {
+ pinctrl_ssc0_tx: ssc0_tx-0 {
+ atmel,pins =
+ <1 16 0x1 0x0 /* PB16 periph A */
+ 1 17 0x1 0x0 /* PB17 periph A */
+ 1 18 0x1 0x0>; /* PB18 periph A */
+ };
+
+ pinctrl_ssc0_rx: ssc0_rx-0 {
+ atmel,pins =
+ <1 19 0x1 0x0 /* PB19 periph A */
+ 1 20 0x1 0x0 /* PB20 periph A */
+ 1 21 0x1 0x0>; /* PB21 periph A */
+ };
+ };
+
pioA: gpio at fffff400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x200>;
@@ -350,6 +366,8 @@
compatible = "atmel,at91rm9200-ssc";
reg = <0xfffbc000 0x4000>;
interrupts = <14 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
status = "disable";
};
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 96e0bc9..6e9a4ff 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -165,6 +165,38 @@
};
};
+ ssc0 {
+ pinctrl_ssc0_tx: ssc0_tx-0 {
+ atmel,pins =
+ <1 0 0x2 0x0 /* PB0 periph B */
+ 1 1 0x2 0x0 /* PB1 periph B */
+ 1 2 0x2 0x0>; /* PB2 periph B */
+ };
+
+ pinctrl_ssc0_rx: ssc0_rx-0 {
+ atmel,pins =
+ <1 3 0x2 0x0 /* PB3 periph B */
+ 1 4 0x2 0x0 /* PB4 periph B */
+ 1 5 0x2 0x0>; /* PB5 periph B */
+ };
+ };
+
+ ssc1 {
+ pinctrl_ssc1_tx: ssc1_tx-0 {
+ atmel,pins =
+ <1 6 0x1 0x0 /* PB6 periph A */
+ 1 7 0x1 0x0 /* PB7 periph A */
+ 1 8 0x1 0x0>; /* PB8 periph A */
+ };
+
+ pinctrl_ssc1_rx: ssc1_rx-0 {
+ atmel,pins =
+ <1 9 0x1 0x0 /* PB9 periph A */
+ 1 10 0x1 0x0 /* PB10 periph A */
+ 1 11 0x1 0x0>; /* PB11 periph A */
+ };
+ };
+
pioA: gpio at fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x200>;
@@ -262,6 +294,8 @@
compatible = "atmel,at91rm9200-ssc";
reg = <0xfff98000 0x4000>;
interrupts = <16 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
status = "disable";
};
@@ -269,6 +303,8 @@
compatible = "atmel,at91rm9200-ssc";
reg = <0xfff9c000 0x4000>;
interrupts = <17 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
status = "disable";
};
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index c40c3eb..63cf206 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -198,6 +198,38 @@
};
};
+ ssc0 {
+ pinctrl_ssc0_tx: ssc0_tx-0 {
+ atmel,pins =
+ <3 0 0x1 0x0 /* PD0 periph A */
+ 3 1 0x1 0x0 /* PD1 periph A */
+ 3 2 0x1 0x0>; /* PD2 periph A */
+ };
+
+ pinctrl_ssc0_rx: ssc0_rx-0 {
+ atmel,pins =
+ <3 3 0x1 0x0 /* PD3 periph A */
+ 3 4 0x1 0x0 /* PD4 periph A */
+ 3 5 0x1 0x0>; /* PD5 periph A */
+ };
+ };
+
+ ssc1 {
+ pinctrl_ssc1_tx: ssc1_tx-0 {
+ atmel,pins =
+ <3 10 0x1 0x0 /* PD10 periph A */
+ 3 11 0x1 0x0 /* PD11 periph A */
+ 3 12 0x1 0x0>; /* PD12 periph A */
+ };
+
+ pinctrl_ssc1_rx: ssc1_rx-0 {
+ atmel,pins =
+ <3 13 0x1 0x0 /* PD13 periph A */
+ 3 14 0x1 0x0 /* PD14 periph A */
+ 3 15 0x1 0x0>; /* PD15 periph A */
+ };
+ };
+
pioA: gpio at fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x200>;
@@ -331,6 +363,8 @@
compatible = "atmel,at91sam9g45-ssc";
reg = <0xfff9c000 0x4000>;
interrupts = <16 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
status = "disable";
};
@@ -338,6 +372,8 @@
compatible = "atmel,at91sam9g45-ssc";
reg = <0xfffa0000 0x4000>;
interrupts = <17 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
status = "disable";
};
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 7b644c5..b211da6 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -28,6 +28,7 @@
tcb1 = &tcb1;
i2c0 = &i2c0;
i2c1 = &i2c1;
+ ssc0 = &ssc0;
};
cpus {
cpu at 0 {
@@ -199,6 +200,22 @@
};
};
+ ssc0 {
+ pinctrl_ssc0_tx: ssc0_tx-0 {
+ atmel,pins =
+ <0 24 0x2 0x0 /* PA24 periph B */
+ 0 25 0x2 0x0 /* PA25 periph B */
+ 0 26 0x2 0x0>; /* PA26 periph B */
+ };
+
+ pinctrl_ssc0_rx: ssc0_rx-0 {
+ atmel,pins =
+ <0 27 0x2 0x0 /* PA27 periph B */
+ 0 28 0x2 0x0 /* PA28 periph B */
+ 0 29 0x2 0x0>; /* PA29 periph B */
+ };
+ };
+
pioA: gpio at fffff400 {
compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x200>;
@@ -249,6 +266,15 @@
status = "disabled";
};
+ ssc0: ssc at f0010000 {
+ compatible = "atmel,at91sam9g45-ssc";
+ reg = <0xf0010000 0x4000>;
+ interrupts = <28 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+ status = "disable";
+ };
+
usart0: serial at f801c000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf801c000 0x4000>;
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 1cb26c28..df84f39 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -88,13 +88,6 @@
interrupts = <1 4 7>;
};
- ssc0: ssc at f0010000 {
- compatible = "atmel,at91sam9g45-ssc";
- reg = <0xf0010000 0x4000>;
- interrupts = <28 4 5>;
- status = "disable";
- };
-
tcb0: timer at f8008000 {
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf8008000 0x100>;
@@ -214,6 +207,22 @@
};
};
+ ssc0 {
+ pinctrl_ssc0_tx: ssc0_tx-0 {
+ atmel,pins =
+ <0 24 0x2 0x0 /* PA24 periph B */
+ 0 25 0x2 0x0 /* PA25 periph B */
+ 0 26 0x2 0x0>; /* PA26 periph B */
+ };
+
+ pinctrl_ssc0_rx: ssc0_rx-0 {
+ atmel,pins =
+ <0 27 0x2 0x0 /* PA27 periph B */
+ 0 28 0x2 0x0 /* PA28 periph B */
+ 0 29 0x2 0x0>; /* PA29 periph B */
+ };
+ };
+
pioA: gpio at fffff400 {
compatible = "atmel,at91sam9x5-gpio", "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x200>;
@@ -266,6 +275,15 @@
status = "disabled";
};
+ ssc0: ssc at f0010000 {
+ compatible = "atmel,at91sam9g45-ssc";
+ reg = <0xf0010000 0x4000>;
+ interrupts = <28 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
+ status = "disable";
+ };
+
usart0: serial at f801c000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf801c000 0x200>;
--
1.7.9.5
^ permalink raw reply related
* [Resend v6 PATCH 2/2] ASoC: atmel-ssc: add pinctrl consumer
From: Bo Shen @ 2012-11-16 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353045837-19474-1-git-send-email-voice.shen@atmel.com>
Add pinctrl consumer for atmel ssc peripheral
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Resend:
Split one patch into two.
- one add pinctrl nodes
- one add pinctrl consumer
---
drivers/misc/atmel-ssc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index a769719..3b3d0e0 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/pinctrl/consumer.h>
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
@@ -131,6 +132,13 @@ static int ssc_probe(struct platform_device *pdev)
struct resource *regs;
struct ssc_device *ssc;
const struct atmel_ssc_platform_data *plat_dat;
+ struct pinctrl *pinctrl;
+
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ dev_err(&pdev->dev, "Failed to request pinctrl\n");
+ return PTR_ERR(pinctrl);
+ }
ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL);
if (!ssc) {
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox